程序员的修炼-02-编程之道

Word count: 5.3kReading time: 17 min

 2018/09/20 

本文是 <程序员的修炼-从优秀到卓越> 的读书笔记的第二篇，这本书的作者是 Jeff Atwood，StackOverflow 的创始人之一，Jeff 的文章涉及面很广，他是一个经验老道的程序员、管理者、创业者，这本书谈到了编程之外的很多东西，不管你是初级工程师，还是资深工程师，本书都值得一读。随着你的阅历的增加，每一次重读这本书，都会有不一样的感悟，正如书名“从优秀到卓越”，作者为你指明了道路，至于是否能成功，则要看自己的修炼了。

我会把读书过程中一些精彩的言论摘录下来，有时会加入一些自己的见解或者经历，读书笔记的大纲与书本身的大纲是一致的，这也是我从另外一个地方学到并一直在用的“如何阅读一本书”，记录下来方便自己经常查看，也方便读者查看。下面是<程序员的修炼-从优秀到卓越> 读书笔记系列：

切记一根筋

优秀的程序员擅长编程，成为更加优秀的程序员的方法是抛开编程，你必须培养对于编程周边的所有事情的热情

比尔盖茨在2005年的访谈中提到：“工作的本质不是闭门造车，最最匮乏的人才是那些既对工程技术有超强的领悟能力，有可以与核心开发人员建立良好的关系，并且可以充当与客户、市场等之间桥梁的人”

你的兴趣爱好越广泛，就越能胜任你的工作

破窗理论

破窗理论：如果一栋楼的一个窗户破了，并且留在那里不去修复，这栋楼的其他窗户很快就会被破坏。一个长久没有修复的破窗户释放出来的信号是“没人管”，这会让人觉得，即使再破坏更多的窗户也不会付出什么代价

从编程的角度来看，破窗理论也存在，你需要及时采取措施：不要放任“破窗”（不良的设计、错误的决定或者糟糕的代码）不管，一但发现就要尽快修复。如果时间不够，就先把他隔离起来。你可以把这些令人不快的代码注释掉，或者显示“尚未实现”的消息，或者用虚假的数据来代替。

编程是非常注重细节的！如果你不能够掌握这些细节，你就会有一种失控的感觉，而你的项目失控也只是一个时间问题。或许，我们就应该谨小慎微。

要么热爱，要么离开

我所认识的最杰出的程序员，他们对所从事的事情都有着终生的热忱，他们绝不会因为一次微弱的经济波动而转行去做其他的事情

对于编程：要么热爱，要么离开

简单之美

在编程开发领域，人们很容易就陷入“越新越好”的思维模式，而忘记了“想法往往比代码更重要”。

Forth 的进化指出了 Charles 在发明和实现 Forth 语言的时候的知道原则：

保持坚定
不要妄加推测
自己动手

Charles 认为：简单必须被强制执行，而不是作为一个可有可无的目标。现实中，很多开发者难以保持程序的简单，因为他们没有在需要做艰难决定的时候坚持说“不”，而事事允诺，处处妥协却容易的多

很多人看不上 oppo，但是 oppo 的系统在设计上保持了简单之美，所以 oppo 的系统用起来很轻，很舒服，长时间使用也很少有卡顿的情况出现，低端机的上面的表现也比同类竞品要好很多，这也与 oppo 的开发理念契合：优先保证基础体验（即快省稳）

乐于删代码

如果有一段你不再需要的代码，请真正地删除它而不是把它闲置在那里，其主要的原因是为了去除噪音和不确定性，开发者面临的众多最困难的事情之一就是代码流的噪音或者不确定性，因为这会影响他们将来的工作效率。无用的代码会引发其他开发者的思考：

为什么这段代码以前是这样写的？
为什么这段新代码更好？
将来我们会重新使用老代码么？
我们评判的标准是什么？

在目前 Git 横行的时代，你更不应该保留那些没用的老代码，如果想看之前的写法，也就是 Git 几行命令的事情。如果你不能有一个好的不删除的理由，那么删掉它就是合理的

你是程序员这块料吗

这一节提到，并不是所有人都适合编程，事实上，大部分人学不会编程，其中决定因素是他们对无意义事物的态度

形式逻辑证明，进而用一种叫编程语言的形式系统来表达，通过执行某种特别的计算得出结果，这其实是完全没有意义的。为了编写一个计算机程序，你必须做出妥协，赋予程序某种意义，但不管你想要这个程序做什么，计算机都会按照这些没有意义的规则运行，并且得到一些没有意义的结果。在测试中，那些有稳定思维模型的人都体现出了在这方面的先天接受能力，他们都有能力看见规则背后的数学计算问题，而且无论怎样都能遵循那些规则。另外一个方面，那些没用稳定思维模型的人总是找不到头绪。

你循规蹈矩么

这节我感觉标题不好，循规蹈矩：原指遵守规矩，不敢违反。现也指拘守旧准则，不敢稍做变动。而文中则说的是你是否遵循基本的规则。

这一节可以理解为：很多事情，包括软件开发，都是有一定的套路或者基本规则的，这些套路或者基本规则是被大家验证过的，你要做一件事的时候，最好按照这些套路或者基本规则来办，比如作者列出了一篇博客中写出更好的代码的 12 个步骤：

你使用源代码管理系统么？
你能一步之内完成软件的一次构建么？
你每天都出版本么？
你有一个 bug 跟踪数据库么？
在写新代码之前，你先解决 bug 么？
你有最新的软件开发计划表么？
你有产品规范文档么?
程序员有安静的工作环境么？
你在使用最好的商业工具么？
你有测试人员么？
在面试过程中，你让应聘者写代码么？
你做可用性测试么？

虽然上面都是疑问句，但答案是肯定的

科里定律：坚守一个目标

科里定律：坚守一个目标。这个定律在现代人居开发的下面几个核心原则中都有体现

Don‘t Repeat Yourself （DRY，避免重复）
Once And Only Once （OAOO，唯一一次）
Single Point Of Truth （SPOT，单点真理）

科里定律同时也告诉我们，要有意识地选择你的代码不做什么

最牛的编码套路

与你所相信的恰恰相反，单纯地每天埋头于工作并不能算是真正意义上的锻炼 – 参加会议并不能锻炼你的人际交往能力；回复邮件并不能提高你的打字水平。你必须定期流出时间，集中锻炼，这样才能把事情做得更好

上面这个理论也就是我比较推崇的两本书《深度学习》和《刻意练习》里面所强调的（如果你还没有看过这两本书，那么建议你看一下）：一万小时不是一个小时重复一万次，而是每个小时都能全心全意投入学习，深入思考，总结归纳

另外作者也提到了“努力地学习”：要不断地挑战自身能力之外的东西，学习和训练的主要价值在于发现弱点，有针对性地进行提高。“努力地学习”意味着，要常常去处理那些刚好在你能力极限上的问题，也就是那些对你来说有很大可能失败的事情。如果不经历一些失败的话，你可能就不会成长。你必须不断挑战自我，超越自己的极限

作者列举了一些套路（是那些真正可以实施的套路，有些长，不过我还是把所有的条目都摘抄出来，因为我自己也要实施）：

写一份自己的简历。把自己所有的相关技能都罗列出来，然后把那些在100年后还用得到的标出来。给每个技能打分，满分为10分
罗列出你所景仰的程序员。尽量包括那些与你一起工作的人，因为你会在工作中从他们身上获取一些技能。记录下他们身上的1 ~ 2个闪光点，也就是你希望自己有所提高的方面
查看维基百科上的“计算机科学”栏目，找到“计算机领域先驱者”这个分类，从这个列表中挑选一个人，阅读他的事迹，并且在阅读时打开任何你感兴趣的链接
花20分钟通读别人的代码。读出色的代码和读糟糕的代码都是有益的，两者都要读，轮流切换。如果你无法感觉出它们之间的区别，可以求助于一位你尊敬的程序员，让他给你展示一下什么是出色的代码、什么是糟糕的代码。把你读过的代码给别人也看看，问问他们的看法
罗列出你最喜欢的10个编程工具——那些你觉得你用得最多、非有不行的工具。随机挑选其中的一个工具，花一个小时去阅读它的文档。在这一个小时里，努力去学习这个工具的某个你不曾意识到的新功能，或者发现某种新的使用方法
想一想，除了编程之外你最擅长什么事情？再想一想，你是通过怎样的锻炼才变得如此熟练和专业的？这对于你的编程工作又有什么启发呢？（怎么把这些经验应用到编程方面？）
拿出一叠简历，并和一组面试官在同一个房间里待上一个小时。确保每份简历都至少被3个面试官看过，并且要给出1 ~ 3分的评分。针对那些不同面试官评判大相径庭的简历展开讨论
参与一个电话面试。事后写下你的反馈，抛出你的观点，然后与主持电话面试的人聊一聊，看看你们是否达成了一致的结论
进行一次技术面试，并且被面试的人应该是某个你不太了解的领域里的专家。让他假定听众在该领域里一无所知，因此请他从最基础的讲起。努力去理解他所说的，必要时问一些问题
有机会参与别人的技术面试。期间，你只是认真地听、认真地学。在应聘者努力解决技术问题的同时，你也要在自己脑子里尝试解决这些问题
找到一个能和你交换实际问题的人，每隔一周，相互交流编程问题。花10 ~ 15分钟来尝试解决这些问题，再用10 ~ 15分钟进行讨论（无论能否解决）
当你听到任何你一时之间也无法解决的面试问题时，赶紧回到你的座位上，把这个问题用电子邮件发给自己，以留作日后的提醒。在那一周里找出点时间，用自己最喜欢的编程语言来解决它

另外作者也提到了 Peter Norvig 所列出的一些建议：

与别的程序员交流。读别人的代码。这比任何书籍或培训课程都更重要
动手写程序！最好的学习方法就是边做边学
在本科或研究生的课程中学习编程课程
找一些项目来做，并且需要与其他程序员形成团队来合作。在项目的进行过程中，学会辨别最出色的程序员以及最糟糕的程序员
在项目中跟随别的程序员一起工作，了解如何维护那些不是你写的代码，并且学习如何写出利于他人维护的代码
学习多种不同的编程语言，特别是那些与你现在所熟悉的语言有着不同的世界观和编程模型的
了解硬件对软件的影响。知道你的电脑执行一条指令需要多少时间，从内存中取出一个字（在有缓存或没缓存的情况下）需要多少时间，在以太网（或者因特网）上传输数据需要多少时间，从磁盘中读取连续的数据或者在磁盘上跳转到另一个位置需要多少时间，等等

最后作者也阐述了自己的编程套路：

写博客。我在2004年初创办了CodingHorror.com博客，作为我自己努力学习的一种形式。它在一开始很不起眼，到后来成为我职业生涯中做过的最重要的一件事。所以，你也应该写博客。最后“闻达于天下”的人，往往就是那些能够有效书写和沟通的人。他们的声音最响亮，是他们在制定游戏规则，并且引领世界的潮流
积极参与著名的开源项目。所有的高谈阔论听起来都很好，但是，你是一个大话王还是一名实干家呢？别光说不练，这个非常重要，因为人们会用你的行动来衡量你，而不是你的言论。努力在公众面前留下些实实在在有用的东西吧，到时候你就可以说，“我在那个项目中出过力”

当你能编写精彩的代码、并且能用精彩的言辞向世人解释那些代码时，到那时候，我会觉得你已经掌握了最牛的编码套路！

孤独的人是可耻的

我觉得这一节作者引用的 “Creating My Own Personal Hell” 中阐述独自编程的危害性非常值得深思：

有些人宣称，“独自工作”为建立起自己的工作流程提供了极好的机会。但是，根据我的经验，在团队只有一个人的时候是没有流程可言的。没有任何东西可以帮你抵挡住如潮水般涌来的大量工作。当你的代码太急于求成时，没有人去纠正你的错误。没有人检查你的代码。没有人保证你的代码能准时提交、打好标签、进行常规的单元测试。没有人保证你遵循了某个编码标准。没有人督促你及时修复代码里的缺陷。没有人检验你是否把一个实际存在的问题标注成了“无法重现”。没有人复核你的估算，在你玩忽职守的时候把你抓回来

没有人在你生病时或者出差时接过你的工作。没有人在你工作繁重时帮助你，在你深陷于骚扰电话、无聊会议、还有在最后关头忽然被扔过来（但需要立即解决）的杂碎任务时，没有人能拉你一把。没有人忽然有奇思妙想，帮助你走出困境。没有人在设计、架构或技术上与你合作。你在一个真空中工作；在真空中，没有人能听到你绝望的尖叫

如果你读到了这些内容，请以此为鉴。如果某个公司只招你作为唯一的一位开发者，在你答应他们之前请三思。那根本就是另一种地狱。如果有机会的话，请选择那些能与其他开发者一起工作的职位，这样你至少可以在与别人一起工作的过程中得到指导，这有助于你发展自身的技能，让你在技术方面与时俱进

如果你不能展示给别人看，再漂亮的编码技巧又有什么意义？如果你不去接触其他程序员的不同观点、不同方法以及不同的技术，你又怎么能学到更多的技艺？谁又能检查你的代码并告诉你，那个问题有更简单的解决方法？如果你对待编程的态度是认真的，你应该要求与同伴们一起工作

个人的能力总是有限的，它决定了你在这个领域里只能走那么远。找一些其他的聪明程序员吧，和他们一起工作。努力让自己保持谦逊低调，然后你会很快发现，软件开发其实是一种社会活动——它的社会性比大部分人想象的要大得多。你可以从那些性格内向的同伴身上学到很多东西

就像我们常说的，一个人可以走的更快，但是一群人可以走的更远

你要编程伙伴么

在健康的软件工程文化影响下，团队成员通过结对的方式来提高他们的工作质量和生产力，他们明白，他们花在查看同事工作上的时间，总会在别人反过来查看他们自己的交付物的时候得到回报。

作者更是给出了一份数据来说明代码 Review 的作用（有点颠覆我的认知）：

在平均缺陷发现率方面，单元测试只能到到 25%，功能测试可以达到 35%，而集成测试也不过45%，相比之下，设计和代码审查的平均功效可以达到 55% 和 60%

编程有很多乐趣，其中一点在于：“你不必独自一人去做。”，所以，谁是你的编程伙伴？

软件学徒制

很多公司会给新人配一个导师，通过这种 1V1 的指导，让新人能尽快融入到公司，这与学徒制度很类似

晚上学习理论，白天编程工作 — 这种组合方式特别有效

《程序员的修炼——从优秀到卓越》是《高效能程序员的修炼》的姊妹篇，包含了Coding Horror博客中的精华文章。全书分为8章，涵盖了时间管理、编程方法、Web设计、测试、用户需求、互联网、游戏编程以及技术阅读等方面的话题。作者选取的话题，无一不是程序员职业生涯中的痛点。很多文章在博客和网络上的点击率和回帖率居高不下—— from 豆瓣