-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
134 additions
and
0 deletions.
There are no files selected for viewing
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,131 @@ | ||
# 如何从零开始设计一款好的技术开源产品 | ||
|
||
> 本文发表时间:2018 年 7 月 13 号 | ||
> 分类于[技术管理](../../index/manager.md) | ||
## 前言 | ||
技术男擅于想象也擅于幻想,类如在全球最大同性交友平台上,打造你的最强兵器,出尽风头,博得更多的同性友谊。那么问题来了,那么大的用户群体,你怎么才能脱颖而出,笔者自己也思考了很久,总结出一套可行的方案。 | ||
|
||
## 七种兵器 | ||
> 剑之灵动,刀之雄厚,七种兵器如果选择就够侠者喝一壶了。同时用千年寒铁和普通铁矿打造出的兵器肯定是云泥之别的,但是千年寒铁肯定是极其稀有的。 | ||
### 各种XXX攻略 | ||
君不见最近Github上Star上涨很快的大部分都是XXX攻略,例如架构师知识图谱,面试知识图谱等等,简直是开挂般的存在,但是本文的标题是‘技术开源产品’,因此攻略显然不是产品,这里就排除在外了。 | ||
|
||
### 什么是具有可行性的产品 | ||
拥有特定的目标和用户群体,能产生出相对独一无二的价值,就可以认为是一款具有可行性的产品了,这里有三个对象:产品目标、用户群体、产品创新,下面我们来一一分析,该怎么选材 | ||
|
||
### 用户群体 | ||
因为咱们已经是技术开源产品了,用户群体无非就是开发或者测试,但是考虑到github上绝大部分都是开发,因此排除测试用户,至于开发,可以进一步细分为前端、后端、运维,产品对应的用户群体越大,自然收获的star会更多。 | ||
|
||
众所周知,前端的开发群体是最多的,因为作为开发或多或少都要会一些前端。在前端领域,javascript的开源产品,获取star的速度明显是鹤立鸡群,藐视一切英雄好汉的,因此如果你具有较好的js和nodejs水准,就可以倾向于打造面向js用户群体的产品了。 | ||
|
||
再来谈谈后端,后端又分为面向特定领域:云计算、区块链等和面向特定语言:python、go、java、rust等,那该怎么选择呢? | ||
|
||
首先是,一定站在风口上,猪都能起飞,何况咱们这些高智商人群,因此特定领域的风口目前来看就是k8s+docker生态,区块链生态,机器学习生态等,至于特定语言,go和rust是有很大优势的,因为这两门语言目前在开源社区非常受欢迎,附带着相关的库也会变得容易获得青睐。 | ||
|
||
**总结:尽量选择处于技术风口的技术领域和编程语言,让你的目标群体放得更大** | ||
|
||
|
||
### 产品目标 | ||
产品的目标首先来说就是产品的类型 | ||
- 一站式平台 | ||
- 工具类服务 | ||
- 编程框架库 | ||
|
||
其次就是产品难易度,这个也很重要,你要充分预估你的时间能完成的项目是什么样的?相对简单的产品,同时还更容易让社区中的同性伙伴们参与进来,但是换来的代价就是你面对的可能是一片红海,这个很自然,简单的东西做得人自然更多。 | ||
|
||
**总结:首先根据自身的时间/技术能力选择一个最适合的产品类型,同时要考虑到两点: 未来社区的参与度和用户群体的潜在大小** | ||
|
||
### 产品创新 | ||
要知道,任何一个产品都不太可能是完全创新,因此和你的产品重叠的产品可能已经存在很多,那么你的产品凭什么突围而出呢?是时候祭出我们的尚方宝剑了:微创新。 | ||
|
||
微创新的概念这里就不谈了,我谈谈几个点: | ||
- 功能上的创新:完善、优化等 | ||
- 使用体验方面的创新:举个例子,区块链火了后,P2P网络也迅速火了,这个时候ipfs把自己的p2p技术栈抽象了出来,形成了一个库:libp2p,但是!实在是太tmd不好用了,谁用谁熬夜! 这个时候,另外一个主打产品体验的p2p库横空出世,简直完爆libp2p,尽管功能上还不完善,稳定性上也达不到生产级别,但是在可以预期的未来,这款产品在市场上肯定要大火的 | ||
- 生态的创新:有些产品自成生态,啥都自己来;有些产品选择三方生态,设定好基本的产品形势,让大家都能参与进来 | ||
- 文档和官网的创新:这个很重要!有好的官网和文档,对比不好的,完全两码事,对了你还需要一个和产品名字相同的域名,看上去更专业 | ||
- 可维护性的创新:有些产品天生就难以维护,让后来者欲生欲死 | ||
|
||
**总结:一定要考虑清楚产品的微创新是什么,通过创新给用户带来的价值是什么?千万不要自我觉得良好** | ||
|
||
|
||
#### 用户思维 | ||
如果你是XX用户,你需要什么功能;如果你是一个小白用户,该怎么使用这款产品。简而言之,要换位思考,换位思考这个词大家都知道,但是又有几个人真正知道,你做的产品是为你自己虚拟的用户打造的还是为真是用户打造的?值得深思。 | ||
|
||
|
||
|
||
## 独孤九剑 | ||
> 武器在手,天下我有,哈哈!等等,大侠,你这是?野球拳??! | ||
对于绝大多数程序员来说,想到了做什么后,紧接着就是简单思考一番,就是直接开撸了,但是大侠们,你们是不是略过了很重要的一步?你还没有学剑谱呢!因此产品设计是极其重要的一步,否则做到后面,重构或者目标偏移都是很正常的事情。 | ||
|
||
### 设定产品价值观(产品哲学,英文Philosophy) | ||
大家应该都听说过阿里的六脉神剑价值观:客户第一、团队合作、拥抱变化、诚信、激情、敬业。 | ||
|
||
从中可以看出,价值观对于公司行为和员工行为的导向有着极其重要的作用。同样的,产品价值观也是如此,我们做产品时,任何需求的变动,任何体验的优化都应该在产品价值观的范畴之内。 | ||
|
||
例如一个新出的小众语言pony,它的价值观就很简单: | ||
> 让事情能够简单、高效的完成 | ||
根据这个价值观,它分解了几个子价值观,一起来看看: | ||
- 正确性 | ||
事情能完成的前提条件是它是正确的。因此一切功能特性的添加和修改首先要保证的就是正确性 | ||
- 性能 | ||
除了正确性之外,最重要的就是性能。因此有损性能的语言特性和功能均不予以添加 | ||
- 简洁 | ||
因为简洁只排到了第三名,因此为了正确性和性能是可以牺牲简洁性的,与此相比,另一门很流行的语言go,就把简洁性排在了性能前面,因此为了简洁可以稍微牺牲性能 | ||
|
||
从上面看得出,产品价值观会在方方面面指导我们的产品特性和功能该怎么添加、修改,一旦了有边界,产品就会按照既定的轨道前行,最终很好的到达终点。 | ||
|
||
### 在价值观基础上分解产品总的目标,形成几个子目标 | ||
例如,要开发一款消息平台,目标用户是外部的用户,包括了浏览器、移动客户端、物联网客户端等,那么这就是我们的产品总目标,该怎么分解为子目标呢? | ||
|
||
**注意!这里是产品目标,尽量不要带上技术色彩** | ||
1. 我们需要提供外部用户连接产品并发送和消费消息的能力 | ||
2. 消息应该是有序的,可持久化的,可从任意位置开始遍历 | ||
3. 消息应该尽可能快的送到用户手中 | ||
4. 要支持单播、广播等方式,让消息推送的策略更加灵活 | ||
5. 消息要能被追踪,通过消息ID可以对消息进行可视化 | ||
6. 完善的数据统计 | ||
7. 通过管理后台进行管理操作 | ||
8. 需要做业务隔离,业务之间彼此互不影响 | ||
|
||
这些产品目标加起来,就能形成一个可用的消息平台了,但是到了这一步我们无法进行开发,同时这些需求也太大了,因此下一步,我们需要根据这些目标对产品做一下技术架构。 | ||
|
||
### 技术架构 | ||
整体架构可以大概分为三层,客户端层,服务器逻辑层,数据存储层。 | ||
|
||
外部用户要连接产品并进行操作,就需要提供通信协议和客户端SDK | ||
|
||
#### 通信协议 | ||
然后客户端和服务器通信肯定要有一套协议,按照目前的标准,选择MQTT是合理的选择。MQTT是应用协议,那网络协议用什么承载呢?TCP、Websocket、Http?按照我们的使用场景,可能都需要支持。 | ||
|
||
#### 客户端SDK | ||
再来看客户端,我们是否需要SDK?因为MQTT协议本身表达能力有限,如果要做复杂的逻辑,可能需要基于MQTT封装一层自定义协议,那这个时候就需要客户端的SDK,常用的有安卓、IOS、Javascript、Go、python等。 | ||
|
||
消息需要有序、持久和遍历,那么就需要提供数据存储层,同时我们还是一个开源项目,在产品价值观中,性能肯定是很靠前的,因此我们要重视性能。 | ||
|
||
### 数据存储层 | ||
这个时候选择mysql等关系数据库就不慎可靠了(注意!如果是给公司开发的内部项目,用户较少,是可以考虑Mysql的,更加方便);hbase很有名,性能也还可以,还能水平扩展,但是维护成本高,遇到问题未必hold住。因此Nosql成为比较自然的选择,例如foundationDB和cassandraDB。同时,为了测试方便,而且有些用户不需要持久化消息,那需要提供一种基于内存的存储模式。 | ||
|
||
|
||
剩下的功能,包括后台管理都应该在服务器逻辑层了,具体得就不再细讲了,大家有兴趣可以自己私下尝试,或者看看[MeQ消息平台](http://meq.io) | ||
|
||
|
||
**对于产品价值观和目标、技术架构,我们可以写到产品的首页Readme.md中,让所有用户看到。** | ||
|
||
### 设定里程碑 | ||
有了产品目标、技术架构还不够,还需要为开发过程设定里程碑,在某个阶段我们都应该提供一个可交付的产品,要有详细的产品交付目标和日期,因此这些就是一个一个里程碑,对应敏捷项目管理里,类似一个一个迭代。 | ||
|
||
然后把这些里程碑输入到项目issues中的milestone里,设定好截止日期。 | ||
|
||
### 需求分解 | ||
最后,就是需求分解了,基于产品目标和技术架构,分解出一个一个详细的需求,每个需求都不要太大,以1-5天可以完成为准,然后把这些需求录入到issues中,再指定到具体的里程碑。 | ||
|
||
至此,我们的产品就完成了设计的过程,剩余的就是开发了,相信这个也是大家最熟悉的部分,就不赘述了。 | ||
|
||
|
||
|
||
## 总结 | ||
我相信,任何事务都有方法论可以依循,就看我们能不能根据实际情况,正确的去发现和运用这些方法了,而且有了方法后,一定要落成文档,让更多的人可以复制你的经验,更快的走向成功。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters