本文作者余晟，来自其微信公众号“余晟以为”，原文题目为《“把程序写好”这回事》

刚领证的著名程序员狗叔（@Googollee），前几周提出了很好玩的问题：“把程序写好的知识，是从哪里学来的呢？”。

我和狗叔回忆，我们好像都没有正经上过什么“把程序写好”的培训班，也没有《九阴真经》之类的宝典。但是我们又都看到，很多程序员写的程序是不合格的，大量基础规范都没有遵循（更可怕的是这样的程序很可能还在服务我们每天的生活）。那么，优秀的程序员，是从哪里学到把程序写好的知识的呢？

这个问题我想了很久，有几点结论可以分享给大家。

首先，必须要正视“写代码”这回事

有很多人虽然做着程序员的工作，其实内心是看不起写程序的。对他们来说，写代码只是不得不经历的初级阶段，等到职业生涯发展了，就可以脱离这种单调无聊的工作了。但是，这种想法是错的，有这种想法只能说明对计算机和程序的认知还相当肤浅。写代码绝不是简单无聊的劳动，程序员首先必须了解计算机的运行原理，然后需要把现实问题建模，并在计算机的世界里精确地治疗癫痫大发作还原出问题的解决方案。既然代码要交给功能强大的计算机去严格执行，程序员要担负的责任就相当大，因为代码的任何一点差异，都有可能影响程序最终的运行结果——因为程序的细治癫痫病比较有效的办法小缺陷导致航天任务失败的例子已经有好几次了。

反过来说，程序员能掌握的权力相当大，成为“合格程序员”的门槛也相当高，虽然这种门槛并不为许多人所知 。前段时间有很多人叫嚷“我万事俱备，只差一个写代码的”，恰恰是因为他们把写程序看成简单机械的劳动，但以自己的聪明才智又学不会这种“简单机械”的劳动。这种矛盾，恰恰说明写程序是有门槛、有要求的。所以，要想成为称职的程序员，必须正视写代码。

其次，必须读过一些基本的书籍

学校里通常会安排编程语言的课程，但不会教“怎样把程序写好”的课程。许多人对计算机的理解还停留在“科学与理论”的角度，只要程序能“对”，能输出正确结果就可以；却不知道如今与计算机相关的大量工作，其重心已经转移到实践和工程意识的方面了。这种错误的理解，导致很多程序员在工作之后相当长的时间里，学习的内容还局限于钻研理论和算法，一直忽略了“把程序写好”的补习。

其实市面上已经有一些教人“把程序写好”的书籍，认真读完这些书，认真落实其中的规范，至少能保证把程序写“合格”，不会有明显的缺陷，为将来把程序写好奠定坚实的基础。从我和身边朋友的经验出发，我觉得《代码大全》、《重构》、《编程珠玑》、《程序员修炼之道》这几本书都是很不错的，如果能耐心读完并认真思考，写程序的水平会有相当的保证。

要保持好奇心，多借鉴其它项目的内部实现

我们时常开玩笑说，现在很多程序员的工作，就是从网上下载一些开源项目，然后改改参数。其实这并非玩笑，而是很多程序员工作的真实写照。充其量，他们还要做一些穿针引线的工作，把这些项目粘合组装起来。

这看起来确实是简单机械的劳动，也不会给人多少提升。但事实并非如此。很多好的程序员就在这个过程中学会了把代码越写越好。因为他们保持了好奇心，去探究这些开源项目的内部实现，把应用的过程当成了学习的途径。在使用一个现成方案之前，先想想如果自己去解决要怎么办，再看看其他人的现成代码，确保自己懂得了这些代码蕴含的思维。甚至比较相类似的几个开源项目的源代码，分析其优劣，在自己的工作中注重借鉴其长处，避免其短处。久而久之，写程序的水平自然会有大的提升。

在写程序时，要懂得在工程与理论之间求得平衡

在谈到写程序时，经常有人引用奥卡姆剃刀原则，说“如无必要，勿增实体”；也有人引用爱因斯坦的话，“要足够简单，但不应该过于简单”。由此证明，好的程序应当是足够简单而且非常优雅的。

在大方向上，我认同这种说法。但在具体的问题上，它未必正确。因为编程是与工程密切相关的工作，与工程密切相关就意味着大量的权衡、取舍。无论奥卡姆剃刀原则还是爱因斯坦的话，原本的主题都是针对理论的，所以两者并不能严格划等号。

在实践中我见到过很多过份迷恋简单、美感的程序员，我称之为“玩套路”——他们太在意程序的形式美感，为了刻意追求那种严谨整齐的感觉而忽略了现实，也不懂得针对现实做出取舍，最终把自癫痫病会遗传吗己套了进去。结果，用户明明需要的一亩菜地，他们交付的却是一份盆景，还振振有辞地指责用户不懂技术。这样的人，往往既当不好程序员，也成不了软件开发工程师。

坦然接受其他人对自己代码的批评

Code Review是提高代码质量的有效手段，这一点大家公认。但是在很多场合，Code Review很难推行起来，原因之一就是程序员内心难以接受其他人对自己代码的批评。

这种现象倒也情有可原，因为写程序这回事，大家多少认为是有绝对标准，可以分出高下的。对大多数人来说，潜意识里也确实很难区分“对我的工作的批评”和“对我的批评”。所以面对其他人对自己代码的批评，除非是来自上级，否则多少有些面子上挂不住，天然有争辩的冲动。我自己就遇到过好几次这样的情况，本来讨论理论和方案一切正常，只要涉及到“看某人的代码”，气氛就随之大变。

我们需要明白，不经历挑战和批评，人是很难提高的。其他人的批评，只要不是恶意的，总是能提供不一样的视角，帮助我们更深入或者更全面的认识问题，这是很好的成长机会。相比起来，“丢面子”更多只是一闪而过的，甚至根本只是自己觉得很丢脸，其他人完全不在意的。为了怕“丢面子”而排斥其他人的批评，实在是得不偿失。

另一方面，团队领导也应当营造平等合理的协作气氛，倡导“对事不对人”的价值观。这样，才能让更多的成员坦然接受对自己代码的批评。

程序员需要有对荣誉感的追求

归根到底，“荣誉感”是驱动个人不断追求更高境界的源动力。对没有荣誉感的程序员来说，“把程序写好”充其量是不得已背上的负担；而对于具有荣誉感的程序员来说，“把程序写好”是需要不断追求的目标。

在我看来，程序员的荣誉感主要体现在两个重要的方面。第一是对质量的追求，好的程序员一定会对自己交付的程序的质量负责，力求做到没有缺陷，所以不会依赖Code Review来发现代码的缺陷，也不会依赖测试来发现功能的缺陷…… 甚至要向上游扩展了解问题的起因和目的，向下游扩展了解程序运行的状态和行为——这已经是“全栈工程师”的雏形了。

第二是对“用技术更好解决问题”的不断思索和追求。程序与现实不完全相同，所以很多时候并不受现实的严格限制，程序能不能突破这些限制，如何突破这些限制，靠的就是程序员的荣誉感。现实中很多时候确实“鱼与熊掌不可兼得”，但是在程序的世界里，在某些情况下，鱼与熊掌是可能兼得的。现实中“菜刀用来杀人”似乎是无解的，但在程序的世界里，有些菜刀就可以做到不能用来杀人。普通人或许囿于现实生活经验无法想想“鱼与熊掌兼得”、“菜刀不能杀人”，但想把程序写好的程序员，一定不能就此止步。

最后我想说的是，程序员应当属于德鲁克说的“知识工作者”。对于知癫痫患者如何检查识工作者，我们就不能像对待机器和工人那样去严格约束工作的过程，只能要求结果，或者说“找到合适的人，提供合适的环境，期待美好的事情发生”，这也是很多程序员享受的方式。但是，如果程序员不在乎自我驱动和追求，把写程序当作不需要任何想象力和创造力简单重复劳动，那么“血汗工厂”的工作方式可能更能保证生产效率。