杂谈关于在C++紧急项目中配备资浅人员

　　在C/C++嵌入式开发项目中，由资深人员对系统进行分析并做好详细的设计，然后由资浅人员进行“比较机械的”编码，我一直比较好奇这种方式的可行性如何， 由于我是开发人员，所以按照开发人员的思维去理解的话，我觉得就算你设计得再好，你也没有办法控制到资浅人员编写的每一行代码，而他的一行代码就有可能导 致程序崩溃，例如对c/c++的指针使用不当，除了导致程序崩溃外，可能还会导致隐蔽的（例如内存泄漏）或者其它难以重现的bug。
　　大部分做 信息化项目的公司使用JAVA、VB、C#等比C/C++更高阶的开发语言来开发项目，由于JAVA、VB、C#等语言去掉了指针等大部分导致程序不安全 的元素，所以资浅人员编写的代码再烂，可能也不太容易导致程序崩溃等重大BUG。另外，VB、C#等都有较成熟的IDE，会自动生成代码框架，且支持组件 式拖放编程，调试功能也很强大，这些，都在一定程度上降低了开发人员的技能和经验要求。且就算有BUG，如果不影响使用，在信息化系统中有时也是可以容忍 的，例如网页出错了重新刷新一下就好，或者程序崩溃了重开一下，但是我们不同，我们写的是电子设备中的嵌入式软件，很多bug是不可容忍的，就例如你的手 机在待机时死机，或者在通话时崩溃，估计你是不能容忍的，况且，如果电子产品已经上市，召回将会是极大的灾难。所以鉴于我们使用的是C/C++比较低阶的 编程语言，且是嵌入式的软件开发，开发人员的技能与经验对项目的成功率来说还是很重要的。
　　新人的代码需要Review，你可以事后 Review去发现资浅人员代码中的可能大部分的错误，但就算你发现并指出了所有功能层面上的错误，但你也不能保证资浅人员由于缺乏经验，所编写出来的代 码出现的如下问题：
　　1) 缺乏弹性，例如稍有需求改动就需要大幅改代码。
　　2) 没有处理出错流程，例如输入一个超出范围的数据就导致程序异常。
　　3) 编码规范混乱，就算完全按编码规范去做了，一些规范中没有规定的一般编程规则他也容易犯，例如滥用宏、滥用全局变量、滥用编程语言的一些高级特性(如 C++中的模板)等。
　　4) 代码不健壮，存在潜在的隐患，例如，配置文件不存时程序就崩溃。
　　5) 设计过度，例如滥用类继承，或者滥用多线程等等，使得代码难以阅读和维护，出现错误也难以debug。
　　6) 代码的执行性能差。

　 　这些问题你在Review时指出了，他根据你的意见来修改，但由于毕竟是能力和经验不足，不可能在短时间内有大的提高，当他再修改两版估计也不太能令你 满意时，当项目确实比较紧时，资深人员就会失去耐心，资深人员都会有想铲掉资浅人员的代码然后重写的冲动，我说说我在上一家公司的经历，我和同事B都是新 人，同事B所编写代码没写好，PM让我重写了他的代码，等到项目接近尾声时，PM也把我写的代码也给重写的，也就是说，最终的产品中的代码，都是PM经过 重写或重构过的质量较好的代码，但这毕竟是小项目，我们如果出现这样的情况就是灾难了。
　　是否资浅人员的代码就没有价值呢？当然不是，至少：
　 　1) 如果前期需求分析得不够详细，那么在资浅人员在进行编码时，会发起讨论，这时可以帮忙挖掘出一部分的需求来。
　　2) 可以检验你所制定的，或者其它模块的一些接口是否能满足设计需求。
　　3) 你的一些试验性的想法会在编码中得到验证，用于指导你的下一步设计。
　 　4) 资浅人员都是从一些简单的模块做起，不会影响大的进度的同时，也得到煅炼和培训，为下一个项目做准备。

　　当他们的代码不能作为 最终产品的代码时，改也改不好，项目进度又紧，除了重写它们还有什么办法呢？ 可这重写的任务又只能是资深工程师的工作，但有趣的是，资深工程师可能已经是管理职位，例如组长或课长，让他们去重写资浅人员的代码，在公司管理层来看， 是管理人员在“跳下去做工程师”，是一件没有效率的事情，而且对于带管理职位的资深工程师来说，自已底下的兵品质不佳，自已也有责任，同时代码需要重写在 领导看来是一种资源浪费，所以资深人员既累又得不到肯定的理解，而对于资浅人员来说，更是会有很大的心理负担，因为自已的辛苦的工作成果没有整合到系统 中。


　　说了这么多到底想表达什么呢？我的思考如下：
　　1) 我们的项目都是C++项目，由于C++的复杂性，且我们所进行的是嵌入式开发，因此开发人员的技能与经验对项目的成功率来说还是很重要的。
　　 2) 新人是要带的，这是在为公司储备后备能量，不容置疑，但资深人员带新人，应该是在一个不紧急、不重要的项目中进行，目的是在推进项目的同时也培养新人，对 于紧急且重要的项目，1~2个资深人员设计+多个资浅人员编码这种模式有极大的风险，在一个已经进度落后的项目中增加资浅的人手，搞不好反而会拖慢该项目 的进度而不是提高。
　　3) 如果项目中有资浅的新人，除了培训、手把手的指导、Review文档、代码外，适当时候可能还要重构他们的代码，这就增加了资深人员的工作量，也就这就是 培训新人的成本吧，所以对于紧急且重要的项目，就应该权衡其中的利弊。
　　4) 在项目进度落后时，对临时增派人手要持谨慎而不是过于乐观的态度，这一点可以看了一下<<人月神话>>一书中“人月神话”这一章 中的“人月”这一小节的分析。

　　纯粹杂谈，欢迎大家讨论，指正。