我之前写过一篇叫《加班与效率》的文章,从概念上说了一些我对“效率”的认识,但是那篇文章趋于概念化,对于一些没有经历过这样的环境的同学来说,可能会觉得太抽象了。很早以前就想写一篇更具体一点的,可执行的文章与《加班与效率》这篇文章相辉映。
但是我遇到了一些思维方式上的麻烦——我讲的总是从我的经历背景出发,没有从其它人的经历背景来讲。这就好像,我在酷壳里说了很多东西(比如:专职的QA,Code Review很重要,编程年龄,创业的,Rework的……),有好些人觉得是不可能甚至太理想,其实我说的那些东西都是实实在在存在的,也是我所经历过的。于是,不同的经历,不同的环境,不同的眼界,造成了——有些人不理解我说的,而我也不能理解他们所说的。
所以,过去的这段时间我一有机会就找一些人交流并观察一些身边的事情,并去试着跟从和理解那些我不能理解的东西。现在觉得差不多了,所以,写下了这篇文章。(但越是去理解对方,我就越坚持我的观点,所以这篇文章可能还是会出现鸡同鸭讲的情形,无所谓了)
本文不讨论任何业务上的效率问题,只讨论软件开发或是软件工程中的效率问题。虽然产品和业务上的效率问题是根本,但是因为本文不是拉仇恨的,我也不想混在一起谈,所以请原谅我在这里先说开发团队的,以后重新开篇文章专门谈产品和业务的。
我下面会罗列几个非常典型的开发方式——软件开发中的“锁”,接力棒式软件开发,保姆式软件开发,WatchDog软件开发,故障驱动式软件开发。
软件开发中的“锁”
如果你搞过并发编程,你一定知道什么是“锁”,锁就是用来同步和互斥。我发现有好些开发部门里的各个开发团队间存在很多锁。比如:
我上面并非瞎扯,这都是事实。我们可以看到,
有时候,我们会觉得分工和分模块是产生效率的前提,但是实际情况并不是这样。我们也可以看到,所谓的“分工”被彻彻底底的滥用了。他们把“分工”当成了永远只干一件事的借口。
【解决方案】
一个程序员应该能够掌握多个语言,也能够负责多个模块甚至不同的职责。如果一个程序员觉得多学习一门语言,多掌握一个模块是件很困难的事,那么这个程序员本质上是不合格的。
“接力棒式”软件开发
在有各种“工作锁”的软件开发团队里,一般都无法避免“接力棒式”的开发。也就是说,底层的C程序员干完了,交给上层的Java程序员,然后再交给更上层的前端程序员,最后再交给运维人员。这就是接力棒式的开发。
而且,更糟糕的是,如果在引入了软件流程下,这种“接力棒的方式”真是会把你搞崩溃的。比如下游团队开发一个月,交给QA测试一个月,再交给运维分 步上线一个月,然后,上游团队拿到下游开发的API后开发一个月,再交给自己的QA测试一个月,然后再交给自己的运维上线一个月,于是,半年就这样过去 了。这是一个由一个一个小瀑布叠出来的一个大瀑布。
哦,你会说,这个好办啊,上下游不会先商定好接口么?然后做并行开发么?是的,这是其中的一个优化方式,但是需要很好的接口设计。但是,在实际过程中,你会发现(这时我并非信口开河,我说的都是事实),
【解决方案】
我以前写过一篇叫《IoC/DIP其实是一种管理思想》,对于这种接力棒的方式,应该反过来,如果业务应用团队是A团队,那B/C/D团队应该把自己的做成一个开发框架也好,服务化也好,让应用团队自己来接入。比如:前端做好一个前端开发框架,PE做好一个运维开发框架、各种工具,共享模块团队做好开发框架,让应用团队自己来接入,而不是帮他做。你会发现,在这么多团队各自P2P勾兑出来的很随意的接口的所带来的成本已经远超过一个统一标准的协议。
“保姆式”软件开发
所谓“保姆式”软件开发就是——我只管吃饭,不管做菜洗碗,就像——衣来伸手,饭来张口的“小皇帝”一样,身边有一堆太监或宫女,不然生活不能自理。这种情况经常见于开发和测试,开发和运维间的关系。很多公司,测试和运维都成了开发的保姆。
我就能看到,很多开发快速写完代码后基本上都不怎么测试就交给QA去测试了,QA一测,我草,各种问题,而只会做黑盒的QA并不能马上就能确定是代 码的问题还是环境的问题,所以还要花大量时间排除不是环境问题,才给开发报BUG。很多问题,可能只需要做个Code Review,做个单测就可以发现了,硬要交给QA。运维也是一样的,开发出来的软件根本就没有考虑什么运维的东西,因为有运维人员,所以我才不考虑呢。
这和我们带孩子的道理是一样的,对于孩子来说,如果父母帮孩子做得越多,孩子就越觉得理所应当,就越不会去做。
“保姆式”开发一般会进化成“保安式”开发。
就这样,你不行,我找人来看着你,看你的人不行,我再找人来看着看你的人……层层保姆,层层保安。于是,你就会发现,团队或部门里的人员越来越多,你整天都在开会,整天都在互相解释,互相争吵,会扯淡的人越来越多。那还有个屁的效率。
【解决方案】
1)不要招只会写代码的“码农”,要招懂“需求”,注重“软件工程”和“软件质量”和“软件维护”的“工程师”。
2)最好的管理,不是找人来管人,而是自己管自己。
3)组织和团队中支持性工作的人越少越好,最好不要。
4)服务化。我服务于你并不代表我要帮你干活,而是代表——我要让你干活干得更爽。
运维要用“云服务”的思路去做。如果一个公司内的运维团队开发出一堆工具,让做应用开发 团队可以很容易地申请机器、存储、网络、中间件、安全等资源,并很容易管理、监控和部署应用,并提供运维资询。而不是帮应用开发团队干活擦屁股当保姆。那 么,这个公司就会不经意地做出一个云计算平台来了。
“WatchDog式”软件开发
什么是WatchDog?就是说——为了解决某个系统的问题,我要用一个新的系统去看着它。
做加法谁不会?就不想去简化一样系统吗?就不能不拆东墙补西墙么?这些了系统加的越来越多,我看你以后怎么运维。
一开始没有想清楚就放到线上,然后,出了故障后,也无法重新设计和重新架构,只能以打补丁地方式往上打,这就好像一个本来就有缺陷的楼没有盖好,你要拆了重盖是不可能的,也只能不停地打补丁了。字是一只狗,越描越丑。
【解决方案】
1)设计想好了再做,多评估几个设计没坏处,简化,简化,简化。
2)残酷无情地还债,就算是CEO来了,也无法阻止我还债的脚步。
“故障驱动式”软件开发
WatchDog式的软件开发通常来说都是“故障驱动式”软件开发的产物。这种开发方式其实就是在表明自己智力和能力的不足。以上线为目的,上了线再说,有什么问题出了再改。
上面的老大或是业务方基本上会说,没关系,我们不一开始并不需要一个完美的系统,你先上了再说,先解业务的渴,我们后面有时间再重构再完善。而有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的。
我同意逐步迭代以及架构演化论,但是,我觉得“系统迭代说”和“架构演化论”被彻彻底底地成为那些能力有限甚至不学无术的人的超级借口。
你们有没有搞错啊?你们知道什么叫迭代,什么叫演化吗?你们知道,要定位一个线上的故障需要花多大的力气吗?你们知道,随随便便去应付局部上你会快,但总体上来说你会慢。
虽然,我看到那些系统在一个又一个的故障后得到一点又一点的改善,但是我想说,为什么一开始不认真不严谨一点呢?我从来就没有见过一个精良的系统是 靠一个一个的故障和失败案例给堆出来的,就算是Windows 95/98这样史上最烂的操作系统,如果没有设计精良Windows NT的补位,Windows也早玩完了(看看IE的下场就知道了)。
【解决方案】
1)基础知识和理论知识非常重要。多多使用已有的成熟的方案是关键。
2)对技术要有一颗严谨和敬畏的心。想清楚了再干,坚持高标准,Design for failure! 很多事情都急不得。
其它开发方式
其实,这样的事情还有很多。比如:
1)配置管理上的问题。对于源代码的配置管理,其实并不是一件简单的事情。配置管理和软件和团队的组构的结构非 常有关系。我看到过两种非常没有效率的配置管理,一种是以开项目分支的方式来做项目,同时开很多分支,分支开的时间还很长,导致merge回主干要花大量 的时间去解决各种冲突,另一种是N多的团队都在一个代码库中做修改,导致出现很多复杂的问题,比如某团队的改动出现了一个bug,要么所有的团队的功能都 得等这个bug被修复才能被发布,要么就是把所有的改动回滚到上一个版本,包括其它团队开发的功能。很明显,软件模块的结构,软件的架构,以及团队的组织 形式都会严重影响开发效率。
2)人肉式的软件开发。大多数的软件团队和主管都会用“人手不够”做为自己开发效率不够的借口,而大多数故障发生的时候,都会使用更重的“人肉流程”来弥补自己能力的不足。他们从来没有想过使用“技术”,使用更“聪明”的方式来解决问题。
3)会议驱动式开发。人多了,团队多了,想法也就多了,沟通也就多了,于是需要不停得开会开会开会。
总结一下
综上所述,我有如下总结:
1)软件工程师分工分得越细这个团队就越没效率,团队间的服务化是关键的关键。不管是从语言上还是从软件模块上的人员分工,越细越糟糕。服务化不是我要帮你做事,而是我让你做起事来更容易。
2)你总需要在一个环节上认真,这个环节越往前就越有效率,越往后你就越没效率。要么你设计和编码认真点,不然,你就得在测试上认真点。要是你设计、编码、测试都不认真,那你就得在运维上认真,就得在处理故障上认真。你总需要在一个地方认真。
3)“小而精的团队”+“条件和资源受限”是效率的根本。只有团队小,内耗才会小,只有条件或资源受限,才会逼着你去用最经济的手段做最有价值的事,才会逼着你喜欢简单和简化。
4)技术债是不能欠的,要残酷无情地还债。很多事情,一开始不会有,那么就永远不会有。一旦一个事情烂了,后面只能跟着一起烂,烂得越多,就越没有人敢去还债。
5)软件架构上要松耦合,团队组织上要紧耦合。
6)工程师文化是关键,重视过程就是重视结果。只重视结果的KPI等同于“竭泽而渔”和“饮鸩止渴”。