大型软件开发中的流程与规范

对于长生命周期的大型软件，流程和规范十分必要。IT行业作为一个快节奏的行业，不光技术革新快，人员的更替也是很快的，没有严格的规范和流程，几个大版本迭代下来，可能产品的代码就维护不下去了。

估计很多大厂的小伙伴面对自己日常开发维护的的code base会产生这样一种错觉，这么庞大复杂，逻辑绕来绕去，时不时会有些巨型函数，还有些看的让人崩溃的if esle分支，各种自造的轮子，历史遗留天书代码，但是就是这么神奇，软件跑的好好的，功能性能都没有任何问题。这个时候不得不感慨软件工程的魅力，下面就谈谈软件开发中我个人认为的比较有用的流程和规范。

合理的特性规划

大型软件是有自己特定的版本节奏的。每个版本能够承载的feature是有限的，这个也要根据feature的技术复杂度来评估。不顾客观规律的大跃进是要不得的，Windows Vista就是被过于牛逼的特性所拖累的典型案例。没有合理评估匆忙开发的特性往往会成为产品后面的技术债务，bug爆发的源泉，长期都稳定不了。

规范的文档写作和方案评审

规范的文档协作和方案评审大型软件开发中的重要一环。方案是否准确严谨，是否绕弯子了，这个经过团队评审才会发现，一个人的思维往往会有局限性，经过大家的评审，早日把方案级的错误给排除，后面开发才会更顺利。此外，文档还有一个重要的作用就是给后面来的小伙伴看的，把团队人员变更对产品开发的影响降到最低。

统一的代码风格与严格的code review

代码风格一定要统一。比如：大家大括号都不换行，你非得换；大家都用驼峰命名，你偏用下划线；代码库里有现成久经生产环境考验的哈希库容器库，你偏偏自己造轮子…那你肯定会被狠狠的怼。新人代码里花式秀骚操作的无一例外都过不了code review的，不遵守规范的代码还想check in，模块的owner不发飙就不错了。忽然想起 Linus 面对pull request里的骚操作所发的飚：

Get rid of it. And I don’t ever want to see that shit again. – Linus

大型软件作为公司重资产，是要长期演进和维护的，每个人都来骚一把，那么只能是吃枣药丸~

清晰的分支管理策略

分支管理是一门艺术。master分支，feture分支，release分支，bug-fix分支，test分支都是有其不同的功能的。Linux Kernel内核的分支管理绝对是分支管理的典范。软件开发中项目管理很重要的一环就是code base的分支管理，围绕不同的分支类型，会有不同的配套构建测试系统，这些都是保证开发活动有序进行的基础。

每日的持续集成与验证

持续集成（Continuous integration）对于大型软件非常非常重要。因为需要集成的组件提多了，涉及的部门和开发团队多了，bug也会相应变多，这个时候保证bug在第一时间发现就非常关键了，今天这个组件一个bug，明天那个组件一个bug，不及时解决，一起在后期爆发，绝对够喝一壶的。

定期性能测试归档

性能作为一个关键指标，是需要长期监控的。周期测试并且存档perf数据。第一时间发现性能恶化引入的版本节点，修复的代价是最小。如果没有这些记录，往往后面优化都没有针对点。还是那个道理：问题发现的越早，越容易解决。