1. 模式知识提供了一大致的方案,是否需要添加新功能取决于编程环境,他们只是蓝图,不是死的.
2 .发现设计模式一个"通病":好象喜欢将简单的问题复杂化, 喜欢在不
同类中增加第三者,当然这样做有利于代码的健壮性 可维护性 还有复用性.
3.如果问题看起来很复杂的话,不如寻找一个第二选择.
4.按功能来设定类的角色,只考虑责任,不考虑具体的数据.
5.封装:不仅仅是数据的隐藏(汽车与伞) hiding anything and 封装一切变化了的
6.记得把设计写成文档 有时间就拿出来看
part2:
(转载)
1.考虑整个项目或者产品的市场前景。作为一个真正的系统分析人员,不仅要从技术的角度来考虑问题,而且还要从市场的角度去考虑问题。也就是说我们同时需要考虑我们产品的用户群是谁,当我们产品投放到市场上的时候,是否具有生命力。比如即使我们采用最好的技术实现了一个单进程的操作系统,其市场前景也一定是不容乐观的。
2.从用户的角度来考虑问题。比如一些操作对于开发人员来讲是非常显而易见的问题。但是对于一般的用户来说可能就非常难于掌握,也就是说,有时候,我们不得不在灵活性和易用性方面进行折中。另外,在功能实现上,我们也需要进行综合考虑,尽管一些功能十分强大,但是如果用户几乎不怎么使用它的话,就不一定在产品的第一版的时候就推出。从用户的角度考虑,也就是说用户认可的才是好的,并不是开发人员觉的好才好。
3.从技术的角度考虑问题。虽然技术绝对不是唯一重要的,但是技术一定是非常重要的,是成功的必要环节。在产品设计的时候,必须考虑采用先进的技术和先进的体系结构。比如,如果可以采用多线程进行程序中各个部分并行处理的话,就最好采用多线程处理。在Windows下开发的时候,能够把功能封装成一个单独的COM构件就不作成一个简单的DLL或者是以源代码存在的函数库或者是对象。比如能够在B/S结构下运行并且不影响系统功能的话就不一定要在C/S下实现。
4.合理进行模块的分割。从多层模型角度来讲,一般系统可以分成用户层、业务层和数据库层三部分。当然每以部分都还可以进行细分。所以在系统实现设计的时候,尽量进行各个部分的分割并建立各个部分之间进行交互的标准。并且在实际开发的时候,确实有需要的话再进行重新调整。这样就可以保证各个部分齐头并进,开发人员也可以各施其职。
5.人员的组织和调度。这里很重要的一点是到考虑人员的特长,有的人喜欢做界面,有的人喜欢做核心。如果有可能要根据人员的具体的情况进行具体的配置。同时要保证每一个开发人员在开发的时候首先完成需要和其他人员进行交互的部分,并且对自己的项目进度以及其他开发人员的进度有一个清晰的了解,保证不同部分的开发人员能够经常进行交流。
6.开发过程中文档的编写。在开发过程中会碰到各种各样的问题和困难,当然还有各种各样的创意和新的思路。应该把这些东西都记录下来并进行及时整理,对于困难和问题,如果不能短时间解决的,可以考虑采用其他的技术替代,并在事后做专门的研究。对于各种创意,可以根据进度计划安排考虑是在本版本中实现还是在下一版本中实现。
7.充分考虑实施时可能遇到的问题。开发是一回事情,用户真正能够使用好它又是另外一回事情。比如在MIS系统开发中,最简单的一个问题就是用户如果数据输入错误的时候,如何进行操作。在以流程方式工作的时候,如何让用户理解自己在流程中的位置和作用,如何让用户真正利用计算机进行协作也是成败的关键。