之前读了一本《高效程序员的45个习惯》，是以前总结的文章，最近把它在这里整理发布，顺便又重新看了一遍，发现又有收获，这本是在微信读书上可看
1 做事
一个重大的错误应该被当做一次学习而不是指责他人的机会，团队成员一起工作，应该互相帮助，而不是互相指责
2 欲速则不达
不要为了修复问题而去修复，要投入时间和精力保持代码整洁
3 对事不对人
一个团队能够很公正的讨论一些方案的优点和缺点，你不会因为拒绝了有太多缺陷的方案而伤害别人，也不会因为采纳了某个不完美（但更好的）解决方案而被人记恨
尽量贡献自己的好想法；不要脱离实际的争论；不要带个人情绪的争论和盲目接收观点
4 排除万难，奋勇前进
如果设计或者代码中出现了奇怪的问题，花时间去理解为什么代码会这样。如果你找到了解决办法，但代码还是令人费解，那么只能重构，让它可读性更强。如果你没有理解那段代码，就不要轻易否定和重写它们
如果在你提出代码中出现问题的时候，遭到抵制，你需要用他们能够听懂的话表达
5 跟踪变化
跟踪技术变化，你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯
6 对团队投资
“一个学习型的团队才是较好的团队”，比如设定每周轮流主持讲座，讲完后，进行开放式讨论，这样每个人都可以发表自己的意见
7 懂得丢弃
在合适的场景决定使用新技术还是旧技术
8 打破砂锅问到底
通过问"为什么"，直到明白问题的根源
9 把握开发节奏
在每天结束的时候，测试、提交代码
以固定、规律的长度运行迭代，调整迭代长度，找到团队最舒服可行的时间值
10 让客户做决定
让你的客户做决定，开发者，经理或者业务分析师不应该做业务方面的决定，用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定
11 让设计指导而不是操纵开发
“不要在前期做大量的设计”，在没有经过真正的代码验证之前，不要陷入太多的设计任务。当对设计一无所知的时候，投入编码业是一件很危险的事 。好的设计应该是正确的，而不是精确的，也就是说它描述的一切必须是正确的，不应该涉及不确定或者可能发生变化的细节，它是目标，不是具体的地方
12 合理的使用技术
根据需要选择技术，首先决定什么是你需要的，要解决什么问题，接着为这些具体的问题评估使用技术，对任何要使用的技术，多问一些挑剔的问题，并如实回答
13 保持可以发布
保证系统随时可以编译，运行，测试并立即部署，可以通过分支来专门处理某个需要修复的问题，再把代码合并到主分支，但这里需要注意代码冲突问题，简单流程是 本地测试 > 检查最新代码 > 提交代码，最好是通过持续集成系统，自动集成部署并报告集成结果
14 提早集成，频繁集成
代码集成是主要的风险来源，要规避这个风险，只有提早集成，持续而有规律的集成，比如每天集成2-5次，如果到最后才进行集成，可能将花费更多的时间来解决集成中的问题，而持续集成发生的问题都是一些小问题更容易解决
15 提早实现自动化部署
自动化部署使得软件能在不同的目标机器上同时部署应用，并且更容易发现问题，比如缺少依赖关系
16 使用演示获得频繁反馈
在开发软件的时候，要跟客户保持沟通，每个一周或者两周，将完成的最新功能演示给客户看，并获取他们的反馈
17 使用短迭代，增量发布
发布带有最小可用功能块的产品，每个增量开发，使用1-4周左右迭代周期
18 固定的价格就意味着背叛承诺
软件项目是变化无常的，不可重复，如果要提前给出一个固定价格，就几乎肯定不能遵守开发上的承诺，如果必须要提供一个价格，可以先构建最初的，小而有用的部分，并给客户演示，客户可以选择继续开发，还是停止或者取消合同
19 守护天使
使用自动化的单元测试，好的单元测试能够为你的代码问题提供及时的警报，如果没有好的单元测试，就不要轻易设计和修改代码，直到修改好单元测试
20 先用它再实现它
测试驱动开发（TDD），先写测试，再写代码。先写测试能让你从用户的角度去思考，而不是一个单纯的实现者，另外先写测试有助于消除过度复杂的设计
测试驱动开发 https://juejin.im/post/5c3e73876fb9a049d37f5db1
测试驱动开发实例 https://blog.csdn.net/mostbravebird/article/details/12833409
21 不同的环境，就有不同的问题
使用持续集成工具，在不同的平台和环境中运行单元测试
22 自动验收测试
使用客户的业务逻辑来验证系统
23 度量真实的进度
评估剩下的工作量，不要用不恰当的评估来欺骗自己或者团队，要评估那些需要完成的待办事项，通过待办事项，就可以随时知道下一步最重要的任务是什么。有时候对于一个任务，评估是2天，做到一半发现还需要4天时间来完成任务。
24 倾听用户的声音
每一个用户的抱怨都是有原因的，不要生气，不需要轻视，要找出真相，修复真正的问题
25 代码要清晰的表达意图
应该让自己或者团队的其他任何人，可以读懂自己一年前写的代码，而不是只读一遍就知道的它的运行机制。
在编写代码时，应该使用语言特性来提升表现力，使用方法名来传达意向，对方法参数的命名要帮助读者理解背后的想法，异常传达的信息是哪些可能会出问题，以及如何进行防御式编程，要正确的使用和命名异常，好的编码规范可以让代码变得易于理解，同时减少不必要的注释和文档。
26 用代码沟通
写简明扼要的注释；
在代码可以传递意图的地方不要使用注释；
解释代码做了什么的注释用处不那么大，反而注释要说明为什么会这样写代码；
当重写方法时，保留描述原有方法意图和约束的注释
27 动态评估取舍
如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一定要得到回报（大部分情况下，是不会有回报的）；
真正的高性能系统，从一开始设计时就在向这个方法努力；
过早的优化是万恶之源；
过去用过的解决方案对当前的问题可能适用，也可能不适用，不要事先预设结论，先看看现在的状况；
28 增量式编程
在很短的编辑、构建、测试循环中编写代码，要比话费长时间仅仅做编写代码的工作好得多，可以创建更加清晰、简单、易于维护的代码。
如果构建和测试循环花费时间过长，你就不会希望经常运行他们了，要保证测试可以快速运行；
在编译和测试运行中，停下来想一想，并暂时远离代码细节，这是保证不会偏离正确方向的好办法；
要休息的话，就要好好休息，休息时远离键盘；
要像重构你的代码那样，重构你的测试，要经常重构测试；
29 保持简单
开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
代码几乎总是可以得到进一步精炼，但到了某个点后，再做改进就不会带来任何实质性的好处了。
强行让代码变得优雅和过早优化类似，同样会产生恶劣的影响。
简单的解决方案必须要满足功能需求，为了简单而在功能上妥协，这就是过分简单化了。
30 编写内聚的代码
让类的功能尽量集中，让组件尽量小，避免创建很大的类或组件，也不要创建无所不包的大杂烩类
31 告知，不要询问
不要抢别的对象或是组件的工作，告诉它做什么，然后盯着你自己的职责就好
调用者不应该给被调用对象做决策，这个工作应该由被调用对象自己完成
32 根据契约进行替换
通过替换代码来扩展系统，通过替换遵循接口契约的类，来添加并改进功能特性，要多使用委托而不是继承
相对继承来说，委托更加灵活，适应力也更强
33 记录问题解决日志
维护一个问题及其解决方案的日志，保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以快速找到并使用
34 警告就是错误
将警告视为错误，签入带有警告的代码，就是签入有错误或者没有通过测试的代码一样，都是极差的做法，签入构建工具中的代码不应该产生任何警告信息
35 对问题各个击破
将问题与应用其他部分隔离开，可以将关注点直接放在与问题相关的议题上，可以通过多种改变，来发现问题发生的核心，只有最小数量的相关代码与问题有联系
36 报告所有的异常
处理或者向上传播所有的异常；当捕获或者抛出异常时，都要记录日志信息；
37 提供有用的错误信息
展示有用的错误信息，提供更易于查找错误细节的方式，发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中
38 定期安排会面时间
定期与开发人员进行良好的沟通，立会是比较好的选择，立会一般在大家到公司后的半个小时到一个小时之内举行。立会能让团队达成共识，保证会议短小精悍不跑题。
39 架构师必须写代码
优秀的设计从积极的程序员那里开始演化，积极的编程可以带来深入的理解，不要使用不愿意编程的架构师，不知道系统的真实情况，就无法展开设计。
40 实行代码集体所有制
任何一位团队成员，只要理解某段代码的来龙去脉，就应该可以对其进行处理，如果某一段代码只有一位开发人员能够处理，项目的风险无形中就增加了。
在团队中实行任务轮换制，让每个成员都可以接触到不同部分的代码，可以提升团队整体的知识和专业技能，也可以提升代码的整体质量
代码集体制并不意味着可以随心所欲的随意改变代码
41 成为指导者
分享自己的知识，付出的同时便有收获，还可以激励别人获得更好的成果，而且提升整个团队的实力
42 允许大家自己想办法
给别人自己解决问题的机会，指给他们正确的方向，而不是直接提供解决方案，每个人都能从中学到不少东西
用问题来回答问题，可以引导提问的人走上正确的道路
如果有人真的陷入坑里，就不要折磨他们了，告诉他们答案，再解释为什么是这样
43 准备好后再共享代码
绝不要提交尚未完成的代码，不要签入编译未通过或者没有通过单元测试的代码，代码一旦提交，别人就可以访问到
44 做代码复查
复查所有的代码，有助于提升代码质量和降低错误率，
在代码复查中要看什么呢？如下是基本的检查列表：
代码能否被读懂和理解
是否有任何明显的错误
代码是否会对应用的其他部分产生不良的影响
是否存在重复的代码
是否存在可以改进或重构的部分
45 及时通报进展与问题
及时通报进展与问题，发布进展状况，新的想法和目前正在关注的主题，不要等着别人来问项目状态如何。
