作者：【美】Robert C. Martin
第1章 专业主义
专业主义就意味着担当责任，软件开发太复杂了，不可能没什么 bug。但很不幸，这并不能为你开脱。人体太复杂了，不可能尽知其全部，但医生仍要发誓不伤害病人。如果他们都不拿 “人体的复杂性” 作托词，我们又怎么能开脱自己的责任呢？
所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误在所难免。专业人士们要练习的第一件事就是 “道歉”。经验多了之后，你的失误率应该快速减少，甚至渐近于零。
你怎么知道代码能否常运行呢？很简单，测试！一遍遍地测，翻来覆去、颠来倒去地测，使出浑身解数来测！
写一些随时都能运行的单元测试，然后尽可能多地执行这些测试。
如果你希望自己的软件灵活可变，那就应该时常修改它！让软件保持固定不变才是危险的！如果一直不重构代码，等到最后不得不重构时，你就会发现代码已经“僵化了”。
为什么大多数开发人员不敢不断修改他的代码呢？因为他们害怕会改坏代码！为什么会有这样的担心呢？因为他们没做过测试。
第2章 说不
专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说 “不”。优秀的经理人对于敢于说 “不”的人，总是求贤若渴。因为只有敢于说 “不”，才能真正做成一些事情。
我的个人经验告诉自己，面对艰难决定，直面不同角色的冲突是最好的办法。
大多数时间，我们都希望能够说 “是”。确实，健康的团队都会努力寻求给他人以肯定的答复。
但有时候，获取正确决策的唯一途径，便是勇敢无畏地说出 “不” 字……我们要明白，委屈专业原则以求全，并不是问题的解决之道。舍弃这些原则，只会制造出更多的麻烦
许诺 “尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。
时常提醒自己——客户所要的任何一项功能，一旦写起来，总是远比它开始时所说的要复杂许多……
成为英雄及 “解决问题” 的诱惑诚然巨大，只是我们要明白，牺牲专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造出更多的麻烦。
“有可能写出好代码吗？有可能坚守专业主义精神吗？”
我的回答是：“是的。但你要学会如何说‘不’。”
第3章 说是
真正的承诺听起来是怎样的？
我将在……之前……（例如，我将在周二之前完成这个任务。）
如果因为意外，无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好。
第4章 编码
疲劳的时候，千万不要写代码。奉献精神和职业素养，更多意义上指要遵循纪律原则而非成为长时间工作的工作狂。
“创造性输出” 依赖于 “创造性输入”。科幻小说最能激发我的创造力。
对你来说，可能是其他东西。也许是一本精彩的悬疑小说、一首诗，甚至是一本言情小说。在抛开问题的几个小时内，我会在潜意识中非常活跃地模拟各种挑战和创意，最终，内心中会升腾起几乎无法遏止的力量，激励自己去创造。
花时间手把手地辅导年轻程序员是资深程序员的专业职责所在。同样道理，向资深导师寻求辅导也是年轻程序员的专业职责。
第5章 测试驱动开发
测试驱动开发可以优化设计，我们需要隔离出待测试的代码。如果一个函数调用了其他函数，单独测试它通常会比较困难。为了编写测试，你必须找出将这个函数和其他函数解耦的办法。换言之，测试驱动开发，会迫使你去考虑什么是好的设计。
第6章 练习
专业人士都需要练习。他们用自己的时间练习，因为他们知道保持自己的技能不落伍是自己的责任，而不是雇主的责任。练习的时候你是赚不到钱的，但是练习之后，你会获得回报，而且是丰厚的回报。
第7章 验收测试
要解决开发方和业务方沟通问题，我所知道的唯一有效的办法就是编写自动化的验收测试。这些测试足够正式，所以其结果有权威性。这些测试不会造成模糊，也不可能与真实系统脱节。它们，就是无可挑剔的需求文档。
第8章 测试策略
自动化测试金字塔
第9章 时间管理
关于会议，有两条真理：
（1）会议是必需的；
（2）会议浪费了大量的时间。
收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则不必参与。
有时候你工作时会心不在焉。很可能是因为要做的事情让人恐慌、难受，或者厌烦。你说服自己有些工作更紧急，所以转去处理，这种行为叫作优先级错乱——提高某个任务的优先级，之后就有借口推迟真正急迫的任务。优先级错乱是自我麻醉的谎言，我们知道这不是真的，但还是用它来欺骗自己。
第10章 预估
业务方觉得预估就是承诺。开发方认为预估就是猜测。
为了降低预估的误差，可以把大任务分成许多小任务，分开预估再加总，结果会比单独评估大任务要准确很多。
第11章 压力
观察自己在危机时刻中的反应，就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律，就说明你确实相信那些纪律。反过来说，如果在危机中改变行为，就说明你并不真正相信常规行为中的原则。
第12章 协作
程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里。专业程序员会花时间去理解业务。会和用户讨论他们正在使用的软件，会和销售人员与市场人员讨论所遭遇的问题，会和经理们沟通，明确团队的短期目标和长期目标。
第13章 团队与项目
团队已经有了凝聚力，但却因为项目结束了就解散这样的团队，则是极为荒谬的。最好的做法是不拆散团队，让他们继续合作，只要不断地把新项目分派给他们就行。
第14章 辅导、学徒期与技艺
学校能够传授的是计算机编程的理论。但是学校并不会也无法传授作为一名编程匠者所需掌握的原则、实践和技能。这些东西只有经由师徒个体间多年的细心监督和辅导才能获得。
