zoukankan      html  css  js  c++  java
  • 高效程序员的45个习惯敏捷开发之道 读书笔记


    1. 做事
    在软件出了bug之后,应该首先根据现象找到问题的根源,而不是去找到当时编写这段代码的人,去痛骂一顿,指责是不能解决bug的.
    2. 欲速则不达
       2.1 不要急于修复一段自己没有看懂的代码,另外,在修正时,要投入时间和精力保证代码的整洁和可阅读性
       2.2 代码阅读的时间是远大于编写的时间,所以在编写的时候指的花点功夫让他阅读起来更加简单
       2.3 如果在修正他人的bug时,发现难以理解,可以与其沟通商量,了解细节,同时自己也花时间理解一下,如果理解之后,代码比较难以费解,个人认为可以和实现者沟通商量,进行重构
    3. 对于他人的想法,我们的评论不能否定个人能力,也不能指出其观点中明显的缺点,并否定其观点,应该询问提出这个观点的人,并提出个人的疑虑(礼貌的对待自己的同事)
    4. 你不需要很出色才能起步,但是你必须起步才能变得很出色
    5. 几乎是没有完美的解决方案,我们能找到的是符合当前业务场景的最适合和最优的解决方案
    6. 你不可能精通每一项技术,也没有必要做这样的尝试.只要你在某些方面成为专家,就能使用同样的方法,很容易成为一个新的领域的专家
    7. 让客户加入到项目组中,并且让客户做决定
       7.1 当你和客户讨论问题的时候,准备好几种可选择的方案,不是从技术的角度,而是从业务的角度,介绍每种方案的优缺点,以及潜在的成本和利益.和他们讨论每个选择对时间和预算的影响,以及如何权衡.无论他们做了什么决定,都必   须接受他,最好让他们了解一切之后再做决定.如果事后他们有想要其他的东西,可以公正地就成本和时间重新谈判
       7.2 记录客户做出的决定,并且注明原因,可以使用工程师工作的日记或日志.Wiki,邮件记录或者问题跟踪数据库,但是也要注意,选择记录的方法不能太笨重或者太繁琐.
    8. 瀑布模型的重大缺点和不实用性
    严格的需求-设计-编码-测试开发流程源于理想化的瀑布式开发方法,它导致了在前面进行了过度的设计.这样在项目的生命周期中,更新和位数这些详细的设计文档变成了主要工作,需要时间和资源方面的巨大投资,却只有很少的回报
    9. 敏捷开发的工作流程是什么(参见IBM 敏捷开发过程中如何开发高质量的软件)
    10. 根据需要选择技术
    我们首先要考虑的是我们需要什么,接着为这些具体的问题评估使用技术,对任何要使用的技术,多问一些挑剔的问题,并真实的做出回答.
    11. 团队协作中如何防止个人的代码破坏系统的代码
       11.1 在本地运行测试
       11.2 检出最新的代码
       11.3 提交代码
       11.4 如果遇到其他人提交的代码没有通过编译或者测试,要通知他们
    11.5 保持系统可随时编译,运行,测试并且立即发布,因为无论什么时候,我们都可以把自己的项目演示给客户,领导和其他相关同事
    12. 使用短迭代,增量发布
      12.1 对付大项目,最理想的方法就是小步前进(敏捷方法的核心),大步跃进大大地增加了风险,小步前进才可以帮助你很好的把握平衡
      12.2 大部分用户就是希望现在就有一个够用的软件,而不是在一年之后得到一个超级好的软件,确定使产品有核心可以使用的功能,然后把他们放在生产环境中,越早交到用户的手里越好.
      12.3 使用短迭代和增量开发,可以使得开发者更加的专注于自己的工作,如果目标很遥远,就很难让自己去专注于他.

    13. 保证自己的代码能够实现高内聚和低耦合,这样的代码类似于组件(微件),组件之间可以结合,也可以随时脱离.
    14. 修改bug/添加新功能的一般流程

    1. 首先应该理解代码做了什么,他是如何做的
    2. 搞清楚需要更改那些部分
    3. 测试

    15. PIE原则: 代码要清晰的表达你的意图(我们需要的是清晰而不是讨巧的代码)
    16. 我们需要的是文档化所有的方法,而不是文档化所有的代码

    1. 方法体内部核心的要素需要注释,但是一般性的代码,应该通过变量名运用正确,空格使用得当,逻辑分离清晰,以及表达式非常简洁的方式来告诉读者,代码的意图
    2. 方法注释的书写

               1) 目的:为什么需要这个方法
        2) 需求(前置条件): 方法需要什么样的输入,对象必须出于何种状态,才能让这个方法执行
        3) 承诺(后置条件): 方法执行成功之后,对象现在处于什么样的状态,有哪些返回值
        4) 异常: 可能会发生什么样的问题?会抛出什么样的异常
    17. 过早的优化是万恶之源,因为程序没有最佳的解决方案
    18. 增量式编程
    采用增量式编程和测试,会倾向于创建更小的方法和更具内举行的类.你不是在埋头忙目的一次性编写一大推代码.相反,你会经常性评估代码,并不时的进行一些小的调整,而不是一次修改很多东西
    在编写了几行代码之后,你会迫切地希望进行一次构建/测试循环,在没有得到返回时,你不想走得太远
    19. 开发可以看工作的,最简单的解决方案
    除非有不可辨驳的原因,否则不要使用模式,原则和高难度技术之类的东西
    20. 让类的功能尽可能集中,让组件尽量小
    要避免创建一个很大的类或组件,也不要创建无所不包的大杂烩类
    21. 不要抢别的对象或是组件的工作,告诉他做什么,然后盯着你自己的指责就好了
    将命令和查询分开来,
    22. Bug调试相关方面
    22.1 识别复杂的问题的第一步,将他们分离出来(将他们与应用的其他部分隔离开,特别是在大型应用中)
    22.2 以二分查找的方式来定位问题是很有用的.也就是说,把问题空间分为两半,看看那一半包含问题,再讲包含问题的一半进行二分,并不断重复这个过程
    23. 即使通报进展与问题
    发布进展状况,新的想法和目前正在关注的主题,不要等着别人来问项目状态如何

  • 相关阅读:
    [算法] 堆栈
    [刷题] PTA 02-线性结构3 Reversing Linked List
    java IO流 (八) RandomAccessFile的使用
    java IO流 (七) 对象流的使用
    java IO流 (六) 其它的流的使用
    java IO流 (五) 转换流的使用 以及编码集
    java IO流 (四) 缓冲流的使用
    java IO流 (三) 节点流(或文件流)
    java IO流 (二) IO流概述
    java IO流 (一) File类的使用
  • 原文地址:https://www.cnblogs.com/pandapan/p/3943380.html
Copyright © 2011-2022 走看看