架构师前辈告诉你：代码该如何才能自己写得容易，别人看得也不痛苦

来源 | 编程新说

责编 | Carol

头图 | CSDN 下载自视觉中国

切身感受

在这个世界上，最难看懂的文档，永远是同事写的需求文档。最难看懂的代码，永远是同事写的业务代码。

我很纳闷，像Spring这样的官方英文文档，我看起来也不太费劲，但是需求文档，我却要花费极大力气。

像Spring这样的源码，我读起来也尚能较好应付，但是业务代码，我却常常需要绞尽脑汁。

清晰 VS 混沌

如果一道高考证明题的作答，是卷面清晰，字迹工整，说明考生当时的思路是清晰的。

相反，如果卷面凌乱，写了之后又划掉，划掉之后又再写，说明考生当时的思路是混沌的。

对高考作文来说也是一样的，一气呵成的一定是思路清晰的，修修改改的一定是思路混沌的。

思路清晰的作答，正确的可能性更大一些，思路混沌的作答，错误的可能性更大一些。

就像狙击手一样，一定要一发命中，否则便暴露了自己、丧失了天机、影响了情绪，几乎不可能再命中了。

需求文档写的不清晰，是因为需求人员自身对需求的认知就不清晰。代码写的混乱的，是因为开发者自身的思路就是混沌的。

相同的东西，不同的宿命

北方有些省份早晚都是吃稀饭的，我家乡就是。

面粉和水就可以做出一种稀饭叫面汤，如果加几个鸡蛋进去，口感会更好些。

然而同样是面粉和水，只要把比例变一下，最后做出来的就是浆糊。可以用来粘东西。

我们经常听到一个比喻，说场面乱成了一锅粥，其实粥还好，要是乱成一锅浆糊，那才是真的乱。

如果我们要建造一个普通的平房，那几乎不用准备什么，直接按自己的思路走就可以，最后也不会有太大出入。

如果要建造一座复杂的房子，那必须要先设计好造型、画好图纸，这才能保证造出来是自己想要的样子。

同样是面粉和水，一个成了面汤，一个成了浆糊。同样是一堆建材，一个成了平房，一个成了别墅。

为什么相同的东西最后却落得不同的宿命呢？其实不在东西本身，而在它的主人，主人掌握了它们的命运。

主人精雕细刻一些，那就是工艺品，主人粗制滥造一些，那就是日用品。

渴望美丽，追求美好

工具都是一样，代码却是不同，原因不在于语言、类库或IDE，而在于写代码的人。

水平和能力只占次要原因，主要是认知和态度。

这些写代码的人只把代码当作“日用品”，压根儿没想过把它变成“工艺品”。

要知道代码除了被服务器运行外，也是要被人看的，怎么说也要讲究点美感吧。

我们从小都知道踏青和春游，那是因为春天万物复苏、柳绿花红、春意盎然。不仅是视觉上的盛宴，还有心灵上的享受。

我们从来没见过像下面这样的诗句：

脚踩干枯的野草，手拿落叶的光棍，眼望满目的疮痍，背对凄凉的大地，内心万念般俱灰。

这种场面应该不会有人追求，是吧。

前戏做足，水到渠成

我对画画不太了解，但是我知道有个成语叫胸有成竹嘛，就是在画竹子之前，大脑中已经有竹子的样子了。所以画画就是一个对物体的复原过程。

随着计算机科学的发展，软件行业也得了较大的发展，三维立体图，三维动画，各种仿真程序等做的越来越逼真。这对各行各业都起到了极大的推动作用。

比如在一栋大楼开工前，它的三维立体模型就用软件做出来了，跟真的一摸一样。那么在实际建造时，就是一个复原过程，只需解决工程问题即可。

同样在装修开始前，装饰公司也会用三维软件把装修后的效果图给画出来，我们可以调整配色方案，调整家具布局，这样最后装出来的才能最大限度的满意。

写代码也是一样的，如果提前不规划，想到哪儿写到哪儿，结果很可能就是混乱的。不仅别人很难看懂，自己过段时间也会迷糊。如果再没有注释的话，简直就是噩梦。

当然了，写代码要想做到“胸有成竹”，其实也是很难的。但是大脑中必须有个七七八八的样子，这样写代码的过程就是对自己想法的复原过程或实现过程，这就叫做代码实现。

所以“代码实现”的含义就是，已经做好了设计或已经有了成熟的想法，然后采用写代码的方式来变现。而不是啥也不想，一上来就一通乱写。

就像从来没见过，哪个人在街上看到个美女就立马上去表白的，这样的结果不是挨骂就是挨揍。所以，无论做什么事情，前戏一定要做足。

模型化是必由之路

其实“建模”这个词我们每个人都知道，而且都听过无数次了，我自然也是这样的，但是我以前一直没有认真思考过这个问题，所以对建模也没有什么深刻印象。

直到我从事软件开发几年后，我发现如果能把复杂的问题在生活中找到一个与之相似的场景，这样问题可以得到极大的简化，真的是极大的。

这其实是一种“转换”的思想，把不熟悉领域的问题转换到熟悉的领域去解决。当然这也是一种“模型”思想，因为在我们熟悉的领域必然存在很多我们熟悉的场景，而场景就是模型，或者说是简化的模型。

举一个转换的例子，以前科学家在地球上观测火星，记录了很多时间和位置数据，最后把火星的轨迹画出来，发现是一团乱麻。可是我们都知道火星的轨道明明就是椭圆啊。

这需要一个前提，就是以太阳作为参考系才是椭圆。但是科学家是在地球上观测的，是以地球作为参考系的，因此画出来的是火星相对于地球的轨道，是非常复杂的。

这里讲的是参考系或坐标系的转换，可以极大的简化天体的轨道方程。我记得高中物理中也有通过转换坐标系来简化解题过程的。

把复杂的领域转换到简单的领域，把不熟悉的领域转换到熟悉的领域，很多熟悉的场景自然浮现，很多适合的模型也会灵光乍现。

操练一把试试

老话说得好，“光说不练假把式，光练不说真把式，连说带练全把式”。这次咱们来个全活儿，从头到脚的“大保健”，有说也有练。

首先需要郑重说明的是：

在对未知事物探索的过程中，不存在严格意义上的对错，也不存在严格意义上的好坏。

只有一个八字方针，那就是：大胆假设，小心求证。

我希望读者朋友不要以对错好坏去评价这个世界上的任何人和事。这不是一个非黑即白的世界，这是一个五彩缤纷的世界，同样，这也是一个真实的世界。

假设领导让你实现一个限流方案，可是你对此没有一点概念，说白了就是束手无策，因为你从来没有接触过编程中的限流。

此时我们要把不熟悉的领域转换为熟悉的领域，那么什么领域是我们最熟悉的呢？当然非生活莫属，那生活中有限流场景吗？

非常之多，经过这次疫情之后，我们应该对限流更熟悉一筹。下图就是2月份在我家楼下拍的，超市八点半开门，我去晚了，所以要排队等待。

这其实就是一个限流场景，因为怕人员太密集的话，会增加互相感染的风险，所以在人为的控制。

我们一起来分析下，看这个场景中有哪些值得我们关注的方面：

1、所有人进入超市前都要测体温（后来还要扫码），也就是说需要满足一定条件才可以进入，这叫准入门槛。

2、体温并不是自己测，而是由专人为你测，所以这个人就是准入门槛的执行者。

3、超市空间有限，一次进入的人数是有限制的，要保证低的人员密度。所以有专人查看着密度，一旦达到临界值便通知门口测体温的，不允许顾客再进入。或者测体温的自己记录好进入超市的人员数目也行。

4、当超市内人员密度降下来后，或者出去一定数目的顾客后，才允许新的顾客进来。

5、当超市内顾客购物时间过长时，会有人提醒他们赶紧选购好去收银台结账，外面还有很多人在排队等着呢。

6、当体温不合格时，会被拒绝入内，或者直接打120把人拉走。（我没有遇到过不合格这种情况）

7、外面很多人排队时，可能还需要一个人来维持队形或秩序，或给一些解释说明，甚至安抚。

8、有些人排队时间较长，等不及了，就选择放弃，然后自行离开了。

这就是生活中真实发生的且我亲身参与的限流场景。对于这个普通的甚至有些平淡的场景，我们随意分析一下，竟然分析出至少8个方面的问题。

所以我就想问一句，对于那些想成为优秀程序员或架构师的人，你们是否真心愿意花时间和精力去琢磨和分析这些各个方面的问题，如果愿意，那恭喜你，如果不愿意，那也恭喜你，至少是遵从自己内心的选择。

这个场景中描述的限流方法是有效的，因为最终解决了问题，大家都买到了菜，而且整个过程中人员也不密集。

我们可以把这个场景（或模型）中的限流方法转换到编程中，如果代码写的没有问题的话，一定是管用的，因为它的有效性已经在生活中得到了验证。

不过话说回来，肯定不是原封不动的直接照抄过去，要根据实际的情况和需求进行适合的取舍和定向的改造。毕竟生活领域和编程领域还是有差别的。

当然了，即使最后不采用这个方法，但是，它也为你打开了思路，不再让你没有方向，不再让你寸步难行。

最后送给读者朋友一个祝福（或期望）吧：

勤学习，多思考，要总结，会分析。凡事多向自己熟悉的领域靠，但也要有挑战未知领域的勇气。