31 告知，不要询问
“不要相信其他的对象。从别人那里去拿你需要的信息，然后自己处理，自己决策。不要放弃控制别人的机会”。
告知=命令，询问=查询
命令和查询相分离模式，就是要将功能和方法分为命令和查询两类，并在源码中记录下来，以做到将命令代码都放在一起，并将所有查询代码都放在一起。
绝对不能允许一个看起来无辜的“查询”去修改对象的状态。
32 根据契约进行替换
“深层次的集成是很棒的。如果你需要其他类的函数，直接继承它们就好了！”
保持系统灵活性的关键方式，是当新代码取代原有代码之后，其他已有的代码不会意识到任何差别。
如果你不确定一个接口做出了什么样的承诺，或者有什么样的需求，那就很难提供一个对其有意义的实现了。
33 记录问题解决日志
“在开发过程中是不是经常遇到似曾相识的问题？这没关系，以前解决过的问题，现在还是可以解决掉的。”
面对问题是开发人员的一种生活方式。当问题发生时，我们会希望记起第一次是如何解决的，而且希望下次能够更快地把它搞定。但是，有时我们又记不清上次是如何修复的了。
不要在同一处跌倒两次。
要想得到更好的效果，不妨维护一个保存曾遇到的问题以及对应解决方案的日志，我们称之为每日日志（daylog）。
可以选择符合需求的任何格式，下面的内容可能用得上：
- 问题发生日期
- 问题简述
- 解决方案详细描述
- 引用文章或网址，以提供更多细节或相关信息
任何代码片段、设置或对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入地理解相关细节。
务必要将上述信息变为计算机可搜索的格式。
34 警告就是错误
“编译器的警告信息只不过是给过分小心和过于书呆子气的人看的。它们只是警告而已。”
有些警告是过于挑剔的编译器的良性副产品，但有些则不是。例如，一个关于未被使用的变量的警告，可能不会产生什么恶劣影响，但却有可能是暗示某些变量被错误使用了。
签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。
35 对问题各个击破
“要调试一个明显的错误，只要去查看整个系统的代码，而且是要全部过一遍。毕竟你不知道问题可能发生在什么地方，这样做是找到它的唯一方式。”
单元测试带来的积极效应是它会强迫形成代码的分层。要保证代码可测试，就必须把它从周边代码中解脱出来。
认识复杂问题的第一步，是将它们分离出来。
很多应用的代码在编写时没有注意到这一点，使得分离变得特别困难。应用的各个构件部分之间会彼此纠结：想把这个部分单独拿出来，其他的会紧随而至。在这些状况下，最好花一些时间把关注的代码提取出来，而且创建一个可让其工作的测试环境。
36 报告所有的异常
“不要让程序的调试者看到那些奇怪的异常。处理它们是你的责任。把你调用的一切都包起来，然后发送自己定义的异常。”
作者曾经使用一个非常流行的开源程序库时倍受打击。作者调用的一个方法本来应该创建一个对象，可得到的却是null，调查很久都没有头绪。幸好这个库是开源的，所以他下载了源代码，并找到了出问题的那个调用方法。那个方法认为她的系统中缺少了某些必要的组件。这个底层方法抛出了带有相关信息的异常。但是，上层方法却偷偷地用没有异常处理代码的空catch代码块，把异常给忽略掉了，然后抛出了一个null。后来，作者安装了相应的组件，问题解决了。
37 提供有用的错误信息
“不要吓着用户，吓程序员也不行，要提供给他们干净整洁的错误信息。”
在设计一个登陆页面时，当用户输错密码时，我们提示哪个信息更好呢：“Unable to perform operation”、“Couldn’t login…”、还是“Error validating password”
错误信息有助于问题的解决。当问题发生时，可以详细研究问题的细节描述和发生上下文。
38 定期安排会面时间
“会议安排得越多越好。实际上，我们要安排更多的会议。”
立会 （站着开的会议，Scrum最早引入并被极限编程所强调的一个实践）是将团队召集在一起，并让每个人了解当下进展状况的好办法。顾名思义，参与者们不允许在立会中就坐，这可以保证会议快速进行。一个人坐下来之后，会由于感到舒适而让会议持续更长的时间。
要保证立会议题不发散，每个人只能回答下述三个问题：
- 昨天的收获是什么
- 今天计划要做哪些工作
- 面临着哪些障碍
大家都期盼着立会，希望彼此了解各自的进度和手上的工作，而且不怕把各自遇到的问题拿出来公开讨论。
39 架构师必须写代码
“我们的专家级架构师会提供设计好的架构，供你编写代码。他经验丰富，拿的薪水很高，所以不要用一些愚蠢的问题或者实现上的难点来浪费他的时间。”
这些架构师通常在项目开始时介入，绘制各种各样的设计图，然后在重要的代码实现开始之前离开。有太多这种“Powerpoint架构师”。由于得不到反馈，而且设计会随着时间而演进，所以他们的架构设计工作也不会有很好的收效。
新系统的设计者必须要亲自投入到实现中去。
40 实行代码集体所有制
“不用担心那些烦人的bug，Joe下周假期结束回来后会把它解决掉的。在此之前先想个权宜之计应付一下吧。”
不应像国家宣称对领土的所有权一样，声明个人对代码的所有权。任何一位团队成员，重要理解某段代码的来龙去脉，就应该可以对其进行处理。如果某一段代码只有一位开发人员能够处理，项目的风险无形中也就增加了。
相比找出谁的主意最好、谁的代码实现最烂而言，解决问题，并让应用满足用户的期望更为重要。
在大型项目中，如果每个人都可以随意改变任何代码，一定会把项目弄得一团糟。代码集体所有制并不意味着可以随心所欲、到处破坏。
41 成为指导者
“你花费了大量的时间和精力，才达到目前的水平。对别人要有所保留，这样让你看起来更有水平。让队友对你超群的技能感到恐惧吧。”
教学相长。通过详细解释自己知道的东西，可以使自己的理解更深入。当别人提出问题时，也可以发现不同的角度。
成为指导者，意味着要分享，而不是固守自己的经验、知识和体会。
42 允许大家自己想办法
“你这么聪明，直接把干净利落的解决方案告诉团队其他人就好了。不要浪费时间告诉他们为什么这么做。”
作为指导者，应该鼓励、引领大家思考如何解决问题。
用问题来回答问题，可以引导提问的人走上正确的道路 。
43 准备好后再共享代码
“别管是不是达到代码签入的要求，要尽可能频繁的提交代码，特别是要下班的时候。”
向代码库中提交仍在开发的代码，会带来很多风险。当其他开发者获取最新版本的代码时，也会受到这些代码的影响。
绝不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码，对项目来说，应被视作玩忽职守的犯罪行为。
44 做代码复查
“用户是最好的测试人员。别担心–如果哪里出错了，他们会告诉你们的。”
代码刚刚完成时，是寻找问题的最佳时机。如果放任不管，它也不会变得更好。
管理层担心进行代码复查所耗费的时间。他们不希望团队停止编码，而去参加长时间的代码复查会议。开发人员对代码复查也感到担心，允许别人看他们的代码，会让他们有受威胁的感觉。这影响了他们的自尊心。
要寻找深藏不露的代码bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。
在极限编程中，不存在一个人独立进行编码的情况。编程总是成对进行的 ：一个人在键盘旁边（担任司机的角色），另一个人坐在后面担任导航员。他们会不时变换角色。有第二双眼睛在旁边盯着，就像是在进行持续的代码复查活动，也就不必安排单独的特定复查时间了。
你也可以考虑使用诸如Similarity Analyzer或Jester这样的代码分析工具。
不进行思考、类似于橡皮图章一样的代码复查没有任何价值。
45 及时通报进展和问题
“管理层、项目团队以及业务所有方，都仰仗你来完成任务。如果他们想知道进展状况，会主动找你要的。还是埋头继续做事吧。”
如果等到截止时间才发布坏消息，那么经理或技术主管就会担心你再次让他们失望，并开始每天多次检查你的工作进度。
及时通报进展和问题，有情况发生时，就不会让别人感到突然，而且他们也很愿意了解目前的进展和状况。他们会知道何时应提供帮助，而且你也获得了他们的信任 。
结束语
《高效程序员的45个习惯》，
每一个习惯都值得程序员同学去仔细体会和吸收。