如何理解程序员职业的本质

如何理解程序员职业的本质

程序员这个职业，和其他职业非常不一样。这大概是由软件的本质决定的。

自动化

其他行业的工作，都需要由人来完成；今天做的事情，明天可能还要同样的做一遍。但这是人类工作的方式，不是机器工作的方式。

软件，仔细想想，它不就是一系列可以重复执行的命令么？

为了让机器去做重复的工作，我们才需要编码，通过各种编程语言告诉机器如何去完成一项特定的工作，而在这之后，这项工作就由机器完成了，再也不需要人类来参与。程序员的注意力会转移到下一个还没有被自动化的工作上。对，「自动化」就是软件的本质。

DRY 是程序员的职业信条

所有重复的工作，都应该被抽象和描述成命令，交给机器去做；人类，至少程序员，应该把时间花在创造性的工作上。

《程序员修炼之道》中提出的 DRY 原则（ Don’t Repeat Yourself ）将这种内在信念表现得更为具体。相对的，我们把违反DRY原则的解决方案通常被称为 WET （ Write Everything Twice ）。

仔细想想，为了避免重复，程序员们都做过什么：从函数库到框架再到脚手架、从面向过程的函数级重用到面向对象的继承式重用、从软件分包和管理到SOA和服务发现，我们不断的改良着重用的技巧。

更进一步，为了不重复别人的代码，从古代开始，程序员们就开始通过软盘交换程序；有了互联网以后，更是发起了规模庞大的开源运动，把一个巨大的代码仓库毫无保留的开放给了全世界，让新一代的程序员们可以轻松的站在巨人的肩上，写出更美妙的程序。

为什么一个好的程序员可以代替很多普通的程序员？

深入理解了程序员们和重复的不共戴天以后，你就会明白为什么一个好的程序员可以代替成百上千个普通的程序员，因为机器放大了这个差距。如果一个普通程序员在重复劳动，那么一个好的程序员花一天写段代码就能干掉他/她一年的活。

所以你看，程序员就是不断的干掉自己的后路，逼着自己去做创造性的工作，不断指数级的提升生产率的职业。

自动化的残酷现实和应对策略

所有尝试过将工作自动化的程序员最后都会毫无例外的认识到，理想是丰满的、现实是骨干的。在现实世界，并不是所有东西都可以自动化的，有各种原因，一些是因为时间和精力所限、一些是因为有不遵守规则的人类参与。

好在我们所处的世界并不是二元的，在「完全自动化」和「不能自动化」之间，还有各种选择。在多年的「自动化」尝试之后，我总结出了一个准则，可以在理想和现实之间做一个不错的折中：

能自动化的自动化，不能自动化的半自动化

完美主义害死人，我见过不少做着重复劳动的程序员，问为什么不用代码将其自动化时，他们总是会说，因为不能完全自动化，所以干脆就全部手写好了。

其实不能全自动化的工作，是可以半自动化的，可以通过交互操作来完成，Web 界面就是最常见的一种、而命令行询问输入参数是写起来最方便的一种。

整个工作流程不能自动化时，只自动一小部分也能提升不少效率。

我之前做过的一个小工具，就是把数据表的各个字段都显示出来，你复选上以后，可以生成增删改查的 SQL 语句。这个工具至少帮我节省了上千次字段拼写，因为用到它的那个项目表很多字段更多，最后做下来光 SQL 都 100 多K。

再举一个例子。之前我们的一些资料是编辑给的，他们都用 Word 发过来。当时没有特别好的 Doc 格式解析工具，所以好多同学都放弃了解析数据。我给的解决方案是这样的，直接在 Word 里边选中表格，然后粘贴到一个 textarea 里边。用 PHP 分析 tab 和换行就能把数据抓取出来。多动动脑子，解决办法很多。不完美，也可以很精彩。

只为自己设计

通用工具往往无法面面俱到，而只为自己设计的时候，事情就变得非常简单，生成器最终只需要生成你每天写的代码而已，工具也只是在重复你的日常，你非常清楚元数据是哪儿来的，应该怎样被加工，最终要生成怎样的输出才合格。当然坏处就是，这个只为自己设计的工具，也只能自己开发。

使用最高性价比的工具

凡事都自动化还有一个现实问题，就是成本太高。但如果这些自动化工具只是为你或者你的团队设计，只给程序员使用，那么我们不一定非要用图形界面这种更友好的但是开发周期更长的东西。

交互式命令行就是一个廉价又好用的解决方案，即使最后要做图像用户界面，也应该先用脚本把整个流程弄通，先把工作效率提升起来，再用节省下来的时间去开发界面细节。

工程化

另一方面，程序员其实是「软件工程师」，持续稳定的保证整个工程的质量是最为重要的。所有的「创造性」都要臣服于这个核心目标。

工程最重要的不是创造，而是去风险化。

工程是关于如何 低成本、高效率、按时按量完成既定任务的。

所以判断一个工程师是否优秀，并不是他多有创意多有名气，而是看他有多稳，看他能多 Getting Things Done，中文就是「靠谱」。

有时候一个好的解决方案，未必采用了最新的技术和框架，而是看上去朴实无华，功力都包涵在背后的细节里。就像顶尖高手打的斯洛克台球，每一杆都平淡无奇，只是因为上一杆的回球太到位。

同样的，一个好的工程师，会选择最适合需求和团队的方案，考虑开发效率和系统效率的均衡，从而已达到最优效果；而不是整天和别人去争论什么语言最好、哪些框架过时了。

工程的另一个要求是进度控制和质量控制。

在项目立项之后动工之前，对要做的事项作出详尽的规划，对未来一到两周的工作给出细致的排期，这是进度控制的基础。

代码的及时入库与合并，自动化测试和每日构建，Code Review 和文档编写，这些看似无关紧要的习惯则决定了项目质量。

不幸的是，很多程序员把这些工程上至关重要的东西当成垃圾，视为对他们「创造力」的压抑。

他们总是以创造力为借口去寻求自身的自在，比如上班不带胸牌不打卡，中午休息时间在公司看视频打游戏，最好可以远程上班，项目到期之前再来检查进度，公司不要用统一框架，只有傻X才写文档。

对职业的理解偏差和工程能力上的荒芜，培养了大批能写代码但死活写不好代码的「码农」，反而让那些有着彪悍工程能力和良好习惯的程序员变得奇货可居。

总结

「工程化」和「自动化」可能是程序员职业中最重要的两个信念，如何在保证「工程」品质的前提下，「创造性」的通过「自动化」来避免重复劳动，是值得我们花上经年累月的时间，在工作中时刻思考和实践的问题。对这个问题的思考，将帮助你获得前所未有的竞争力，比如说，如果你拥有了一系列的半自动化工具，在人工智能日益成熟的时代，它们就可能变成全自动工具，这背后的职业价值和商业价值不言而喻。