Teaser Image

mindwind

十日画一水,五日画一石




每个人做事情都有些个人习惯,有些习惯特别强烈的,可能其程度就会上升到「癖」这个词。明朝散文家张岱在其文《陶庵梦忆》中留有名句:“人无癖不可与交,以其无深情也。”。这里的「癖」就是一个强烈的个人喜好与习惯。

作为程序员,过去这么些年干的最多的事情自然就是写程序,所以也就形成了一些个人习惯或者说癖好。自己的习惯或癖好对别人本该是无所谓的,但有时不注意主动去把这种习惯或癖好强加于人就不太好了。

1

好些年前了,毕业几年后我也成了需要带新毕业学生的“老”程序员了。带学生的主要事情自然也就是一起做项目,指导下他们上手开始写真正的项目代码,而不是实验性质的课程作业。

工作头几年是我写程序最多的几年,基本也就写出了一些个人的习惯和喜好。比如,工程的目录结构,类的命名模式,接口的参数定义,甚至注释和签名的方式,都是我特别在意的东西。当看到新同学们各自按自己的想象写的随心所欲,就感到非常的焦心。那时候像 Java Maven 这种约定优于配置的工具还没有流行起来,大家都按自己的喜好使用 Ant(一种 Java 构建工具)来定义工程项目结构,所以千差万别。

因而,我就忍不住去把新同学们的工程按我自己的定义喜好进行修改,以一种权威的说辞来强调自己的偏好:“我们要统一下,免得像以前旧项目一样差异太大,换个项目熟悉起来都要好半天,也不利于相互之间的代码交流。”。

如今回想起来,当时这种“约定优于配置”的个人习惯在行业里还没有成为共识,而我仅仅是出于自己对代码的“洁癖”或者说强迫症,而产生了这种强加于人的冲动行为。一些年后,Maven 崛起逐步取代了 Ant,这种约定优于配置的思维就变成了 Java 程序员的普遍共识,而我也可以确认这个习惯确实是一个好方法了。

编程中如今总结出来的一些好方法,可能最早确实源自一些人的个人习惯,直到它们被大众所认同并形成了普遍共识。即使这些习惯最后也许真得变成了大家认同的好方法,我们也不该去以个人的方式强加于人,何况当时你还未必能确认这样的习惯真得会是一个好方法?

2

如今,很多形成共识的代码规范,基本就是从早期少数人的习惯中加以提炼总结出来的,形成了大家共同认可的好方法,并在组织层面去形成了规范。形成了规范的东西,就不再是从个人习惯的角度去强加于人了。

写代码的一些方法能形成规范,但还有一些编程的好方法可能比较难用规范描述,这些就慢慢形成了所谓的“编程的智慧”。在程序员之间口口相传,如今的“口口”可能更广义一些,也包括了互联网上的文字交流和传播。

一些编程智慧类的好方法,不太好形成具体的规范描述,我随便想了下,举点例子:

设计模式
遵守设计模式总是能让你少踩坑的,但如何灵活的采用合适的模式又是一种智慧了。

术语约定
约定了术语,总是能让口头的概念和落在代码上的东西保持一致,沟通歧义减少,从而更高效。

单元测试
这比任何的代码评审都来得可靠,哪里该写哪里可以不用写,这又是智慧了。但不要为了追求覆盖率去写,覆盖率的技术统计方法其实是很唬人的,有些覆盖率很高项目,该有的 bug 还是有的。

随时重构
技术债务,每个月付点利息,比好几年后连本带息去还要感觉轻松得多。这条的特殊点在于,我想这是大部分程序员都认可的好方法,但却不是大部分人的习惯。现实中欠了债,最多亲人能帮你还,但技术上的债,实在自己还不起,总是可以推脱给下个倒霉的家伙的。

3

编程中除了好方法,还有些确实是个人习惯的东西,如果我们不去留心区分,很容易模糊了两者的界限。

举个例子,我曾经一直有个编程习惯是这样的。假如有一个接口方法叫 lookup(),在实现这个方法内部的逻辑要根据好几种条件来查找,按不同的参数条件来实现不同的内部逻辑分支,但最后执行时又会走同样的一段逻辑去存储里查找。描述起来比较绕,用个简图来说明如下:

                 lookup()
                    |
   ---------------------------------------   
     |              |                 |
  lookupByA()    lookupByB()       lookupByC()
     |              |                 |
   ---------------------------------------
                    |
                 lookup0()

如上,lookupBy... 表达了不同参数逻辑的差异化处理,最后的 lookup0 一段共享的查找执行代码。 lookup 是一个公开的接口方法,而后面再加个 0 基本就是我的个人的习惯了,表达了内部私有的一种技术性实现,它一定是私有的,不对外暴露的。

4

如上,这样的个人习惯是让我对所有类似需要的接口实现模式保持一致。但这确实只是个人的习惯偏好,我没法也不会要求别人也用类似的方式,别人也可能有自己的习惯偏好,谈不上谁比谁更好。

大家都认同并形成共识的习惯一定是好方法吗?很有可能,能驱动大众行动的方法很大可能是好方法。但反过来,大家都不做的一定是不好的方法吗?这个就很难说了,比如程序员都不爱写文档,也没有这个习惯。另外,一些流行的概念是好方法吗?比如,结对编程。

结对编程,是一种流行的概念。结对编程的行为要求:两位程序员坐在同一工作台前开发软件。它的优势作用:与两位程序员各自独立工作相比,结对编程能编写出质量更高的代码。它的理论基础是:两个程序员具有相同的缺点和盲点的可能性很小,所以当我们采用结对编程的时候会获得一个强大的解决方案。

但有些人是很不喜欢结对编程的,比如我。真坐在一起编程,我感觉自己的效率会下降一半以上,因为难免分心而无法进入完美的心流状态。除此以外,有些人还喜欢在看你代码讨论时,用手戳屏幕指指点点,这也是我很难接受的点。当然,听说更严重的除了代码洁癖,还有生活洁癖,根本接受不了任何其他人和自己共用一个键盘的。

也许稍微松散点,没有那么物理上的严格结对。而是确保每一个程序员写得每一行代码,如果都能有一个配对的程序员去进行检视,这个过程完全是异步或远程的,效果应该也是可以保障的。这几乎就是开源项目的运作模式。

开源协作模式是一种大众行动证明的好方法,而结对编程也许只是一个流行的概念。

在我们从程序新人成长起来的过程中,要学会区分,哪些确实是值得学习与推广的好方法,哪些仅仅是自己的个人习惯。特别是在我们开始成为技术主管后,曾经犯过的错就是希望别人按照自己无关紧要的特有习惯来做事。

古语有云:己所不欲,勿施于人。而己之所欲,是自己的特有习惯,也就请勿施于人了。若确实觉得是个好方法,尽量建议于人,而非强加于人,即使你手上掌握有强加的权力。


写点文字,画点画儿,记录成长瞬间。
微信公众号「瞬息之间」,既然遇见,不如一起成长。