《高效程序员的45个习惯》-末篇
请您在阅读本文之前，先了解《高效程序员的45个习惯》-之三。
每一期都会涉及15个话题，用3期来列出这45个习惯，每次不贪多，贪精，大家如果有空，一定要细细品味这15个习惯。
注意：每一个好的习惯，开头都会相应有一个唱反调的句子哦。
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个习惯》，
每一个习惯都值得程序员同学去仔细体会和吸收。
《高效程序员的45个习惯》-末篇相关推荐
- 【连载】高效程序员的45 个习惯（不断更新中。。。）
高效程序员的45 个习惯 本书收集了成功人士在开发过程中的 45 个个人习惯.思想观念和方法,有助于开发人员在开发进程.编码工作.开发者态度.项目和团队管理,以及持续学习等 5 个领域改善其开发工作. ...
- 《高效程序员的45个习惯》之体会
不知大家是否有这样的感觉,总有那么多国外的好东西因为名字翻译太烂被大家忽视或者被低端化,比如那部印度的经典影片<3 Idiots>,被本土化后成了<三傻大闹宝莱坞>,还有经典书 ...
- 《高效程序员的45个习惯》读后感
为什么80%的码农都做不了架构师?>>> 感受 敏捷开发人员必读. 关于书名.从内容看来,原书名<Practices of an Agile Developer>比 ...
- 《高效程序员的45个习惯》-之三
请您在阅读本文之前,先了解<高效程序员的45个习惯>-之二. 每一期都会涉及15个话题,用3期来列出这45个习惯,每次不贪多,贪精,大家如果有空,一定要细细品味这15个习惯. 注意:每一个 ...
- 《高效程序员的45个习惯》-之二
请您在阅读本文之前,先了解<高效程序员的45个习惯>-之一. 每一期都会涉及15个话题,用3期来列出这45个习惯,每次不贪多,贪精,大家如果有空,一定要细细品味这15个习惯. 注意:每一个 ...
- 《高效程序员的45个习惯》-之一
敏捷开发是当下最流行的开发方法,它采用的是一种以人为核心.迭代.循序渐进的开发思想,值得你关注和学习. 最近我就阅读了一本有关敏捷开发的书籍,<高效程序员的45个习惯>. 它以" ...
- Hunter的读《高效程序员的45个习惯》
本文完全节选自<高效程序员的45个习惯> 第一章敏捷--高效软件开发之道 敏捷开发宣言: 个体和交互胜过过程和工具 可工作的软件胜过面面俱到的文档 客户协作胜过合同谈判 响应变化胜过遵循计 ...
- 读书笔记 -《高效程序员的45个习惯-敏捷开发修炼之道》
<高效程序员的45个习惯-敏捷开发修炼之道> 一本2010年出版的书,当时敏捷还只是在国外开始流行,像我这种菜鸟级根本听都没听过.这次通读了这本书,受益良多,回顾自己的职业生涯,多是漫无目 ...
- 读书笔记之《高效程序员的45个习惯----敏捷开发之道》 摘录
读书笔记之<高效程序员的45个习惯----敏捷开发之道>摘录 此次原创的意思是指这个文章中的内容是由笔者从<高效程序员的45个习惯----敏捷开发之道>书中摘录,而不是别人摘录 ...
最新文章
- GitHub也会断供：美国制裁地区帐号都受限，毫无预警，个人页面直接404
- JVM 核心技术 调优分析与面试经验
- mysql和php数据交互_php mysql交互
- window下搭建Python3.7+selenium3.1.1+pycharm环境
- TCP/IP学习笔记-Qt中的ReuseAddressHint以及SO_REUSEADDR，以为组播常用场景分析
- 02 unix文件系统和命令
- Go36-32-context.Context
- 解决CentOS6.4 Docker “Couldn‘t connect to Docker daemon ...“ 问题
- 比较三个数的大小，让其按大小顺序排列
- java从入门到进阶
- dcp9020cdn硒鼓!错误_打印机硒鼓错误是什么意思？故障解决【详解】
- Fingerprint 解锁流程
- java课设心得体会2000字_java课程设计报告心得体会
- gis地图图层（前台）
- C++学习45 流成员函数put输出单个字符 cin输入流详解 get()函数读入一个字符
- windows server 2016打开服务器管理器和启用或关闭windows功能报.net fr
- 小米路由器3无线网连接到服务器,192.168.31.1小米路由器手机登录设置方法
- 查询 MySQL 字段注释的 5 种方法
- Barbalat引理与类李雅普诺夫引理，及它们在自适应控制系统设计的应用
- 致敬中国杰出量化女性