关于项目完成后的逆向思考

 

XX项目结束了，从整个产品的外在表现以及我们软件系统内部做的事情来看，这是一个大项目，做的事情也很多，同时，也跟最初可预见的一样，遇到的问题也很多，有时候遇到的问题甚至会让人崩溃和无语。这也很正常，那么大的产品，那么多的功能通过简单的捏合是不可能完成的，再加上我们的整个团队经验上的不足，遇到这么多问题也就不足为奇了，从3月份到现在为止，项目持续了大概7个月的时间。这个项目，我基本上是作为一个局外人参与其中，只是偶尔需要协调资源或者有大的变化时我才需要参与进来，更多的时候我都是在做别的事情。虽然是个局外人，但是在项目结束的时候，我仍然想停下来思考一下，当然，由于我参与的并不多，有可能这里面的观点会不正确，这个可以多多的探讨.

1.    新功能开发方面

我们在开发一个新功能之前，都做了哪些事情？ 我认为以下几件事情是我们在开发一个新功能之前是必须要考虑的：

A. 这个功能的用处是什么？在用户的业务场景里面，这个功能是处于什么位置？如果没有这个功能，会出现什么问题？这个需求的原始出处或者原始背景是什么？ ——此为深入了解用户需求。

B. 我们的友商是怎么做的？ 或者说业界领先的厂商是怎么看待的这个功能？ ——此为竞争对手分析。

个人认为，如果认真分析了以上两点，需求规格应该可以很容易的抽取出来了；这也限定了我们的问题域.为我们后续的工作指出了一个范围。

需求规格完成后，开始做设计，很遗憾的是，我们团队里面的很多人，不知道怎么做设计，拿着公司制定的设计文档模板无从下手，不知道写什么，不知道怎么呈现。我曾经也遇到过类似的问题，根据我个人的经验，我认为解决这个问题有两个步骤，

1）：不管怎么样，你都要写，按照他的模板去做，多写几次，就能找到感觉了，也能知道为什么那个设计文档的模板是那样制定的。

2）：参考别人的，去看在我们的团队里面比较优秀的人写的文档，看看他们的文档是怎么组织的，然后模仿、借鉴、超越，去其糟粕、吸取精华，最终变成自己的成果。

在设计阶段做的事情，是对这个功能进一步的熟悉过程，同时，设计阶段做的是否完整也决定了你后面对这个模块的把控程度。如果这个阶段做好了，在内部测试阶段，你对这个模块的把控程度就会很高，你一定可以知道这个模块可能还会存在哪些问题，以及哪些方面一定不会出问题。现在，我们有的同事无法完全掌控自己的模块，本质原因是对这个模块的熟悉程度不够，是对整个模块的组织结构、交互流程等不清楚。

做好了需求和设计，编码阶段应该会轻松许多，只要我们在编码阶段能够掌握一些基本的编码原则，那么这个模块一定不会很烂，反之，如果写到哪儿算哪儿，没有事先做好设计和规划，这个模块的质量风险一定会很高。

关于自测试，我以前也很少为单元测试写过代码，更多的是依赖于黑盒测试。但是通过了解，有公司的单元测试的用例数目是有要求的，而且是硬指标，加上XX在OAM整改阶段使用了Gtest，也带来了一些成效，使我对这个有了全新的认识，希望我们大家在后续的开发工作中把这个多用起来。单元测试做的越充分，后面的麻烦事儿就越少.

2.    Bug解决方面

在这个项目里面，我们组的bug数目很多，但事实上这个项目里面我们增加的新功能或者改动大的模块确并不多，不知道大家有没有在项目结束的时候反向去看一下自己曾经解决过的那些bug？ 有没有针对那些bug做一些分析？有没有去研究下这些bug，有哪些是不应该出的，或者是我们在开发阶段通过一些自测试手段可以很容易的避免掉的？

根据以前公司给出的业界比较合理的bug率是这样的：如果是新功能模块，bug率应该在0.3%以内(这里面还要除开CLI、MIB这种功能逻辑很简单的代码)，如果是维护模块，bug率比这个应该更低；如果高于这个数据，那么这个模块就不是一个高质量的模块。我估计如果按这个去衡量我们的功能模块，低质量的模块占据了大多数；当然质量不高可能也有一些其他方面的原因，比如：进度紧张、测试设备紧张等等；但是我想说的是，我们有没有主动想办法去提高质量？或者为高质量做了特别的工作？ 还是做完一个模块就听天由命，测试报一个bug我就解决一个，测试没有报bug，我就什么都不做，默认一切正常？

3.    质量控制方面

目前我们组在质量控制方面的工作做的非常有限，这个我有一定的责任，后面的项目我会想办法把这部分工作抓起来。我理解的质量控制应该包含几个方面：

1）： 各阶段输出物的评审；目前虽然项目线组织了一些评审，但是我们专业组内部的同行会审没有做起来，后续多加强一下这方面的评审，也可使得大家可以更多的横向了解业务，尤其是组内比较资深的同事，更应该多参与。

2）： 关键设计方案的评审；这里的关键设计方案是指,关键模块的设计方案以及关键bug的重大改进方案， 这部分基本上依赖于各责任人的经验，事实上我们可以更多的利用组内的资源，这样可以在一定程度上降低质量风险；如果当事人在做某件事情时，觉得需要其他人参与评审下，这样的行为就是一件非常值得肯定的事情.

3）： 代码质量的评审；我们现在提交代码的权限都是开放的，基本上是只要你愿意提交，就可以提交，没有做任何的审查，比如：编码规范检查，代码逻辑检查等等。后续这方面需要持续加强。

4.    其他方面

我们的团队还是一个新建的团队，大家都来自不同的公司，也都有不同的做事方法，加上我们公司在这方面实行的是松散管理，导致每个人做事情的方式和思路不一样，在合作过程中难免遇到无法达成一致的地方，甚至还会有一些冲突。有一段时间我也经常在思考，怎么样去解决这类问题，但没有有效的结论。不过，我认为可以指引我们在沟通方面做的更好的有两点：

A. 任何的沟通和合作都要以解决问题为目的；

B. 我们不怕吃亏，我们愿意多做一点事情；

       我希望我们团队的成员可以从这几个角度去考虑问题，我们能做的就是让自己做的更好。

5.    最后

前面谈到的东西很宽泛，基本上把我们的整个开发过程都说了一遍，有的是问题，也有的不是问题，也有说的不完善或者不正确的地方，我的想法是能激发大家去思考，去反省，只有这样，我们才能有提升。如果只是简单的重复做项目，而不去想怎么样把事情做好，对我们自己没有任何好处.