程序员最重要的技能知道什么时候不写代码

作者丨Huseyin Polat Yuruk

译者丨杨志昂

本文指出大多数程序员都简略犯下的错是，由于对编程的振奋，不知道什么时分应该对编码说“不”。程序员需求知道什么时分不需求编码，并从项目中删去全部不必要的代码，这将让作业变得更简略，并使软件寿数更耐久。

1

对什么说“不”

学会说“不”是一个好的初步。

可是到底是对什么说“不”，又是什么时分合适说“不”呢？

这的确是大多数程序员，乃至是那些高档程序员都很简略混杂的一个关键。

作为一名程序员，编写代码无疑是你作业中最重要的部分。在你的编程生计中，你不可防止的地将会处理各种关于不同类型代码的恳求。而每个恳求都或许会迫使你做出一些困难的决议。这些看上去全部正常，好像也没什么错。究竟，这是全部人对你的期望：作为程序员就该编写代码。可是，这里有一个问题：你是否应该编写向你恳求的全部代码？

这个问题给咱们引进了一个程序员所能学到最重要的技术：

知道什么时分不编码或许是程序员所能学到最重要的技术。——《可读代码的艺术》

对上面这句话，我彻底同意。这是为什么呢？

编程是处理问题的一门艺术。因而，自可是然地，程序员成为了问题处理者。作为程序员，当咱们面前有一个新问题有待处理，或由于任何其他原因需求咱们写出代码行时，咱们会由于使命感而感到振奋。

有这种振奋也是再正常不过的，究竟咱们是程序员，咱们便是喜爱写代码。

可是，对编写代码这件事过于振奋就会让咱们变得盲目。这种心情会让咱们忽视了一些重要的现实，而这些现实或许导致更大的问题，让咱们在未来不得不再去处理这些更严峻的问题。

那么，咱们往往简略疏忽哪些重要的现实呢？

你写的每一行代码都是：

有必要被其他程序员阅览和了解的代码

有必要被测验和调试的代码

会增加软件缺陷的代码

或许会在将来引进新 bug 的代码

正如 Rich Skrenta 所写的，代码是咱们的敌人：

代码可谓是凶恶的。代码会腐朽。代码需求定时保护。它们总是包括有待发现的 bug。而新特性的增加总是意味着旧代码有必要进行调整。

代码量越大，bug 所能藏身的当地就越多，且 checkout 或编译代码所需的时刻就越长，而新员工了解这个体系所需求的时刻就越长。这还意味着，假如你需求重构代码，需求移动更多东西。

此外，更多的代码一般意味着程序具有更少的灵活性和更少的功用。这一点乍一看是违背直觉的，但的确许多时分，较之一个才调平凡的程序员所编写的冗长紊乱的代码，一个简略高雅的处理方案能运转更快，且其功用会更通用。

代码都是由程序员编写的。所以编写更多的代码往往需求更多的程序员。而程序员之间的交流本钱是以 n 的速度增加的，然后，这些程序员写的全部代码都增加到体系，在扩展体系功用的一起，也会增加整个软件工程的运营本钱。

我说的这些都是真的，莫非不是吗？所以，那些用他们的出产功率和编程思想来鼓励你的巨大程序员们，都是那些知道什么时分该说“不”，什么时分不编程的人。易于保护、持续寿数长、不断协助用户完成功用的那种软件，应该不包括任何不必要的代码行。

最好的代码其实是没有代码，而最有功率的程序员知道什么时分不应该编码。

2

怎样知道什么时分不应该编码呢？

当你投身一个项意图时分，很自然地会感到振奋，满脑子都是全部那些想要完成的炫酷功用。可是程序员往往简略高估了他们的项目真实需求多少特性。所以就形成体系中有许多未完成或未投入使用的特性，乃至有些特性朴实只是让应用程序变得过于杂乱。你应该首要了解什么对你的项目是必要的，以防止犯下这种过错。

了解软件的用处及其间心界说，这是知道什么时分不应该编写代码的第一步。

请容许我举一个比如。假定，你的软件只要一个意图：办理电子邮件。根据这个意图，发送和接纳电子邮件是该软件项意图两个基本功用。你就不应该等待这个软件一起也能办理你的待办事项清单，莫非不是这样吗？

因而，你应该回绝与此中心界说无关的任何或许的特性恳求。在这种时分，能够切当地必定你了解什么时分不应该编写代码。

永久不要随意扩展软件的用处。

一旦知道了什么内容对你的项目是必不可少的，那么鄙人一次评价全部或许呈现的代码恳求时，你会意识到这一点。你将明晰地知道编写代码的需求是什么。这个体系应该完成哪些特性？哪些代码值得编写？所以，你能够勇敢地去质疑全部，由于你切当地了解那些不必要的代码是怎么拖垮你的项意图。

知道什么时分不应该编码能够使你的代码库更小。

当你发动一个新项目时，一开端体系里只要两三个源文件。全部看起来都那么简略明了。而编译和运转代码只是需求几秒钟。这时，你彻底清楚在哪里能够找到你想要的东西。

然后，跟着项意图增加，将会有越来越多的源文件填满你的目录。其间每个代码文件动辄就包括数百行代码。为了更好地安排这些代码，你很快就需求建立多个目录。记住哪个函数调用其他函数变得比曾经愈加困难，而追寻 bug 需求支付更多的作业量。办理这个项目变得越来越困难，所以，你需求更多的程序员来帮助。然后，交流开支跟着程序员数量的增加而急剧增加。你的项目会变得越来越慢。

最终，这个项目变得十分巨大。增加新特性变为一种苦楚。由于即使是很小的改动也需求花上几个小时。修正当时的 bug 总是会引进新的 bug。你的项目开端赶不上最终期限……

现在，这个项目对你来说是一场摧残。为什么会变成这样？

这都是由于你不了解什么时分不应该编码。所以你对全部或许的特性恳求都毫不犹豫地说“是”。你是盲意图。编写那些不必要的新代码会让你疏忽软件最必不可少的中心内容。

这听起来就像恐惧电影相同，是吗？

但假如你一直对每件事都说“是”，这种恐惧的状况就会发作。你需求知道什么时分不需求编码，并从项目中删去全部不必要的代码。这将让你的作业变得更简略，并使你的软件的寿数更耐久。

我出产功率最高的一天便是扔掉了 1000 行代码。——Ken Thompson

我知道，要了解什么时分不需求编写代码，这点做起来是很难的。即使是高档程序员来说也并不简略。或许，我在这篇文章中所写的东西关于初级程序员来说很难了解，但我以为本文的叙说方法仍是能让人了解这些关键的。

我了解，有的程序员或许刚刚开端你的编程生计，想在编码范畴大展身手。你对此感到振奋不已。这点无可厚非。作为软件从业者，期望你永久不要失掉这种振奋感，但也请不要忽视重要的现实。咱们需求从自己的过错中吸取教训。你和他人相同，也会犯过错，也会从自己的过错中吸取教训。但假如你能从咱们的经历中学习，至少能更事半功倍。

请持续编码吧，但要知道什么时分需求对编码说“不”。

点个在看少个 bug