总结:不推荐购买,浏览完下面各章节的要点即可,书中仅是对各个要点进行展开论述或列举小故事进行论证。

书中内容大体可分为两种,一种是自己可控,一种是与他人协作沟通。与他人沟通协作部分仅供参考,国外作者举证的事例,国内环境不一定适用。自己可控部分主要有以下几点:

  1. 提交经过充分自测的代码;
  2. 随时重构,确保代码结构整洁灵活可扩展;
  3. 持续学习,广泛涉猎;

一、专业主义

  1. 对自己的代码负责,尽可能的充分的自测;
  2. 对代码中的BUG负责,但有责任让BUG无限接近零;
  3. 不提交明知有缺陷的代码,不提交没有把握的代码;
  4. 要求写的每一行代码都要测试;
  5. 随时修改,不断重构,确保代码结构灵活可变,等到不得不重构时会发现代码已经很难修改了;
  6. 保持学习,投入时间;
  7. 坚持广泛学习,学习新技术新语言;
  8. 勤于练习,工作之外专门练习,实现自我提升;
  9. 与他人合作,一起编程、练习、设计、计划,彼此学习;
  10. 辅导新人,教学相长;
  11. 了解业务领域;
  12. 明确需求,寻求最佳解决方案,站在雇主/客户角度思考;
  13. 谦逊,充满自信,勇于承担有把握的风险,不嘲笑他人,出问题时接受他人嘲讽;
  14. 了解领域:
  • 设计模式。GOF中的24种,POSA书中的多数模式实战经验;
  • 设计原则。SOLID原则,深刻理解组件设计原则;
  • 方法。XP、Scrum、精益、看板、瀑布、结构化分析及结构化设计;
  • 实践。测试驱动开发、面向对象设计、结构化编程、持续集成和结对编程;
  • 工件。UML、DFD、结构图、Petri网络图、状态迁移图表、流程图和决策表;

二、说“不”

  1. 面对艰难决定,直面不同角色冲突是最好的办法,相互说“不”,找到双方都能接受的解决方案;
  2. 有时候不需要给出“为什么”,太多细节可能招致更多微观管理;
  3. 高分险关键时刻,“不”字就越具有价值;
  4. 团队精神,恪尽职守,明确做到或者做不到,不会总是说“是”;
  5. 强调不确定性,不要承诺“试试看”;
  6. 避免消极对抗,坚持说“不”;
  7. 获取正确决策的唯一途径,是勇敢无畏地说出“不”;
  8. 坚持写好代码,坚守专业精神,学会说“不”;

三、说“是”

  1. 承诺,口头上说,心里认真,付诸行动;
  2. 不要使用,需要、应当,希望,但愿,让我们等词语;
  3. 只承诺自己能完全掌控的事;
  4. 即使目标无法完成,仍然全力以赴,离目标更近;
  5. 无法兑现承诺时,尽早向承诺对象发出预警;

四、编码

  1. 代码必须正常工作;
  2. 代码必须能够解决问题;
  3. 代码必须与现有系统良好融合;
  4. 代码必须有很好的可读性;
  5. 疲劳或心烦意乱,不要编码;
  6. 焦虑时不要编码;
  7. 结对编程解决难题;
  8. 创造性输入,广泛阅读;
  9. 尽量做到降低调试时间,意味着代码质量很高;
  10. 保持节奏,调整状态,保持精力和创造力;
  11. 疲劳时停下;
  12. 不要盲目冲刺加快进度,欲速则不达,坚持估算
  13. 要求“完成”高标准,不应付;
  14. 多交流,从他人的思考和想法中获益;
  15. 帮助别人;
  16. 接受他人帮助;
  17. 给予新人辅导帮助;

五、测试驱动开发TDD

  1. 此事已定,争论结束,GOTO有害、TDD确实可行;
  2. TDD优势,确定性、降低缺陷率、勇于修改代码的勇气、单元测试即是文档、迫使你考虑好的设计、专业人士的选择;
  3. TDD局限,不是所有场合都适用,视情况选择使用;
  4. TDD三项法则:
  • 优先编写失败单元测试,然后编写产品代码;
  • 有一个单元测试失败,停止编写测试代码,直到产品代码通过;
  • 产品代码恰好能够让当前失败的单元测试通过即可,不要多写;

六、练习

  1. 努力拓展自身经验,接触不同领域;
  2. 为开源项目贡献代码;
  3. 业余时间保持练习,保持技能不落伍;

七、验收测试

  1. 确保沟通准确、流畅;
  2. 避免过早精细化;
  3. 业务观察者效应,通过看到完成的样子又会产生新的想法,改变需求;
  4. 需求一定是会变化的,开发人员无需精确,只是评估;
  5. 开发人员尽量确认需求中没有任何不确定因素,通过验收测试完成;
  6. 验收测试,业务与开发合作编写的测试,用于确定需求已经完成;
  7. 验收测试的目的是开发、业务、测试对验收测试达成共识;
  8. 验收测试都应当自动化;
  9. 验收测试应当越晚也好,通常是功能完成的前几天;
  10. 验收测试不是单元测试;
  11. 保持持续集成,测试失败立刻中止,确保测试通过;

八、测试策略

九、时间管理

  1. 决绝不需要的会议;
  2. 凡是不能在5分钟内解决的争论,都不能靠辩论解决;
  3. 按照真实的紧急程度执行任务;
  4. 保持开放的头脑听取其他意见,路的尽头依然有其他选择;
  5. 持续保持代码整洁,发现错误或不当立刻修改,不要等到必须修改时才去修改;
  • 我昨天干了什么?
  • 我今天打算干什么?
  • 我遇到了什么问题?
  • “立会”:

十、预估

  1. 预估是业务和开发之间最主要的障碍;
  2. 业务认为预估是承诺,开发认为预估是猜测;
  3. 承诺必须做到,预估是一种猜测,不包含任何承诺色彩;
  4. 墨菲定律,如果可能出错,就一定会出错;
  5. 避免给出暗示性承诺;
  6. 只在确切可以完成的前提下,才给出承诺;
  7. 一组人集合讨论,预估时间,知道意见统一;

十一、压力

  1. 保持冷静果断,尽管压力不断增大;
  2. 保持冷静的最好方式,是尽量规避导致压力的环境;
  3. 不做不切实际的承诺;
  4. 保持代码整洁,牺牲代码质量并不会加快进度,只会导致缓慢;
  5. 危机中保持信念;
  6. 保持冷静,与人沟通,坚持信念,直面压力;

十二、协作

  1. 深刻理解业务目标;
  2. 遵守制度规范,端正工作态度;
  3. 代码共享;
  4. 结对编程是解决问题的有效方法;

十三、团队与项目

  1. 先创建有凝聚力的团队,然后分配项目,不要围绕项目构建团队;
  2. 团队比项目更难构建;

十四、辅导、学徒期与技艺

附录、工具