一直以来，不断的进行着项目的设计、开发，然而，差的设计，痛苦的维护、编码，让我不断的审视自己的设计是否有问题，在最近的一些思考、理解中，终于有了一些领悟，总结一下过去的设计，以此来作为参考和警示，以免以后再入误区。
一直以来的设计都是很粗浅的，没有做过足够的分析，就开始了编码工作，可以说直接就开展到了代码的层次，没有分析清楚自己要做的是什么就开始了，直接就准备开始实现需求了。这样做的后果就是，系统的需求不清、层次不清，因为，没有弄清楚要做的什么，要得到的结果是什么，也没有进行规范（就像接口一样，定义了要获得东西），这样就会导致需求不清，经常的改代码，而经常改代码也会导致，错误连连，之前的分析工作没做好，层次没有分清，改一处的代码可能就会导致整个代码的改动，恶梦从此就开始了。
由于上来就开始写代码，开始实现代码，对于整个项目的了解也不够，文档也没有，以后的项目维护也是一场恶梦，因为过了几个月，甚至是一个月以后，你就不知道自己做的什么了，不知道，规范是什么，要得到什么东西，又不敢轻易的改动，这个时候将是举步维艰，头痛万分，想到的估计就是要重做项目了。
由于一直以来都是这么分析设计程序的，让我痛苦不堪，不得不审视下自己的设计到底哪里出了问题。经过比较发现，我总是站在系统的最底层进行着开发，追求如何实现，任何需求来了，我想到的不是它要做什么，而是它该怎么实现，一旦当需求变化的时候，我整个写的就白费了，甚至如果它和其他地方有牵连，又是一个恶梦的开始。
站在系统的最高层，以系统能做什么，将会得到什么东西来思考问题的思想解救了我。由于从开始就定义好系统要做的东西，得到的东西，然后得到客户的确认，这样系统就定下来了，它也不容易改变了，这个时候的系统是很稳固的，当系统的最高层定下来了，就这么一步一步往下分析，系统的结构层次也会很明了，某个模块该做什么，调用了哪个模块，一目了然，复用就更不用说了，很自然的就开始复用代码了。再将这些结构以文档的方式写下来，以后的维护也会是一件相当省力的事。
由于这种思想带来的变革，使得自己从底层的代码中解放，开始了解系统架构层面的东西，如何获取需求，如何由需求推导出设计，再到编码的实现，都是顺理成章的事了，也会给自己带来更快乐，更省力的程序设计。由此走向真正的面向对象的设计分析之路。
