这次应该说是经验总结，以下是我在工作中的几点经验总结，都是个人意见，望大家一起讨论， 多多交流，批评，指正。

1. 注意“重构”的影响程度。对于公用代码（模块）的修改尤其要慎重，到了项目开发的后期，如果不是非改不可的修改，还是不要改为好。
  例如一个典型的数据库应用程序，如果要重命名一个字段名，则下面的项都会受到牵连：
SQL Script;
Hibernate 映射文件(*.hbm.xml);
实体类;
DAO层;
表现层;

2. 关于时间。
声明一个DateTime实例，应该设置其默认值，如果不设，其值将是0001年1月1日，这样插入数据库将会出现问题。
在后台（代码，数据库）里的时间值，应该采用UTC时间（格林威治标准时间），对于CS/BS结构的应用，如果会有不同时区的用户去使用的话，不采用UTC时间将会导致时间不一致，不可比较的问题。当然在表现层还是要转换成当地时间来向用户显示的。

3. （C#）应该写internal 的地方就不要写public,例如同一个solution下会有多人开发多个模块(project)，会有多个命名空间，如果你自己的子模块有一个Util类，只有你自己的模块用到，但是把它写成public了，这样很可能别人也写了一个这样的类，这样就会产生名字冲突（当然可以通过在类名前加命名空间前缀来解决，但是这样长的一串，还是不大好！）

4. 尽量为代码多打Log, 因为当你的产品拿出去用户用的时候，如果出现了问题，是不可能用开发阶段的一步一步Debug去找问题所在的。

5. 对于Web Application， 如果有IIS， 还是尽量用IIS来作平常调试，而不是用Vs.net 2005 自带的Web Server，因为他们还是有不少地方不一样的。并且产品Release之前， 要多在不同的操作系统，浏览器（即使是版本不同）测试，例如同一个网页可能在IE6与IE7完全两个样了。还有，建议使用预编译来部署，因为这样做一方面可能提高性能，一方面的把源代码隐藏。

6. 对于WCF 的Contract定义，建议化多个参数为一个参数，例如有一个OperationContract是
Login(string userName, string password), 应该先定义一个类：ParamOfLogin, 里面就两个属性：UserName, Password。 Login就定义成Login(ParamOfLogin loginParams); 这样做可以减少代码耦合性，如果哪一天需要往Login里面再加一个参数，就可以只加一个属性而用不着动Contract/接口了。

7. 写代码要写易于测试（至少是可测试）的代码。如果一段代码是无法用UT或者FT去测的话，其正确性将无法用自动化工具来保证。

8. 开发的每一个阶段都不能脱离需求（SR）。
9. 对于你给别人定的Schedule, 应该多设Checkpoint， 常问问他完全地怎么样了。