登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

读《高效程序员的10个习惯》  

2010-04-19 13:55:52|  分类: 读书 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

读《高效程序员的10个习惯》 - 秒大刀 - 秒大刀的城堡

本书下载地址:http://www.infoq.com/cn/minibooks/practice-agile-developer


译者序

迭代开发,价值有限;分解任务,真实进度

站立会议,交流畅通;用户参加,调整方向

结对编程,代码质量;测试驱动,安全可靠

持续集成,尽早反馈;自动部署,一键安装

定期回顾,持续改进;不断学习,提高能力

 

习惯一:对事不对人

  1. 发现别人明显的错误后:不要否定个人能力;不要指出明显的缺点,并否定其观点;而应该询问你的队友,并提出你的顾虑。
  2. 引导性的提出一个疑问,并让他们自己意识到问题
  3. 要专业而不是自我
  4. 注意礼貌的对待他人,将有利于整个团队关注真正有价值的问题,而不是勾心斗角、误入歧途
  5. 负面的评论和态度会扼杀创新
  6. 必须把重点放在解决问题上,而不是极力证明谁的主意更好。
  7. 只是智商高是没有用的,顽固和拒绝合作是非常糟糕的。
  8. 你不需要很出色才能起步,但你必须起步才能变得更出色
  9. 如果你是一个有远见的人,就一定要特别尊重别人的意见。你是一个掌舵者,一定要把握方向,深思熟虑,吸取各方意见。
  10. 能容纳自己并不接受的想法,表明你的头脑足够有学识——亚里士多德
  11. 会议建议:
    1. 设定最终期限。没有最好的答案,只有更合适的方案。设定期限能够帮助你在渭南的时候果断作出决策,让工作可以继续进行
    2. 逆向思维。一种客观对待问题的办法是:先是积极的看到它的正面,然后再努力的从反面去认识它。
    3. 设立仲裁人。仲裁人作为本次会议的决策者,确保让每个人都有发言的机会,并维持会议的正常进行。要防止明星员工操纵会议,并及时打断假太空式发言。仲裁人应该专注于调停,而不是发表自己的观点。
    4. 支持已经做出的决定。一旦方案被确定了(不管是什么样的方案),每个团队成员都必须通力合作,努力实现这个方案
  12. 让我们骄傲的应该是解决了问题,而不是比较出谁的主意更好
  13. 一个团队能够很公正的讨论一些方案的优点和确定,你不会因为拒绝了有太多缺陷的方案而伤害别人,也不会因为采纳了某个不甚完美(但是更好的)解决方案而被人忌恨。
  14. 尽力贡献自己的好想法,如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法儿对拟定好的思路画蛇添足
  15. 脱离实际的反方观点会使争论变味
  16. 想要支持或者反驳一个观点,有时候你必须先做一个原型,或者调查出它有多少的同意者或者反对者。
  17. 在开始寻找最好的解决方案之前,大家对“最好”的含义要先达成共识。在开发者眼中的最好,不一定就是用户认为最好的,反之亦然。
  18. 只有更好,没有最好。尽管“最佳实践”这个术语到处在用,但实际上不存在“最佳”,只有在某个特定条件下更好的实践。
  19. 不带个人情绪并不是要盲目的接受所有观点。

 

习惯二:跟踪变化

  1. 如果在是掌握了工作中需要的技术并不够。那样的工作也许几年之后就不再有了——它会被外包或者会过时。
  2. 坚持迭代和增量式的学习,如饥似渴的阅读
  3. 你不需要精通所有技术,但需要清楚的知道行业的动向,从而规划你的项目和职业生涯
  4. 你能嗅到将要流行的新技术,知道它们已经发布或投入使用。如果必须要把工作切换到一种新的技术领域,你能做到。
  5. 许多新想法从未变的羽翼丰满并成为有用的技术,所以你要正确的把握自己投入的精力。
  6. 你不可能精通每一项技术,没有必要去做这样的尝试。只要你在某些方面成为专家,就能使用同样的方法,很容易的成为新领域的专家。
  7. 你要明白为什么需要这项新技术
  8. 避免在一时冲动的情况下,只是因为想学习而将应用切换到新的技术、框架或开发语言。在做决策之前,你必须评估新技术的优势。开发一个小的原型系统,是对付技术狂热者的一剂良药。

 

习惯三:让设计指导而不是操纵开发

  1. 设计满足实现即可,不必过于详细
  2. 设计可以分为两层:战略和战术
  3. 如果你自己都不清楚所谈论的东西,就根本不可能精确的描述它——冯诺依曼
  4. 好的设计应该是正确的,而不是精确的。它是目标,不是具体的处方。
  5. “不要在前期做大量的设计”并不是说不要设计。只是说在没有经过真正的代码验证之前,不要陷入太多的设计任务。当对设计一无所知的时候,投入编码也是一件危险的事。如果深入编程只是为了学习或创造原型,只要你随后能把这些代码扔掉,那也是一个不错的方法。
  6. 即使初始的设计到后面不再管用,你仍需设计:设计行为是无价的。计划是没有价值的,但计划的过程是必不可少的。
  7. 白板、草图、便利贴都是非常好的设计工具。复杂的建模工具只会让你分散精力,而不是启发你的工作。

 

习惯四:提早实现自动化部署

  1. 有了自动化部署系统后,在项目开发的整个过程中,会更容易适应互相依赖的变化。
  2. 在没有询问并征得用户的同意之前,安装程序绝对不能删除用户的数据。

 

习惯五:度量真实的进度

  1. 判断工作进度最好是看实际花费的时间而不是估计的时间。
  2. 不应该去计算工作量完成的百分比,而应该测定还剩下多少工作量没有完成
  3. 工时度量中,诚实非常重要,隐瞒真相毫无意义
  4. 如果能一直让下一步工作是可见的,会有助于进度度量。最好的做法就是使用代码事项(backlog)
  5. 清楚项目的真实进度,是一项强大的技术。
  6. 不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
  7. 对于Scrum中的一个Sprint,不管怎么样,只要所有任务的评估总和超过了一个迭代剩余的时间,那么任务就必须移到下一个迭代中开发。
  8. 关注功能,而不是日程表

 

习惯六:用代码沟通

  1. 源代码可以被读懂,不是因为其中的注释,而是它本身优雅而清晰。
  2. 代码被阅读的次数要远超过被编写的次数,所以在编程时多付出一点努力会让你在将来受益匪浅的。
  3. 在代码可以传递意图的地方不要使用注释
  4. 解释代码做了什么的注释用处不那么大。相反,注释要说明为什么会这样写代码

 

习惯七:编写内聚的代码

  1. 重用的粒度与发布的粒度相同。软件包越大,可重用性就越差

 

习惯八:根据契约进行替换

  1. 继承是OO建模和编程中被滥用最多的概念之一
  2. 相对继承来说,聚合更加灵活,适应力也更强

 

习惯九:报告所有的异常

  1. 处理或是向上传播所有的异常。不要将它们压制不管,就算是临时这样做也不行。在写代码时要估计到会发生的问题。

 

习惯十:做代码复查

  1. 代码复查需要积极评估代码的设计和清晰程度,而不只是考量变量名和代码格式是否否和组织的标准。
  2. 同样的功能,不同的开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码明确变得更好,否则不要随意批评别人的代码。
  评论这张
 
阅读(1692)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018