程序员：写代码究竟为谁？

　　几周前，布莱斯在网上发帖，漫谈自己对编程工作的看法。在Reddit上引起了广泛讨论。讨论的焦点集中在程序员的等级——“优秀”、“良好”、“糟糕”和“极差”。我发现，讨论中一些用语十分不妥。"好"与"坏"都是道德评价，评价之后似乎便给人贴上了永久不变的标签。

　　可以肯定的说，我曾被另一个程序员称作是 “极差”的程序员。我也承认，我确实写过一些极差的代码;但我也自认为曾写过相当多的“好”代码。

　　要评判很久以前写出的代码是优是劣很不容易，因为现在已经不知道当时为什么编写这些代码，也不知道为谁编写了这些代码。

　　问问自己，现在正为谁编写代码?

　　为了按时交付任务

　　也许最常见的原因就是为了按时交付任务。走走捷径，宁可复制粘贴删掉几行代码也不愿意重构代码，然后匆匆交工。我们都这么做过，也都知道这是不妥的。

　　为了突出的考核结果

　　当管理者本身不懂代码，却有一套程序员“好坏”评价标准时，会出现什么情况?程序员要理清这套标准并不困难，因为他们的特长就是解决难题，然后他们会努力完善自己，从而迎合评价标准。代码行数、已解决Bug数量、注释的密度、代码深度等都可能是衡量编码人员的指标，但这些又都是相对标准，而不是绝对标准。也有些新颖的衡量手段(比如“已删除代码的行数”)。

　　为计算机编写

　　从某种意义上来说，所有的程序都是为计算机编写的，但计算机应当程序员最后才考虑的。计算机只注重语法，不注重注释和变量名称。大多数程序语言也不注重间距与代码格式化。当然，你还是要选择正确的算法，但不要想着通过微小的优化来加速算法。在for循环中，使用i++还是++i并不重要，编译器和JITs 会解决这些问题。在考虑优化算法之前，还是应该先把代码写的清晰易懂。要知道编码在使用通用模式时，计算机和编译器运行的更快。

　　为了自己

　　虽然学习一门新的程序语言很有趣，不过如果你将整个公司架构都建立兴趣之上是不切实际的。Hacker News上曾有一则相关故事，Lambda the Ultimate网站上还有更糟糕的案例。如果你是为自己写代码，你可以不加注释，可以随意使用糟糕的变量名，甚至使用其他“怪癖”，但这样写出来的怪异代码别人很难看明白。不过没关系，因为每个人都会时不时想在某些事上找点漏洞出来。

　　为后来者编程

　　编程是把抽象观念转换成计算机可以理解的形式。即使是细微的抽象观念，转换成代码也是很不简单。因此很多软件项目都衍生出了成千上万甚至是上百万行的代码，相当于一本代码书。通过有限的语法与其他人交流这些概念，大多数时候都注定失败。

　　我所写的最出色代码就是我愿意花时间来添加注释、列出代码流、甚至附上一些ASCII文字图的代码。编写过程专注于如何把自己抽象概念，与今后将有可能读到这些程序的、不幸的程序员进行传递和交流。我认为专注于这种交流，代码会变得越来越好，因为你会更深入地思考抽象概念以及如何对正在做的事情分层，而不是一味的编写代码和转到下一个程序块。