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

对于长生命周期的大型软件,流程和规范十分必要。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数据。第一时间发现性能恶化引入的版本节点,修复的代价是最小。如果没有这些记录,往往后面优化都没有针对点。还是那个道理:问题发现的越早,越容易解决。

猜你喜欢

转载自blog.csdn.net/thisinnocence/article/details/80158921