优秀的程序员，应选择明智但并不聪明的方式写代码

写代码其实不难，但写好代码却是门大学问。写代码以及编程的工作，其实就像人生的一个缩影，不同的人会选择不同的风格、方式、路径去实现自己的目的，但不同选择所带来的结果，却又有着很大差距。

Ravi Shankar Rajan 是一位来自印度的职业 IT 项目及技术管理人，目前在一家跨国 IT 咨询公司中任职。他的兴趣爱好十分广泛，同时也是一位知名博主及作家。Ravi Shankar Rajan 不久前在博客网站 Medium 上发布了一篇文章，向读者们分享了其 15 年编程经历中的一些重要的个人心得，以及他自己的编程哲学。

以下为该文章的正文（ SegmentFault 编译版）：

作为一名拥有15年开发经验的工程师，最早让我开始“懂事儿”的，是简洁明了的一句话：

出色的代码，是表达能力更强的（expressive），而不是令人印象深刻的（impressive）。

我记得当时自己对此感到很疑惑，表达能力更强的和令人印象深刻的，他们在本质上有什么区别呢？

实际上，表达能力更强意味着清晰、明确、具体。因此，一段表达能力较好的代码需要能解决一个特定的问题。在为了写这样一段代码所付出的时间与努力的背后，是非常清晰、明确、具体的目标，而这段代码也必须能够真正地实现这个目标。

而令人印象深刻的，则表示要在写代码的过程中留下明显的个人标志或印记。一段自身结构复杂，夹杂着多种深奥算法的代码，也许可以为你吸引来他人的关注、赞叹与掌声，在充分满足你的虚荣心的同时，也有可能转化为那个在未来接替你继续维护代码的工程师的满腔怒火。如果他正好是一个脾气暴躁且知道你住在什么地方的人，那么接下来会发生的事情恐怕就不会那么让你感到高兴了。

这就是程序员应该选择明智而不是聪明的原因。一个精明的开发工程师需要具备那种能够预见自己的哪些行为在什么情况下会带来什么后果的能力，并能对「自己写的是什么样的代码」、「自己为什么要这么写」，以及「这些代码在未来可能会有怎样的演变」这三个问题有着清楚的认知。简单来说，精明的工程师不会去做“亡羊补牢”式地救火开发工作，他们在写代码时坚信应当一劳永逸地解决问题。

而“聪明”的工程师则正好相反，他们做起开发工作来速度很快，也知道如何运用各种歪门邪道的方法来让代码看起来可以“正常工作”。聪明的工程师拥有一种能快速通过“捷径”来解决任何手边问题的能力。但随着时间的推移，那些不断由“创可贴”和“胶带”累积搭建起来脆弱代码建筑，总有一天会崩塌，然后让所有为之付出过心血的人都感到蒙羞。就像美国著名软件工程师、Construx Software 公司创始人 Steve McConnell 在其 1993 年的著作《代码大全》中所写到的：

编程，可不能像为美国中央情报局工作那样，偷偷摸摸、投机取巧并没有什么好处。

精明的开发工程师绝不会做见风使舵的事，他们写出的代码平淡但却简洁易懂，不会太出彩，但也不会出差错。

除此之外，精明的工程师还有一些其他值得学习的做事习惯。

化繁为简

ThoughtWorks 首席科学家 Martin Fowler 认为，

任何人包括傻瓜都能写出计算机能看懂的代码，但只有优秀的程序员才能写出其他人也能看懂的代码。

程序员有的时候会莫名觉得自己需要去证明些什么事情，或者是需要向其他人展示自己的能力以说明自己能够胜任现在的工作岗位。这种想法会导致他们在尝试解决每个问题的过程中，优先选择那些更复杂、更困难的方法，而忽略就在眼前摆着且是最直接、最简单的解决方案。这是每个开发工程师都很容易犯的，同时也是最糟糕的错误。

精明的程序员会直截了当地写代码，这些代码在后续的工作中易于维护、优化或重构，不会出现任何奇葩或难以预料的问题，其他同事看了这些代码也能准确地知晓其意图以及解决问题的思路。而那些新颖的、不寻常的算法或是开发思路，再配上程序员那副熬了一整夜的疲惫却又自豪的表情，有时在上级或同事看来确实很棒。但在其引发一场可悲的失败时，很可能也会更加“耀眼”。

不论什么时候，只要你在写代码时，如果你的自负心理开始影响、诱惑你，那你最好问自己这样一个问题：「假如你离开了这项工作两个月时间，等你再回来继续工作时，还能看得懂这些代码吗？」如果你的回答是肯定的，那么你就可以完全按照自己的想法和意愿去写这段代码，只是请对你的继任者手下留情 ── 为了不需要过多地解释这段代码，请在合适的位置加上注释，合理地为各种变量命名，并尽可能地将其进行模块化处理。

高质量的代码，就像一个玩笑。如果必须要通过额外的解释才能让别人看懂，那这就不是一段好代码。

在合适的时机下完善代码

已故荷兰系统科学专家、著名软件开发工程师、计算机科学先驱 Edsger W. Dijkstra 曾提出，

关注「为什么」而不是关注「是什么」，能让你成为更出色的开发工程师。

优化代码的方法有很多种，比如可以调用更多内存，或是加快运行速度，或是采用不同的算法和逻辑思路。而不管用哪种方法，只要客观条件允许，精明的开发工程师都会明智地做出决定。但在开始进行任何优化工作之前，他们会严格遵守「『不要』准则」：​

我为什么要这么做？这些代码写得足够好吗？在了解、明确程序将被如何使用以及其运行环境的情况下，如果加快运行速度的话会带来任何好处吗？这些问题你都应该提前问问自己。

如果一个非常重要的程序运行得很慢，同时开发团队又期望在维持鲁棒性、准确性、清晰度的同时能让它变快一些的时候，优化工作才能在付出与成本上显现出意义。然而，一个运行很快但却得到了与预期相反结果的程序，仍然没有任何意义。高效率的代码优化工作通常能带来更多的益处，但如果你没有按照正确的方式去进行优化的话，结果可能非但无益还附带了更多缺陷。

无论你做了什么优化上的工作，都应当是效果显著的、可衡量的。不要总是依赖直觉，直觉永远都是糟糕的指南针。

复用而不是写新的代码

前谷歌公司高级副总裁 Vic Gundotra 曾提出过一个直击问题要害的观点：

写代码之前，我必须要先去搞清楚他们真正想要什么。

精明的程序员在开发项目前更喜欢先「看」代码，接着再到处寻找可行的、已存在的解决方案。而另一些工程师则认为「通过正确的方式进行重构」才是理所当然的。但在大多数情况下，这些人其实都是在重复造轮这件事上浪费时间而已。

不要害怕花时间在寻找上，在互联网上或是你的代码数据库中搜索那些已经被实践过的的解决方案，将有助于你去学习、掌握解决类似问题的通用方法，以及与之相关的各种利弊。这就是为什么精明的工程师在写代码之前会花更长时间先去看代码。因为重写一段全新的代码，总是要耗费更多的时间、成本和精力的。除非万不得已，否则不要这么做。

因此当你需要完成一项任务时，最好先去查一查是否有人已经做过解决类似问题的事了，这不是在抄近道耍小聪明，这是在节省不必要耗费的力气。

挑战自我

古希腊哲学家亚里士多德曾说过，

如果你正在做的事情并没有什么挑战，那么做这件事就不会让你变得更好。

精明的程序员总是会挑战自我，更准确地说，是抓住每个机会来挑战他们自己写的代码。他们总是能谦虚地意识到，没有最完美的代码，只有更出色的代码。

精明的程序员也不会安逸于呆在自己的舒适区，然后重复不断的按照同样的模式实施部署工作。他们会有意识地避免自己的代码参数设置受到教条主义思想的干扰，并总是会寻找合适的方法与手段把事情做得更好，即便这意味着需要去花时间学习新的东西，他们仍然会全力以赴。

精明的程序员是不会被浮夸的想法与花哨的功能所吸引的。他们能很务实地认识到，完美的解决方案并不存在，每一个杰出的功能或神奇的技巧都伴随着不同的弊端。

敢于向其他人求助

古希腊剧作家、悲剧诗人索福克勒斯曾相信，

如果我们每个人都能真正地做到互相帮助，那么就没有人再需要好运气了。

身为程序员，总是会自认为是比较理智、机灵的那种人。事实上，有不少的开发工程师确实是天赋异禀。但有的时候，程序员们也会过度自信地认为自己是无所不知的，可以凭借自己的大脑解决任何问题。毕竟，没有人愿意在工作会议上承认「这个我不会」，或者是对即将要部署的新功能一窍不通。

所以，他们会不停地告诉自己：「我会自己想办法解决的。我过去总是依靠自己的力量，现在依然可以继续这样。」

然而，精明的程序员却不会这样想。他们知道何时该去求助，何时该保持独立思考。他们清楚地知道任何拖延都可能让整件事情向不可控制的方向发展并最终演变为，团队中的每个人都将在无止境的焦虑与令人近乎绝望的压力下看着项目截止日期不断临近。而这就是精明的程序员能够在必要时勇敢地暴露出自己的不足并向他人及时求助的原因。

向他人求助并不是对自身能力的一种质疑，实际上这反而巩固了他人对你的信任与信心，因为他们看到了你能够不惜一切代价地履行自己的职责并按时交付符合预期的工作成果。你在他人心中的印象，也将变为一位有进取心的、自信的，且每天都希望让自己变得更好的开发工程师。

正如印度最佳女主持人奖获得者、演员、模特 Kubbra Sait 所说的，

提出问题，是开始变得更好的第一步。

---

那么，
你是否也在开发过程中遇到了困难？
是否对某些问题仍感到疑惑？
欢迎各位开发者来 SegmentFault 思否社区问答版块进行提问或参与讨论！