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. 即使通报进展与问题
发布进展状况,新的想法和目前正在关注的主题,不要等着别人来问项目状态如何

高效程序员的45个习惯-敏捷开发之道 读书笔记