敏捷开发修炼之道阅读笔记3

7. 敏捷调试

  1. 记录解决问题的日志

    • 不要在同一个地方跌倒两次
      每日日志
    • 维护一个问题及其解决方案的日志
      保留解决方案是修复问题过程的一部分,以后发生相同或类似问题时,就可以很快找到并使用了。
    • 要记录团队做出一个重要决策的原因
  2. 警告就是错误

    • 将警告视为错误
      签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。
  3. 对问题各个击破

    • 用原型进行分离
    • 对问题进行各个击破
      在解决问题时,要将问题域与其周边隔离开,特别是在大型应用中。
  4. 报告所有的异常

    • 处理或是向上传播所有的异常
      不要将它们压制不管,就算是临时的也不行。在写代码时要估计到会发生的问题。
  5. 提供有用的错误信息

    • 展示有用的错误信息
      提供更易于查找错误细节的方式。发生问题时,要展示出尽量多的支持细节,不过别让用户陷入其中。
    • 区分错误类型

      • 程序缺陷
      • 环境问题
      • 用户错误
    • 通过跟踪记录报告的错误类型,可以为受众提供更加合适的建议。

8. 敏捷协作

  1. 定期安排会面时间

    • 要保证会议议题不会发散,每个人都应该只回答下述三个问题:
      • 昨天有什么收获?
      • 今天计划要做哪些工作?
      • 面临着哪些障碍?
    • 每日立会有诸多好处:

      • 让大家尽快投入到一天的工作中来
      • 如果某个开发人员在某一点上有问题,他可以称此机会将问题公开,并积极寻求帮助
      • 帮助团队带头人或管理层了解哪些领域需要更多的帮助,并重新分配人手
      • 让团队成员知道项目其他部分的进展情况
      • 帮助团队识别是都在某些东西上有重复劳动而耗费了精力,或者是不是某个问题有人已有现成的解决方案
      • 通过促进代码和思路的共享,来提升开发速度
      • 鼓励向前的动力: 看到别人报告的进度都在前进,会对彼此形成激励
    • 使用立会
      立会可以让团队达成共识。保证会议短小精悍不跑题。

  2. 架构师必须写代码

    • 不可能在PowerPoint幻灯片中进行编程
    • 新系统的设计者必须要亲自投入到实现中去
    • 架构师最主要的任务是通过找到移动软件设计不可逆的方式,从而去除所谓架构的概念
    • 增加可逆性是注重时效的软件实现方式的关键构成部分
    • 优秀的设计从积极的程序员那里开始演化
      积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况,是无法展开设计的。
  3. 实行代码集体所有制

    • 要强调代码的集体所有制
      让开发人员轮换完成系统不同领域中不同模块的不同任务。
  4. 成为指导者

    • 教学相长(knowledge grows when given)
    • 分享自己的知识很有趣——付出的同时便有收获。还可以鼓励别人获得更好的成果,而且提升了整个团队的实力。
    • 结对编程是一种进行高效指导的、很自然的环境
  5. 允许大家自己想办法

    • 能欣赏自己并不接受的想法,表明你的头脑足够有学识
    • 给别人解决问题的机会
      指给他们正确的方向,而不是直接提供解决方案。每个人都能从中学到不少东西
  6. 准备好后再共享代码

    • 代码不执行提交操作的其他安全选择

      • 使用远程访问
      • 随身携带
      • 使用带有底座扩展的笔记本电脑
      • 使用源代码控制系统的特性
    • 绝不要提交尚未完成的代码。故意签入编译未通过或没有经过单元测试的代码,对项目而言,应被视为玩忽职守的犯罪行为

  7. 做代码复查

    • 代码复查和缺陷移除
      要寻找深藏不露的程序bug, 正式的进行代码检查,其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知方法
    • 对于提升代码质量和降低错误率来说,代码复查是无价之宝。如果以正确的方式进行,复查可以产生非常实用而高效的成果。要让不同的开发人员在每个任务后复查代码
    • 除非你可以让某段代码明确变得更好,否则不要随便批评别人的代码
  8. 及时通报进展与问题

    • 发布进展状况,新的想法和目前正在关注的主题。不要等着别人来问项目状态如何

9. 尾声: 走向敏捷

      • 一灯能除千年暗,一智能灭万能愚
      • 只要一个新的习惯,就让团队发生了巨大的变化
      • 拯救频临失败的项目
        如果事态没有那么糟糕,可以采取更加全面、整齐的方式来引入敏捷习惯
        • 引入敏捷:管理员指南
        • 引入敏捷:程序员指南
posted @ 2021-09-26 16:02  禁小呆  阅读(53)  评论(0)    收藏  举报