在IDP项目也待了近10个月了，记忆中没有怎么清闲过，现在项目结束，也该总结下。
从纯技术的角度来说，这个项目使用的是silverlight和telerik技术，以前没有接触过，首先必须得学习silverlight和telerik，在学习silverlight基本特性的时候不断锻炼了自己的自学能力，同时也积累了一些silverlight binding，command，dependency property，布局系统等特性，Prism框架，DI，MEF，Unity Application Block，强引用与弱引用等技术，也对面向对象的思想理解更深刻了。
从项目流程方面，使用TDD的模式开发，交付频繁。在项目中，我觉得作为开发者应该注意以下问题：
（1） 需要理解用户的真实需求，而不只是需求文档上面的那些说的不太完善字。因为可能有这样的情况，PM向开发者解释需求的时候，会提出一种实现方式，当开发者发现这种实现方式很难实现的时候，这个时候开发者可能就不知道怎么办了。因为在理解需求的时候，开发者只是理解了实现需求的实现方式，而没有理解隐藏在实现方式背后的真实的用户需求。如果理解了用户的真实需求，就可以换一种方式来实现这个需求。
（2） 在修改问题的时候，经常会有场景考虑不全的情况。原因有两个，其一只考虑问题单中的场景，没有考虑相关场景。其二，修改完bug后只测试了单一场景，没有测试相关场景。解决方法：（1）写代码的时候，代码结构要清晰，方便日后修改，写完代码后需要多看看自己的代码，来梳理场景，熟悉代码。（2）修改代码的时候，注意影响范围，从代码层面和测试角度来审视，确保修改后不会引入新问题。
（3） 在动手写代码前需仔细考虑功能的中场景，然后梳理场景，即使有些场景暂时不需要实现（可能在下一个迭代中实现，或者是打桩），也需要把注释写清楚，这样下次补充的时候，不至于遗漏场景。
（4） 在写一个功能考虑到模块之间通信的时候，要问自己为什么要这样写，这样写好处是什么？有没有坏处？有没有更好的实现方式。因为考虑这些问题，模块之间的关系才不至于很乱。
（5） 模块之间通信的时候，最好传递的是对象，而不是C#的基元类型的对象。因为这样能增强模块之间的通信的可扩展性。
（6） 在修改别人代码的时候，需要别人协助理解一下原来要求是怎么做的，原来做到什么程度，如果这两个点没有搞清楚，很可能这个bug没改好。
（7） 要有项目的全局观。包括项目的由哪几个模块组成，项目是数据怎样流向本模块。模块之间通信采用的是什么技术，有什么弊端。虽然开发者开发的是一个小的模块，很多问题在模块内就能解决。但是如果没有项目的全局观很多牵涉到模块之间的通信的问题，可能思路就受限制了。
不管在从技术方面还是从流程方面，IDP项目都给我一些新的东西。但是还得继续努力。