多吹牛,少写代码

来,说点大逆不道的。

代码是程序员的基础能力,毫无疑问。Linus 说,“Talk is cheap, show me the code.”。软件工程师,归根到底是要做工程的,代码写不好,就谈不上把工程做出来。

可是我觉得,越来越多勤奋的程序员,是写代码写得太多了,而不是太少了。

胡扯!读书百遍,其义自见。书山有路勤为径!代码也是如此,没有足够的积累,怎么能写得好代码?

可是,写代码真的需要那么勤奋地练习,那么大量的积累吗?

我想说一个现象,那就是很多公司每年都会举行调研,一个很常见的问题是,作为程序员,一年工作时间里面,写代码的比重有多少?

有一个很朴素的想法,就是如果编码时间的比例不足够高,那基本上就意味着程序员的时间都用去扯皮、流程,或者 ops……总之就是做一些内耗严重而缺乏实际产出效率的事情。进一步地,很多程序员就会抱怨,我想写代码,我不喜欢开会,不喜欢搞流程,不喜欢项目管理和人员管理。

可是,这真的 “正确” 吗?

来看看所谓的软件工程师的基础素质里面,写代码占了多大的比重?沟通、合作、学习,问题分析、解决,系统设计、算法,代码实现、测试、ops……到底有多少部分是 “写代码” 的?

如果我们把写代码看做软件的具体实现,那么,为了能写代码,有很多工作要做;而在写代码之后,也有很多工作要做。真正的、纯粹的写代码的时间,其实很少。

具体来说,当一个问题分析透彻,当一个系统设计清楚,当一个算法厘清逻辑,写代码的过程,本质上是一个使用特定的编程语言,将思路 “翻译” 到纸上(电脑上)的一个过程,这个过程难道不该很快完成吗?

如果你觉得写代码的时间很多,占得比例很大,我觉得多半可以怀疑,是不是这里面有些问题?

如果卡壳了很久,删删改改、来来回回折腾了很久,那多半是其它环节没有做到位。比如说,问题没分析透彻就开始写了,系统没有涉及清楚就开始码代码了,或者算法逻辑还没有厘清就开始先 “边写边看”……说到底,还是思考得太少,而代码写得太多。

哦,那看来这种觉得编码时间不够高的朴素的想法其实是 “错误” 的。

不知,你怎么想?

好吧,这有点像一个圈套,我认为正确和错误的回答都是不妥的。如果你是程序员,又在这一点上带着强烈的黑白是非的态度,无论觉得它明显地 “正确” 或者 “错误”,尖锐地说,这样的思维,似乎要把复杂的问题都简单地黑白论?如果回答是肯定的,那么我想这也是一个程序员思维模式很容易遇到的问题,因为我们在代码的世界里已经习惯了,使用 0 和 1 去描述一切。可就像生活中大多数的问题一样,很多问题往往不是非黑即白的——哪有可以用这样一句简单的判断,就给出绝对的是非结果来?

抱歉,扯远了……

话说回来,我从未否认的是,代码能力是程序员的最基本的素质之一,不会写代码的程序员无法称得上是 “合格” 的程序员。我只是觉得,程序员应当多分析、多思考、多讨论,实际我们能看得到的编码行动派很多,而 “想清楚了再动手” 的却很少。

也许有人会说,代码就是很难一蹴而就的,需要不断地迭代、重构,这是很花时间的。这话当然没错,但是我觉得现在某些流行的新的技术和编程技巧,让程序员的思考能力不断退化。

比如曾经大火过的 TDD(测试驱动开发)的例子,任何实践都是工具,是工具,就有适用场景。即便是最佳实践,也有不合适的时候,更何况 TDD 在我看来在多数场景下根本不是。不客气地说,在大多情况下,TDD 是弊大于利的。

原因就是它在一定程度上规避了好的自顶向下的思维习惯,而是自底向上,很容易丢掉系统和代码设计上的大局观,小细节抠得特别完美,结果做出来的东西大的设计是残缺的。

它带来的好处毫无疑问,对于一个即便设计能力不过关的程序员,也能够 “下手”,能够看到明确的代码产出成果,让情况看起来明显好过那些,不知道从何下手而干瞪眼的尴尬场景,因为自上而下的设计不但对于思考能力要求非常高,容易 “手足无措”,而且还容易让人感觉到 “没有进展”。

因此,自底向上的设计方法本来也没有什么问题,但是它的缺陷也太过明显。举个相关的例子,我们通常在面试的时候,一个新手程序员能掌握自底向上的思维方式其实很不错,但是如果一个老江湖了,设计编码还没有大局观,都是从一个个小的类和方法开始,写到哪算到哪,这样的程序员是不合格的(如果你对面试感兴趣,也认可我的观点,可以去看看我写的面试专栏)。

再有一个我工作中的例子,团队中的一位程序员在 oncall 的时候遇到一个上游系统 field 名称冲突的问题。简言之就是,我们系统交互中的 field 的名称通常都是唯一的,如果有冲突,我们的代码逻辑还没有足够聪明到可以应付这样情况的程度。他就在代码中增加了一个 “聪明” 的逻辑,通过引入更多辅助条件的判断,来识别当名称冲突的时候,哪一个 field 才是我们的系统需要的那一个。代码也不复杂,问题就解决了。

可是很快其他的一位同事看到这个问题以后,通过进一步调查和分析,发现在几个相关系统的设计中早就明确了,这个 field 就不应该冲突,于是和上游系统沟通后,这个 field 的问题从上游系统中修改掉了。而作为下游系统的我们,最多只需要增加一个验证的判断就可以了,根本不需要去带着任何正确与错误的假设,来处理这样的冲突问题,因为这样的的冲突本是不该出现的问题,而不是合理的特性。这就是一个问题不研究清楚,不沟通清楚,就拿写代码来凑的例子。

再呼应到标题和开头,所谓的 “写代码”,我们可以简单地将它理解为,问题都分析透彻了,系统都设计清楚了,算法逻辑也都厘清了,写代码的过程,就是一个将思维翻译成代码逻辑的过程。这个过程,不只可以说应当只占用程序员很少的一部分时间,而且还可以说,将来如果程序员的工作可以被越来越自动化的机器所替代,那么首先能被替代的几件事情中,有一件就是 “写代码”。

看看开头我们随便列出的程序员基础素质里面——沟通、合作、学习,问题分析、解决,系统设计、算法,代码实现、测试、ops,哪些才是作为程序员最值钱、最不可被替代的部分?

因此,往后再有还在情况模模糊糊的时候,就有想写代码的冲动的时候,不妨问问自己,真的是时候了吗?如果确实思考不清楚,那最好的办法,我觉得就是 “吹牛”,就把问题拿出来,和程序员朋友、程序员同事一起讨论,不要过于设置讨论的边界,内容完全可以宽泛一点(这也正符合吹牛的精神!),最好能讨论到不止你自己,连对方也觉得挺清楚,那就是动手写代码的时候了。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

2,262 次阅读

1 thought on “多吹牛,少写代码

Leave a Reply

Your email address will not be published.

back to top