任何傻瓜都能写机器执行代码，而优秀的程序员写的代码傻瓜都能看懂

早上参与了这个讨论 博客：成长，就是不断向自己妥协的过程 ，此处做下记录方便后续回顾和引用。

多年以前上过斯坦福的一个开放课程 —— CS 106A: Programming Methodologies ，看的是 2008 年版，当时由语速很快幽默的 Mehran Sahami 教授主讲。

有兴趣的同学可以了解下，Bilibili 上有双语字幕视频 斯坦福大学公开课：编程方法学 。

课程内容现已记不清，但是编程多年偶尔会想起课程中他多次提及的一句话，凭着大概意思找到了 《Refactoring: Improving the Design of Existing Code, 1999》 一书中作者 Martin Fowler 有类似的观点：

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

翻译过来大概是：

任何傻瓜都能写机器可执行的代码，而优秀的程序员写的代码傻瓜都能看懂。

这跟我一开始对编程的认知相驳：

编程不应该是以运行效率为最高标准吗？

在这之前，我常用的变量是 $a ，对的，当然是 $array 的简称。并且所有数组类型的数据，都命名如 $a = User::all()->toArray() 。那如果在一个方法里有两个数组怎么办？那第二个数组我就会命名为：$_a = Topic::all()->toArray() 或者 $a1 = Topic::all()->toArray()。函数和方法名也是比较随意，本着执行效率优先，尽量使用比较简短的命名，例如 getTopicType() 我会命名为 gtt()，简短好记写起来也不费劲。

因为当时学过一点 C 和编译原理的我知道，变量名你怎么命名，问题不大，机器都能顺利执行。

当然，我已经好久没这么写代码了。多年以后偶尔看到有朋友或者同事这么写代码，也会心一笑。

为什么？

为什么要写傻瓜都能看得懂的代码？

首先应该认识到，商业软件一般都很复杂，复杂到需要一个团队来维护。而以上观点就是在团队编程这个前提下提出来的，在团队开发里，编写高可读性至关重要。

可读性不仅影响开发效率，还会影响编程愉悦性，想想你每接触一个项目就要去熟悉一大堆不规范的编码方式，很快你就会对编程产生厌恶心理。

可读性不仅仅表现在变量和方法的命名上，软件架构选项、设计模式的选择和新增，这些都会影响其他人对项目理解难度。可读性的代码会增加维护成本，从而降低软件的健壮性和稳定性。

所以不要在某个地方学了 Repository 和 Command Bus 设计模式，就迫不及待的在公司项目中使用。对于商业项目，每一次新的设计模式引入，都要非常谨慎，建议和团队成员充分讨论后再操作。可以从下面几个问题开始：

• 是否增加了学习成本？
• 是否增加了维护成本？
• 是否会降低了开发效率？

简而言之，这是一个『软件工程（Software Engineering）』的范畴，需要考虑的不止是软件编码，还需要把软件参与者、项目管控和商业效率等因素考虑进来。

结语

Laravel 框架作者和 laracasts.com 作者在往期的 Laravel 播客 中提到，他们会用 50% 的时间来编码，剩下的 50% 的时间来考虑如何命名。因此可见，Laravel 的优雅是有原因的。

本作品采用《CC 协议》，转载必须注明作者和本文链接