最近在工作中遇到一些事情，让我有点不爽，或者说是愤怒。我觉得很多程序员根本称不上是 engineer，只能勉强算是个”terrible programmer”。

有些程序员不关心自己的代码，能不能被其他人看懂，会不会被别人错误地理解和使用。有些程序员甚至不关心自己的代码能不能被三天后的自己看懂。有些程序员其实根本不知道自己在写什么？他们只是凭借自己的感觉写完代码，然后扔给测试，然后等待测试提 bug，然后跑去问别人这边的逻辑应该是什么样的，然后用最“简单”的方式修复这个 bug（让这个 bug 不再发生）。

很多人都抱有这样的心态，甚至这种结果导向已经成为了一种政治正确。代码写的好坏不重要，赶紧通过测试，修好手上的 bug 上线才是最重要的。当然我同意修 bug 很重要（绝大多数情况下优先级最高），但是很多时候，大家都只想着怎么关掉这个 bug，而不会想想更重要的一些问题：这是不是一个 bug？这个 bug 是从哪来的？修复这个 bug 的方式会不会影响到其他逻辑?这个 bug 后面是不是还藏着别的坑？

如果你不去思考这些问题，而是快速看一眼 Jira,打开 debug 模式找到问题的原因(比如说，需要在某一段处理逻辑中加一段条件判断，在某种情况下跳过某几行代码的执行)。然后你想，oh，这个 bug 很好修，我只要多写个 if 然后在这种情况下跳过这几行代码就行了。你开心的写完这两行代码，提交并发布到测试环境，然后告诉测试那个 bug 被你修好了。接着去处理你还没处理的那十个新的 bug。

你觉得自己效率很高么？你错了，你糟糕透了，因为你失去了最适合思考和重构代码的时机。你被其他人催着跑，却丢掉了你最重要的东西。产品经理不会关心你的代码，测试不会关心你的代码，架构师不会关心你的代码，他们只要你把事情搞定。但是你必须关心你的代码，如果有必要的话，fight for your code!

如果需求要你写出难以维护的代码，你必须站出来发声，别人不会知道这东西有多坑，你必须非常严肃地告诉他们在技术实现上这是一个多么糟糕的主意。否则，你很可能为了一个优先级很低的需求，毁了你优雅的系统设计。

如果你不关心你的代码，那你永远也写不出好的代码，你的代码也不会成为好的产品。