译者序

素养强调的并不是天赋的神秘，也不是技艺的高深，而是持续积淀的结晶：一方面，它体现了能力和素质；另一方面，它又强调了持续的积累和养成。

真正的解决办法，是约定共同认可的验收测试标准。
笔记：甲方就不要一直问有没有更好的，应该用定量的数据说话，达到要求就可以了，不断提高上限有刁难的味道。

序

负责技术方面工作的项目经理
笔记：或许可以做为自己的职业目标

负责业务方面的项目经理
笔记：是负责技术方面的项目经理的合作伙伴

必读引言

请把本书看成我的错误大全
笔记：错误才有学习的价值，与其告诉你怎么成功，不如告诉你怎么避免失败，因为成功不可复制，错误动动脑子就可以避免

第1章 专业主义

1.1 清楚你要什么

实际上，专业主义的精髓就在于将公司利益视同于个人利益，看到了吧，“专业主义”就意味着担当责任。

没有对例行程序进行测试就交付软件是不负责任的。

1.3 首先，不行损害之事

（1）开发的软件有bug会损害软件的功能。
（2）软件开发太复杂了，不可能没什么bug。但很不幸，这并不能为你开脱。人体太复杂了，不可能尽知其全部，但医生仍要发誓不伤害病人。
笔记：我觉得本质上是一样的

所谓专业人士，就是能对自己犯下的错误负责的人，哪怕那些错误实际上在所难免。所以，雄心勃勃的专业人士们，你们要练习的第一件事就是“道歉”。道歉是必要的，但还不够，你不能一而再、再而三地犯相同的错误。

什么样的代码是有缺陷的呢？那些你没把握的代码都是！

测试驱动开发（TDD）
但是有些代码不是很难测试吗？是的，但是之所以很难测试，是因为设计时就没考虑如何测试。唯一的解决办法就是要设计易于测试的代码，最好是先写测试代码，再写要测的代码。

所有软件项目的根本指导原则是，软件要易于修改。
要想证明软件易于修改，唯一办法就是做些实际的修改。

为什么大多数开发人员不敢不断修改他的代码呢？因为他们害怕会改坏代码！为什么会有这样的担心呢？因为他们没做过测试。

1.4 职业道德

将自己的职业发展寄希望于雇主的软件开发人员将会很惨。
笔记：所以跟雇主不要强调潜力，说“我可以学”，这是你自己的事，你要跟他说有马上就可以为你带来什么样的价值的能力。

雇主也没义务给你留学习的时间。

你应该计划每周工作60小时，前40小时是给雇主的，后20小时是给自己的。在这剩余的20小时里，你应该看书、练习、学习，或者做其它能提升职业能力的事情。
因为所谓“术业有专攻”那也是需要投入时间去追求的。

或许你会觉得工作就该在上班时间完成，不该再带回家中。赞成！

桑塔亚纳的诅咒：“不能铭记过去的人，注定要重蹈覆辙。”

不懂就学，不要畏难。
笔记：自控力和畏难情绪是阻止进步的两大首要因素。

最糟糕、最不专业的做法是，简单按照规格说明来编写代码，但却对为什么那些业务需要那样的规格定义不求甚解。
笔记：因为做传感器系统的开发，就有必要去了解传感器的相关知识，才是负责任的做法。

第2章 说“不”

“能就是能，不能就是不能，不要说‘试试看’。” ———尤达
笔记：“我可以学”，那就说“能”。

奴隶没有权利说“不”。劳工或许也对说“不”有所顾虑。但是专业人士应该懂得说“不”。
笔记：大部分人对自己的定位都是劳工。

2.1 对抗角色

“为什么”远不如“事实”重要。事实是，“登录页面”还需要两周才能完成。而为什么需要两周，则只是个细节。
有时候，提供太多细节，只会招致更多的微观管理。

2.3 要有团队精神

许诺“尝试”，就意味着你承认自己之前未尽全力，承认自己还有余力可施。

2.4 说“是”的成本

多年的从业经验让我渐渐明白，是客户需求阻碍我写出自己想要的真正高品质的应用程序。

2.5 如何写出好代码

专业人士常常会成为英雄人物，但是这样的荣誉并非是他们所刻意追求的。他们之所以成为英雄人物，是因为他们出色地完成了任务，不但按时，而且符合预算。而John却是一门心思想成为风云人物和救世主，从这点上看，他表现得并不专业。

成为英雄及“解决问题”的诱惑诚然巨大，只是我们要明白，牺牲专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造出更多的麻烦。

第3章 说“是”

3.1 承诺用语

你只能承诺自己能完全掌控的事。

如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好。

第4章 编码

能够感知到错误非常重要。对于一切事情莫不如此。具备“出错感知能力”，说明你已经能够非常迅速地获得反馈，能够更为快速地从错误中学习。要精熟掌握每项技艺，关键都是要具备“信心”和“出错感知”能力。

4.1 做好准备

如果感到疲劳或者心烦意乱，千万不要编码。

奉献精神和职业素养，更多意义上指要遵循纪律原则而非成为长时间工作的工作狂。

大脑里还有一个后台进程在运行。
笔记：我时常感觉有的人和事一直在我大脑后台运行。

4.2 流态区

流态：一种意识高度专注但是思维视野却会收拢到狭窄的状态。问题在于，在流态状态下，你其实放弃了顾及全局。

4.3 阻塞

和别人一起工作，会发生一种生理上的变化。
笔记：“男女搭配，干活不累”是有道理的。

“创造性输出”依赖于“创造性输入”。
笔记：平时要广泛阅读，多元接受各种信息。

4.4 调试

出于某些原因，软件开发人员会认为调试时间并非编码时间。
笔记：所以调试时间也是编码时间。

4.5 保持节奏

创造力和智力来自于大脑的高速运转，当你感到疲劳时，它们就不翼而飞了。

埋头忙于解决问题时，有时候可能会由于和问题贴得太近，无法看清楚所有的可选项。由于大脑中富有创造性的部分被紧张的专注力所抑制，你会错过很棒的解决方案。
笔记：短暂地抽离出来，会更新思维，获得更大的解决问题的视角。

4.7帮助

要清楚团队伙伴的状态。如果有人看起来遇到了麻烦，就应该向他提供帮助。帮助别人所带来的显著影响一定会让你感到相当惊讶。给他们提供帮助并非说明你比人家聪明许多，而是因为你带来了一个新的视角，对于解决问题起到了显著的催化作用。

第5章 测试驱动开发

5.2 TDD的三项法则

（1）在编好失败单元测试之前，不要再编写任何产品代码。
（2）只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
（3）产品代码恰好能够让当前失败的单元测试成功通过即可，不要多写。

5.3 TDD的优势

事后写的测试只是一种防守。而先行编写的测试则是进攻，事后编写测试的作者已经受制于已有代码。

第6章 练习

6.3 自身经验的拓展

保持不落伍的一种方法是为开源项目贡献代码。

第7章 验收测试

7.1 需求的沟通

做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。业务方还没有启动项目，就要精确知道最后能得到什么；开发方还没有评估整个项目，就希望精确知道要交付什么。双方都贪求不现实的精确性，而且经常愿意花大价钱来追求这种精确。

7.2 验收测试

单元测试是程序员写给程序员的，它是正式的设计文档，描述了底层结构及代码的行为。关心单元测试结果的是程序员而不是业务人员。
验收测试是业务方写给业务方的。它们是正式的需求文档，描述了业务方认为系统应该如何运行。关心验收测试的是业务方和程序员。

第9章 时间管理

9.1 会议

关于会议，有两条真理：
（1）会议是必需的；
（2）会议浪费了大量时间。

凡是不能在5分钟内解决的争论，都不能靠辩论解决。争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。

9.2 注意力点数

注意力是稀缺的资源，它类似魔力点数。如果你用光了自己的注意力点数，必须花一个小时或更多的时间做不需要注意力的事情，来补充它。
笔记：人一天可以高效学习和工作的时间是有限的。

在你不集中注意力的时候，注意力点数可以缓慢恢复。

肌肉注意力有助于改善心智注意力，而且不仅仅是简单的恢复。我发现，定期训练肌肉注意力，可以提升心智注意力的上限。

9.5 死胡同

坑法则：如果你掉进了坑里，别挖。

第10章 预估

“是的，我觉得花的时间太多了，但是我知道你在努力解决这个问题，而且有切实的进展。这就是我们真正需要的。所以，我一点儿也不生气。”
笔记：有努力，有进展，两个条件，缺一不可。

10.2 PERT（计划评审技术）

三元分析法：乐观预估，标称预估，悲观预估。

第11章 压力

我决心通过高质量的工作，而不是愚蠢的劳作来享受自己的职业生涯。

11.1 避免压力

在压力下保持冷静的最好方式，便是规避会导致压力的处境。

观察自己在危机时刻中的反应，就可以了解自己的信念。如果在危机中依然遵循着你守持的纪律，就说明你确定相信那些纪律。反过来说，如果在危机中改变行为，就说明你并不真正相信常规行为中的原则。

第12章 协作

12.1 程序员与人

专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问。你的工作职责就是要让业务免于陷入困顿，让公司可以长久发展下去。

12.2 小脑

也许你认为自己一个人工作时会做得更好。也许确实如此，但是这并不意味着你一个人工作时，整个团队会做得更好。

第13章 团队与项目

13.1 只是简单混合吗

有凝聚力的团队通常有大约12名成员：7名程序员、2名测试人员、2名分析师和1名项目经理。
分析师开发需求，为需求编写自动化验收测试。测试人员也会编写自动化验收测试，但是他们两者的视角是不同的。两者虽然都写需求，但是分析师关注业务价值，而测试人员关注正确性。分析师编写成功路径场景，测试人员要关心的是那些可能出错的地方，他们编写的是失败场景和边界场景。
项目经理跟踪项目团队的进度，确保团队成员理解项目时间表和优先级。

（完）