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

最新推荐文章于 2024-09-30 10:36:33 发布

2401_84519929

最新推荐文章于 2024-09-30 10:36:33 发布

阅读量60

点赞数 27

分类专栏：程序员文章标签： java 算法前端

本文链接：https://blog.csdn.net/2401_84519929/article/details/138377736

版权

程序员专栏收录该内容

190 篇文章 0 订阅

订阅专栏

本文探讨了编程中的两种态度——精明工程师注重清晰解决问题，避免复杂和临时修补，而聪明工程师倾向于快速实现，可能导致长期维护问题。作者强调了代码的可读性、复用现成解决方案和系统化学习的重要性，提倡在编写代码时保持谦逊和长远考虑。

摘要由CSDN通过智能技术生成

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

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

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

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

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

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

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

化繁为简

ThoughtWorks 首席科学家 Martin Fowler 认为，

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

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

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

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

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

在合适的时机下完善代码

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

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

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

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

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

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

复用而不是写新的代码

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

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

精明的程序员更喜欢先看代码，接着到处寻找可行的、已有的解决方案。而另外一些工程师则喜欢在「以正确的方法进行重建」。在大多数情况下，这些人都是在重复造轮这件事上浪费时间。

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

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

挑战自我

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