公司发展过程中的软件质量管理

创业初期，公司的核心资产首先是人，然后是现金，最后才是代码，因为前期来说能搞出东西才是最实在的；
创业中期，公司的核心资产首先是现金，然后是代码，最后才是人，因为活下去才是最重要的，如果代码没有管理好，最后也容易死掉；
创业后期，公司的核心资产是文化，我理解为各种原则，什么该做什么不该做，原则可以规划代码，可以规范员工做事方式，也可以尽可能地保护员工；原则因为足够简单，所以容易传承，随着公司做大，最终形成企业文化；

风口的本质

风口的本质是资本跑马圈地。

前几年独角兽企业满天飞，资本市场日益膨胀。互联网圈流行雷总说的一句话：“风口过来，猪都能飞”；在那个时候，身边的人张口一个项目，闭口一轮融资。在当时的人们看来不去创业，不去拉投资，似乎就显得很傻。

当然，那个时候我也随大流去创业，几年前的那会，我们做的是一个智能硬件的项目，在当时的我们看来，项目看起来蛮靠谱的，最后当然是黄了。黄的原因有很多，但是总结起来也就那么几点：定位、团队、资本；

自身能力肯定是一个大问题，因为当时也才毕业一年，自己也算不上大神级别的人；但是这不是最根本的问题，根本问题我觉得还是团队定位和项目定位的问题。团队的定位错在一开始想挣大钱，而项目定位错误在主要负责人急于挣钱，而那个项目需要资本的完全投入才能快速做成；

经过那件事情之后，我开始注意培养自身能力，我也慢慢看到所谓风口的本质不过是一场资本的游戏；现在的我看来，既然是资本游戏，自然是有资本的人才能玩的转的，谁的资本大，资源多，那这场游戏的胜率就大很多，至少相对于没有资本的人来说是这样；很多草根跑去跟大佬抢肉吃，一开始就错了；更有一些人失败了埋怨大环境，埋怨资本家，真的没必要，草根嘛，能活下去就不错啦，然后慢慢把事情做好，总能够吃到一点肉；当然也有跑偏的，我有个同学，草根出身，一开始想着挣大钱，一开始搞了个小公司，虽然挣钱，但是他挣得不多，那点钱距离他的理想差太远了，于是他奋发图强，最后终于挣到了大钱，只不过他干的是套路贷，去年作为头号进去了；

那草根不能有远大抱负了吗？也不是，只不过现在和以前世道变了；以前草根只要敢拼敢闯，借钱承包个煤矿，承包个工程，指不定就发迹起来了；现在的挣钱的大项目基本都被资本盯上了，包括灰色和黑色的，大资本家们也整天在盘算怎么挣大钱，对于草根来说，基本就没有什么优势了；草根的出路在哪里？与龙共舞或者扎根底层才是更好的出路；

意识到这点后，我老老实实找了个公司上班，用心的工作和复盘，在公司的发展中透过公司遇到的问题看背后问题的本质；因为对于我这种草根来说，只有扎实的研究某个细分的，前期不需要大量资本注入的领域，才能真正做成事；

风口上成立的公司

我自己是15年毕业的，那就从15年讲起吧。15年那一会正好是移动互联网风生水起的时代，也是万众创业大众创新的时代，那个时候聊得最火的一切和资本有关，就好像那个时候资本突然变得不要钱，楼市，股市，创业，融资，各种各样的口号和新词重出不穷，搞得好像不懂几个新词就融不进当时的深圳一样。

我自己搞安卓开发的，当时印象最深的是随便一个培训出来的工资都很高，我当时是在大学时候跟着老师做项目，心想着怎么着也应该比培训出来的高。实际上并没有，当时我特别羡慕那些人，水平不怎么样但是工资却很高（当然后来很多都因为干不下去转行了）；安卓开发在当时有一个很大的缺口，很多传统公司急需转行，好多是瞎转，各大媒体鼓吹一句口号：不转行等死转行找死；

后来我才明白，那只是媒体贩卖焦虑的一种方式，就和我们现在看到的各种公众号和新闻媒体鼓吹的一样一样的，那些随便转行的小公司们，东搞搞西搞搞，把自己的老本一点点赔进去了，也没见激起一个水花；最后不得不大规模裁员，然后沉下心来思考下一步怎么走；

前面说的这类公司占据了转型的的大都数，还剩下一些理智一些的老板没有瞎转型，只是在自己的领域往移动端云端扩展；这类老板做事谨慎，更容易给人靠谱的感觉；既然是试水，自然是采用一步步试错，小步迭代，快速疾走的方式，一步一步的挨到了现在；

有人把15年到现在的各行业发生的大事件叫做洗牌，我更加愿意理解成为资本诸侯跑马圈地的过程，因为洗牌的话会重新分配，而实际上现在的小公司如果没有依靠在什么系上真的很难活下去，哪怕是一些真正做实事的公司，如果没有加入某个派系，基本也都艰难的活着；

熬过来的小公司

在资本肆虐的年代，人才也更加愿意往更高的地方流，对于小公司来说，能够找到那么一两个人才的，实属万幸；在我熟悉的移动开发领域，基本是这样的：

项目初期

首先成立一个移动开发部，然后招一个价值观相近肯出力的组长，然后由组长招一批能干活的下属，然后这个项目组就算成立了。由于是新项目，老板给的预算不会很高，因此找过来的员工也不会有很强的能力，项目组长也不见得有多强的能力，但是有一点是肯定的，这个项目组能正常运行起来；

为了节省成本，这个时候一般是没有很多繁琐的流程，至于项目经理，产品经理，技术总监，架构师可能都是同一个人。这样的好处当然是减少了一些沟通成本，而且在当时看来应该是非常优化的结果。

这个时候项目组负责人为了让上头尽快看到效果，可能会通过缩短开发周期的方式加快产品功能的开发，也就是我们常说的堆功能；其实对于老板来说他也只能看到功能，因此这个时候老板听说又开发出来一个新功能，那自然是相当开心的；

项目中期

项目开发进入深水区，一些麻烦的问题开始显现，由于前期质量管控不严，或者架构设计已经不适用当时情景（我一直觉得架构没有好坏之分，只有合适与否，如果在一开始原本不需要复杂的架构搞了个很复杂的架构，反而是脱裤子放屁，不仅不能提高效率不说还把当时做开发的人累屎，所以架构方面没啥好说的，很多就是适合当时的架构，当然不排除一些给自己加塞搞一些华而不实架构的，不在本文讨论范围内）；

在软件领域产品质量问题基本都是代码质量导致的，这个包括了代码运行的稳定性和健壮性，这个是显性的，当时就能够发现的。还有一些隐性的，诸如代码规范，文档，编码质量等；

到了这个阶段，软件开发和维护人员可能已经换了一波人了。前人自然是没有少给后面的开发和维护人员埋坑，不管是有意还是无意，坑就在那里了。新来的开发人员有两种选择：勇敢的踩坑或者机智的避开。多数人自然是选择后者，毕竟对于自身来讲风险最少，谁愿意和上级汇报的时候说我写代码bug越写越多呢？

这些机智的人处理的方式多种多样，总结来说就是尽可能的多写一些相似的类或者方法，把自己认为可行的代码放进去，原来的代码能不动的尽量不动，实际上对于管理者来说也希望有尽可能少的bug，毕竟有很多bug可不是一件让人开心的事情，老板不好和客户交代，程序员还得加班；

随着开发人员的更替，结果自然是项目代码越来越臃肿，代码的可读性也越来越差，维护代码的成本也日益增加，解一个bug或者在原有功能上扩充显得越来越难。慢慢的，原有的人手开始不够支撑整个项目的运行，必须增派人手。

增派人手必然导致整个项目成本的上升，对于一些有实力的公司还能撑下去，通过扩招的手段解决当下的问题，资金实力没那么强的就比较惨了，公司的资金链不容许无限制的人员扩招下去，而且人员的扩展必然带来管理成本的扩招，管理体系必然是越做越大，最终会由于资金链断裂而解散掉整个项目组甚至把公司拖垮；

这真是应了马太效应:强者越强,弱者越弱

那么资金实力强一些的公司的老板也不是傻子，项目组不可能无限制扩展，当项目的支出超过红线，迎接这个项目的要么是被砍掉要么是调整；调整有几种方式，一种是通过思加压力迫使员工加班以节省开支，另一种是招一个懂质量管理的人进来专门负责质量管理，还有一种就是从内部培养出一个质量管理人员出来；

这三种方式里面，第三种当然是最靠谱的，但是很多公司用的是第一种方式。一方面是有些老板没有意识到是代码质量的问题，另一方面是公司成本控制不容许花高价钱招一个懂质量管理的人进来；不管怎么样，第一种方式都是很容易把项目拖垮的；

项目后期

项目交付阶段，原来埋得那些坑再也藏不住了，问题一个个暴露出来，项目组的压力也越来越大，公司的资金链也越来越紧张，其实在这个阶段，不扩招的话项目维护不过来，招人的话前面的那些问题又会出来，所以最靠谱的方式就是控制瓶颈；

敏捷开发里面有一本很有名的书《一个it运维的传奇故事》，里面很重要的理念就是瓶颈理论，通俗点来说，项目就像一条流水线，分为上下游，当流水线中间某一块堵住时，管理者会下意识以为是上游生产效率低下导致，实际上，症结点就在中间堵住的那环，疏通了，问题也就解决了；

项目管理的疏通和水管的疏通有一点区别，水管的疏通我们不需要担心上游大量的水涌下来水管会坏掉，但是在项目中需要考虑，如果突然把节点疏通，必然导致下游短时间承受较大压力而出现故障；稳妥的方式是先控制上游的产出，让瓶颈处的压力不再增加。然后慢慢疏导瓶颈，经过一个较长的疏导后，问题自然就解决了，项目也就理顺了；

这个里面主要的就是前面说的代码质量，一方面要项目中懂质量管理，上级要明白质量管理的重要性。另一方面下游需要将代码质量管理控制到位，不是表面上的减少bug数量。而是从编码上梳理每条业务运行的经络，明确实现思路，确保编码质量；

如何提高代码质量

上面说过，要提高代码质量，一方面是要统一编码方式，使代码通俗易懂，另一方面是疏通业务流程，让每一条业务实现有据可查且条理清晰；

《代码整洁之道》是一本专注于提升代码质量的书，但是对于没有阅读习惯的人来说把这本书看完是一件比较痛苦的事情，同时我们也不可能要求每个员工通读这本书，及时都堵了也不一定都吸收进去了。因此最好的办法是管理者将里面的精髓抽象成原则性定义；

成功的公司都有自己的原则定义，比如华为研发内部就有《华为C语言编程规范》，阿里巴巴不仅有相关的文档，还将约束做成代码检查插件，我们在idea的插件仓库就能直接安装，在开发过程中给与规范提示，更加高效；

我觉得，如果想要用一句话总结如何提高代码质量的话，那就是：

尽可能的少说废话，尽可能的多干实事；

废话就是那些对于当前场景来说可以省略的话；
实事就是能够实际解决问题的事，处理问题抓住本质而不是边边角角，一真见血的把事情搞定；实事是有实在意义的事，半成品是没有意义的，只有成品才有意义。因此多做实事就是多做成品，少做半成品；

废话和实事不是绝对的，就比如我写这篇文章，我现在制式想做一个记录，那么里面很多废话我就懒得删了，因为对于我来讲，删了反而耗费时间，我只是纯粹的记录，如果能帮助到别人自然是很好，没有那也无所谓，毕竟我这篇文章是写给自己看的；