不要追求”完美”,“足够好”就行
2015-08-09 10:26
330 查看
作者:格雷格﹒纽伯格(Greg Nyberg)
软件设计师,尤其是架构师,在评估针对某个问题的解决方案时,会倾向于考虑它是否优雅完美。我们在查看设计或实现时,仿佛自己是选美比赛的评委,会立即找出其中的微小瑕疵,而这些瑕疵只须经由一些调整或迭代重构便可消除。对领域模型中是否存在可被移入基类之中的共同属性或函数过于关注;当在多个实现中发现存在重复的服务时,就大声疾呼一定要把它变成为web服务;对“从缓存中得到的”查询和非唯一性索引时,则指摘不止。
我的建议是:不要屈服于企图使设计或实现达到完美的诱惑!把目的设定在“足够好”就行,当己经达到目标时,就停下来。
你可能会问,究竟什么是“足够好”?“足够好”指的是,剩余的不完美之处,对系统的功能、可维护性或性能不会产生任何有深远意义的影响。架构和设计协调一致;系统的实现正确可用,并符合性能需求;代码整体简明,文档化良好。还可以做得更好吗?当然可以,但这样己经足够好,所以就到此为止了吧。可以宣布设计胜利完好,然后转入下一个任务了。
在我看来,在设计和实现上追求完美,会导致过度设和模糊混乱的解决方案,最终使系统难以维护。
本书中己有不少主题都在提醒设计师,要注意避免不必要的抽象或复杂性。为什么保持简单会这么困难呢?因为我们在寻求完美的解决方案!架构师无法忍受设计中可感觉到的不完美,定要除之而后快,向己可工作的简洁的解决方案中引入了额外的复杂性!
请记住,应用程序开发不是选美大赛,因此,停止吹毛求疵的做法,不要再浪费时间追求尽善尽美。
软件设计师,尤其是架构师,在评估针对某个问题的解决方案时,会倾向于考虑它是否优雅完美。我们在查看设计或实现时,仿佛自己是选美比赛的评委,会立即找出其中的微小瑕疵,而这些瑕疵只须经由一些调整或迭代重构便可消除。对领域模型中是否存在可被移入基类之中的共同属性或函数过于关注;当在多个实现中发现存在重复的服务时,就大声疾呼一定要把它变成为web服务;对“从缓存中得到的”查询和非唯一性索引时,则指摘不止。
我的建议是:不要屈服于企图使设计或实现达到完美的诱惑!把目的设定在“足够好”就行,当己经达到目标时,就停下来。
你可能会问,究竟什么是“足够好”?“足够好”指的是,剩余的不完美之处,对系统的功能、可维护性或性能不会产生任何有深远意义的影响。架构和设计协调一致;系统的实现正确可用,并符合性能需求;代码整体简明,文档化良好。还可以做得更好吗?当然可以,但这样己经足够好,所以就到此为止了吧。可以宣布设计胜利完好,然后转入下一个任务了。
在我看来,在设计和实现上追求完美,会导致过度设和模糊混乱的解决方案,最终使系统难以维护。
本书中己有不少主题都在提醒设计师,要注意避免不必要的抽象或复杂性。为什么保持简单会这么困难呢?因为我们在寻求完美的解决方案!架构师无法忍受设计中可感觉到的不完美,定要除之而后快,向己可工作的简洁的解决方案中引入了额外的复杂性!
请记住,应用程序开发不是选美大赛,因此,停止吹毛求疵的做法,不要再浪费时间追求尽善尽美。