这个问题长久以来一直困扰着我。这不仅仅是为了找到出色的工程师同事，同时也是为了能让自己更进一步并拥有更卓越的技能储备。下面，我就把自己的一点拙见与大家分享……

在同样的时间之内，出色的软件工程师能够编写出更少的代码。而最出色的工程师根本无需编写代码。”——ElliotChance

这项结论需要立足以下三个角度进行理解，请让我具体加以解释：

1.利用简化方式缩减代码量

大多数情况下，软件变更都能够在项目初期快速轻松地得到实现，同时随着项目不断推进而变得缓慢且困难。虽然造成这种状况的理由多种多样，但复杂度的提升无疑是其中的核心因素。随着软件当中需要维护的对象逐渐增加，bug数量以及构建与测试周期也会变得水涨船高……考虑到其它众多非理想条件的影响，包括水平低下的代码、业务压力以及无数推动软件快速迭代的实际需求，这份负面因素清单只会变得越来越长。

我没时间写短信，所以我决定直接写封长的。——MarkTwain

使用更多代码无疑是种懒惰的表现。多数情况下，添加更多代码不会是什么最佳解决方案，无论是立足于当下还是未来。我们应当投入时间以找到更为精简的解决思路，从而尽可能用较少代码解决较多问题。

2.利用丰富的经验削减代码量

我认为多数软件工程师都经历过以下三个阶段：

感觉一切深不可测。我们都曾经是新手，并在刚刚入行时乐于接受一切新鲜事物。大家可能希望自主做出决定，但匮乏的经验与严重的时间压力让一切能够提升软件质量的作法都显得成本高昂，因此最终只得选择放弃。在此期间，大家会犯下很多错误，但也能够从错误中吸取教训。这时，我们只能希望身边的老手们能够提供理想的支持与引导。

才华超过当前岗位设置。这时，大家自认为已经掌握了当前软件堆栈、语言或者框架的全部奥秘。这时，很多人会热衷于以“重新发明轮子”的心态编写大量代码，而理由仅仅是“我能做得更好”。也许这是出于对过去所犯下错误的一种报复心理，或者是为了证明我们已经不需要学习任何新的知识。至少我本人就曾经有过这么一段“中二”经历，相信大家对此也深有体会。

趋于成熟。到这个阶段，大家会重新回顾自己以往的工作，并扪心自问“我为什么要用这么复杂的手段来解决这么简单的问题？”或者“我为什么没在着手解决之前，先看看有没有现成而且好用的方案？”现在，大家会真正理解自己作为工程师的短板所在，并着眼于未来拿出更出色或者说更加行之有效的解决思路。

程序写出来是要让他人阅读并理解的，机器执行只是其附带的条件。——HaroldAbelson，《计算机程序设计与解释》作者

我认为软件工程师群体当中的一大错误思维，在于自认为编写的内容只需要保证机器能够理解。总体来讲，我们的工作内容到底是什么？面对问题时，我们通常选择编写代码加以解决，但这并不是正确的思维方式。除了解决软件问题外，我们还需要保证质量同时维持与工作环境相匹配的维护水平，而这些任务并不一定要涉及代码层面。代码是将经验与知识同实际问题相对接的粘合剂，而非真正重要的本质因素。

3.深入理解以削减代码量

软件构建与维护工作当中，最糟糕的副产品是什么？大多数对此都有着相同的共识，即“技术负担”。所谓技术负担包含多种要素，但源代码无疑是其中最重要的组成部分。需要强调的是，代码存在问题并不一定意味着其编写水平较为拙劣。事实上，标准、框架甚至是语言本身都会随着时间推移而发生改变。当初编写水平较高的代码，很可能会在数年后不受兼容甚至根本无法使用——这就需要我们对其加以批量重构。

如果大家拥有多年代码编写经验，那可以肯定的是各位一定经历过依靠编写代码解决问题的状况。之所以执着于找到最理想的技术解决方案，是因为我们正是因为喜爱这种挑战才决定成为软件工程师。与此同时，当初的我们往往并不能确切掌握深不可测的技术元素，这意味着创建更多代码往往成了最简单或者说最可行的解决办法。

代码很难撤销，无论是在编写当中还是在发布之后。始终是编写水平最高的代码，同时可能在特定情况下成为一种技术负担，甚至导致下一代工程师（或者我们自己）在多年后很难理解其确切作用。

在这方面，沟通是最好的解药。除了工程师与非技术人员间的沟通之外，工程师之间也需要顺畅交流以理解彼此的想法。如果大家能够多花点时间用于思考，没准可以利用极少代码拿出更出色的解决方案。

总结

在某种意义上，我们要做的其实是努力摆脱软件工程师所固有的习惯性思维。

当然，我也必须承认在日常工作当中，也有很多实际情况并不适用于此前提到的原则。软件工程师几乎不可能在不使用代码的前提下完成上级下达的任务，但我们可以尽可能压缩代码使用量，从而努力降低未来可能由代码带来的维护难度。

这里感谢大家耐着性子看完这篇“个人意见”。希望各位在评论中分享您的感受、体会与经历。总之，祝大家编程愉快！

本文翻译自：