代码过度设计，真的有意义吗？

看着自己每次根据设计原则及模式的代码重构，虽效果不错，但也自省：如果我的每段代码都这么写，是不是过度设计？把握设计的度，需长久锤炼。行业也总结了很多原则，帮助我们把握设计的度。它们是一种思考方法、一种行为准则。,Keep it simple, stupid，保持简单、愚蠢。提醒我们大多数系统，与其变得复杂，保持简单能让系统运行更好。越资深的人，越觉得这大有道理。因为大佬们见识过因为复杂而引发的各种问题。堆太多功能，调整起来就很费劲：,真是吸引crud boy，但无法指导具体工作。啥叫保持简单，怎么就叫复杂？这都没标准。有人基于自己的理解给具体原则：,You aren’t gonna need it，你用不着它。如非必要，勿增功能。软件设计对抗的是需求规模：,很多需求不需要做。很多产品经理以为很重要的功能实际上是没什么用的。真正重要的功能大约只占20%。做了更多的功能，并不会得到更多的回报，但是，做了更多的功能，软件本身却会不断地膨胀，越难维护。,所以，在现实经常看到一些功能简单的东西不断涌现，去颠覆更复杂东西。如Word强大，但只是个写字工具，重点排版功能都用得少。而Markdown简单地让我们专注写内容，而且简单的几个排版标记在日常沟通中就完全够用。尽量可能不去做不该做的事，从源头堵住问题。,Don’t repeat yourself，不要重复自己。在一个系统中，每一处知识都必须有单一、明确、权威地表述。Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.,即不要做cv工程师。这还远远不够，DRY针对的是你对知识和意图的复制：在两个不同地方的两样东西表达形式不同，但表达内容却可能相同。如下打印账户信息：,这段隐藏一些重复。如对负数的处理显然是复制的，可通过增加一个方法消除：,数字字段格式反复出现，不过，格式与我们抽取出来的方法一致，复用：,打印格式其实也重复，如果我要在标签和金额之间加一个空格，相关的代码都要改，所以，这也是一个可以消除的重复：,重构后：,有人说这种调整粒度太小。如你这样感觉，证明你看问题的粒度太大。品味这个修改，与分离关注点和单一职责原则异曲同工：粒度要小。,DRY不局限于写代码：,都是在试图减少重复，其实也是减少了维护成本。,Simple Design，提出者Kent Beck，只包含如下规则，后3条规则是重构方向,保证系统能按预期工作。怎么知道系统按照预期工作，就需要有配套自动化测试，最好能TDD，最根本的还是要懂设计，否则，你的代码就是不可测。,正如DRY，你得能发现重复，就要会分离关注点,编写有表达性的代码，这也需要你对“什么是有表达性的代码”有认识。代码要说明做什么，而不是怎么做,让类和方法的数量最小化，不要过度设计，除非你已看到这必须要做个设计，比如，留下适当扩展点，否则，就不要做。能做出过度设计的前提，是已懂得各种设计，这时才需要用简单设计的标准对自己约束。所谓简单设计，对大多数人并不“简单”。,没有良好设计，代码就没有可测试的接口，TDD就无从谈起。不懂设计，重构就只是简单提取方法，改改名字，对代码的改进相当有限。,简单设计的前提是，把编程基础打牢。片面地追求敏捷实践，而忽视基本功，是舍本逐末。,