0. 前言
国庆期间，一个从事HR的朋友发了一篇公众号文章给我，问我的看法如何
对话里，包含两个问题：
- 对“世界上没有技术驱动型公司”是否认同。
毫无疑问不认同。这个话题太大，也不是本文讨论的重点，就不展开论述了。
- 程序员是否需要写文档。（截图是关于程序员是否要写文档的篇幅）
由于今天恰好是1024，借这个热点，通过本文发表一下我自己的看法与实践经验。
1. 是否需要写文档视乎场景
这几年跟我一起工作的程序猿朋友应该知道，我是鼓励大家不要写文档的，这个论断和我最近的工作环境有关，实际上，是否需要写文档视乎场景：
- 像引述文章的作者是华为的工程师，对于电信级的项目，文档输出是过程管理的重要环节，也可能是其中一样给甲方客户的交付，甚至是第三方审计的重点，这种场景，文档必须写。
- 对于互联网项目，如果是比较稳定的中间件模块，应该写一些文档，除了作为设计过程的一个输出以外，也是给后续调用者的一个理解依据。
- 对于互联网项目，如果是迭代频率比较高的模块，要维护文档的成本比较高，往往代码和文档的差别比较大，反而成为维护代码的累赘，则没有必要写文档。
1.1 我的写文档方法论
在北电工作的职业生涯，历练了或许是软件开发中最完善的过程管理，在这过程中我总结出一套写文档的方法论—— WHO方法
- What——系统将要解决的问题是什么，俗称需求。无视需求、过分放纵需求都是不合适的，成熟的程序员，甚至应该引入限制和约束，令问题域简化，这是写出高质量软件很重要的一环。
- How——怎样实现需求，解决方案是什么。
- Options——做到以上两点，基本可以成为一个合格的程序员，要成为优秀的程序员，则需要针对需求，提出多种解决方案，并在多种解决方案中作出权衡，选择最合适的解决方案（没有最完美，只有最合适）。
1.2 真的不写文档？
我鼓励大家不写文档，是因为设计文档并不是唯一意义上的“文档”，除了传统意义上的设计文档，其实还有两样东西我更推崇。
注释与代码
注释其实也是文档的一种，它的好处是更容易维护与代码逻辑的一致性。对于代码注释，我曾经这样说过，注释有三种境界：
- 三流的程序员不写注释
- 二流的程序员写注释
- 一流的程序员写好代码，必要时写注释
第三种境界，源于一句很经典的话——“Good code is self-documenting.”。
什么是编程？编程就是对客观世界建模的过程，如果你的代码里，能很直接地映射到客观世界的各种概念，这对代码的可读性有莫大帮助，以下是来自于Stack Overflow的一个例子。
熟悉我的人都知道，我做code review的时候，会很纠结接口、函数、变量的命名，甚至会因为一个命名的问题思考半天，就是这个原因。
测试用例
在我大学的时候看过一本书，影响了我一生的设计和编码的思维，我一直认为这本书是程序员必读的书目之一——《敏捷软件开发：原则、模式与实践》。这本书主要讲设计原则，里面有一个很小的章节，提到TDD（测试驱动开发）。从那开始，我很多时候都将测试用例的重要性放在设计文档之前。
程序员要不要写文档，总是一个永恒的话题，我开始想，为什么这个话题总是被不断讨论，我想到其中一个原因，或许，这是评判一个程序员是否优势的一个标准？
2. 我的优秀程序员标准
多年以来，我对优秀程序员都有一个特别、政治不正确的评判标准，而我也是这个标准的坚实执行者。我对一个程序员是否优秀的评判标准是——他是否具备“懒惰”的特质。
在我的职业生涯里，如何用更少的时间完成工作，用更多的时间上班划水，始终都是我苦思冥想的重要问题。
2.1 偷懒是创新的源动力
我刚进入北电实习的时候，北美的工程师重新设计了一个数据读取模块，新的模块需要替换老的模块，有很多板式代码需要替换。板式代码没有任何技术含量可言，就是一连串的枚举值映射到不同命名变量的读取访问，由于当时有不少实习生，这种脏活，用一个很华丽的理由——on-job training，安排给了几个实习生。我记忆中，当时安排了4-5个实习生，计划花大概2-3周的时间完成这个工作。当时我手上有另外的工作，计划是，如果我完成工作之后，这个脏活还没做完的话，我需要去支(tian)援(keng)。当时我第一反应是震惊的，北电这种high-tech公司，竟然还有这样毫无技术含量的脏活？但机智的我马上缓过神来，这是我天才程序员难得的表现机会。
我暗中提前完成了手上原本的工作，花了点时间写了一个脚本，定义好一些替换规则，把无脑、繁琐的码字工作用脚本完成大部分，再加一些人工的修正，减少了95%的码字工作。为了更好的装逼，我还写了一个GUI界面，把文件选中，即可完成大部分的转换工作。嗯，万事俱备，有一天我怀着无比激动的心情上班，准备装逼的时候，被负责这个项目的人告知，代码工作已经完成……
虽然樱木经常装逼失败，但是，天才最终还是有闪光的一刻。偷懒装逼这种事情我还是坚持着，最终让我获得GDNT首个Innovation Spot Award—— 偷懒是人类创新的源动力，这是我一直坚信的。
我经常跟程序员同事分享这个故事，我想表达的是，在你的工作生涯中，难免有很多没有技术含量甚至枯燥的工作，枯燥的工作安排你没有办法改变，但是你有足够的理由，让这个枯燥的工作变得更轻松、有趣，甚至有成就感。
2.2 程序员的三大美德
最近看到一些资料，才发现《Programming Perl》的作者Larry Wall提出过“程序员的三个美德”
- Laziness——懒惰
- Impatience——不耐烦
- Hubris——骄傲
我顿时觉得，英雄所见果然略同……
3. 结语
不知不觉，竟然写了2000多字，要成为一个更好的程序猿，除了懒惰，我还有其他的一些见解，但限于篇幅，就不在此文展开了，有兴趣的朋友可以课金（赞赏），我后续文章会作出更多我所理解优秀程序员想法的分享。
愿天下的程序猿，有更多的时间上班划水，这是对这个职业最大的尊重！