高效程序员的八个习惯

最近对敏捷比较感兴趣，正好翻看了《高效程序员的45个习惯-敏捷开发修炼之道》，颇有些感触，倒不是对敏捷的实施方法，而是文中所提的一些习惯之处，觉得习惯的养成可能比具体的敏捷实践要重要得多。所以这里借用下文中标题，谈谈对高效程序员习惯的理解。

<h2>一、做事优先</h2>
在项目团队开发过程中，出现问题时最高优先级应该是解决问题，而不是找到责任人并进行指责。当然在问题解决之后，可以找到责任人一起分析问题产生的原因，尽量在后期避免再次发生。在团队还是能看见一些成员喜欢“推卸责任”或者“事不关已，高高挂起”，这往往不可取。

<h2>二、欲速则不达</h2>
必须得承认人是有惰性的，如果个人对自身的要求不高或者项目的进度比较紧的情况下，就容易为了完成任务而“赶进度”，这样造成的后果就是质量太差而花了更多的时间去修复问题。又或者是解决bug的时候只是解决“浅层次”的问题，比如可能存在类似问题的地方不做检查解决、可能只是解决了单个场景的问题等等，结果没有从根本上将问题解决。所以这里要提倡重速度更要重质量，“为了看起来完成任务”的思想要切换成“为了有效地完成任务”，“解决单个问题”要切换成“解决一类问题或根本问题”。

<h2>三、对事不对人</h2>
在与人沟通具体事情的过程中尽量要保证客观公正，避免夹带过多感情色彩。因为这样才能更好地让大家关注在事情本身，而不至于因为个人情感表达造成对当事人的伤害。这里一方面需要注意对不同的声音持有一个开放的态度，另一方面也需要在沟通过程注意方式方法，比如对事情有不同看法时最好以提问的方式提醒当事人，这样在情感上更加容易接受。

<h2>四、有问题要沟通</h2>
程序员喜欢钻研问题，但容易陷入死胡同。比如问题比较棘手的时候，往往喜欢闷头研究而不愿求助，最后可能有些问题就会一直比较纠结而得不到很好的解决。而实际的经验一次又一次的告诉我们往往求助之后可能立即豁然开朗或者得到新的解决思路。所以在实际遇到问题时，当然首先需要自己想办法解决，然而在黔驴技穷的时候一定不能将问题捂住，一定要寻求沟通与帮助。另外如果是发现别人的问题，那更加需要及时地提醒，更进一步还可以提供解决方案以供参考。

<h2>五、终身学习</h2>
信息技术的发展可谓是日新月异，所以需要大量的学习才能保证对知识的敏锐度。书中提到的几个方法值得对待：（1）迭代和增量式的学习：即花固定的不需要太长的时候持续学习；（2）了解最新行情；（3）参加本地的活动：比如讲座或者培训；（4）参加研讨会议；（5）如饥似渴地阅读。总之就是生命不止，学习不息。这方面我有个自认为的最佳实践：学习一方面需要考虑兴趣，喜欢的才高兴去学；另一方面需要考虑整个行业的发展方向，跟着大势起码不容易过时；另外最好能“学以致用”或者“解惑”，这样可以更快地实践检验和得到反馈。

<h2>六、投资团队</h2>
“教会徒弟，饿死师傅”这样的话经常被当做玩笑话讲，不过实际情况中确实也有不少人存在这样的想法，但是这种想法是非常危险的。如果这样的人做为领导，团队的实力会很难提高，另外自身的水平也会受到很大的局限性。另外现在是个崇尚开源的技术世界，不论是做为领导还是普通的一员，都要乐于分享，保持一个开放的心态，多听多讲必有所获。如果在公司可以定期组织一些分享交流会或者坐谈会，而且形式也不用过于死板，可以轻松愉快点。

<h2>七、打破砂锅问到底</h2>
凡事多问几个为什么，对于问题要不满足于简单地解决，更进一步要了解问题产生的原因？遇到类似问题怎么解决？怎么解决更好等等。总之重要的不是问题本身，而是问题背后深层次知识的掌握和解决类似问题的方法。

<h2>八、客户为大</h2>
程序员做为项目的实施人员喜欢从实施的角度考虑问题，而忽视用户的角度，这样往往就造成对需求的理解与用户存在偏差，更有甚者有些程序员直接闭门造车，最后交付的时候与用户所想千差万别。所以程序员一定要多注意以客户（业务）的角度考虑问题，在需求不明确的时候不要埋头若干或想当然地实施，一定要及时与需求方进行沟通确认。
<h2></h2>
我这里没有讲到太多的编码细节相关的习惯，原书其实提到了很多，还有大量的讲解与示例，而且都有一些实践的技巧讲解。我更多地是谈了些个人的体会，不及书中万一，所以这里推荐下这本书，值得一看。

同步发表于CSDN博客：http://blog.csdn.net/qiubabin