原文:
”在项目中担任过分析和设计工作的人,对于下面一些问题,一定会与译者一样深有同感:.
1. 概念混淆,术语混乱—— 在讨论时,经常发现不同的人把同一个词理解为不同的概念,导致沟通无法顺利进行;
2. 设计似乎很难理解—— 开发人员无法很快抓住设计的重点,甚至会出现不同程度和方向的曲解;
3. 代码也很难理解—— 阅读代码比编写代码更痛苦,即使它严格地遵循了缩进规则和命名规范;
4. 当需求发生变化时,发现要对设计作大量修改——框架、模式似乎并未带来所需的灵活性;
5. 当系统的复杂性达到相当程度时,整个项目似乎会无可避免地滑入“焦油坑”,或者为维护工作而疲于奔命。“
解决方式:
1. 订立业务领域的词典,在项目组中规范用词;
2. 设计没有反应业务的本质,从根本上来说,是没有深刻理解业务造成的;
3. 主要的原因就是第二条,没有好的设计,哪里来好的代码结构,即使它严格地遵循了缩进规则和命名规范;
4.框架和模式只是工具,并不是万能灵药,没有对业务的深入思考,只会错用,滥用框架和模式,并将随后导致恶果的原因推到框架和模式的身上;
5.设计和代码一样,需要时时的加以维护并在必要时重构,才能保持灵活性;