首先，设计不详细，详细设计不应该停留在文档的层次上。当然，详细设计基本上是我来做的，之前我没有任何设计经验。PM让我写详细设计说明书，那时候需求分析说明书还没有呢，估计PM是想一蹴而就吧，结果呢，我把写详细设计说明书当成一项任务，而不是把详细设计。写文档是一个枯燥的过程，我冥思苦想，努力用文字和简单的图形表达清楚我的意思。终于，我觉得我把我的意思表达清楚了，而且，我认为，如果软件按照我的思想来设计的话，应该是可用的、易扩展的。我以为，项目组的每个人都领悟了我的意思。结果证明这是错误的，每个人都有自己的理解，而且每个人都用自己的理解在编写自己的代码，这是软件工程中的大忌，也最终导致我们的软件松散、不统一、代码大量重复。直到最近，我看了 敏捷软件开发 方面的书，才发现，其实这个有很好地解决办法。那就是TDD-测试驱动的开发，测试是最好的设计。为什么说测试是最好的设计呢？特别是在编写系统核心模块和公共模块的时候，如果我们编写了相应的单元测试，那么这些模块的使用者就可以从单元测试用看出我们的设计目的，也就更容易的按照类似的方式来使用这些模块。当然，单元测试还有很多其他的优点。
其次，在给客户作界面原型上浪费了太多时间。我们的想法是先做一套界面给客户看。但是，最终客户看了以后，没有提太多的意见，因为，单从界面上，很难看出什么东西来。客户需要看到可以运行的程序。所以，界面原型不是必需的，要么干脆直接建立系统原型。敏捷软件开发的思想也是这样-通过不断的交付可以工作的原型来满足和挖掘用户的需求细节。
再次，为了写文档而写文档，这在我们公司已经形成了一种风气了。经理的意思是说，一切都要见于文档。可能是因为公司的ISO评审和人员流动非常频繁两个原因。甚至，在我们这里，需求分析不叫需求分析，而是叫写需求分析文档；详细设计也不叫详细设计，而叫写详细设计文档。我就在这种说法中迷失了方向。我不知道，我们最重要生产的是一堆文档，还是可以工作的软件。
最后，项目和项目之间的依赖关系过于错综复杂，业务逻辑和数据逻辑、表现逻辑纠缠不清。理想的状态是，表现层依赖于业务外观层、业务外观层依赖于业务规则层，业务规则层依赖于数据访问层。当然，现在还有一种说法“依赖反转”，业务规则层作为数据访问的消费者，应该提供数据访问的接口，即转化了外层对内层的依赖为对双方对接口的依赖。然而，在我们的系统中，依赖关系是错综复杂的，甚至于与数据访问无关的用户控件都存在对于数据访问空间的依赖。这种依赖使系统变得异常的丑陋。那么，推荐的做法，一是避免跨层的调用，二是应该是采用标准的MVC模式。这是个非常有内涵的模式，三是，有可能的话使用依赖反转、依赖注入。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
