前言

这本书是我踏入编程界两年多来对我影响最深的书。书中的许多建议与指导让我受用无穷，Bob大叔以自己的亲身经历指导我规避很多坑，同时也培养了我对编程这份职业的尊敬之心，我将以成为专业人士为目标。

书的结构

图片.png

这本书分为14章，从思想到编码到管理到团队再到学习，涉及程序员开发过程的方方面面

序

• 享受职业素养

• 与问题本身的难度相比，解决问题的方式、步骤以及反思的程度，才更能体现出一个人的职业素养

• 负阴抱阳，知行合一

• ASD 和代码整洁之道 至于术， 而职业素养 至于道

• 软件工匠

专业主义 图片.png

• 专业主义不但象征着荣耀与骄傲，而且明确着责任与义务

• 主动承担责任，积极主动去做事是专业主义的第一要素

• 让QA找不出任何问题

• 用单测来确信代码正常运行

• 所有软件项目的根本指导原则：软件要易于修改，必须能让修改不必花太高的代价就可以完成

• 无情重构

• 了解你的领域，了解历史，不能铭记过去的人，注定要重蹈覆辙

  • 设计模式

  • 设计原则

  • 方法 （xp,scrum,精益，看板，瀑布，结构化分析，及结构化设计）

  • 实践 （TDD,OOP,结构化编程，持续集成和结对编程）

  • 工件 （uml,DFD,结构图，Petri网络图，状态迁移图表，流程图，决策表）

• 了解你的业务领域 开始一个新领域的项目是，应当读一两本改领域相关的书，要就改领域的基础架构与基本知识作客户和用户访谈，还应当花时间与业内专家交流，了解他们的原则与价值观念

说“不”

• 能就是能，不能就是不能，不要说‘试试看’

• 专业人士敢于说明真相而不屈从于权势。专业人士有勇气对他们的经理说“不”

• “为什么”远不如“事实”重要“

• 最要说”不“的是那些高风险的关键时刻。越是关键时刻，”不“字就越具价值

• 客户所要的任何一项功能，一旦写起来，总是远比它开始时所说的要复杂许多

• 牺牲专业原则以求全，并非问题的解决之道。舍弃这些原则，只会制造出更多的麻烦

说“是”

• 承诺用语：

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

• 如果最终目标依赖于他人，那么你就应该采取些具体行动，接近最终目标

• 缩短与最终目标的距离

• 如果你无法兑现承诺，那么最重要的就是尽早向你的承诺对象发出预警，越快越好，越早越好，你越早向各利益相关方发出预警信号，整个团队就越有可能抓住机会，中止并重新评估当前的活动，并决定是否采取些措施或做出些改变

• 当专业人士给出肯定回答时，他们会使用正式的承诺，以确保各方能明白无误理解承诺的内容

编码

• 编码必须平衡互相牵制的多种因素

  1.首先，代码必须能够正常工作
  2.代码必须能够帮你解决客户提出的问题
  3.代码必须要能和现有系统结合得天衣无缝
  4.其他程序员必须能读懂你的代码
  
  
  

• 为了追求所谓的速度，理性思考的能力会下降

• 结对编程最大的一个好处在于，结对中的任一方都不可能进入流态区

• 结对是用以应对中断的一种好办法，结对搭档能够维护住中断处的上下文

• 失败的测试也能帮你维护住编码进度上下文

• 礼貌地表现出乐于助人的态度才是专业的态度

• 专业人士的一个重要方面，便是看你是否能将调试时间尽量降到最低

• 管理延迟的诀窍，便是早期检测和保持透明

• 不要经受不住诱惑盲目冲刺

• 如果老板无法向你清楚说明加班方案失败后的后备预案，那么你就不应该同意接受加班方案

• 如果有人向你伸出援手，要诚挚接受，心怀感激地接受帮助并诚意合作

测试驱动开发

• TDD的三项法则

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

• 事后写的测试只是一种防守，而先行编写的测试则是进攻

• TDD是专业人士的选择，能够提升代码的确定性，给程序员鼓励，降低代码缺陷率，优化文档和设计原则

练习

• 卡塔是一套设计好的，用来模拟搏斗一方的招式
• 练习的目的在于，在需要的时候，可以凭借本能完美出招
• 保持不落伍的一种方法是为开源项目贡献代码

验收测试

• 验收测试定义为业务方和开发方合作编写的测试，其目的在于确定需求已经完成
• 验收测试的目的是沟通，澄清，精确化
• 验收测试都应当自动进行，要考虑成本
• 业务分析人员测试“正确路径”，以证明功能的业务价值；QA则测试“错误路径”，“边界条件”，“异常”，“例外情况”
• 身为专业开发人员，你的职责是协助团队开发出最棒的软件
• 实现某功能的代码，应该在对应的验收测试完成后开发
• 单元测试是深入系统内部进行，调用特定类的方法；验收测试则是在系统外部，通常是在API或者是UI级别进行
• 单元测试和验收测试首先是文档，然后才是测试
• 自动化验收测试，规避模糊性

测试策略

• QA 应该找不到任何错误

• 测试流程

  单元测试 -》 组件测试 -》 集成测试 -》 系统测试 -》 人工探索式测试  （金字塔）
  
  

• 单元测试

  编写人员： 程序员
  目的：   最低层次上来定义系统
  代码规约： 先编写测试，在编写产品代码
  
  

• 组件测试

  编写人员： QA和业务人员， 开发人员提供辅助
  目的： 让不具备编写测试能力的业务人员也能理解这些测试
  主要测试： 成功路径情况，一些明显的极端情况，边界状态和可选路径
  
  

• 集成测试

  编写人员：系统架构师 或主设计师来编写
  目的： 编排性测试，装配测试，用以确认这些组件已经正确连接，彼此间通信畅通
  主要测试： 性能测试 和吞吐率测试
  
  

• 系统测试

  编写人员： 系统架构师 和技术负责人
  目的： 针对整个集成完毕的系统来运行的自动话测试，测试系统是否正确组装完毕，以及系统各个组件部件之间是否能正确交互，确保正确的系统构造
  
  

• 人工探索式测试

  编写人员： 所有人
  目的： 验证预期行为的时候，探索系统预期之外的行为
  
  

时间管理

• 关于会议，有两条真理

  会议是必需的
  会议浪费了大量时间
  
  

• 受到邀请的会议没有必要全部参加。参加的会议太多，其实只能证明你不够专业。你应该理智地使用时间

• 如果会议让人厌烦，就离席

• 如果收到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长的时间，要取得什么成果。如果得不到切确的答案，你可以礼貌拒绝

• 立会

  1. 我昨天干了什么
  2. 我今天打算干什么
  3. 我遇到了什么问题
  每个问题的回答时间不应当超过20秒
  
  

• 迭代计划会议

  1.评估可选择任务的开发时间
  2.确定这些任务的业务价值
  

• 肌肉注意力有助于改善心智注意力，定期训练肌肉注意力，可以提升心智注意力的上限

压力

• 当困境降临时，也不要改变行为。如果你遵守的纪律原则时工作的最佳方式，那么即使是在深度危机中，也要坚决秉持这些纪律原则
• 应对压力的诀窍在于，能回避压力时尽可能回避压力，当无法回避时则勇敢直面压力，可以通过慎重承诺，遵循自己的纪律原则，保持整洁等来回避压力。直面压力时，则要保持冷静，多与别人沟通，坚守自己的原则纪律，并需求他人的帮助

协作

• 首要职责是满足雇主的需求。这意味着要和你的经理们，业务分析师们，测试工程师们和其他团队成员很好的协作，深刻理解业务目标
• 你需要理解手上正在编写的代码的业务价值是什么，了解雇你的企业将如何从你的工作中获取回报
• 我期望拥有代码的是整个团队，而不是个人

团队与项目

• 形成团队是需要时间的。团队成员需要首先建立关系。他们需要学习如何互相协作，需要了解彼此的癖好、强项、弱项，最终，才能凝聚成团队。
• 项目经理跟踪项目团队的进度，确保团队成员理解项目时间表和优先级
• 团队已经有了凝聚力，但却因为项目结束了就解散这样的团队，则是较为荒谬的。最好的做法是不拆散团队，让他们继续合作，只要不断地把新项目分配给他们就行
• 项目承包人的职责所在，便是清晰地定义和陈述项目的价值与意义，让项目得到公司管理层的认可与支持

辅导、学徒期与技艺

• 技艺是工匠所持的精神状态。技艺的“模因”中包含着价值观，原则，技术和正见
• 你无法说服别人成为一名匠者，你无法说服他们接受技艺模因。口舌之争并无益处，数据亦无足轻重，案例研究也无法说明什么
• 只要技艺模因可以被人观察到，它便具有传染性。
• 你自己首先要成为表率，自己要首先成为能工巧匠，向人们展示你的技艺。然后，将剩余的事情交给技艺模因的自然运行之道即可