“穿的越少越好”在夏天说和在冬天说是不一样的

本次我们从4个话题来分享。

第1个话题：

ER数据建模也是一种建模方法。在这个过程中将事物抽象成【实体】【属性】【关系】，进而来表达现实世界事物的描述。比如一个商品、一个订单、一名老师等等这是实体，然后商品的颜色、重量、大小这是属性，一个订单包含多个商品，或者一名老师购买了多个商品，这些是关系。

是的，早先的时候，对于简单的软件产品，软件研发人员直接创建了E-R关系图，我们用工具标识出了实体与实体之间一对一、一对多、多对多的关系，那个时候我们就是在做ER数据建模。其实很多复杂的软件产品我们也是这样做的。

采用ER数据建模之后，就到了我们的CRUD操作。而我们在这个过程中也把CRUD当成了业务，创建用户代替发展新用户，创建订单代替下单，创建商品代替发布商品。你会发现，一旦套上了CRUD就失去了业务原有的语义。很显然，创建用户和发展新用户所要表达的含义是不完全一样的。

我们建模的目的就是让建模要忠于输入需求的目标。

当使用CRUD这样的通用词替代业务术语以后，最大的遗憾是丢失了术语背后的上下文—在冬天说“穿得越少越好”与在夏天说“穿得越少越好”是不一样的。失去业务上下文以后，设计的逻辑性将很难去追溯和质疑。

因此，为了更贴近现实世界，触及现实世界事物之间的关系，反映现实世界的真实反映。我们更愿意使用面向对象的分析，或者是像DDD这种领域驱动的设计方法，而不是数据驱动的设计方法。

诸如此类，比如西红柿是蔬菜还是水果？分得清这一点，也就理解了业务语义。

第2个话题：

《代码大全》这本书阐述了一个核心的观点：解决软件的复杂度是开发软件最核心的问题。什么叫复杂，比如我要增加一个功能，修改了一处代码，结果却引起好多地方连锁故障反映，更为严峻一点的是，bug满地，修改了一个，却导致整个系统崩溃，不修改反而程序还能运行。这种情况肯定是复杂了，更进一步讲是技术债务“堆山”了。

更进一步细致地讲，大致是出现了下面的情况。

组件间依赖混乱，职责不清晰；

组件、文件、函数太大，包含的内容太多；

使用不必要的、复杂的设计范式；

函数、接口参数太多等；

当然，解决一个复杂度问题的最基本的方法是：大化小，多化少。

把一个系统拆分成好多个子系统，把一个模块拆分成好多个子模块，使得作为一个人的程序员的大脑，可以面对有限的信息。乱、多、绕对机器不是问题，但是让人就会认知消化不了。

我们有的同学写代码，只考虑了功能的实现，一丁点都没有考虑功能的扩展，这样的结果，就是造成上面那种僵化的现象。将来没人敢动你的代码，包括你自己。

繁和简之间，怎么界定呢，有什么标准么，其实可以直接用单一职责原则，它是所有原则的基础原则。

但是呢，有时候我却不建议你，一开始就把代码写得“八面玲珑”。

拿我们人人都讨厌的重复代码来讲，更有一个原则叫做DRY，不要重复自己。可很多时候，刚开始的重复也不一定是坏事。

很多时候，重复的代码可能会带来相当大的优势，重复能拖延决策，这是软件开发的黄金。

怎么理解。

把重构的决策延迟一段时间。如果一开始，刚有一处功能代码的时候，你对之进行DRY，这很有可能导致出现不存在的抽象，也很有可能是无中生有的创造。

第3个话题：

让你讲清楚万有引力是怎么回事，估计很难，因为万有引力是一件复杂的事情，所以那个时候牛顿用他的观点提出了牛顿力学来解释万有引力是怎么回事。可是在那个当时的年代，大家也不太容易牛顿力学。这样就造成了一个现象：解决复杂性问题的方法本身可能也具有一定复杂性。

随着时间的推移，知识点被应用、讨论得越来越广泛。之后，你会发现，原先用来解决复杂性问题的“复杂方法”就不那么复杂了。比如，现在初中课本里面就学到了牛顿力学，相信所有的初中生都能够理解万有引力的基本知识。

像DDD这个东西，就有点类似这样的情况。本身DDD是被用来解决软件复杂性的方法。但是很多初学者会觉得DDD复杂，较难掌握，行话也多。但只要这个方法的方向是对的，在日常的生产实践中，被频繁的使用，实验，那么相信将来大家一样会很容易的接受DDD的方法。

第4个话题：

不喜欢了解业务知识，更喜欢学习技术知识，因为像高并发、大数据量、队列机制等等这样的技术说出来就显得”高大上“，如果你的简历上写着你熟悉购物车流程、熟悉订单流程，好像吧，就是不如前面那些技术词汇“牛掰”。所以呢，程序员们很乐意钻研那些中间件、MQ等等，然后将来把它们写到简历上，感觉更为充实。而不愿意主动去了解、熟悉业务知识，大多数时候都是迫于需求交付和实现，被动得去熟悉业务知识。

这样的结果就是好多程序员为了技术而技术，程序员里面一批一批的人去攻克技术难题，而不是业务建模难题。实际上，互联网也好，传统企业也好，软件开发的技术发展到现在，基本都是有很成熟的基础技术来支撑了。

稳定、性能、扩展。稳定和性能在互联网里面有很多像容器、Redis等等这样成熟的技术来搞定，反而是业务上的扩展更有挑战性，只要业务发展，需求就会增多、变化，就要在原先的代码基础上“添砖加瓦”。业务建模不完善，代码的结构型不合理，当你手里拿着“一块砖”的时候，你可能会发现，我到底该往哪里放呢。可能就是没有地方放，最终你的软件代码扩展受限。

在软件开发的过程中，高效率不一定代表高质量，但软件的高质量却能带来高效率。

参考资料：

《复杂软件设计之道：领域驱动设计全面解析与实战》