其实这个我在TW的第一个项目还没结束，现在就总结还为时尚早。但我担心我会遗忘，而且既然有心思写下来，为什么要等那么一个时机呢？
- JS代码组织结构和单元测试。按照客户要求，我们使用SmartClient作为客户端RIA库，这个库的优点是丰富的UI控件，但逻辑和视图耦合很紧。当我们发现JS端代码日渐庞大臃肿时，耦合紧导致维护很难，而这时已经过了第一个Release。在第二个Release中，我们讨论过用MVP来解耦，引入Jasmine作单元测试，讨论尽可能将代码做M、V、C三个角度分离并有了尝试，但仍未引起足够多的重视。我们是侥幸的，因为这个项目并不复杂，不管从技术上还是业务上，所以这个方面的技术债感受不深。我们知道我们应该做的。
- 代码静态分析和质量控制。我们直到第二个Release的后期，才试图引入cobertura和sonar来分析我们的所有代码，结果可想而知，一些测试没有覆盖，代码的逻辑有问题，有些是多余的分支，有些是永远不会走到的逻辑。这样又方便又能让我们学习的工具，为什么没能早点采用呢？
- 成熟框架。因为Team半数以上是新TWer，从一开始team并未引入Hibernate和Spring等重量级框架，但在Domain Model分析上下了功夫，这样一直平静发展到Release 1结束。Release 2开始，因为团队学习的需求和客户要求架构统一，我们同时引入Spring和Hibernate，用到的多是框架最核心和基础的技术，除了遇到个别问题比如双向关联、继承和Proxy Bean，一切都还正常，业务和技术的双重相对简单性决定也用不了多复杂的框架技术。只是在临近Release 2结束时，客户要求集成双方的系统时，我们发现引入Hibernate和Spring在这时是一种风险，或者说累赘，我们不得不合并或者修改一些配置，以期避免冲突，这个过程不那么平滑。
- 代码合并。最后关头时间紧，我们却发现我们要merge一个超过一万两千行代码的类，这个类基本是一个Release才merge一次。过程痛苦，IDE自作主张的分析合并让我们无法相信它，我们能做的只是纯文本的手工对比，这时Beyond Compare帮了大忙，但即使这样也消耗了我们近半个下午的时间，这还只是不到十个类文件。我在想，如果能前瞻一点再果断一点，我们定不会在这个一万两千多行的类里面再添加我们全部的实现的代码，而是挪到自己的实现类里。
- 管理客户期望。系统集成，是客户在Release 2还剩一个半迭代时，强烈提出的。这个问题似乎从项目开始时可以预期，甚至中途客户也是偶尔提及，但我们似乎没有足够重视。我更认为这是业务理解和管理客户期望的问题。我还没有更好的想法，期待跟团队一起回顾。
