从11月初开始，我想对系统中的一个模块做重构。这是一个任务管理的模块，主要负责任务的自动生成，手动生成，任务的查询，跟进和统计。
该模块是一年以前做的，当时虽然我也负责架构，但是头绪很多，我没有很细致的设计这块，主要由几个同事分工完成。从开发的角度，各自负责自己的业务，不统一，存在很多重复冗余的代码。从业务的角度来看，业务单一，范围比较狭隘，有些东西用户不需要却设计的很复杂；有些地方又不能满足用户的需求。从业务和开发的结合来看，开发者没有深入挖掘需求的概念，对概念进行模型设计；而是采用肤浅的业务处理，导致很多概念的共性没有发掘出来。同时很多技术的选择也不是很合理，比如数据按照月分表，实际查询并非如此。
经过2周的调研，包括对现有系统业务以及技术方面问题的总结，我把PM拉进来讨论，同时和专家一起深入挖掘业务模型，最终形成了新的系统业务模型。然后是确定设计方案，最重要的是数据库的设计。我在完成数据库设计之后，同时也完成了系统模块的划分。然后我开始拉入开发人员进行讨论，对他们讲解设计。原计划12-15号上线，后来推迟到22号。
回顾过程中做的好的地方：
1. 清晰的定义了业务模型，确保大家对业务模型有一个统一的认识；
2. 业务模块划分清晰，没有发现开发人员功能重叠的地方；
做得不好的地方：
1. 没有能及时发现项目延期的风险，知道14号才发现不能上线，推迟到22号，pm也不满意，还发生了争吵；
2. 有些细节问题没有描述清楚，也没有形成有效的文档，导致大家缺乏一个参考的标准，很多时候都需要面谈；
3. 没能说服PM对系统进行深入的概念挖掘，导致系统模型仍然存在模凌两可的地方，不利于后续的演进。
感悟：
1. 系统架构师要先抓住大的主要的架构元素，哪些核心概念，并把它们清晰的传递给开发人员；
2. team内部要有严格的进度跟踪系统，不管使用方式，需要了解代码的完成程度，才能进一步提前预知风险。虽然有可能进度管理不是架构师 责任，但通常两者是一起的；
3. 一些小的地方也需要仔细的设计，有时候小地方也存在大问题。