《代码整洁之道》-[美]Robert C. Martin

想要从技术人员晋升为专业人士，该经历哪些步骤呢？

前言

享受职业素养 Professionalism（能力+素质、积累+养成）

• 解决问题的方式、步骤以及反思的程度。也就是说，怎样分析问题，找了怎样的资料，采取了怎样的步骤，此后，做了哪些措施来避免这种错误再次出现。
• 懂得什么时候说“是”（对自己做某件事做了清晰的事实陈述，并且明确了deadline）和“不”（委屈求全并不是解决问题之道，放弃专业原则只会造成更多问题）。

与目标业务部门确定目标原型之后，要求对方指派对接人在IT部门作伴，负责协商、跟进整个开发流程，确认每一点修改。这样既保证最终结果符合业务部门需求，又提高了开发人员的工作效率。

• 各做各的是不行的，必须要保持交流。

美的东西比丑的东西创建起来更廉价，也更快捷、构建、维护一个美的软件系统所花费的时间、金钱都要少于丑的系统。……美的系统是灵活的、易于理解的，构建和维护它们是一种快乐。

• 为了开发迅速，可能会复制粘贴复制粘贴，但是这种维护起来就要死人的。非常耗费时间和精力，可能是好好开发新系统的好几倍。

《敏捷软件开发：原则、模式与实践》

• 虽然是03年出的书，但是作为始祖书，我觉得可以去看看，毕竟道理都是一样的。有些团建上的事情，其实一直都没有变。

我们每天都会调整计划，找到关键路径，扫除在关键路径上所有可能出现的障碍。如果有人需要什么，我们就去弄来。

• 听着好像这个很基本。其实在真的开发过程当中，这是一种难能可贵的素质。扫除除去主要任务以外的所有障碍，是非常重要的。试想一下，我要什么有什么，那么我只要关注我如何实现功能就可以了，而不需要去做其他无关紧要的事情。

在务实性建议背后，隐隐体现出一种奋力突破的积极态度。这种态度提倡要重新，要富有荣誉感、自尊心和自豪感，要用于承担作为一名手艺人和工程师所肩负的重大责任。这种责任包括要努力工作，出色完成任务；要善于沟通，能够就是论事；要管理好时间，能够坦然面对艰难的“风险回报”决策。除此之外，这种责任之中还包括神圣的使命感。身为一名工程师，你比任何管理者可能都了解得更透彻。了解这些，也意味着你肩负着要敢于行动是重大责任。

• 责任感和使命感。

我们其实有点越界了，他们对此很清楚，因为他们从未要求我们这么做，也从没有说过我们可以这么做，更没有给我们电话的钥匙。我们悄悄的进去，他们默默地离开——放手让我们去做。

• 良师益友。
• 兴趣是最好的老师。

第一章 专业主义

1.不行损害之事

1. 不要破坏软件功能
   1. 让QA找不出任何问题。
      不要把QA当成啄木鸟，应该提交自己找不出问题的代码。
   2. 要确信代码正常运行。
      用自动化测试所有代码！虽然很难达到100%的理想值，但是要尽可能做到。→测试驱动开发（TDD）
   3. 自动化QA
2. 不要破坏结构
   不要为了发布新功能而破坏结构。结构良好的代码更为灵活。
   PPP2001
   如果你希望自己的软件灵活可变，就应该时常修改它。如果发现这些改动并不想你预想的那样简单，就要改进设计，使后续修改变得简单。

2. 职业道德

要自己保持充电的习惯。计划每周60h的工作时间，40h工作+20h学习。
如果是对职业发展有利的事情，可以从20h中划出合理的部分给工作时间。
这20h应该充满乐趣！

1. 了解你的领域
   不能铭记过去的人，注定要重蹈覆辙。
   必须精通的事项
   1. 24种设计模式。
   2. SOLID设计原则。
   3. 方法：XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计。
   4. 实践：测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程。
   5. 工件：UML图、DFD图、结构图、Petri图、状态迁移图表、流程图和决策图。
2. 坚持学习
   你不会找不看医学期刊的医生，别人也不会找不与时俱进的程序员。
   软件开发人员必须坚持广泛学习才不至于落伍。
3. 练习
   日常工作之余专门练习技能，以期自我提升。
4. 合作
   独处之余，和他人一起，可以学习到好的习惯和经验。
5. 辅导
   教学相长。
6. 了解业务领域
   开始一个领域的项目时，应该去了解他们的原则与价值观念。一知半解是最要不得的，发现自己不明白的时候，千万不要装明白。
7. 与客户/雇主保持一致
   站在雇主角度思考问题，确保开发的功能真正能满足雇主的需求。
8. 谦逊

第二章 说“不”

如果觉得被要求的事情，真的是不合理的，就要说出来。
优秀的manager对于敢说“不”的人，总是求贤若渴。
##1. 对抗角色
经理和开发都有各自要守卫的目标，经理要求在deadline前完成任务，确保按时上线，开发明知道在deadline前任务无法完成，不能按时上线。这是天生的对抗角色。
要通过协商达成一致。也就是说，各自维护自己的目标，讲出各自需求的细节，看有什么是能妥协的，有什么是必须坚持的。
“为什么”远不如“事实”重要。
##2. 高风险时刻
##3. 要有团队精神
考虑整个团队，不要硬说“可以”，在恰当的时机用恰当的方式说“不”

1. 试试看
   能就是能，不能就是不能，不要说“试试看”。
   尝试看着是件好事，但是在赶工期面前，并不是。这表示你将会承担高风险，需要列出新方案。

2. 消极对抗
   保留任何交流记录，表明自己已经承担了需要负责的部分。（在各部门协作的时候，比较常见，也不失为一种自我保护的手段。）

3. 说是的成本
   客户所要求的任何一项功能，一旦写起来，总是远比它开始时所说的要复杂得多，但最终你还是会接下这些活。
客户总会吧项目截止日期往后拖，他们总是想要更多的功能，他们总是提出需求变更——而且常在最后关头这么做。
   客户永远不会像你那么在乎（他们还有别的项目）
   急于完成，却迟难面试。几个特点。

   1. 告诉开发人员这个应用很简单。
   2. 挑剔指责开发团队没发现他们的需求，并借机添加各种功能。
   3. 一而再推迟项目截止日期，随口添加功能。

4. 如何写出好代码
   专业人士：完成任务，不但按时，而且符合预算。
   对内心想要成为“英雄”的渴望说“不”，拒绝不合理的要求。

第三章 说“是”

口头上说，心里认真，付诸行动。

1. 承诺用语

1. 识别“缺乏承诺”的征兆
   需要/应当、希望/但愿、让我们
2. 真正的承诺听起来都怎么样
   你自己始终都能掌握某些事情，也就是说，总有些事情是你可以承诺做到的。
   你要对自己将会做某件事做了清晰的事实陈述，而且还明确说明了完成期限。
   1. 之所以没成功，是因为我寄希望于某某去做这件事儿。
      如果最终目标依赖于他人，那么你就应该采取某些具体行动，接近最终目标。
   2. 之所以没成功，是因为我不太确信是否真的嫩完成得了。
      即使目标无法完成，你仍能权利前进，离目标更近些。而弄清楚目标是否能达成这件事儿，就是采取的努力行动之一。
   3. 之所以没成功，是因为有些时候，我真的无能为力。
      有些事情发生是始料未及的，这个时候就要调整别人对你的预期，越快越好。预警要趁早。
3. 总结
   做到承诺，才能成为一名“严谨负责的程序员”。

2.学习如何说“是”

1. “试试”的另一面
   对于有风险的事情，要明晰deadline。
2. 坚守原则

3.结论

专业人士不需要对所有请求都回答“是”。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方能明白无误地理解承诺的内容。

第四章 编码

自信+出错感知
##1. 做好准备
（1）代码能够正常运行。
（2）能够解决客户提出的问题。（有的时候，客户并不知道自己想要什么，需要你帮助梳理需求。）
（3）如果是增加性的需求，不能破坏原先的体系。
（4）其他程序员必须能读懂你的代码。（注释+优秀的代码）

1. **凌晨3点写出的代码 **
   千万不要在疲劳的时候写代码，写出来的会是坑！
2. **焦虑时写下的代码 **
   琐碎的生活中的事情如果干扰工作的话，还是优先处理掉，至少降低给自己造成的困扰。否则，无法专心敲出的代码，会花更多的时间去填坑。

2. 流态区

意识高度专注但思维视野却会收拢到狭窄的状态。

1. **音乐 **
   见仁见智，好坏无法评断。
2. 中断
   中断无法避免，礼貌地表现出助人为乐的态度才是专业的态度。
   要保存好被打断的思维，结对编程+TDD。

3. 阻塞（写不出代码）

1. **结对编程了解一下。 **
2. **创造性输入 **
   做一些其他能激发你兴趣的事情。

4.调试

1. **调试时间 **
   调试时间也是编码时间的一部分，要考虑到。

5. 保持节奏

1. **知道何时离开一会儿 **
   没解决问题不回家？不，应该回去。
   碰到困难受阻时，感到疲时，离开一会儿，让潜意识接管问题。

2. **开车回家路上 **
   短暂从工作问题中脱离出来，十分有助于大脑以不同但更具创造性的方式搜球各种解决方案。

3. **洗澡 **
   也是一个道理，从工作问题中脱离出来，放松一下。
   ##6. 进度延迟
   根据目标定期衡量进度

4. **期望 **
   对于达不到的期限要求，千万不要轻易松口退步。不仅影响声誉，也会让所有人失望。

5. **盲目冲刺 **
   要坚决抵制！
   坚决维护你的估算！唯一的方案是，缩减需求范围。

6. **加班加点 **
   不要轻易加班，达不到什么好结果。
   除非满足以下三个条件：
   （1）确保可以挤出这些时间。
   （2）短期加班，最多加两周
   （3）你的老板有后备方案，以防加班失败。

7. **交付失误 **
   自欺欺人说完成了是千万不可以的。
   提交完代码不叫完成！

8. **定义“完成” **
   通过验收测试，才叫完成。
   ##7. 帮助（团队）
   编程从来不是一个人的事情。
   礼貌地告知他人你希望独处的时间和开放的时间。

9. **帮助他人 **
   并不是你比别人聪明，而是说，你可以提供新的思路，催化问题的解决。
   如果做了，那就全情投入，你也会收益良多。

10. **接受他人帮助 **
    不要固守自己的地盘，不肯接受帮助。
    要学会寻求帮助。如果帮助唾手可得，你却自己僵持在那边，是不专业的表现。

11. **辅导 **
    除了自身的内驱力和资深导师的有效辅导之外，没有东西能将一名年轻的软件开发人员更快地提升为敏捷高效的专业人士。
    向资深导师寻求帮助也是专业职责。很多情况下，大多数新进开发是不太会去问问题的，觉得添麻烦，但是，真的是自我反复研究之后得不到解决的问题，就应该寻求专业的帮助。

第五章 测试驱动开发TDD

##1.此事有定论
##2.TDD三项法则

1. 在编好失败单元测试之前，不要编写任何产品代码。
2. 只要有一个单元测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。
3. 产品代码恰好能够让当前失败的单元测试成功通过即可，不要多谢。
   ##3.TDD的优势
4. 确定性
   FitNese
5. 缺陷注入率
6. 勇气
   如果整理变得轻松，那么程序员自然会开始整理代码。
7. 文档
8. 单元测试即文档。
9. 设计
   测试先行的代码
10. 专业人士的选择
    ##4.TDD的局限

第六章 练习

1. 训练意识和身体是为了真正搏斗时能够正确应对。目的在于在需要的时候，可以凭借本能完美出招。

2. 编程“卡塔”也是一套敲击键盘和鼠标的动作，用来模拟编程问题的解决过程。练习者不是在解决真正的问题，因为你已经知道了解决方案。相反，你是在联系解决这个问题所需要的动作和决策。
3. 逐步练习以达纯熟。
4. 有利于在潜意识中构筑通用的问题与解决方案间的联系，以后再设计变成中遇到这类问题，马上就知道要如何解决。

• 孰能生巧。
• 类似于电竞选手每日练习手速。

自身经验的拓展

1. 开源
   保持不落伍的一种方法就是为开源项目贡献代码。
   职业程序员用自己的时间来练习。老板的职责不包括避免你的技术落伍，也不包括为你打造一份好看的履历。

第七章 验收测试

1. 需求的沟通

专业开发人员既要做好开发，也要做好沟通。

1. 过早精细化
   做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。

2. 不确定原则（观察者效应）
   问题在于，东西画在纸上与真正做出来，是不一样的。
   业务方看到真正的运行情况时，就会意识到，自己想要的根本不是这样的。一看到已经满足的需求，关于到底要什么，他们就会冒出其他想法-通常不是他们当时看到的样子。

3. 预估焦虑
   需求是一定会变化的，所以追求那种精确性是徒劳的。
   误差棒。

4. 迟来的模糊性
   相比于解决分歧，更好的办法是换一种说法，所以会寻找各方都同意的关于需求的表述，而不是去解决争端。
   需求文档中的每一点模糊之处，都对应着业务方的一点分歧。

2.验收测试

1. “完成”的定义
   代码都写完+测试都通过+QA和需求方已经认可。

2. 沟通
   开发方、业务方、测试方对验收测试达成共识。大家都明白系统的行为将会是怎样。各方都应当记录这种准确的共识。

3. 测试
   自动化测试

4. 验收测试什么时候写，由谁写
   业务分析员测试“正确路径”，以证明能的业务价值；QA则测试“错误路径”、边界条件、异常、例外情况，考虑哪些部分可能出问题。

5. 开发人员角色
   把验收测试与系统联系起来，然后让这些测试通过。

6. 测试的协商与被动推进
   不能被动接受测试，要考虑测试是否对系统有意义。

7. ** 验收测试和单元测试**
   价值在于文档！
   单元测试是程序眼写给程序员的，是正式的设计文档，描述了底层结构以及代码行为。
   验收测试是业务员写给业务方的，正式的需求文档，描述了业务方认为系统该如何运行。

8. 图形界面及其他复杂因素
   单一责任原则：UI背后的功能不变，有唯一ID。

9. 持续集成
   集成之后，所有代码都需要重新构建，遇到bug要中止其他行为，优先解决bug。

第八章 测试策略

1. QA应该找不到任何错误

1. QA也是团队的一部分
   需求规则定义者+特性描述者
2. 自动化测试金字塔
   单元测试→组件化测试→集成测试→系统测试（测试的10%）→人工探索式测试（探索系统预期之外的行为）

第九章 时间管理

##1. 会议
会议是必须的，会议浪费了大量时间。

1. 拒绝
   收到邀请没必要都要参加。参加会给自己目前的工作带来切实且显著成效的会议。
   对于感兴趣的会议，要考虑是否花得起时间参加。
   领导的最重要责任之一：帮助你从某些会议脱身。
2. 离席
   如果会议让人厌烦，那就找个理由离席。
3. 确定议程与目标
   会议需要明晰议程和会议需要达成的目标。
4. 立会
   每个问题的回答时间不应当超过20s，所以每个人的发言不超过1min。
5. 昨天干了什么。
6. 今天打算干什么。
7. 遇到了什么问题。
8. 迭代计划会议
   会议之前评估可选择任务的开发时间+验收和组件测试的概略方案。
   用来选择在下一轮中实现的任务开发。
   节奏足够快，每个候选任务讨论5-10分钟，细节另做讨论。
   每轮迭代中，迭代会议时间不超过5%。
9. 迭代回顾和DEMO展示
   20分钟回顾（得失）+25分钟展示DEMO
10. 争论/反对
    凡事不能在5分钟内解决的争论，都不能靠辩论解决。
    用数据说话。
    如果你同意了，就必须拿出行动来。

2.注意力点数

注意力有限，所以要在有注意力的时候编程。

1. 睡眠
2. 咖啡因
3. 恢复
   注意力用光了，就要恢复，这点很重要。小睡、聊天、听音乐或者其他放松的形式。
4. 肌肉注意力
   注意体育锻炼。
5. 输入与输出

3. 时间拆分和番茄工作法

（25分钟工作+5分钟休息）*4+30分钟休息

4. 要避免的行为

1. 优先级错乱

5.死胡同

坑法则：在走入死胡同的时候要迅速地意识到，并有足够的勇气走回头路。

6. 泥潭

发现自己身处泥潭还是固执前进是最严重的优先级错乱。