ION APJ Interface项目总结

    ION（Input Output Network）是公司的物流系统的简称。一个占用10个开发人员，耗时1年完成的系统，终于到了尾声。偶有幸成为开发组长，和大家一起折腾了一年。这里罗列工作失误，一一分析。
    中国的开发人员直到需求分析的后期才应邀加入系统开发。刚开始接手需求，自然是浩瀚的文档，来来回回的沟通邮件，散落在四处。每次开会时都在找最新的版本，即缺乏效率又浪费时间。直到后期大家才把文档迁入source safe里统一管理。
    第三手的需求说明。中国开发组在需求分析的后期才加入项目。最终用户的需求通过业务分析人员，开发组长，开发人员，一共转诉了三手才传递到开发人员手上。由于每个人对功能的理解程度不同，导致实际开发的系统功能和用户的期望存在一些偏差。
    缺乏对现有开发人员的能力评估和培训。ION是公司的核心物流系统，代码中的错误会对公司生产带了巨大的损失。虽然开发前期我们要求每个开发人员要做单元测试，但未定义单元测试的标准。直到编码阶段的中期，一些开发人员还在重复着“单元测试通过了，但功能错误”这样愚蠢的错误。
    总结：对项目的所有文档，需要一个统一的集中的资源管理工具，例如把文档分类迁入VS team system server资源管理器中，再把最新的文档发布在share point portal server上。同时要对参与项目的开发人员做一个能力评估，对“木桶上短的那一块板”迅速给予培训和强化培训结果，以期符合项目要求。进行数据流分析，从而使每个开发人员明白数据的处理流程和每个模块在流程中的位置。

    项目到了设计阶段，自然需要制定一些标准，“游戏规则”。其中大家最不遵守的一条就是peer review。在项目的开发阶段，大家要不没有review要不就是象征性的review，这造成了一个非常严重的后果：一位开发人员的代码质量严重低于要求而很久没被发现，虽然他实现了功能，但代码实在是一团浆糊。最终不得不另外抽调人手来接替他的工作。
    标准定义冲突。对系统发生错误的处理方式，我和老板定义了不同的标准。这使开发人员都很迷惑。最后在代码中出现了错误处理的三种版本：一种遵循老板的错误处理方式，一种遵循我的错误处理机制，一种混合两种错误处理机制。
    过度设计。在系统接收外部消息的模块上进入了“为了模式而模式”的陷阱。开发人员花了不少时间做了一个既能兼容FTP又能兼容IBM MQ的消息接收模块。最后发现调用很复杂，不得不又放弃了这个模块。
    人员分配的策略失误。由于开发人手不够，老板们在印度分配了一个开发人员，在马来西亚分配了三个开发人员。由于没搞清谁是这个系统的责任人和最终是那些开发人员需要对系统的维护负责，在开发标准和代码质量上，我对其他区域的开发人员只给了建议，而不是强制遵守。简单地认为他们又不是我管，他们写的东西不关偶的事。但最终，系统都由中国的开发人员负责。我们不得不为所有不合标准的代码买单。
    风险管理。夸区域的电话沟通是又费时又费力的工作，虽然开发人员多了三个，但造成了交流时间的巨大
浪费和部分模块的质量失控。
    废弃的SDS(system design specification)。由于SDS不是出自开发组，开发人员普遍不认同系统设计而另立门户，造成了设计阶段最重要的文档被束之高阁，开发时无人阅读。
    总结：游戏规则一旦制定，还需要有个好的榜样。需要有人带头出来，给大家做一个best practise。标准的制定不允许存在冲突，需要有人为了全局牺牲和妥协。设计阶段需要有风险管理计划，例如做FMEA：定义什么时候该peer review其他区域同事的代码，如果他们的代码质量不能符合要求怎么办？备用计划是什么？在设计阶段，测试组应该完成了测试用例的书写，开发组就测试用例进行走查设计，确保这是一个“为了实现用户需求的设计”。

    代码和设计的同步。既然没有一个人能在设计时做到百分百正确和最优化，在编码阶段自然会修改设计。开发人员常常会改了代码忘了同步设计文档。倒不是因为开发人员懒，而是工作方法问题和设计文档编写的问题。
    总结：一定先修改设计文档再修改代码。保证一项设计内容只出现在一个文档一个地方，避免一项设计出现在多个文档中。这样方便开发人员同步设计文档。否则，即打击开发人员同步设计文档的积极性也使设计文档变的难以管理。

    系统终于部署上线了，周六一试运行，哇，一大堆的错误报警！连忙检查，发现数据库竟未同步！跳脚了半天才明白，DBA同步开发环境和生产环境的时间有误差，部分新修改的存储过程和表结构不一致。这回搞笑了，大家急急忙忙进行人工比对。但对于一个有好几十张表，好几百个数据库对象的数据库，人工比对难免会有遗漏。一周后的一天，系统性能突然急剧下降，生产线几乎要停工。在老板们的“咆哮声”中迅速检查原因，原来生产环境遗漏了5个重要的索引！
    再好的系统都难免会有bug，何况是这个不怎么好的系统，就看补丁怎么打了。如果不忘了更新配置文件，遗漏了DB脚本，重新运行回归测试，理应不该引入什么问题。:)
    总结，在部署计划中，数据库的同步必须要有一个清晰的cut off时间。cut off后的更新都归入上线后的补丁。和DBA的沟通障碍导致了不少麻烦，这么笨的问题，真不好意思写出来。

    系统已经运行三周了，逐渐越来越稳定了，长舒一口气。希望下个项目能做的更好。:)