高效程序员的45个习惯1

1.一个错误是一次学习的机会而不是指责人的机会
2.面对一次临时改动就能修复的东西,好的表现是多想想,搞清楚它后面的机制,而不仅仅是修复它.不要坠入简单的修复代码中,要花时间保持代码的整洁
3.对事不对人.
4.设定期限,确保一件事情能正常的运转而不是无休止的争论
5.会议上设定一个仲裁人,避免会议被自由发挥而离题
6.支持已经做出的决定
7.脱离实际的反方观点会使争论变味.若对一个想法有成见,你很容易提出一堆不太可能发生或者不太实际的情况去批驳它
8.不顾一切,向正确的方向前进
9.如果设计或者代码中出现了奇怪的问题,花时间去理解为什么代码会是这样的.如果你找到了解决方法,但代码依然令人费解,唯一的方法就是重构代码,如果你没有理解这个代码,不要轻易去否定甚至重写,那是鲁莽,不是勇气.
10.对缺乏背景知识的听众,需要用他能听懂的话来表述问题.

学习
11.保持自己技术的新鲜,用迭代和增量式的学习会是一个好办法,每天都计划出一点时间来学习,重在坚持.
12.经常读一些最新技术的blog,了解别人在关注的东西,不要闭门造车.
13.经常阅读.人不可能成为每个领域的专家,但是可以成为某个领域的专家,选择学习一门新技术的时候,不要靠冲动而是需要一些来自资深者的建议.了解新技术的优势.
14.在轻松的环境里分享自己的所得,聆听别人的意见
15.勇于抛弃旧的知识和习惯
16.转换知识的时候,尽量切换到新的环境,即使慢也要坚持(这个我自己有个例子,我一开始学习的是拼音打字法,后来学习五笔打字法的时候,字根什么都能背了,但是每次打字前都要思考一下,觉得好慢,于是就想,抽时间专门练习吧,还是完成手头的输入先,于是用拼音完成了输入.最终的结果是,我一直没有等到那个专门练习的机会)
17.打破砂锅问到底是一个很好的习惯.



18.上帝发明了时间,就是为了防止所有的事情同时发生,不要随意的安排计划,让开发保持一个固定的节奏,这样整个团队的人都有了共同的期待,让事情更可控.
19.每天作为一个单位,不残留代码,以固定的节奏运行迭代.
20.开发者真正的敌人事变化,只有能识别和适应变化的能力才是制胜关键.
21.开发者能做的一个最重要的决定就是:判断哪些东西是自己决定不了,而是应该由需求方决定的,不要给业务上的关键问题做决定
(记录客户做出的决定,并注明原因,不要随意假设低级的问题不会影响客户的业务)

22概要设计相当于战争中的战略设计,不要困在过多的细节里面,这是详细设计的职责(相当于战术设计) Strategic versus tactical design
23好的设计应该是正确的,而不是精确的.即它描述的一切必须是正确的,不应该涉及不确定或者可能发生变化的细节.
24.选择新技术要谨慎,多问自己几个为什么,选适合的而不是为了其他的理由(学习的理由/模仿的冲动),不要重复开发(Don't build what you can download)
25.已经提交的代码应该随时可以行动(Checked-in code in is always ready for
action),千万不能让代码即不能发布,又不能撤销.

26.早期集成是一个抵御风险的好习惯.不要做大爆炸式的集成
27.自动化部署很重要,便于快速修正问题,让开发不用一直纠结在环境中.


28.经常给客户演示程序,不管演化和纠正偏离方向的地方
29.琐碎的问题记录不应当随意,应当约定好一个记录的地方,方便所有人跟踪.
30.找到产品中不能缺少的核心功能,尽快让它能发布,尽量使用小步伐来完成大系统,不要花太多时间在华而不实的功能
31.短迭代会让人感觉非常专注且有效率.如果每个迭代的时间都不够用,要么是任务太大,要么是迭代周期太短,把握好节奏

32.让团队和客户一起,真正地在当前项目中工作,做具体实际的评估.由客户控制他们想要的功能和预算.

33.确保测试是可重复的,使用当前时间,当前机器ip之类的东西有时候会让单元测试产生依赖
     测试边界条件
     不要放过任何一个失败的测试.
34.Write tests before writing code.
35.不要假设代码是在任何环境都能很好运行的,不同的环境,就有不同的问题:使用持续集成工具,在每一种支持的平台和环境中运行单元测试,积极寻找问题
36.为核心的业务逻辑创建测试.让你的客户单独验证这些测试,要让它们可以像一般的测试一样自动运行.

37.用实际消耗的时间而不是估算的时间来看进度,设置合理的待办事项,完成的从列表里去掉,新来的就重新排列优先级,加入待办事项,不断和评估的时间做对照修正,这样后面就能评估得比较准确了.不要用不准确的评估来欺骗自己和团队.
38.一周有40个工作小时,但是这些不都是编码时间,需要把会议/电子邮件/其它从中去掉.
39.对于用户"愚蠢"的抱怨,不能生气和轻视,要找出背后的真相,学会倾听.


40.PIE原则,代码必须明确说出你的意图,而且必须富有表达力,这样可以让代码更易于被别人理解和阅读,代码不让人迷惑,也就减少了发生潜在错误的可能.
PID=Program Intently and Expressively 意图清楚并且表达明确的编程.
41.代码被阅读的次数要远大于被写的次数,所以容易理解是很重要的

转自冲哥的总结