掌握5个基本概念,让你写出好Code

掌握5个基本概念,让你写出好Code

Bug 少、表现好、易于更改。好的程式码影响深远,而且大概是大家公认高效率开发者背后的重要因素之一。儘管如此,新手还是很难理解什幺是好的程式码,大部分的相关文章会有整理很多没有前后因果的小秘诀,但新手开发者怎幺可能全部背起来?比如说,光是这本程式领域的经典《软体建构之道》,就有 960 页这幺厚。

我相信能建立一种心态架构,是能超越任何语言和函式库,让人一开始就能产生好的程式码。这里提出 5 点概念,记住这些原则,写出好的程式码将非难事。

1. 避免特立独行的程式码

当你看到文章谈到新技巧,瞬间惊为天人,一定忍不住就想用来写些聪明的程式码来让你的同事眼睛一亮。

问题是,其他人其实只想把 bug 修好,然后继续处理其他事。所谓的聪明小技巧只会让人分心。就像我在「Applying neuroscience to software development」一文所说,当人们需要消化你写的那段程式码,他们脑袋里的 stack 堆叠就会塞爆,而变得难以运作。

掌握5个基本概念,让你写出好Code
如果需要你来解释才能懂,就不要把程式码弄得太有个性

别用「你自己的流派」写程式,照标準来写就好。这些东西都已经有标準做法了,照大家习惯的方式来写,能让你的程式尽量好预测又好读。

2. Divide and Conquer

複杂的程式码通常能利用模组化技巧来整理,而且除了创造更多函式以外,还有很多方法可以达成。把一项长条件的结果放在一两个变数内,就是取代呼叫函式 overhead 系统开销的模组化方法之一。这样一来还能用它们组成更大的条件式,或是在其他地方重複使用这些结果。

这个拆解问题的方法,要尽量让每个部分保持集中,影响範围只留在本地状态,不要混进其他不相干的 issue,可能的话尽量避免副作用。程式语言和函式库通常都带有各自的 issue,把这层影响抽掉能够让你的程式码专注在自己的工作上。「单一责任原则」也是在强调,专注在本地程式码可以产生好的设计。

掌握5个基本概念,让你写出好Code
我喜欢利用变数来釐清逻辑

TDD除了成功实行带来的好处以外,还强迫大家採用一些之前没那幺热门的準则。之前无状态的程式码被嫌弃又慢又没必要,而现在大家都在谈纯函式。就算你没在用 TDD ,也该了解一下背后的原则。在新的规範下工作能让你成为更坚韧的开发者。

3. 分散且可行

写程式的时候,电脑和工具面对的困难跟程式设计师差不多,而程式愈複杂,要使用的前端处理程式和变体就愈多。

先不说额外建置工具的优点,它们有很高的机率会要你用像自订模板或杂凑表格之类的複杂动态资料架构等等限定範围的语言。整合开发环境通常在这方面的表现都不太好,要找到相关的程式片段就会更加困难。

避免使用你的 IDE 支援度低的扩充和程式,它们带来的冲击,远远超过简化架构或节省几行程式这些微不足道的好处。

掌握5个基本概念,让你写出好Code
使用 ServiceLocator 也是和 IDE 整合不佳的例子之一

另一个保持 IDE 整合度的重点是避免使用 magic code。大部分的语言都会提供一些方法让你写出更动态的程式,但滥用这些像是魔术字串、魔术阵列索引和自订模板语言等功能,会产生一个更难连结的 codebase。

通常只有人类才看得懂的程式码,就会让你走上这条难以回头的路,因为如果你的 IDE 看不懂这些程式码,那当你想要换到更静态的架构时,它所有的重构功能都没用了。

4. 让程式更好读

建立一个可预期的架构。这样一来团队成员能更容易地找到东西,而大幅减少完成工作的时间。 当你定好整体架构,记得让主要元素的位置保持显眼。 比如用 MVC 就把模型、视图和控制器放在各自的资料夹里,不要藏在层层路径下或是分散在各个不同的地方。

前面谈到了模组化,过犹不及也可能发生过度模组化的情形,让人更难找到程式码。IDE 有时候帮得上忙,不过通常会因为有太多不相干的程式码,你还得让 IDE 忽略 vendor/library 资料夹,或编入指引,手动处理这些问题。这是双输的局面,因此尽量试着选择符合最多需求的函式库,减少函式库的数量。

函式库和工具也可能成为新开发者的阻碍,我最近就用 EcmaScript 7建置新专案,随后却发现开发的新人卡在那里,试着弄懂这些程式码的意思。这大大地拖累了团队的生产力,我也能了解对新手来说这压力有多大。不要使用太难上手的工具,除非你碰到更好的时机。

掌握5个基本概念,让你写出好Code
这是我写的 makefile 的部分程式码。而新人无法处理过多的新技术。
5. 让程式更好消化

如果你终于读到这里,恭喜你,这可能是最重要的一段。命名在软体开发中是公认的大哉问。建置工具大概不会在这上面有所改进了,因为电脑不会懂某个解背后的意义。 你得亲自记下原因,为变数及函式取个有关联且有包含前后文的名字会是不错的方法。 能够传达用途的名字甚至还能减少所需的纪录文件。

直接把意义加在名字前方是个好方法,以前曾经很流行,我想它逐渐消失的原因应该是太常被误用。比如 匈牙利命名法 原本是为了附加意义,但最后常失去前后脉络,变成只有表达类型之类的资讯。

掌握5个基本概念,让你写出好Code
流畅介面  最近常被滥用

最后就是降低迴圈的老生常谈。意思是让条件的分支愈少愈好,每多一条分支不只会增加缩排,也会影响易读性,而且最重要的是会增加需要追蹤的项目。

结论和

以上就是 5 点简单又包罗万象的概念,这篇文章的目的就是给你一些收纳箱,可以让你把管理程式码的想法放进去。

在写程式的时候,练习应用并进一步加强这些观念。 如果你还没开始,我也相当推荐《软体建构之道》这本书,里面有很多範例,并且详细剖析了绝大部分的状况。

相关阅读