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

本文指出大多数程序员都容易犯下的错是 , 因为对编程的兴奋 , 不知道什么时候应该对编码说“不” 。 程序员需要知道什么时候不需要编码 , 并从项目中删除所有不必要的代码 , 这将让工作变得更容易 , 并使软件寿命更持久 。
程序员|程序员最重要的技能:知道什么时候不写代码文章插图
对什么说“不”学会说“不”是一个好的开端 。
但是到底是对什么说“不” , 又是什么时候适合说“不”呢?
这的确是大多数程序员 , 甚至是那些高级程序员都很容易混淆的一个重点 。
作为一名程序员 , 编写代码无疑是你职业中最重要的部分 。 在你的编程生涯中 , 你不可避免的地将会处理各种关于不同类型代码的请求 。 而每个请求都可能会迫使你做出一些艰难的决定 。 这些看上去一切正常 , 似乎也没什么错 。 毕竟 , 这是所有人对你的期望:作为程序员就该编写代码 。 然而 , 这里有一个问题:你是否应该编写向你请求的所有代码?
这个问题给我们引入了一个程序员所能学到最重要的技能:
知道什么时候不编码可能是程序员所能学到最重要的技能 。 ——《可读代码的艺术》对上面这句话 , 我完全同意 。 这是为什么呢?
编程是解决问题的一门艺术 。 因此 , 自然而然地 , 程序员成为了问题解决者 。 作为程序员 , 当我们面前有一个新问题有待解决 , 或因为任何其他原因需要我们写出代码行时 , 我们会因为使命感而感到兴奋 。
有这种兴奋也是再正常不过的 , 毕竟我们是程序员 , 我们就是喜欢写代码 。
然而 , 对编写代码这件事过于兴奋就会让我们变得盲目 。 这种情绪会让我们忽视了一些重要的事实 , 而这些事实可能导致更大的问题 , 让我们在未来不得不再去解决这些更严重的问题 。
那么 , 我们往往容易忽略哪些重要的事实呢?
你写的每一行代码都是:

  • 必须被其他程序员阅读和理解的代码
  • 必须被测试和调试的代码
  • 会增加软件缺陷的代码
  • 可能会在将来引入新 bug 的代码
正如 Rich Skrenta 所写的 , 代码是我们的敌人:
代码可谓是邪恶的 。 代码会腐烂 。 代码需要定期维护 。 它们总是包含有待发现的 bug 。 而新特性的添加总是意味着旧代码必须进行调整 。 代码量越大 , bug 所能藏身的地方就越多 , 且 checkout 或编译代码所需的时间就越长 , 而新员工理解这个系统所需要的时间就越长 。 这还意味着 , 如果你需要重构代码 , 需要挪移更多东西 。 此外 , 更多的代码通常意味着程序拥有更少的灵活性和更少的功能 。 这一点乍一看是违反直觉的 , 但确实很多时候 , 较之一个才华平庸的程序员所编写的冗长混乱的代码 , 一个简单优雅的解决方案能运行更快 , 且其功能会更通用 。 代码都是由程序员编写的 。 所以编写更多的代码往往需要更多的程序员 。 而程序员之间的沟通成本是以 n2的速度增长的 , 然后 , 这些程序员写的所有代码都添加到系统 , 在扩大系统功能的同时 , 也会增加整个软件工程的运营成本 。 我说的这些都是真的 , 难道不是吗?所以 , 那些用他们的生产效率和编程思维来激励你的伟大程序员们 , 都是那些知道什么时候该说“不” , 什么时候不编程的人 。 易于维护、持续寿命长、不断帮助用户实现功能的那种软件 , 应该不包含任何不必要的代码行 。
最好的代码其实是没有代码 , 而最有效率的程序员知道什么时候不应该编码 。 怎么知道什么时候不应该编码呢?当你投身一个项目的时候 , 很自然地会感到兴奋 , 满脑子都是所有那些想要实现的炫酷功能 。 但是程序员往往容易高估了他们的项目真正需要多少特性 。 于是就造成系统中有许多未完成或未投入使用的特性 , 甚至有些特性纯粹只是让应用程序变得过于复杂 。 你应该首先了解什么对你的项目是必要的 , 以避免犯下这种错误 。
了解软件的用途及其核心定义 , 这是知道什么时候不应该编写代码的第一步 。 请容许我举一个例子 。 假设 , 你的软件只有一个目的:管理电子邮件 。 基于这个目的 , 发送和接收电子邮件是该软件项目的两个基本功能 。 你就不应该期待这个软件同时也能管理你的待办事项清单 , 难道不是这样吗?
因此 , 你应该拒绝与此核心定义无关的任何可能的特性请求 。 在这种时候 , 可以确切地肯定你明白什么时候不应该编写代码 。