记一次模块开发经历

去年6月份接到开发模块A的任务，整理完需求后开始详细设计、开发，约7月中旬构建完毕，开始上线测试。7月下旬，由于需求变更，开始考虑重构模块，8月初完成。12月份客户验收，对该功能极为不满，开始考虑如何重新设计该模块及修改后续数据流中的其它模块，目前已构建完毕。本该1.5月完成的模块，前后经历了3.5月，有以下几点教训。

1、重视客户的每一个需求，仔细分析需求形成正规的需求文档，后续的构建活动中严格遵循该文档，妥善管理需求变更。第二次重构的原因是需求分析不到位，没有吃透需求就开始架构设计，模块设计与开发，等开发都进行了一半了才突然发现不满足其中的一个需求。第三次重构的原因是轻视客户需求，认为这个需求无关紧要，其实该问题在第一构建完毕后，曾经就这个问题跟项目组长讨论过，但我只是认为这样做不合适，而没有更进一步的深入考虑拿出可行的思路，因此该讨论不了了之。

2、设计决策上的失误导致后续重构困难。信息隐藏没做好，最容易变化的输出文件格式相关的信息没能很好的隐藏于输出部分，而是散落于整个模块；设计时有些部分过于详细，有些部分过于粗糙，比如输出部分设计的太粗糙，等到实现时才发现现行设计不能解决问题，这时工期又比较紧，只能匆忙修改部分数据结构；某些关键数据结构起得名字暴露了太多信息，以致于不容易扩展；设计时过分追求优化，导致某部分设计复杂、难以理解，也难以重构。

3、理念问题。第三次重构时，考虑整体解决方案时，不是以解决问题为第一要务，而是想怎么能做到整体改动最小，这是不注重实效的理念，应该摒弃；重构时，不舍得对自己模块“下手”，应该痛下杀手，彻底解决不合理的部分；把握好度三者间的度：优雅的设计，控制复杂度，赶工期，不过分注重某一方面。