设计原理整体思考

一。引言

具体问题的设计方案根据实际场景千变万化，其背后的设计原理几乎从未未改变。设计原理是比设计模式更抽象一级的方法论，接近于哲学。高度的抽象使得设计原理使用范围很广，小到代码书写，方案设计，大到生活的方方面面，都非常有价值。设计原理都很简单，原理的使用并没有它外表那样简单，因为辩证论的二分法，任何原理都有适用和不适用的场景，不要因为名字带原理，就认为绝对是正确的，需要在解决问题的实践中进行权衡。在原理的理论学习和实践的结合过程，会经过一些迭代和反复，本文尝试展开自己对于原理的体验过程，希望能对原理的探索者有所帮助。我的学习过程大致分为下面三个阶段。

1.1 尽信书阶段

尽信书，学习到原理后，有机会就会用上，容易形成过度设计，系统搞的比需要的更复杂，收益却不高。

1.2 不信书阶段

针对过度设计的问题，有时候会产生逆反心理，干脆直接分析具体场景的痛点，并直接独立思考来解决问题，这个过程往往比“尽信书”阶段更实际高效。

不信书阶段的思考：针对每个独立思考的解决方案，应该沉淀下来，不然每次都要解决重复的问题，并且你如果都不能沉淀下来，伴随一个个的问题，如何证明自己的能力呢？说出来，表达不出来的能力，并不是真正的能力。好，进行沉淀总结，抽象为方法论，当我花费大量精力沉淀出方法论的时候，会发现这些方法论就是前辈们已经总结出来的“设计原理”，前阶段并不是“设计原理”本身有问题，而是自己只了解了部分“设计原理”。

1.3 独立思考+理论参考

不要想着去发明或发现一个新的理论，如果能把人类已有的知识能够熟练运用也很优秀。这个时代，如果你独立思考问题，以为发现了某个想法，大概率很多前辈也曾经发现了，并且有人总结好了。所以要把独立思考和读书结合起来。书的作用我的理解和大部分人并不一样，书并不一定能教会你东西，一定程度上懂的人自然懂，不懂的人还是不懂。看书更多的是加速器和共鸣，书只可能是把你潜在的一颗种子成长为一颗大树，更多的是加速这个过程。

不去发明并不意味着照抄，针对于理论我们还是要独立思考，独立思考可以理解为自己独立的再重新发明或发现一次理论。不去发明也不是说就不能发明，独立思考过程如果发现了他人未总结的理论，当然更好，只是说这个概率很低而已。

给一些优秀但只专注于独立思考的设计者的忠告：优秀的设计者确实可以不用参考设计原理以及设计模式等前人经验，独立的完成问题的可行解决方案。但如果参考下相关经验和原理，站在巨人的肩膀上，是可以做出更优秀的设计。我们要做的是带着怀疑和学习的精神来参考，既然勇于怀疑权威，同时也要对行业先行者总结的原理怀有感激和尊敬。

总结：

• 一方面：我们要多了解行业内的设计原理，包含设计原理的反向原理，不要偏听偏信。
• 一方面：我们要忘掉原理，进行独立思考，去重新走下创造出这个原理，再和原理共鸣。

二。项目实践中的一些原理思考

本部分的原理来源于一些项目中的思考，有些是独立思考的结果，有些是对于原理的使用心得。

问题与答案

”很多时候，别人来和我讨论问题的解决方案，很多我都会追问，然后呢？然后呢？然后呢？不断逼问提出问题面临真正的痛点是什么？识别到了问题真正的痛点，很多问题就解决了。“当你真正的识别到了问题的本身，大部分问题已经有了答案“。很多问题不是解决方案不好，而是根本没有认清问题，药不对症。此时受过度设计的影响，开始抛开理论的束缚，直接通过问题的痛点思考解决方案，确实有很多收获。

业务逻辑与代码

在团队的代码评审中，发现很多人的代码之所以有问题，并不是编程技艺问题，而是对于业务逻辑的理解就有问题，代码只是业务逻辑的一种表现形式，业务逻辑理解都不对，实现代码怎么会正确。不应该在代码中去讨论业务逻辑，而是应该在代码之前先梳理清楚业务逻辑。具体参考《先梳理业务逻辑再写代码》。

利益驱动原则

自己在设计中，尤其是在过度设计阶段，深刻体会到设计都是有成本的，设计带来的灵活性一定要能Cover住成本，才有实施的必要。如果一个系统处处有设计，不如处处没有设计。所以不管评审团队成员的设计，还是自己的设计进行评估，我不再关注于设计本身，不存在放在那里都适用的设计。评价的标准是非常势利的，”利益驱动“。你这个设计的收益是什么？带来的成本又是什么？是否赚了？利益驱动也可以用到代码的写法评审中，先不要说编码原理，这样写和那样写我们到底有什么我们可以感知的切实的收益，有收益的写法就是好写法。

为啥这样写？因为代码规范。为啥这样设计，因为这是X设计模式。这种答案并不能说服我，需要的是这种规范或模式在此时场景起到的作用。

利益驱动的行业参考：利益驱动是自己独立思考得出的，通过参考业界，其实利益驱动并非自己第一个发现，利益驱动的使用非常普遍，比如google的代码评审规范，并不是所有的规则都是死板的，虽然有规范，但规范本身也说明了如果可以说明特殊的写法有更多的收益，也是可以通过评审的。

Aspects of software design are almost never a pure style issue or just a personal preference. They are based on underlying principles and should be weighed on those principles, not simply by personal opinion. Sometimes there are a few valid options. If the author can demonstrate (either through data or based on solid engineering principles) that several approaches are equally valid, then the reviewer should accept the preference of the author. Otherwise the choice is dictated by standard principles of software design.

简单

看到很多代码，你不能说它错，代码也优雅，比如大概100行实现的。但是为了达到同样的目的，独立思考下就会发现另一个思路30行代码实现。如果你沿着写代码人的思路，代码可能没有问题。问题出在了方向上，”简单“，为了达到同样的目的，应该选择最简单的路线。本条规则不仅仅适用于代码，设计同样也是，可以走通的设计，是否真的足够简单，是否复杂的地方都有收益，无法用简单的思路进行替代。

简单的行业参考：简单在多个实践中，都深刻体会到是最重要的一个原则。但这个业界也是非常普遍的，比如KISS。如下google的评审规范中也有对简单的论述。

Complexity

Is the CL more complex than it should be? Check this at every level of the CL—are individual lines too complex? Are functions too complex? Are classes too complex? "Too complex" usually means "can't be understood quickly by code readers." It can also mean "developers are likely to introduce bugs when they try to call or modify this code."

先平铺直述清楚再修辞

在代码评审中，发现代码最难读懂的代码并不是几千行的长方法，而是把长方法抽取为各种不符合单一职责的小方法，方法命名和做的事情也不一致，抽取的层次也非常混乱，要想读懂，你需要人脑把这些小方法全读懂，并且人脑拼接成大长方法。”错误的抽取不如不抽取“。所以开始思考，代码书写的过程，能平铺直述把逻辑写清楚，用代码块区分下不同的逻辑块，就及格了。如果能针对复用性做出一些合适的抽取就非常不错了。我承认，这样的代码远算不上优秀，但一个团队如果还走不好的时候，一定要跑，还不如老老实实的走稳来。

夸夸其谈的未来

夸夸其谈的未来，利益驱动最麻烦的是大家就会说未来，我这么设计或代码这么写，是思考未来会如何如何？未来没有发生，怎么说都行，现在也无法考证。我自己以前也做总用未来作为设计的依据，但实际未来发生的时候，10个猜测基本不会超过2个对的，并且认为不可能的，很多都发生了。设计要针对确定性，而不是不确定性。针对未来不如针对过去，我们不可预知未来，或者说预知未来都是通过过去发生的事情，还不如老老实实的根据现在和过去来设计。程序不要提前设计，而是在发生变化的时候再针对设计进行新的扩展性设计。”不要过早的设计，设计要针对确定性“。

最小化原则

接下来说些相对轻松的，虽然这个阶段不是特别固执于原理，但有些原理确实是非常简单，并且立竿见影的。一个类，一个方法，一个变量应该有一个职责(单一职责)，评审中太多的类，方法，变量都命名非常混乱，不好起名字，问题不是出在了文学功底上，不是因为语文或英文不好，起不了好名字，而是类或方法里面做了太多的事情，没有办法命名。方法的入参呢？经常传入一些不需要的，当然这里不符合我们所的“最小化原则”，这个问题我觉得就得辩证来看了，有的时候为了扩展的通用性，可能会引入“大对象”，大对象虽然设计上认为不优雅，但如果再场景中收益真的大于成本，为什么不呢？我依然认为“利益驱动”才是最终的裁判。

最小化的行业参考：LoD，最小知识原则，对其他单元尽可能少了解，只和朋友打交道。但对于最小知识或最小化原则，并不是总是合适的。比如生活中，你需要带一个螺丝刀去修一个东西，大概率你会带工具箱去，并不会只带螺丝刀。对应程序中，我们经常会用到上下文的大对象，虽然不符合设计原则，但确实带来了方便，我认为收益够高的时候也是合适的。

重复

DRY(Don’t Repeat Yourself)原则告诉我们不要重复，《重构》告诉我们要小方法，小方法要符合符合SRP( Single Responsibility Principle)，我原来认为按照理论大方法是不对的。但在个人的工作实践中，大方法并不一定会造成不易读懂的问题，并且也没有必要为了复用而过早的抽取小方法，应该根据需要在需要的时候再抽取也不迟。这让我对于这些原理的适用性产生了一定怀疑，具体代码还是要通过“利益驱动”来分析。查阅相关资料后，不仅仅有DRY原理，还有WET，AHA，YAGNI原理，是自己了解原理太少偏概全了。

• WET原理：相对于DRY (取义干湿相对)，可以适当重复。
• AHA原理：避免过早抽象。
• YAGNI原理：在需要功能之前，不要提前实现。

总结：原理就成语，有两面性。是一定场景的经验汇集，方便传播和总结，不用从头思考。

童子军军规

设计或代码不用追求完美，但要做到比原来更好些，这个在代码评审或自己写代码的时候非常重要，没有最优，我们没必要要求完美，只要做的比原来更好就可以。下面是google的代码评审规范，只要做的比原来更好，评审就应该通过。

The Standard of Code Review

In general, reviewers should favor approving a CL once it is in a state where it definitely improves the overall code health of the system being worked on, even if the CL isn't perfect.

附：为什么使用google评审规范作为例子

我一直是比较抵触规范的，没有规范能够适用所有场景，所以规范本身不就制约了创造力？只到看到了google的代码评审规范，规范并非只是死板的规定，其中和自己一直信奉的“利益驱动”异曲同工。并且对自己认为非常重要的“简单”和“童子军军规”都非常看重，这些原理才是让代码优秀的本质驱动力。整个规范并不长，也并没有很多官僚主义的繁文缛节，也没有只适用与固定场景的傻规定，整体还是非常优秀的，对于工程质量有着实际可行的指导。

google评审规范原文地址：https://github.com/google/eng-practices/blob/master/review/reviewer/index.md