从2000年大学毕业开始，一直从事软件开发工作。由于本人非彻底科班出身，所以软件开发过程一直在摸索。在早期学校里学的软件工程，比较让人费解，现在中国真正实践教材中方法的企业也不多。中国大部分企业，其开发模式遵循瀑布模型，就是先分析需求，订好需求规格，然后进行方案和总体设计，接口设计，再进行概要设计，详细设计，完成代码，再测试。这一过程当然是必不可少，也是经过实践检验的。只不过在没有新的开发过程理论出来之前，大家比较教条，严格遵循该模式要求，所以需求分析，方案设计，概要设计做的非常详细，而且要求需求定下来就不能再改，因为这是经过长时间讨论的。如果需求不明确的话，就要讨论到明确为止。如果需求定了要改的话，只能推到下一开发阶段，重新走这一流程。
这种模式是很严谨的，开发的系统周期长，程序稳定性和可用性有保障，但付出代价也高。而近几年逐渐兴起的敏捷开发，采用不断迭代的方式，对于需求的变更确实有较好的应对，而且软件的质量也有保证。
在我担任开发经理期间，老总给的时间是从11月到明年3月分，实现一套视频点播系统。而我此前从没有接触过视频点播业务。给的人，一直到12月还是我一个光杆司令。到12月时才招到一个人加盟。原来做直播业务的人，加上两个副总一共三人，其余五人都是新近招的，还在磨合阶段。直播业务人员也慢慢转到点播业务，加上我的上司，一共8人做点播。技术水平参差不齐。因此我制定的时间点，到1月20号，点播系统必须进入联调，年前实现系统点播基本功能和要求性能。这样，年后还有时间进行测试，调优和修改bug，到3月初可以发布版本。其困难的地方，不仅时间紧，人员紧，而且还要与原来直播系统保持兼容。而直播系统本来就还没有完全稳定，经常要抽调人手维护。
因此，在人员没有到齐之前，我先了解需求，了解原有系统架构，独自进行了需求分析，方案设计和总体设计。我采用Rose，画出用例图，时序图，组件图和部署图，并在方案中规划了系统结构，在总体设计中进行了模块规划。但接口一直定不出来，因为要保持兼容，但我不了解原有模块的接口。因为原来公司较小，文档不完善，流程也不规范。到了我这里，也不可能完全遵循流程和文档。期间不断和了解整个直播系统的人交流，但经常抓不到人。
然后我一个人又进行了概要设计和详细设计，这两个部分近年有融合趋势，一般很少在文档中详细到类的每个函数设计的地步。而是在关键的算法和类方面进行伪代码的设计。另一方面，类的设计采用rose直接画出类图，在定好成员和方法之后，直接就生成代码了，相当于详细设计。
在第一个人进来之前，我对于文件管理和文件读写的类都已经生成，整个程序的框架都已经搭好。包括配置，log系统，主程序，文件管理等，我的测试系统已经可以run起来了。而这个时候，关于如何和原有直播系统保持兼容还没有人抽出来和我讨论。没有人可以给出结论。因此我进行了一部分通讯层的设计工作，后面全废了。幸好我是迭代开发，一步一步来的，不过搭了个空盒子。
到2008年1月份，人终于到齐了，没办法，全部拉到怀柔封闭开发。终于讨论清楚了整个消息的流程，一直到11号第一次联调前，还有人要改系统结构。封闭前，决定了使用直播的底层通讯。封闭后开始定接口，以及点播消息。期间，点播已经将状态机，session管理，线程模式想清楚，采用了直播定的空接口，先期进行调试。通讯层实现成为瓶颈。不过我还是要求赶在前面的其他模块先期测试，采用桩函数模拟底层通讯，进行单元测试。负载均衡，客户端，上传端和点播服务器（没有通讯层）先期自测。到11日，通讯层终于出了一个可用版本，可以进行基本联调了。
这样，让测试和联调走在前面，保证了代码的稳定性，同时又促进了系统往前推进，并不要系统完善，就开始联调，立即发现了遗忘的角落和设计的缺陷，接口问题。所幸都还来得及修改。不断的彼此促进，系统逐渐走向完善。
当整个系统由生疏逐渐润滑，无缝运转起来之后，我终于可以腾出手来，准备思考更多系统细节和优化。到明年，在优化的过程中，进行内部培训，让团队更有战斗力。
如非注明转载, 均为原创. 本站遵循知识共享CC协议,转载请注明来源
