高效程序员的45个习惯

习惯三）对事不对人
主要精力要用于解决问题，而不是去评价团队他人。

习惯四）排除万难
代码出现问题最好的办法是重构，但前提是你要理解它。

习惯五）不断学习
迭代和增量式学习，每天计划用一点时间学习新技术，不需要很多时间，但需要经常进行。工作过程中遇到不熟悉的东西，可以先记下来，把它列入学习计划。
通过互联网社区了解最新的技术资讯。如饥似渴的阅读，找一些写的比较好的书，深入了解一门技术。

习惯六）对团队投资
个人能力远远不够，团队的努力才能做好项目。共同阅读一本书，一起交流学习心得。

习惯七）懂得丢弃
勇于接受新事物，开发自己的技术增量。

习惯八）打破砂锅问到底
5why法：从问题出发，不断追问为什么，告别直接原因，路过间接原因，最终找到根本原因。

习惯九）把握开发节奏
小而可达到的目标会让团队全速前进。

习惯十）让客户做决定
尽可能为客户多呈现几种技术方案，并为客户全面讲述各种方案的利弊，以及潜在的成本与收益。最终，让客户决定采用何种方案。

习惯十一）不要让设计操纵开发
不要一开始就纠结代码应该怎么写。

习惯十二）合理的使用技术
世界上没有做好的技术，只有最适合的技术。以问题为导向去选择最适合的技术。
不要重复发明轮子，你的代码写的越少，你需要维护的东西就越少。

习惯十三）保持软件可以随时发布
使用版本控制系统管理代码。

习惯十四）提早集成
早集成能更早发现问题，但也不能过于频繁。

习惯十五）提早实现自动化部署
开发环境能运行，生产不一定能运行。

习惯十九）自动化单元测试
使用Junit进行单元测试

习惯二十）测试驱动开发
测试驱动开发 - 要求开发者只有在自动测试失败的情况下才编写新的代码

习惯二一）不同的运行环境就会有不同的结果
设置一个主构建平台

习惯二二）自动化验收测试
交付测试/场景测试

习惯二五）代码要清晰的表达意图
提升代码可读性一定是要在编码当下执行, 而不要自我安慰等到后面有时间再来修改代码.

习惯二六）用代码沟通
在代码可以清晰传递意图的地方不要使用注释
解释代码做了什么的注释用处不大, 相反注释要说明为什么要这样写代码

习惯二七）动态评估取舍
有了明确的目标, 在复杂的环境中才不会迷失方向.

习惯二八）增量式编程
不要一次性编写一大堆代码, 而应该经常评估代码质量, 并不时地进行许多小调整, 不要一次性编写或修改许多东西.

习惯二九）保持代码简单
简单的代码让读者第一眼看上去, 就知道它的意图和作用

习惯三十）编写内聚的代码
在开发过程中, 让类的功能尽量集中, 尽量做到一个类或组件只做一件事情, 保证让类或组件尽量小, 要避免创建很大的类或组件, 也不要创建无所不包的大杂烩类.

习惯三一）命令与查询相分离
不要让一个查询方法去改变对象的状态

习惯三二）不要滥用继承
当我们要准备使用继承时, 要想想派生类是否可以替换基类. 如果答案是否定的, 那么就要问问自己为什么要使用继承, 如果只是希望在编写新类的时候想重用基类中代码, 那么使用聚合是最佳编程实践.
聚合是指在新建类中包括一个对象, 并且该对象是其他类的实例, 开发人员将职责委托给所包含的对象来完成.

习惯三五）对问题分而治之
二分查找法

习惯三六）报告所有的异常
写代码的时候一方面要考虑该语句在正常状态下是如何运转的, 同时也要想一想该语句没有按照我们预定的目的去运行的时候, 会发生些什么异常情况.
在调用别人的代码模块时, 同样也会出现异常情况, 这时候我们可以试着对其处理, 并从失败中恢复.

习惯三七）提供有用的错误信息
一方面要给软件使用用户提供清晰, 易于理解的问题描述和解释, 明确地告诉用户软件当前发生了什么问题, 应该怎么办.
另一方面还要提供具备关于错误的详细技术细节, 这样方便开发人员寻找代码中的真正问题之所在, 这些信息可以以超链接的形式存在, 因为这些信息不需要直接暴露给最终用户.

习惯三八）定期安排会面时间
站立会议注意事项:
1.10-15分钟比较合适, 每个参与者发言不要太长, 如果要详细讨论某些问题, 可以等会议结束后再详细深入讨论
2.会议中给出具体的进度, 但是不要陷入细节中.

习惯三九）架构师必须写代码
架构师的职责是要根据原型开发, 编码, 测试, 验证等环节不断演化自己的方案, 实现真正可用的设计.

习惯四十）实现代码集体所有制
如果某一段代码只有一位开发人员有能力去处理, 那么会给整个项目带来极大风险.
当自己的工作会被别人注意时, 一定会更加小心自己当前手中的工作, 这是人性.

习惯四一）成为指导者
有些人努力爬上技术高峰后, 再以藐视的眼神轻视他人, 这样的话就会建立沟通的障碍. 此后团队中的其他人可能处于畏惧或尴尬, 而不愿意提出问题, 这样就
无法完成知识的交换了, 我们要成为指导别人的人, 而非折磨别人的人.

习惯四四）做代码复查
为何进行代码复查:
1.形成统一的代码风格
2.提前发现重大缺陷
3.设计逻辑, 思路的审查
4.团队共同的进步

代码复查的内容:
1.代码可读性
2.是否存在明显的错误
3.是否存在大量重复的代码
4.是否存在可以改进或重构的部分

习惯四五）及时并主动汇报进展与问题
及时并主动的汇报工作进展与问题, 当有问题发生时, 就不会让相关方感到突然, 而且他们也很愿意了解当前的进展状况.
如果要等到截止日期才发布坏消息, 会让你的上级和同事对你产生不靠谱的影响.