那为什么会讨厌写这些方案呢？因为我们在开始做事情或者思考问题的时候，总是以单点的方式去思考，那我们写出来的方案也往往非常的简单，甚至有些时候觉得根本没有必要写什么方案，直接做就行了，如果要写的话，也就一个图两行文字就搞定了。或者是我们方案写出来了，当我们去找相关的同学或者TL去评审的时候，才会发现漏洞百出，被喷得考虑得特别不全面。比如没有安全机制，没有考虑边界情况，没有考虑合规情况，边界不清晰等等。那对于刚开始工作的同学来说，还有一个很常见的思维，就是希望自己一边动手干活一边写方案，然后慢慢地去丰富我们的方案，而不是一开始就写的面俱到。所以这里面就是菜鸟和高手的区别。当然，有很多事情确实不需要写方案，比如一些简单的逻辑优化，删除一个多余的入口等等，但是大部分任务或者需求都是比较复杂的，尤其是一些战役型的项目或者产品。是否有一个清晰的方案，80%已经决定了项目的成本和交付质量。我在刚刚参加工作的时候，其实非常讨厌先写方案结构，再去补充里面的内容，往往我就喜欢你先动手为主，把一些我认为核心的东西两三句话先写出来，然后再慢慢去丰富内容和细节。但是随着经验越来越丰富的情况下，我的思考方式有了一个本质的变化。我开始尝试用结构化的思维去思考和总结问题。我之前听过一个大牛说，对于技术架构师或者一名技术骨干同学来说，80%的时间就应该用在写技术方案，画流程图梳理系统架构等等，而20%的时间才是用来真正写代码的。开始我不以为然，现在我越来越开始认同，因为真正到你写代码的时候是一个执行层面的事情，执行层面本来就不应该有特别复杂，特别需要耗时间的地方。反而如果你大量的时间用在写代码上，你要思考一下，你是不是在低水平上持续内卷了。而往往是在前期的思路比较充分，思考得比较全面的时候，你就已经解决了大部分的问题，剩下需要动手的地方，其实可以利用各种各样的语言或者工具来帮你提供效率，甚至，如果你是资深工程师的话，可以考虑把具体执行的任务分派给小弟或者外包同学。所以现在我认为我在产出各种方案的时候，我会投入大量的时间，用结构化的思维完整地去思考和认证自己的方案的闭环性，可执行性以及里面最大的风险点是什么。我在思考一个问题的时候就会变得更加的全面，而且采用结构化的思维，就是能够在更高的一个维度框定自己对于某一个事情，某一个方案，某一个产品的骨架。把核心的思维结构图想出来了，剩下的就是用各种材料补充和丰富就可以了。这样出来的技术方案，你会发现特别的完整，特别的有说服力。最后再提一下，为什么要特别提到「奥卡姆剃刀原则」？奥卡姆剃刀原则（Occam's Razor）是一种科学哲学原则，它的基本思想是，当有多个假说可以解释同一个现象时，我们应该选择那个假说，它所需的假设最少的假说。简而言之，如果有多个解释同一个现象的假说，我们应该选择那个假说，它所需的假设最少。这个原则是由14世纪的英国修道士威廉·奥卡姆提出的。奥卡姆剃刀原则在科学领域中经常被引用，因为它有助于简化科学问题和方法，并有助于防止过度解释和不必要的复杂性。刚才我们提到我们用结构化思维的一个前提，就是我们要用这种树状的结构来梳理出我们整体的框架，但是我们经常会发现写着写着会出现相关的问题，有些东西是累赘的，有些地方是不需要的。所以对于我们产出的方案，我们一定要用奥卡姆剃刀的思维去优化。那么奥卡姆剃刀的原则就是”如无必要，勿增实体”。换句话说，就是对事情的观察和描述一定要简明扼要。这个在写方案和思考问题里面特别有用，那么在我们写一些方案的时候，如果我们发现有一些点可要可不要的地方，那么我们一定就不要。有些模块或者流程我们写上去觉得没有什么帮助，就一定要删掉。这里我再举一个例子，我之前在设计对象或者数据库字段的时候，都会冗余出一些字段，生怕字段不够导致后面的扩展性变得非常差。因此我们在对象的定义和数据库结构的定义上就会非常的纠结，一定要想的非常的全面。事实上我们发现我们最开始预留出来的字段从上线到业务死亡这些字段都没有用到。这种非常典型的就是一种对于不确定性事情的过度担忧和设计。所以我们之前的线上数据库就出现了很多从来不会用到，但是我们不知道为什么会存在的字段。因此我现在的做法就采用了奥卡姆剃刀思维，如果是不必要的字段，我一定不会设计和添加上去。那这种是不是未来真的就没有办法解决扩展性问题呢？我的考虑是这样的，第一个我们所谓的大部分事情其实本身扩展性就没那么强，也就是在你刚开始想到的时候，往往就有可能是囊括了一个对象的所有生命周期所需要的内容。第二个是我们相关的对象和数据库本身也是迭代的，这些东西本身也支持在运行期间去更新和扩展，代价和成本并没有那么大。所以这个就给了我们一个提醒，我们没必要在初始化的时候就考虑得十全十美。甚至在初始化的时候，我们往往应该考虑得更加的精简，以实现最方便的快速上线和试错。再举一个简单的例子，比如我有些时候在用结构化的方式来写整个文章的大纲，但我发现突然有一些分支或者章节完全没有存在的必要，于是我又把它合并到一起，这样看起来就变得更加的清爽了。还有一些是对于外部内容的引用，我只是简单地把它插入到文件里面来，我也不需要对外部引用的文章再做非常复杂或者详细的介绍。综上所述，一篇技术方案或者文章写下来一定是非常简要精简的，不应该有长篇累赘，不应该用重复的话语去描述一个事情。一篇好的技术文章，我觉得就应该像电影一样，一部好的电影不应该有任何一个多余的画面和多余的伏笔。每一个章节，每一个角色，每个人物，每一个布景都有它存在的价值。并且最终剧情环环相扣，有高潮，有低谷，有起承转合，最终构成了一个个经典的电影艺术品。写技术方案也是一样，每篇技术方案应该结构化、精简，能够庖丁解牛般地描述清楚一个产品、一个系统、一个模块的核心思路。因此，结构化思维和奥卡姆剃刀原则，值得每个技术同学仔细揣摩一下。
