眼看着7月进入了下旬，可自己的blog上7月份统计仍然停留在2篇，于是开始担心开心一脚把我踢飞...
其实真实情况是这个月手头一直在进行着一个web项目，所以难免会忙碌一点。说来也是奇怪，从我开始做.NET程序员以来，做产品的时间远远多过做项目的时间（大家别羡慕我哈，嘿嘿），不过做项目有时候真的还是可以得到很多做产品没法接触和体会的东西...
1、保持项目源码规模
嗯，打开VS.NET，创建解决方案，创建DAL项目，创建BLL项目，创建Web项目，创建Entities项目...两天后，在被不停的在项目间切换来切换去搞得头晕以后，我意识到一开始我就犯了一个愚蠢的错误。于是，我花费了一点时间，将各个子项目的内容都移动到了一个统一的Web项目的各个子目录下，呼，整个世界清净了。
教训：如果一个项目的规模不是那么大，盲目的一成不变的按照Architecture结构来划分子项目完全是不必要的，甚至有可能增加跟踪代码的成本。VS2005中Web项目新增的Code子目录特性，可以说用意是深得此要领。
2、ORM，意味着开发速度
这个项目我使用了DevExpress的ORM产品：XPO，它是一个可以完全对开发人员屏蔽数据库操作的透明持久层，而并非常见的在Entity与数据库Table之间定义映射关系后自动进行存取数据操作的ORM。这就意味着，在开发过程中，我可以完全不用去管建表、建字段、取数据之类的所有的数据库相关的操作。根据我的估计，它大约节约了我40%的写代码时间。我承认XPO有这样或者那样的缺点，但是，它最重要的优点，提高开发速度，完完全全的吸引了我。
心得：项目不同于产品，在性能可以接受的情况下，有时候开发效率要远远重要过代码效率，所以，大胆选用ORM吧！但是（生活中总是有那么多的但是），如果整个项目组的成员对ORM都不熟悉，而且有可能在一个为期两个月的项目里面要花费半个月来学习ORM的使用，那么，还是别冒这个风险了...
3、文档重要还是可以工作的程序重要？
其实我到现在还是有点糊涂。我们的客户要求我们在前期撰写非常详细（详细到一个Form上有几个文本框几个按钮，按第一个按钮会出现什么...）的软件计划说明书（这个想法好像倒是很合软件工程的思路），但是我的想法是，与其花费那么大的精力写这样的一份报告，不如直接做一个Prototype的东西，不一定要实现所有的东西，但是可以给客户对产品的功能有一个更加直观的了解和印象，然后我们可以就这个Prototype进行MileStone式的开发，一步一步让它接近于最终的成型产品。至于那个详细之极的软件计划书，如果亲爱的客户能够在确认它以后将需求固定下来，我倒也很乐意这样干，但是好像没有谁能担保它的“有效期”，那么它的意义我就很值得怀疑了。
心得：大家对这个有何心得呢？