程序员：你的代码为谁而写
几周前，布莱斯在网上发帖，漫谈自己对编程工作的看法。在Reddit上引起了广泛讨论。讨论的焦点集中在程序员的等级——“优秀”、“良好”、“糟 糕”和“极差”。我发现，讨论中一些用语十分不妥。"好"与"坏"都是道德评价，评价之后似乎便给人贴上了永久不变的标签。 可以肯定的说，我曾被另一个程序员称作是 “极差”的程序员。我也承认，我确实写过一些极差的代码；但我也自认为曾写过相当多的“好”代码。要评判很久以前写出的代码是优是劣很不容易，因为现在已经不知道当时为什么编写这些代码，也不知道为谁编写了这些代码。
问问自己，现在正为谁编写代码？
为了按时交付任务
也许最常见的原因就是为了按时交付任务。走走捷径，宁可复制粘贴删掉几行代码也不愿意重构代码，然后匆匆交工。我们都这么做过，也都知道这是不妥的。
为了突出的考核结果
当管理者本身不懂代码，却有一套程序员“好坏”评价标准时，会出现什么情况？程序员要理清这套标准并不困难，因为他们的特长就是解决难题，然后他们会努力完善自己，从而迎合评价标准。代码行数、已解决Bug数量、注释的密度、代码深度等都可能是衡量编码人员的指标，但这些又都是相对标准，而不是绝对标准。也有些新颖的衡量手段（比如“已删除代码的行数”）。
为计算机编写
从某种意义上来说，所有的程序都是为计算机编写的，但计算机应当程序员最后才考虑的。计算机只注重语法，不注重注释和变量名称。大多数程序语言也不注 重间 距与代码格式化。当然，你还是要选择正确的算法，但不要想着通过微小的优化来加速算法。在for循环中，使用i++还是++i并不重要，编译器和JITs 会解决这些问题。在考虑优化算法之前，还是应该先把代码写的清晰易懂。要知道编码在使用通用模式时，计算机和编译器运行的更快。
为了自己
虽然学习一门新的程序语言很有趣，不过如果你将整个公司架构都建立兴趣之上是不切实际的。Hacker News上曾有一则相关故事，Lambda the Ultimate网站上还有更糟糕的案例。如果你是为自己写代码，你可以不加注释，可以随意使用糟糕的变量名，甚至使用其他“怪癖”，但这样写出来的怪异 代码别人很难看明白。不过没关系，因为每个人都会时不时想在某些事上找点漏洞出来。
为后来者编程
编程是把抽象观念转换成计算机可以理解的形式。即使是细微的抽象观念，转换成代码也是很不简单。因此很多软件项目都衍生出了成千上万甚至是上百万行的代码，相当于一本代码书。通过有限的语法与其他人交流这些概念，大多数时候都注定失败。
我所写的最出色代码就是我愿意花时间来添加注释、列出代码流、甚至附上一些ASCII文字图的代码。编写过程专注于如何把自己抽象概念，与今后将有可 能读到这些程序的、不幸的程序员进行传递和交流。我认为专注于这种交流，代码会变得越来越好，因为你会更深入地思考抽象概念以及如何对正在做的事情分层， 而不是一味的编写代码和转到下一个程序块。
注释使代码变得更好理解。每当你再次做某事的时候，总会比上一次更好。当你在编写代码和注释时，就是将抽象概念向读者解释了两遍。这会迫使你思考更 多。很多次我写完一个代码以后都会对它写一个注释。然后从头修订代码，甚至改变了一些小地方，例如选择更好的变量名称，来更好的交流想法。
评价代码/程序员
综合前文所述，可以看出，编程人员孰优孰劣确实难以定夺。因为难以明确他们编写代码目的。你可以考评代码，但你无法得知代码编写者当时的心理状况。或 许那天是星期五，他急着要赶去维加斯度周末；也许是程序出了问题，他不得不采取紧急补救措施，但这些补救措施一用就是5年；也可能他原本就是个不合格的程 序员。
也许编程真是一门艺术？
我不知道如何公正地考核编程人员，我想也没几个公司能做到。看看程序员的面试流程就清楚了，他们只不过坐在桌前被问几个问题而已；根本没有什么标准测试能让计算机科学专业的学生证明自己已经掌握了必要的技能。
编程工作带有太多艺术色彩，所以不可能通过测试手段或者固定的考核标准来评价。
你知道还有哪个领域也是通过视觉媒介将抽象的概念传达给其他人？美术和绘画作品。今天，我们或许会说梵高是个大人物（其画作闻名于世），但是仍然有人不喜欢他的作品。类似表达抽象概念的事物不应该用“好”或“坏”来评价。
程序员可以做到的就是时刻提醒自己，编程的目的要正确。不能仅仅要求编译器能识别就行，不能为了迎合某种考核标准，也不能为了按时交工而编程。相反，应该适时注解或写文档，解释或记录代码功能。只要用心，你就能编写出优秀代码。如此一来，以后就会有人夸你是个优秀程序员，而不会因你那一万行的代码文件而“咒骂”你是“极品”程序员。欢迎在评论或微博中分享你的观点。
这个问题提的很尖锐啊 每个人的理解不一样，认知肯定也不一样！ 看看，看看 我一直都认为，编码就是一门艺术！ 编码不仅是技术，也是艺术
页:
[1]