刚领证的著名程序员狗叔（@Googollee），前几周提出了很好玩的问题：“把程序写好的知识，是从哪里学来的呢？”。
我和狗叔回忆，我们好像都没有正经上过什么“把程序写好”的培训班，也没有《九阴真经》之类的宝典。但是我们又都看到，很多程序员写的程序是不合格的，大量基础规范都没有遵循（更可怕的是这样的程序很可能还在服务我们每天的生活）。那么，优秀的程序员，是从哪里学到把程序写好的知识的呢？
这个问题我想了很久，有几点结论可以分享给大家。
首先，必须要正视“写代码”这回事
有很多人虽然做着程序员的工作，其实内心是看不起写程序的。对他们来说，写代码只是不得不经历的初级阶段，等到职业生涯发展了，就可以脱离这种单调无聊的工作了。但是，这种想法是错的，有这种想法只能说明对计算机和程序的认知还相当肤浅。写代码绝不是简单无聊的劳动，程序员首先必须了解计算机的运行原理，然后需要把现实问题建模，并在计算机的世界里精确地还原出问题的解决方案。既然代码要交给功能强大的计算机去严格执行，程序员要担负的责任就相当大，因为代码的任何一点差异，都有可能影响程序最终的运行结果——因为程序的细小缺陷导致航天任务失败的例子已经有好几次了。
反过来说，程序员能掌握的权力相当大，成为“合格程序员”的门槛也相当高，虽然这种门槛并不为许多人所知。前段时间有很多人叫嚷“我万事俱备，只差一个写代码的”，恰恰是因为他们把写程序看成简单机械的劳动，但以自己的聪明才智又学不会这种“简单机械”的劳动。这种矛盾，恰恰说明写程序是有门槛、有要求的。所以，要想成为称职的程序员，必须正视写代码。
其次，必须读过一些基本的书籍
学校里通常会安排编程语言的课程，但不会教“怎样把程序写好”的课程。许多人对计算机的理解还停留在“科学与理论”的角度，只要程序能“对”，能输出正确结果就可以；却不知道如今与计算机相关的大量工作，其重心已经转移到实践和工程意识的方面了。这种错误的理解，导致很多程序员在工作之后相当长的时间里，学习的内容还局限于钻研理论和算法，一直忽略了“把程序写好”的补习。
其实市面上已经有一些教人“把程序写好”的书籍，认真读完这些书，认真落实其中的规范，至少能保证把程序写“合格”，不会有明显的缺陷，为将来把程序写好奠定坚实的基础。从我和身边朋友的经验出发，我觉得《代码大全》、《重构》、《编程珠玑》、《程序员修炼之道》这几本书都是很不错的，如果能耐心读完并认真思考，写程序的水平会有相当的保证。
要保持好奇心，多借鉴其它项目的内部实现
我们时常开玩笑说，现在很多程序员的工作，就是从网上下载一些开源项目，然后改改参数。其实这并非玩笑，而是很多程序员工作的真实写照。充其量，他们还要做一些穿针引线的工作，把这些项目粘合组装起来。
这看起来确实是简单机械的劳动，也不会给人多少提升。但事实并非如此。很多好的程序员就在这个过程中学会了把代码越写越好。因为他们保持了好奇心，去探究这些开源项目的内部实现，把应用的过程当成了学习的途径。在使用一个现成方案之前，先想想如果自己去解决要怎么办，再看看其他人的现成代码，确保自己懂得了这些代码蕴含的思维。甚至比较相类似的几个开源项目的源代码，分析其优劣，在自己的工作中注重借鉴其长处，避免其短处。久而久之，写程序的水平自然会有大的提升。
在写程序时，要懂得在工程与理论之间求得平衡
在谈到写程序时，经常有人引用奥卡姆剃刀原则，说“如无必要，勿增实体”；也有人引用爱因斯坦的话，“要足够简单，但不应该过于简单”。由此证明，好的程序应当是足够简单而且非常优雅的。
在大方向上，我认同这种说法。但在具体的问题上，它未必正确。因为编程是与工程密切相关的工作，与工程密切相关就意味着大量的权衡、取舍。无论奥卡姆剃刀原则还是爱因斯坦的话，原本的主题都是针对理论的，所以两者并不能严格划等号。
在实践中我见到过很多过份迷恋简单、美感的程序员，我称之为“玩套路”——他们太在意程序的形式美感，为了刻意追求那种严谨整齐的感觉而忽略了现实，也不懂得针对现实做出取舍，最终把自己套了进去。结果，用户明明需要的一亩菜地，他们交付的却是一份盆景，还振振有辞地指责用户不懂技术。这样的人，往往既当不好程序员，也成不了软件开发工程师。
坦然接受其他人对自己代码的批评
Code Review 是提高代码质量的有效手段，这一点大家公认。但是在很多场合，Code Review 很难推行起来，原因之一就是程序员内心难以接受其他人对自己代码的批评。
这种现象倒也情有可原，因为写程序这回事，大家多少认为是有绝对标准，可以分出高下的。对大多数人来说，潜意识里也确实很难区分“对我的工作的批评”和“对我的批评”。所以面对其他人对自己代码的批评，除非是来自上级，否则多少有些面子上挂不住，天然有争辩的冲动。我自己就遇到过好几次这样的情况，本来讨论理论和方案一切正常，只要涉及到“看某人的代码”，气氛就随之大变。
我们需要明白，不经历挑战和批评，人是很难提高的。其他人的批评，只要不是恶意的，总是能提供不一样的视角，帮助我们更深入或者更全面的认识问题，这是很好的成长机会。相比起来，“丢面子”更多只是一闪而过的，甚至根本只是自己觉得很丢脸，其他人完全不在意的。为了怕“丢面子”而排斥其他人的批评，实在是得不偿失。
另一方面，团队领导也应当营造平等合理的协作气氛，倡导“对事不对人”的价值观。这样，才能让更多的成员坦然接受对自己代码的批评。
程序员需要有对荣誉感的追求
归根到底，“荣誉感”是驱动个人不断追求更高境界的源动力。对没有荣誉感的程序员来说，“把程序写好”充其量是不得已背上的负担；而对于具有荣誉感的程序员来说，“把程序写好”是需要不断追求的目标。
在我看来，程序员的荣誉感主要体现在两个重要的方面。第一是对质量的追求，好的程序员一定会对自己交付的程序的质量负责，力求做到没有缺陷，所以不会依赖 Code Review 来发现代码的缺陷，也不会依赖测试来发现功能的缺陷…… 甚至要向上游扩展了解问题的起因和目的，向下游扩展了解程序运行的状态和行为——这已经是“全栈工程师”的雏形了。
第二是对“用技术更好解决问题”的不断思索和追求。程序与现实不完全相同，所以很多时候并不受现实的严格限制，程序能不能突破这些限制，如何突破这些限制，靠的就是程序员的荣誉感。现实中很多时候确实“鱼与熊掌不可兼得”，但是在程序的世界里，在某些情况下，鱼与熊掌是可能兼得的。现实中“菜刀用来杀人”似乎是无解的，但在程序的世界里，有些菜刀就可以做到不能用来杀人。普通人或许囿于现实生活经验无法想想“鱼与熊掌兼得”、“菜刀不能杀人”，但想把程序写好的程序员，一定不能就此止步。
最后我想说的是，程序员应当属于德鲁克说的“知识工作者”。对于知识工作者，我们就不能像对待机器和工人那样去严格约束工作的过程，只能要求结果，或者说“找到合适的人，提供合适的环境，期待美好的事情发生”，这也是很多程序员享受的方式。但是，如果程序员不在乎自我驱动和追求，把写程序当场不需要任何想象力和创造力简单重复劳动，那么“血汗工厂”的工作方式可能更能保证生产效率。