( ︎ ●—● )

高效程序员的45个习惯

2018-02-26 14:32:41

读书笔记 高效
  1. 上帝发明了时间,就是为了防止所有事情同时发生
  2. 好的设计应该是正确的,而不是精确的
  3. 计划是没有价值的,但计划的过程是必不可少的
  4. 盲目地为项目选择技术框架,就好比是为了少交税而生孩子
  5. 不要开发你能下载到的东西
  6. 对象-关系的映射就是计算机科学的越南战场-Ted Neward
  7. 保持你的项目时刻可以发布,保证你的系统随时可以编译,运行,测试,并立即部署
  8. 提早集成,频繁集成
  9. 提早实现自动化部署
  10. 清晰可见的开发,积极获取客户的反馈下
  11. 使用短迭代,增量发布
  12. 给我一份详细的长期计划,我就会给你一个注定完蛋的项目
  13. 对付大项目,最理想的办法就是小步前进
  14. 尽快发布你的应用,迟了也许它就没有用了
  15. 固定的价格就意味着背叛承诺
  16. 使用自动化的单元测试,好的单元测试能够为你的代码问题提供及时的警报,如果没有到位的单元测试,不要进行任何设计和代码修改
  17. 先用它再实现它,将TDD作为设计工具,它会为你带来更简单更有实效的设计
  18. 为核心的业务逻辑创建测试,让你的客户单独验证这些测试,要让他们像一般的测试一样可以自动运行
  19. 判断工作进度最好是看实际花费的时间而不是估计时间
  20. 度量剩下的工作量,不要用不恰当的度量来欺骗自己或者团队,要评估那些需要完成的待办事项
  21. 每一个抱怨的背后都隐藏了一个事实,找出真相,修复真正的问题
  22. 没有愚蠢的用户,只有愚蠢,自大的开发人员
  23. 软件设计有两种方式,一种是设计得尽量简单,并且明显没有缺陷。另一种方式是设计得尽量复杂,并且没有明显的缺陷-Hoare
  24. 开发代码时,应该更注重可读性,而不是只图自己方便。代码阅读的次数要远远超过编写的次数,所以在编写的时候值得花点功夫让它读起来更加简单。
  25. 好的编码规范可以让代码变得易于理解,同时减少不必要的注释和文档,要编写清晰的而不是讨巧的代码,向代码阅读者明确表明你的意图,可读性差的代码一点都不聪明
  26. 对于类中的每个方法,可能要说明下列信息
    目的:为什么需要这个方法?
    需求(前置条件):方法需要什么样的输入,对象必须处于何种状态,才能让这个方法工作?
    承诺(后置条件):方法成功执行后,对象现在处于什么状态,有哪些返回值?
    异常:可能会发生什么样的问题?会抛出什么样的异常?
  27. 动态评估权衡:考虑性能,便利性,生产力,成本和上市时间,如果性能表现足够了,就将注意力放在其它因素上,不要为了感觉上的性能提升或者设计的优雅,而将设计复杂化。
  28. 过早的优化是万恶之源
  29. 在很短的编辑/构建/测试循环中编写代码:这要比花费长时间仅仅做编写代码的工作好得多,可以创建更加清晰,简单,易于维护的代码
  30. 要休息的话,就要好好休息,休息时请远离键盘。