从个人习惯到真正的好方法

我就是我 2022-06-01 13:45 200阅读 0赞

![815275-20170521213817275-633616204.jpg][]

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

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

## 1 ##

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

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

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

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

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

## 2 ##

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

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

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

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

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

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

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

## 3 ##

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

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

![815275-20170521213858432-1250596036.png][]

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

## 4 ##

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

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

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

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

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

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

…

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

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

[815275-20170521213817275-633616204.jpg]: /images/20220601/d65c1cefb00b40229e07fac6827ce643.png
[815275-20170521213858432-1250596036.png]: /images/20220601/8e96c2483d1f47ccb7022ed432e0febb.png