高效程序员的45个习惯2

1.选用有意义的注释,用注释描述代码意图和约束,注释不能取代好的代码
2.在性能.商业价值.优雅.生产力几个因素上,没有必要追求所有的最优,开发者需要权衡,合理投入
3.使用渐进的方式来编程,寻找优化点,而不是追求一气呵成,除非有不可辩驳的理由,否则不要使用艰深的技术.模式,使用最简单的解决方案
4.让类的功能尽量集中,让模块尽量小..
5.Liskov替换原则告诉我们:任何继承后得到的派生类对象,必须可以替换任何被使用的基类对象,而且使用者不必知道任何差异.遵循此原则,相对于基类的对应方法,派生类服务应该不要求更多,不承诺更少,要可以进行自由的替换:如果新类可以替换已有的类,并且它们之间的关系可以通过is-a来描述,就要使用继承；如果新类只是使用已有的类,并且两者之间的关系可以描述为has-a或是users-a,就使用委托.
6.不妨维护一个保存曾遇到的问题以及对应解决方案的日志.这样就可以快速搜索以前用过的方法.
格式:
问题发生日期
问题描述
解决方案详细描述
引用文章和链接,以提供更多的细节
任何代码片断.设置或者对话框的截屏
如果解决了新的问题,就及时记录在这个地方.
关于记录
记录问题的时间不要超过解决的时间,保持轻量级
找到以前的解决方法非常关键,使用足够的关键字,可以帮助你找到需要的条目

7.警告,签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法,签入构建工具中的代码不应该产生任何警告信息.
8.识别复杂问题的第一步,是将它们分离出来,对问题各个击破,可以将关注点放在问题相关的议题上.通过各种改变,来接近问题的核心.

9.处理或是向上传播所有的异常,如果代码中会记录运行时调试日志,当捕获或是抛出异常时,都要记录日志信息,这样做对以后的跟踪工作很有帮助.
10.提供给用户的信息可以包含一个主键,以便于在日志文件或是审核记录中定位相关内容.


11.立会时将团队召集在一起,并让每个人了解当下进展状况的好办法.不允许就坐,否则与会者会跟到舒适而让会议延长.
12.保证会议不会发散,每个人只要回答下述三个问题,确保发言时间不要太久,建议总共会议不超过30分钟
     昨天有什么收获
     今天计划做什么工作
     面临些什么障碍
13.立会的好处
让大家尽快投入到一天的工作
如果某人有问题,可以趁机公开并寻求帮助
帮助决策者了解什么地方需要帮助,重新分配资源
让成员知道项目其他部分的进展
帮助团队识别重复劳动,或者知道某个问题已经有了现成的解决方案.
通过促进代码和思路的共享,来提高开发速度.
鼓励向前

14.好的设计者必须能够卷起袖子,加入开发队伍,毫不犹豫的参加实际编程.优秀的设计从积极的程序员那里开始演化.积极的编程可以带来深入的理解.不要使用不愿意编程的架构师--不知道系统的真实情况,是无法展开设计的.
15.不要声明个人对代码的所有权,任何一个团队成员,只要理解某段代码的来龙去脉,就应该可以对其处理.满足用户期望才是最重要的事情.这不是说可以随意修改别人的代码.需要强调知识分享


16.成为指导者,意味着分享,自己的知识.经验.体会,意味着要对别人的所学和工作感兴趣,愿意为团队增加价值,分享自己的知识很有趣,付出的同时便有收获.可以激励别人,提升团队实力.
17.给别人提供解决问题的机会,指给他们正确的方向,而不是直接提供解决方案,让每个人都能成长起来.(用问题来回答问题,可以引导提问的人走上正确的道路.如果真的有人陷入胶着状态,不要折磨他们了,告诉他们答案,再解释为什么这样)
18.保证在提交代码之前,单元测试通过了,使用持续集成保证代码质量是不错的方法.不要提交尚未完成的代码,故意签入未通过或者没有通过单元测试的代码,这是很不好的行为.
19.正式的进行代码复查工作,最基本的检查列表有:
代码能否被读懂和理解
是否有任何明显的错误
代码是否会对其它部分产生不良影响
是否存在重复的代码
是否存在可以改进和重构的部分
及时跟踪代码检查中发现的问题的修正情况.
20可以考虑Similarity Analyzer或Jester这样的代码分析工具.
21.及时向管理层和关注项目的人通报进行状况,不要等别人来问.尽快想法子快速完成这种反馈,不要花很多时间.


summary:从现在开始进行
www.agiledeveloper.com/download.aspx


http://toolshed.com/blog

http://www.urbancode.com/projects/anthill/default.jsp

www.martinfowler.com/articles/continuousIntegration.html

http://cruisecontrol.soureforge.net

http://dev.buildpatterns.com/trac/wiki/DamageControl

http://fit.c2.com

http://c2.com/cgi-bin/wiki?Information

www.stsc.hill.af.mil/crosstalk/2004/10/04010Jones.html

转自冲哥的总结