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

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

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

多年以前上过斯坦福的一个开放课程 —— 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 协议》,转载必须注明作者和本文链接
摈弃世俗浮躁,追求技术精湛
本帖由系统于 9个月前 自动加精
Summer
讨论数量: 5
小李世界

每次站长发的一些经验帖子,都要发给同事看看 ,教材资料 :joy:

9个月前 评论
Summer

@likunyan 主要在于分享和记录哈,不是有那句话说的好:

file

尝试把一个东西简单的讲清楚,是很有挑战的事情。

9个月前 评论
Galois 8个月前
Summer

@likunyan 当然也是为了避免相同的话一直不断重复地说哈 :joy:

9个月前 评论
小李世界 9个月前

但是国内的环境不太好,除非是培训机构。一般的编程工作,很少会将代码写的很直白吧。如果编程人人都能看懂,都能学会,大概离失业也不远了吧

8个月前 评论
Summer (楼主) 8个月前
zulien (作者) 8个月前

代码是写给人看的 。现在就在维护一套极其恶心的代码 ,已经两个月了 ,对我提升非常大 ,尤其是磨练了我的耐心

8个月前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!