首页 > 读书笔记 > 《高效程序员的45个习惯-敏捷开发修炼之道》(下)

《高效程序员的45个习惯-敏捷开发修炼之道》(下)

四. 敏捷反馈
一步行动,胜过千万专家的意见。

  • 19. 守护天使:编写能产生反馈的代码,单元测试是不错的实践。使用自动化的单元测试,好的单元测试能够让你的代码问题提供及时的警报。可以使用一些成熟的单元测试框架,比如gtest for C/C++, PyUnit for python, Junit for Java, etc。
  • 20. 先使用它再实现它:测试驱动开发,编程之前,先写测试
  • 21. 不同环境, 就有不同问题:使用持续集成工具,在每一种支持的平台和环境中运行单元测试。要积极地寻找问题,而不是等问题来找你。
  • 22. 自动验收测试:为核心的业务逻辑创建测试,让你的客户单独验证这些测试,要让他们像一般的测试一样可以自动运行。
  • 23. 度量真实的进度:不要用不恰当的度量来来欺骗自己或者团队,要评估那些需要完成的待办事项,可以做成待办事项列表,完成一项移除一项,真实的度量剩下的工作量。
  • 24. 倾听用户的声音:每一个抱怨背后都隐藏了一个事实,找出真相,修复真正的问题。没有愚蠢的用户,只有愚蠢、自大的开发人员。

五. 敏捷编码
任何一个笨蛋都能够让事情变得越来越笨重,越来越复杂,越来越极端。需要开才的指点以及许多的勇气,才能让事情向相反的方向发展。

  • 25. 代码清晰的表达意图:代码必须明确的说出你的意图,而且必须富有表达力。这样可以让代码更易于被别人阅读和理解。代码不让人迷惑,也就减少了发生潜在错误的可能。一言以蔽之,代码应该意图清晰,表达明确。 要编写清晰的代码而不是讨巧的代码。
  • 26.用代码沟通:使用细心选择的、有意义的命名,最好能让代码能够自注释。如果要加注释,必须要加有意义的注释,注释主要是为了描述代码意图和约束:
    (1)目的:为什么需要这个方法?
    (2)前置条件:方法需要什么样的输入,对象必须处于何种状态,才能让这个方法工作?
    (3)后置条件:方法成功执行后,对象现在处于什么状态,有哪些返回值?
    (4)异常:可能会发生什么样的问题?会抛出什么样的异常?
  • 27. 动态评估取舍:动态评估权衡,考虑性能、便利性、生产力、成本和发布时间。如果性能表现足够了,就将注意力放在其它因素上。不要为了感觉上的性能提升或者设计的优雅,而将设计复杂化。
  • 28. 增量式编程:在很短的编码、构建、测试循环中编写代码。保持代码在比较短的周期内(比如写完一个功能点)是可编译通过的,单元测试通过的,随着代码功能的完善,不断的完善单元测试。切身感受到的好处是,在写了几行代码之后,你会迫不及待地希望进行一次构建、测试循环。在没有得到反馈时,你不想走得太远。
  • 29. 保持简单:简单不是简陋,开发可以工作的、最简单的解决方案。除非有不可辩驳的原因,否则不要使用模式、原则和高难度技术之类的东西。但是,强行让代码变得优雅与过早优化类似,同样会产生恶劣的影响。
  • 30. 编写内聚的代码:让类的功能尽量集中,让组件尽量小。要避免创建很大的类或组件,也不要创建无所不包的大杂烩类。
  • 31. 告知,不要询问:查询与命令分开,查询只做查询,不要做修改代码的逻辑,绝对不允许一个看起来无辜的查询去修改对象的状态;命令用来完成某项明确的修改操作。不要抢别的对象或是组件的工作。告诉它做什么,然后盯着你自己的职责就好了。
  • 32. 根据契约进行替换:针对is-a的关系使用继承,针对has-a或use-a的关系使用聚合(委托)。继承要遵守“子类不应该要求更多,不应该承诺更小”的原则,相对于继承,聚合(委托)更为灵活,适应能力也更强。

六. 敏捷调试
你也许会对木匠那毫无差错的工作印象深户。但我向你保证,事实不是这样的,真正的高手只是知道如何亡羊补牢。

  • 33. 记录问题解决日志:不要在同一处跌倒两次。维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分,以后发生相同或类似的问题时,就可以很快找到并使用了。
  • 34. 警告就是错误:对于一个优秀的开发者来说,是绝不允许自己的代码有警告的。把警告视为错误是一种优秀的习惯。Check-in带有警告的代码,就跟check-in有错误或者没有通过单元测试的代码一样,都是极差的做法。
  • 35.对问题各个击破:有解决问题时,要将问题域与其周边隔离开,特别是大型应用中。二分法是不错的实践,通过二分法隔离,不断缩小问题的范围,直到定位问题。
  • 36. 报告所有的异常:对于异常,如果能正常捕捉处理的,请尽量处理;如果不能捕捉处理的,请向上传播。发生异常时,请提供足够的提示信息,或者是记录异常相关的日志,这对以后的跟踪工作很有帮助。
  • 37. 提供有用的错误信息:提示的错误信息,一定要是对跟踪问题有帮助的。发生问题时,要展示出尽量多的支持细节,不过别让用户陷入其中。

七. 敏捷协作
我不仅发挥了自己的全部能力,还将我所仰仗的人的能力发挥到极致。

  • 38. 定期安排会而时间:使用站立会议,每天开始工作前,团队成员一起开15分钟左右(最长不要超过30分钟)的站立会议。一方面帮助团队成员熟悉相互之间的工作,另一方面,可以更好的把控项目进度。
  • 39. 架构师必须写代码:优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师—-不知道系统的真实情况,是无法开展设计的。
  • 40. 实行代码集体所有制:在团队中实行任务轮换制,让每个成员都可以接触到不同部分的代码,要以提升团队整体的知识和专业技能。另外,还可以降低团队成员离开所带来的风险。
  • 41. 成为指导者:给予别人指导,也是提升自己的一种方式,并且让其他人亦开始相信你可以帮助他们。分享自己的知识很有趣—-付出的同时便有收获。还可以激励别人获得更好的成果,而且提升了整个团队的实力。
  • 42. 允许大家自己想办法:给别人解决问题的机会。“授人以鱼,三餐之需;授人以渔,终生之用”,指给他们正确的方向,而不是直接提供解决方案。每个人都能从中学到不少东西。
  • 43. 准备好后再共享代码:绝不提交尚未完成的代码。故意check-in编译未通过或者是没有单元测试没有通过的代码,对项目来说,应被视做玩忽职守的犯罪行为。
  • 44.做代码复查:代码复查即我们通过所说的codereview, 对于提升代码质量和降低错误率来说,代码复查是无价之宝。如果以正确的方式进行,复查可以产生非常实用而高效的成果。通常的做法是搭建codereview系统,有经验的开发者来review开发经验比较少的开发者的代码,提高代码质量的同时,帮助团队成员成长。
  • 45.及时通报进展和问题:发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。这样,有情况发生时,就不会让人感到突然。
  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.
您必须在 登录 后才能发布评论.