本文内容是训练营一学员跟我在群里聊设计时候的一些对话，做过一些裁剪。
我：首先，设计的确是一个仁者见仁智者见智的事情，没有对错之分。从业界大佬的经验来看，结合咱们公司的上下文，我提供一些参考（并非标准答案或正确答案）：
好的设计应该可以用四个字表达：简洁可用，可用是一切的基础。假程序员连可用的代码都写不出来，一般的程序员能写出可用的代码，优秀的程序员更容易写出简洁可用的代码。简洁的一个评判标准是容易理解，什么样的代码容易理解？跟业务模型越接近的代码就越容易理解，这就很考验一个人的抽象建模能力了，需要长时间的经验积累和提升。
如何要做到跟业务模型一致，有几个参考是：
- 尽可能用业务概念
- 代码中模型关系尽可能与业务中模型关系保持一致
这也是徐八叉在讲到为什么要做DDD的时候说到：为了让代码更容易理解。
Kent Beck提出的简单设计并不是提倡简单了事而不考虑设计，正是因为他考虑到当前的设计如果能跟业务保持一致就是当前最好的设计，容易被理解，没有让人困惑的技术健壮性。
那这是不是意味着就不考虑未来的变化了呢？恰恰是因为考虑了这一点，所以才不会去做未来设计，因为不知道未来会怎么变，现在唯一有信心的是保持系统足够简单，等未来变化真的来临时，也能很容易通过重构做出新的设计，这跟提前做了兼容设计的区别是延迟决策，而且还能始终保持系统当前处于简洁状态。
但如果未来变化未发生，我也不用做这个设计了。另外，如果提前做了兼容未来的设计，如果未来变化不是我预测的这样子，这可能是浪费，而且在屋群中拆掉一座房子比刚开始建的时候成本会更高。
所有以上内容不关乎任何具体系统架构（比如分层架构），只限于代码设计，通过软件建模来解决现实复杂的业务问题。
学员：我是非常赞同这些的，我觉得其中就是没细讲一个点，就是这个所谓的是否兼容变化，不是一个非黑即白的东西，难道代码要么就是兼容变化的，要么就是完全不兼容的嘛？我的侧重点就是我们完全不考虑兼容是会导致代码缺乏设计 后面重构会成本激增
我：因为考虑兼容总会然人难以把握，要兼容到什么程度呢，多一点？少一点？兼容东？兼容西？可能每个人都有不同的看法，这就会导致A的兼容设计，B看着很困惑，B的兼容设计让C又很困惑，为什么会困惑呢？因为每个人的兼容设计都有自己没有明说的信息，而这些信息却在当前业务没有任何体现出来的，这就导致别人对着业务需求看不懂代码，而理解困难是软件难以维护的根因。
我：有了跟跟业务保持一致这个理念为前提，不用去做兼容未来需求的设计。在实现细节上，比如用List代替数组能有更好的兼容性，这个兼容性不是我所说的兼容性，澄清一下这个~
学员：我举个我们这个作业的例子哈，比如我们现在可以直接把每一丢的积分存成一个列表，然后也能完成业务需求。但是这个时候责任的分配就混杂了，Round的概念被揉进了match里，后续如果对于每个Round需要有新的变化，这就没有一个数据结构可以让我去扩展
我：理解你的点，你用Round也是更好的跟业务模型匹配，业务模型里面就有Round这个概念
学员：对， 是这个道理
我：所以我说嘛，我一开始是想通过提问引导你说出更接近的表述，你的表达其实就是说：软件建模跟业务建模保持一致，以后不要用数据结构来表示哦~
学员：好的!
网友评论