创业公司的定义 把服务器数量在千台以内(如果存在服务端),或者业务没有爆发过或者是长时间没有爆发过的公司,叫做创业公司。
朴素技术观的定义 有很多看上去很美好的技术,背后都有很多对应的很残酷的事实,在一个创业公司许多选择给你,你可以使用当前最炫的技术,也可以使用团队最擅长的技术。朴素世界观,是指所有选择使用团队最擅长技术的一种观念。
语言 语言之争是最没品了,这里不争哪种语言好哪种语言坏。
这里有一个办法来选择语言:所有团队成员的简历中,出现最多的一种语言为标准。
例外情况:团队成员中有一位大拿,是某门语言的泰斗,不说在国际上,在国内也要有领头羊的成绩。印象中在创业中大量使用GO语言的许式伟大侠是例外中最典型的一个,不过看看人家的成绩,已经把GO摸的一清二楚了。
反例:太多。
以下条件满足可开启反例模式:
1.至少一人完全理解整个语言的语法
2.至少一人完全理解语言精髓
3.至少一人完全掌握此语言常见debug工具
4.至少一人在一个规模较小应用成功使用
存储 这里主要讲服务器的存储。
如何选择:mysql+memcached至少在twitter、renren.com、taobao、qq、sina、baidu……等公司大量使用,如果你团队成员一个都不是来自这些公司,那大胆地用吧,用死也用不出什么毛病来。当然了,十分需要在业务爆发时找到一位可靠的mysql dba,这里要提一下人人网的创始员工DBA刘启荣大侠,引用一句前老板的话:×××无出启荣之右也。
反例:此处省去创业团队名字,有史可考。当年KV十分火爆,某兄弟对cassandra十分感冒,于是在整个系统初期设计时全部使用了这玩意。后来,开始市场宣传的时候,这玩意儿就是不行了,一行人接连多夜赶制回mysql。
以下条件满足可开启反例模式:
1.使用cassandra要理解全篇dynamo文档所写,完全掌握RWN,完全熟知虚拟分区作用,清晰知道cassandra在分区上偷工减料所带来的影响。
2.团队成员里有一个人完全理解了这个要使用的东西的源代码。这里要提一下张宴大侠,他长年研究tt代码,在使用上已经很有一手,所以有他在的地方,用tt完全没有问题。如果国内有一个人冒出来说自己对cassandra代码长年研究,我一定不相信,因为这些项目代码行数已经超过一个人快速理解的能力,当你看完的时候,新的版本又出来了。
3.很多单独的解决方案,因为代码量不大,完全可以从零开始花人力搞定它,像redis,在新浪被用得很多,到了你的创业公司,不一定可以搞定,因为什么呢,你需要一个完整的人先摸透它的习性。摸透了习性的小项目,完全可以先在小项目上使用。
框架与分工 框架的作用在于更加利于分工。
以服务端为例,java如果你选择了人人网切切王开源的rose框架的话,spring的好处一应俱全,而且因为其天生的restful的好处,最小粒度可以以api为分工。这样,在一个团队内部,任何人完全可以修改任何人的代码,因为是使用同一个框架,同一种思路,写出来的代码不会是完全两样的。php如果你选择的ZF之类的,以controller为单位的MVC模型一下子就定义了你的项目,同样也可以做到成员随意维护任意模块。
如何选择:框架的选择只看历史。如果历史上有框架可选,那一定是选择验证过的。如果没有,那尽可能地花时间提炼框架。
反例:框架似乎人类写代码的常规总结行为,即便再烂的项目,在局部去看也一定会有一些框架性的代码存在。反例要说说discuz1.0以前的代码,感觉完全是应届生所为,想到哪里写到哪里,和放牛一样,维护基本上不可能。
以下条件满足可开启反例模式:
1.android等客户端开发暂时还没有特别好的框架性的东西,不过android本身就是一个大框架,业务代码的框架需要自己提炼。
2.非常非常小的项目,瞬间写完要上线。
3.项目只用一次。
4.救火。
大项目与小项目 反例:从超级大公司出来的工程师,特别是企业开发的同学,特别喜欢一个超级大的项目,把所有的功能都包括在里面。所有人一起,天天折腾这个trunk,动不动的我踩着你的脚了,你压着我的手了。
正例:换到互联网模式,所有项目能拆则拆,越扁平越好,每个部分有一个指定的master,主要负责此项目的稳定。这实际在开源界早就这样干了。实际操作中,只要能够找到一个合适的master,就可以拆。
没有任何条件可以开启反例模式。
流程与管理 这个标题太大,分小来说。主要包括代码版本管理、依赖管理、代码制度、项目发布流程。这里没有反例,只讲经验。
版本管理:目前大多数人还在使用svn,但是git真的非常非常好用。pro git book只需要一个晚上的仔细阅读,就一定可以学会。实际学习成本很低了,一个创业团队,这点学习能力都没有的人,赶紧离开你的团队吧。
依赖管理:java大多已经使用maven,老早的ant带一堆jar包的形式已经落后了,赶紧换。php的依赖管理一直都很弱,不过有人参考ruby搞了一个composer,可以试试,也许可以帮助改进。
代码制度:什么样的代码才可以checkin/merge master?一般的标准为:跑过所有的unit test、master维护者或者团队成员review通过。
项目发布流程:项目立项到项目上线,划分N个小阶段,实施scrum或者变体的scrum,但是一个原则就是任何一个阶段的不确定,都会在后面的阶段里放大,小步快跑才是正确的节奏,有时候宁愿不要一些功能,也一定要先发出来。