高效程序员的读书笔记

高效程序员的45个习惯：敏捷开发修炼之道。

 

第一章高效开发之道

 

不管走了多远，错了都要转回来。----------------土耳其谚语

 

敏捷开发宣言：

个体和交付胜过过程和工具

可工作的软件胜过面面俱到的文档

客户协作胜过合同谈判

响应变化胜过遵循计划
虽然右边的也很有价值，但是我认为左边更有价值。

 

要防微杜渐，把问题解决在萌芽状态

要探索未知领域，在大量成本投入之前先确定其可行性，

要知错能改，在事实面前主动承认自己的所有错误

要自我反省，经常编码实战，加强团队协作精神。

 

第二章态度决定一切

 

选定了要走的路，就是选定了他通往的目的地。

 

1.       做事------------------------在敏捷团队中，大家的重点是做事，你应该吧重点放到解决问题上，而不是在指责犯错者上面纠缠。
过程符合标准并不意味结果正确，敏捷团队重结果胜过重过程

2.       欲速则不达--------------------拙劣的代码工人会为了解决问题而不假思索的修改代码，然后快速转向下一个问题，优秀的程序员会挖掘更深一层，尽力去理解为什么这样修改代码，更重要的是他们会想明白这样修改会产生什么样的影响

必须要理解所在团队采用的开发方法，必须理解如何恰如其分的使用这种方法，为何它们是这样的，以及如何成为这样的.

不要孤立的编码--------阅读代码的频率越高越好，实行代码复审是发现bug的最有效的方法之一。
使用单元测试-----是防止代码难懂的重要技术之一

不要坠入快速的简单修复之中，要投入时间和精力保持代码的整洁，敞亮。

必须要理解一块代码是如何工作的
必须使很难维护的代码变得简单
不要急于修复一段没能真正理解的代码，要解决真正的问题，不要治标不治本
大型系统，除了深入了解你正在开发的代码之外，还需要从更高的层面来了解大部分代码的功能。

3.       对事儿不对人--------------- 要专业而不是要自我。让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。

负面的评论和态度扼杀了创新
团队的每个人都需要自由的表达观点

你不需要很出色才能起步，但是你必须起步才能变得很出色

集体决策很重要，但是一些最好的创新源于很有见地的个人的独立思考，尊重别人的意见，把我方向，深思熟虑，吸取各方的意见。

能容纳自己并不接受的想法，表明你的头脑有足够的学识。

设定最终期限：没有最好的答案，只有更合适的方案，设定期限能够帮助你在为难的时候果断作出决策，让工作继续进行。
逆向思维：团队中的每一个成员都应该意识到权衡的必要性。先是积极的看到它的正面，然后再努力从反面认识它，从而找出有点最多缺点最少的那个方案
设立仲裁人：专注于调停，而不是发表自己的观点
支持已经做出的决定：方案一旦确定，每个团队成员都必须通力合作，努力实现它，目标是让项目成功满足用户需求。

设计充满了妥协，成功属于意识到这一点的团队。

尽力贡献自己好想法，如果你的想法没有被采纳也无需生气
脱离实际的反方观点会使争论变味
想要支持或者反对一个观点，最好先做一个原型或者调查
只有更好，没有最好
不带个人情绪并不是盲目的接受所有的观点。

4.           排除万难，奋勇前进-------------------必须要有勇气向前冲锋，做你认为对的事情。要诚实，要有勇气去说出实情，有时，这样做很困难，所以我们要有足够的勇气。

反思
认真考虑
重构代码，增强可读性
表达语言的使用

第三章学无止境

即使你已经在正确的轨道上，但是如果只是停滞不前，也仍然会被淘汰出局。

软件开发行业是个不停发展和永远变化的领域。

5.       跟踪变化---------------唯有变化是永恒的。你不需要精通所有的技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

迭代和增量式的学习
了解最新行情
参加本地的用户组活动
参加研讨会议
如饥似渴的阅读

许多新想法在羽翼还未丰满，就成为有用的技术。
你不可能精通每一项技术，没有必要做这样的尝试。
你要明白为什么需要这项新技术
避免在一时冲动的情况下，只是因为想学习而将应用切换到新的技术，框架或者开发语言

6.       对团队投资-------------一个学习型的团队才是较好的团队。需要和其他团队成员分享所学的知识，把这些知识引入团队中。

找出你或者团队中的高手擅长的领域，帮助其他团队成员在这些方面迎头赶上

“午餐会议”是团队分享知识非常好的方式。可以促进整个团队对这个行业的了解，自己也可以从其他人身上学到很多东西，优秀的管理着会重用那些能提高其他团队成员价值的人。

每周，要求团队中的一个人主持讲座。概念，演示工具，或者是团队感兴趣的任何一件事，从每周主持讲座的人开始，先让他讲15分钟，然后开放式讨论，每个人都可以发表自己的意见，讨论这个主题对于项目的意义


读书小组可以一起逐章阅读一本好书
并不是所有的讲座都能引人入胜，有些甚至显得不合时宜，但是可以未雨绸缪。
尽量让讲座走入团队，
坚持有计划有规律的举行讲座，持续，小步前进才是敏捷
可以用美食引诱团队成员参加午餐会议
不要局限于纯技术的图书和主题，也可以对团队，项目有帮助的非技术主题、
午餐会议不是设计会议

7.       懂得丢弃---------------------敏捷的根本之一是拥抱变化。

要果断丢弃就习惯，一味的遵循过时的习惯会危害你的职业生涯
不是完全忘记就的习惯，而是只在使用适当的技术时才使用它。
要总结熟悉的语言特性，并且比较这些特性在新语言或新版本中有什么不同

8.       打破砂锅问到底---------------不停的问为什么。不能满足于别人告诉你的表面现象。要不停的提问知道你明白问题的根源。

问为什么，要问到点子上。
问之前，想好你提问的理由，这会有助于你提出恰当的问题。
“这个我不知道”是一个好的起点，应该由此进一步调查，而不是嘎然结束。

9.       把握开发节奏----------------------敏捷项目会有一个节奏和循环，让开发更加轻松。

敏捷实践必须一直进行

敏捷开发者得到反馈的方式——用户，团队成员和测试代码，时间本身就是一非常重要的反馈

时间盒——设定一个短时的期限

站立会议
最大的节拍就是迭代时间

在事情变得一团糟之前，解决任务。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。


在每天结束的时候，测试代码，提交代码，没有残留的代码
不要搞得经常加班
以固定，有规律的长度进行迭代，找到团队最舒服可行的时间值，但之后必须要坚持
如果开发节奏过于密集，你会精疲力竭
有规律的开发节奏会暴露很多问题，让你有更多鼓起勇气德尔借口
小而可达的目标会每个人全速前进


第4章交付用户想要的软件


敏捷——成功的软件开发方法——取决于您识别和适应变化的能力

10.   让客户做决定——让你的客户做决定，开发者，经理或业务分析师不应该做业务方面的决定，用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。

在设计方面，做决定的时候必须有开发者参与，但在整个项目中他们不应该做所有的决定，特别是业务方面的决定

开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。

在和客户讨论问题是，应该准备好几种可选的方案，不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，以及潜在的成本利益。

业务应用需要开发者应该和业务负责人相互配合起来开发。

记录客户做出的决定，并注明原因。
不要用低级别和没有价值的问题打扰繁忙的业务人员。
不要随意假设低级别的问题不会影响他们的业务。

11.   让设计指导而不是操纵开发——好的设计一张地图，他也会进化。

敏捷方法建议早在开发初期就开始编码
好的设计仍然十分重要，如关键工作图是不可少的。
设计满足实现即可，不必过于详细

严格的“需求——设计——代码——测试”开发流程是源于理想化的瀑布式开发方法。

设计分为两种一个战略设计一个是战术设计
不要一开始就陷入战术设计。

“不要在前期做大量设计”并不是说不要设计
即使初始的设计到后面不管用，你仍然需要设计：设计行为是无价的。
白板，草图，便利贴都是非常好的设计工具。

12.   合理的使用技术——根据需要选择技术，首先决定什么是你需要的，接着为这些具体问题评估使用技术，对任何要使用的技术，多问一些挑剔的问题，并能真实地做出回答。

这个技术框架真的能够解决问题吗？
你会被它拴住吗？
维护的成本是多少？

如果没有足够的经验，不要急于决定用什么技术
每一门技术都会有优缺点
不要开发哪些你容易下载到的东西

13.   保持可以发布——保持你的项目时刻可以发布，保证你的系统随时可以编译，运行，测试并立即部署。

已提交的代码应该随时可以行动。

在团队里工作，修改一些东西必须保持谨慎，你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。

在本地运行测试。先保证你完成的代码可以编译，并且通过所有的单元测试。
检出最新的代码。从版本控制系统更新代码到最新，在编译和运行测试。
提交代码。

最好的方法是：有一个持续集成系统，可以自动集成并报告集成结果。

千万不能让系统既不可以发布，又不可以撤销

14.   提早集成，频繁集成

敏捷的一个主要特点就是持续开发。特别是几个人一起开发同一个功能时，更应该频繁集成代码。

在产品开发过程中，集成是一个主要的风险区域，尽可能早的集成，也更容易发现风险，这样及相关的代价就会相当低。

集成和独立不是互相矛盾的
可以一边集成，一边独立开发。
使用mock对象类隔离对象之间的依赖关系，这样在集成之前就可以先做测试。使用mock对象编写独立的单元测试，而不需要立刻就集成和测试其他系统。

独立开发和早期集成之间是有张力的，一般需要每天集成几次，而不是几天集成一次。
早期集成可以看到子系统之间的影响和交互。

提早集成，频繁集成。代码集成式主要风险来源，要想规避这个风险，只有提早集成，持续有规律的进行集成。

集成时产生的问题，都会是小问题并且容易解决。

成功的集成就意味着所有的单元测试不停的通过。
每天和团队的其他成员一起集成好几次代码。
如果集成的不够频繁，就会发现整天在解决代码集成带来的问题，而不是在专心写代码。如果集成问题很大，一定是集成不够频繁。
对那些原型和实验代码，想要独立开发，但是不能独立开发太长的时间。

15.   提早实现自动化部署。——用一种可重复和可靠的方式，在目标机器上部署应用。

质量保证人员应该测试和部署过程。

一开始就进行全面部署，而不是等到项目后期。有些项目在正式开发之前就设置好了所有的安装环境。

一开始就实现自动化部署应用。使用部署系统安装应用，在不同的机器上用同的配置文件测试依赖问题。

一般产品安装的时候都需要有相应的软硬件环境，检查这些依赖关系也是安装的一部分。
在没有询问并征得用户的同意之前，安装程序绝对不能删除用户数据。
部署一个紧急修复的bug应该很简单，特别是在生产服务器的环境中。
用户应该可以安全并且完整的卸载安装程序，特别是在质量保证人员的机器环境中。

16.   使用演示获得频繁反馈。

现实世界中需求是流动的油墨，你无法冻结需求。

你计算的每个精确位置就是一个给客户演示目前已经完成功能的机会，也正是得到用户反馈的时候。在你动身进入下一个旅程的时候，这些反馈可以用来纠正您的方向。


给客户演示所完成功能的时间与得到客户需求的时间间隔越长，那么你就会离最初需求越来越远。

定期性的，每隔一段时间，就与客户会晤，并且演示你已经完成的功能特性。

如果能与客户频繁协商，根据他们的反馈开发，每个人都能从中获益。
要频繁的获得反馈。

在项目的开发过程中，从术语表中为程序结构——类，方法，模型，变量等选择合适的名字，并且要检查和确保这些定义一直符合用户的期望。

清晰可见的开发。要保持应用可见（而且客户心中也要了解），每隔一周，或者两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。


跟踪问题——修正，建议，变更要求，功能增强，bug修复等。

17.   使用短迭代，增量发布。——统一过程和敏捷方法都使用迭代和增量开发。使用增量开发一次开发应用功能的几个小组，每一轮的开发都是基于前一次的功能，增加为产品增值的新功能。

迭代开发室在小且重复的周期里，完成各种开发任务：分析，设计，实现，测试，获得反馈。所以也叫迭代。

迭代的结束就标记一个历程碑。在迭代结束时，新的功能全部完成，就可以发布，让用户真正的使用，同时提供技术支持，培训和维护方面的资源。

对付大项目，最理想的方法就是小步前进，是敏捷方法的核心，大步跳跃大大地增加了风险，小步前进才可以帮助你很好的把我平衡。

使用短迭代和增量开发，可以让开发者更加专注自己的工作。

增量开发——发布带有最小却可用功能模块的产品，每个增量开发中，使用1-4周左右迭代周期。

短迭代让人感觉非常专注且有效率，看到一个实际并且确切的目标。

关于迭代时间长短是一个有争议的问题。可以每4周的迭代中间安排一个周的维护任务。没有规定说迭代必须要紧跟下一个迭代。

如果每一个迭代的时间都不够用，要么任务太大，要么迭代时间太短。

如果发布的功能背离了用户的需求，那么多半是因为迭代的周期太长。

增量发布必须是可用的，并且能为用户提供价值。

18.   固定的价格就意味着背叛承诺。

固定价格的合同回事敏捷团队的一大难题。

主动提议先构建系统最初的，小的和有用的部分。
第一个迭代结束时客户有两个选择：可以选择一系列新的功能，继续进入一个迭代，或者可以取消合同，仅需支付第一个迭代的几周费用。
如果他们选择继续前进，那么就能很好的预测下一个迭代工作，在下一个迭代结束的时候用户仍然有同样的选择机会，要么现在停止，要么继续下一个迭代。


这样对用户来说，他们总是可以控制项目，可以随时停止项目，不需要缴纳任何的违约金。他们也可以控制先完成哪些功能，并精确的知道需要花费多少资金，总而言之客户承担风险更低。

开发者只需要做的就是进行迭代和增量开发。


基于真实工作的评估。让团队和客户一起，真正的参与当前项目中，做具体实际的评估，有客户控制他们想要的功能和预算。


如果对答案不满意，看看是否可以改变问题。
如果是在一个基于计划的非敏捷环境中工作，那么要么考虑一个基于计划且非敏捷的开发方法，要么换一个不同的环境。
如果在完成第一个迭代开发之前，拒绝做任何评估，也许会失去这个项目。

敏捷并不意味着“开始编码，我们最终会知道何时可以完成”。据当前的知识和猜想，做一个大致的评估，解释如何才能达到这个目标，并给出误差范围。

如果别无选择，不得不提供一个固定价格，那么就要学会真正的评估技巧。

可以考虑在合同中确定每个迭代的固定价格，但是迭代的数量是可以商量的。可以根据当前的工作状况进行调整。



第 5 章     敏捷反馈

一步行动胜过千万专家的意见。

在敏捷项目中，小步前进，不停的手机反馈，时刻矫正自己。

19.   守护天使——代码在快速的变化，敏捷就是管理变化的，代码可能是变化最频繁的东西。

编写能够产生反馈的代码。

做自动化单元测试。

测试是一个极好，编写能产生反馈的代码的技术。

敏捷式的单元测试正式采取了相同相似的过程，并且还让其可以更上一层楼。不用扔掉桩程序，把它保存下来，还要让其可以自动化的持续运行。编写代码来检查具体值，而不是手工检查那些感兴趣的变量。

确保测试是可以重复的。
测试边界条件
不要放过任何一个失败的测试。只要有了单元测试，就要让他自动运行，也就是每次编译或者构建代码的时候，就运行一次测试，把单元测试的结果看做是和编译器一样——如果测试没有通过（或者没有测试），那就像编译没有通过一样糟糕。

在后台架设一个构建机器，不断获得最新版本的源代码，然后编译代码，并运行单元测试。

结合本地单元测试，运行每个编译，构建机器不断编译和运行单元测试

一旦单元测试到位，采用这样的回归测试，就可以随意重构代码，可以根据需要进行试验，重新设计或者重写代码：单元测试确保你不会意外的破坏任何功能。


单元测试是最受欢迎的一种敏捷实践。

单元测试能及时提供反馈。代码会重复得到锻炼，若修改或者重写了代码，测试用例就会检查时候破坏了已有的功能，可以快速得到反馈，并很容易修复他们。

单元测试使代码更加健壮，全面思考代码的行为，包括正面，反面，以及异常情况。

单元测试是有用的设计工具。有助于实现简单的，注重实效的设计。

单元测试让你增强自信的后台，测试代码，了解代码在各种不同条件下的行为。这会让你在面对新的任务，时间紧迫的巨大压力下找到自信。

单元测试是解决问题时的探测器。

单元测试是可信的文档。

单元测试是学习工具。

单元测试是优质股，值得投资。

单元测试只有在达到一定测试覆盖率的时候，才能真正的发挥作用。

不是测试越多质量就会越好，测试必须要有效。

20.   先用它再实现它。——将TDD作为设计工具，会为你带来更简单更有效的设计

使用TDD（测试驱动开发）技术，这样总是在有一个失败的单元测试后才开始编码，测试总是先编写，测试失败要么因为测试方法不存在，要么因为方法逻辑还不足以让测试通过。

先写测试，就会站在代码用户的角度思考，而不仅仅是一个单纯的实现者。因为使用它们，所以能设计一个更有效，更一致的接口。

先写测试有助于消除过度复杂的设计，可以专注于真正需要完成的工作。

在测试同步之前，先报证测试是失败的，目的是希望暴露出测试中潜在的bug

消除那些还没有编写的类，这样很容易简化代码。
TDD有机会让你在编写代码之前可以深思熟虑将如何用它，迫使你去思考它的的可用性和便利性。并让你的设计更加注重实效。

设计不是在开始编码的时候就结束了，需要在他的生命周期中持续的添加测试太难敬爱代码并重新设计代码。

不要把测试有限和提交代码之前的测试等同起来。测试先行可以帮助你改进设计。但是还需要在提交代码前做测试。

任何一个设计都可以被改进。

单纯的单元测试无法保证好的设计，但是会对设计有帮助，会让设计更加简单。

21.   不同环境就会有不同问题。——使用持续集成工具，在每一种支持的平台和环境中运行单元测试，要积极的寻找问题，而不是等问题来找你。

硬件比开发人员的时间便宜。
只因为不同的栈层顺序，不同单词大小写，就能发现很多平台上的bug

22.   自动验收测试。

关键业务逻辑必须要独立进行严格的测试，并且最后需要通过用户的审批。

使用FIT集成测试框架，可以更容易的使用HTML表格定义测试用例。

为核心业务逻辑创建测试。让客户单独验证这些测试，要让他们像一般的测试一样可以自动运行。

不是所有的用户都能提供给你正确的数据。
你也许会在旧的系统中发现以前根本不知道的bug，或者以前根本不存在的真正问题。
使用客户的业务逻辑，但是不要陷入无边无际的文档写作当中。

23.   质量的真实的进度——判断工作进度最好是看实际花费的时间而不是估计的时间。

一直让下一步工作是可见的，会有助于进度度量，最好的办法是使用待办事项。

待办事项是等待完成的任务列表。

清楚项目的真实进度，是一项强大的技术

关注功能而不是时间表。

24.   倾听用户的声音。——不仅需要和真实用户进行交谈，还需要耐心地倾听。

不管它是产品的bug还是文档的bug，或者是用户理解的bug，它都是团队的问题，而不是用户的问题。


每一个抱怨的背后都隐藏了一个事实，找出真相，修复真正的问题。

对于客户愚蠢的抱怨，不要生气，也不能轻视，查找背后真正的问题。



第6 章敏捷编码

在开发过程中细心照看代码，在编写代码是，每天付出一点小的努力，可以避免代码“腐烂”，并且保证应用程序不至变得难以理解和维护。

25.   代码要清晰的表达意图。——代码必须明确说出你的意图，而且必须要富有表达力

软件设计两种方式：一种是设计的尽量简单并且明显没有缺陷，另一种是设计的尽量复杂，并且没有明显的缺陷。

开发代码时，应该更注重可读性，而不是只图自己方便。
代码清晰程度的优先级应该排在执行效率之前。

在改动代码以修复或者添加新功能是，应该有条不紊的进行。应该理解代码坐了什么，它是如何做的。然后搞清楚要改变哪些部分，然后着手修改并测试。

作为一个开发者，应该时常提醒自己是否有办法让写出的代码更容易理解。

在编写代码时应该使用语言特性来提升表现力，使用方法名来传达意向，对方法参数的命名要帮助读者理解背后的想法，异常传达的信息是哪些可能会出现问题，以及如何进行防御式编程，要正确的使用和命名异常。好的编码规范可以让代码更容易理解，同时减少不必要的注释和文档。

要编写清晰而不是讨巧的代码：向代码阅读者明确表达你的意图，可读性差的代码一点都不聪明。

应该让自己或团队的其他任何人，可以读懂自己一年前写的代码，而且只读一遍就知道它的运行机制。

现在对于你来说显而易见的事情，对别人可能并非如此，对于一年后的你来说也不一定显而易见。
不要明日复明日。

有意图的编程并不是意味着创建更多的类或者类型。
使用符合当时情形的耦合。

26.   使用代码沟通

建立代码文档无外乎两种方式：利用代码本身；利用注释沟通代码意外的问题。

源代码可以被读懂，不是因为其中的注释，而应该是由于它本身优雅而清晰——变量名运用正确，空格使用得当，逻辑分离清晰，以及表达式简洁。

使用细心挑选的名称和清晰的执行路劲，代码几乎不需要注释，代码可以自解释，而不用依赖注释，是一件很好的事情。

良好的命名可以向读者传达大量正确的信息。

要避免使用神秘的变量名，

对于显而易见的代码增加注释，也会有同样的问题。


注释可用来为读者指定一条正确的代码访问路线图。为代码中每个类或者模块添加一个短小的描述，说明其目的以及是否有任何特别需要，对于类中的每个方法，应该加以注释以下信息

目的：为什么需要这个方法
需求（前置条件）：方法需要什么样的输入，对象必须处于何种状态，才能让这个方法工作。
承诺（后置条件）：方法执行成功后，对象处于什么状态，有哪些返回值？
异常：可能会发生什么样的问题？会抛出什么样的异常？

代码被阅读的次数要远超过被编写的次数，所以在编程时多付出一点努力来做好文档，会让你的团队将来获益匪浅。

用注释沟通：使用细心选择的，有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。

27.   动态评估取舍。

对任何单个因素如果独断强调，而不考虑它是否是项目成功的必要因素，必然导致灾难的发生。

要想让应用成功，降低成本与缩短上市时间，二者的影响同样重要。

客户或者是利益相关者必须进行评估，并作出相关决定，如果团队认为性能上还有提升空间，或者觉得可以让界面看起来更加吸引人，那么就去咨询一下利益相关者，让他们决定将重点放在哪里。


没有适宜所有情况的最佳解决方案，所以必须对手上的问题进行评估，并选出最合适的解决方案。

动态评估权衡——考虑性能，便利性，生产力，成本和上市时间。

最重要的东西——客户认为有价值的特性。

如果现在投入额外的资源和精力，是为了将来得到好处，要确认投入一定要得到回报。
真正的高性能系统，从一开始就在向这个方向上努力。
过早优化是万恶之源
过去用过额解决方案对当前的问题可能适用，也可能不适用。

28.   增量式编程

应该采用增量式编程方式，增量式编程可以精炼并结构化代码。
采用增量式编程和测试，会倾向于更小的方法和更内聚性的类。
采用增量式编程关键在于持续做一些细小而有用的事情，而不是做一段长时间的重构或编程。


在很短的编辑/构建/测试循环中编写代码，可以创建更加清晰，简单，易于维护的代码。

在编译和测试运行中，停下来想一想，并暂时远离代码细节。

要像重构代码那样，重构你的测试。而且要经常重构测试。

29.   保持简单

不要让自己被迫进行过分设计，也不要将代码复杂化。

开发人员更应该为自己能够创建出一个简单并且可用的设计而骄傲。

简单不是简陋。

优雅的代码第一眼看上去就知道它的用处，而且很简单，但是这样的解决方案不是那么容易就能想出来的，优雅是易于理解和辨识的，但是要想创建出来非常困难。

评价设计质量的最佳方式之一，就是听从直觉，它是经验和技能厚积薄发的产物。


开发可以工作的，最简单的解决方案。

简单，可读性高的代码是目标。

强行让代码变得优雅与过早优化类似，会产生严重后果。

太过简洁不等于简单，无法达到沟通的目的。

30.   编写内聚的代码。

内聚性用来评估一个组件（包，模块或配件）中成员的功能相关性，内聚程度高，表明各个成员共同完了一个功能特性或是一组功能特性，内聚程度低，表明各个成员提供的功能互不相干。

在创建一个类时，考虑这个类的功能是不是与组件中某个其他类的功能相似，而且功能紧密相关，这就是组件级别的内聚性。

类也要有内聚性，如果一个类的方法和属性共同完成了一个功能，这个类就是内聚的。


低内聚性的代码会造成很严重的后果。

内聚性会影响一个组件的可充用性，组件粒度是在设计是要考虑的一个重要因素，重用的粒度与发布的粒度相同。这就是说，程序库用户所需要的，是完整的程序库，而不是其中的一部分。

让类的功能尽量集中，让组件尽量小。

每个类或组件只做一件事儿，而且做得很好。

具有良好内聚性的代码，可能会根据需求的变化，成比例的进行变更。

31.   告知，不要询问。

面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。

作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做任何决策，更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任，而不是调用者的。在该对象之外为它决策，就违反了封装原则。


告知，不要询问，不要抢别的对象或者是组件的工作，告诉它做什么，然后盯着自己的职责就可以了。

32.   根据契约进行替换。

保持系统灵活性的关键方式，是当新代码取代原有代码之后，其他已有的代码不会意识到任何差别。

Liskov替换原则告诉我们：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。

相对基类的对应方法，派生类服务（方法）应该不要求更多，不承诺更少，要可以进行自由的替换。

继承是OO建模和编程中被滥用最多的概念之一，如果为了里氏替换原则，继承层次可能仍然可以提供带的可重用性，但是将会失去可扩展性。


当使用继承时，要想想派生类是否可以替换基类，如果不能，那么就要问问自己为什么要使用继承。

聚合是在类中包含一个对象，并且该对象是其他类的实例，开发人员，将责任委托给所包含的对象来完成

针对is-a关系使用继承，针对has-a或uses-a关系使用委托。

在委托模型中，Called Class必须要显示将方法调用转向包含的委托的方法。

如果新类可以替换已有的类，并且它们之间的关系可以用is-a 来描述，就要使用继承。

如果新类只是使用已有的类，并且两者之间的关系可以描述为has-a或是uses-a就使用委托。


通过提花代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性，要多食用委托而不是继承。

委托更加灵活，适应能力更强。



第 7 章敏捷调试

在调试时面临的真正问题是无法用苦丁的时间来限制的。

33.   记录问题解决日志。


不要在同一处跌倒两次。

每日日志（dayLog）

问题发生的日期，
问题简述，
解决方案详细描述，
引用文章或网址，以提供更多细节和相关信息。
任何代码片段，设置对话框的截屏，只要它们是解决方案的一部分，或者可以帮助更深入的了解相关细节。

维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同的或类似的问题是，就可以很快找到并使用了，


记录问题的时间不能超过在解决问题上花费的时间，要保持轻量级和简单，不必达到对外发布的质量。

找到以前解决方案的方法非常关键，使用足够的关键字，可以帮助你在需要的时候发现需要的条目。

如果在互联网上找不到相关信息，那么肯定是你搜索的方式有问题。

妖姬路发生问题时应用程序，应用框架或平台的特定版本。

要记录团队做出一个重要决策的原因。

34.   警告就是错误

要找到一种方式让编译器将警告作为错误提示出来，如果编译器允许调整警告的报告级别，呢么久吧级别调到最高，让任何警告都不能被忽略。

在修改设置的时候，要记得在构建服务器上使用的持续集成工具中，修改同样的设置选项。

将警告视为错误——嵌入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，签入构建工具中的代码不应该产生任何警告信息。

35.   对个问题各个击破

用原型进行分离

对问题各个击破，在解决问题是，要将问题与其周边隔离开，特别是大型应用中。
以二分查找的方式来定位问题是很有用的。
在想问题发起攻击之前先查找自己的问题解决日志。

36.   报告所有的异常信息

像Java中的检查异常一样，强迫捕捉异常。或是把异常传播出去，

必须要处理所有的异常，如果可以，从失败中恢复再好不过。

以优雅的方式将问题的信息告诉用户。

处理或是向上传播所有的异常，不要将他们压制不管，就算是临时这样做也不行，在写代码是要顾及到会发生的问题。


决定由谁来负责处理异常是设计工作的一部分。
不是所有的问题都应该抛出异常。
报告异常应该在代码的上下文中有实际意义，
如果代码中会记录运行时的日志，当捕获或是抛出异常时，都要记录日志信息

要传播不能处理的异常。

37.   提供有用的错误信息


常用的解决方案是记录日志：当问题发生时，让应用详细记录错误的相关数据，错误日志最起码应该以文本文件的形式维护。不过也可以发布到一个系统级别的事件日志中，


记录日志很有用，可是单单这样做事不够的。（对于用户来说，这样做一点用都没有）

作为开发人员，经常要将自己假定为用户来测试新功能。要是错误信息很难理解，或者无助于错误定位的话，就可以想象真正的用户和支持团队，遇到这个问题该有多么痛苦。


展示有用的错误信息——提供更易于查找错误细节的方式，发生问题是，要是出尽量多的支持细节，不过别让用户陷入其中。


区分错误类型

程序缺陷：真正的bug，用户或者系统管理员对此束手无策。
环境问题：如：数据库连接失败，无法远程连接Web Service，磁盘空间不足，权限不足等类似问题，如果提供足够详细的信息，系统管理员应该可以解决这类问题。
用户错误：程序员与系统管理员不必担心这些问题，告知用户哪里操作的问题后，用户可以重新来过。


通过追踪记录报告的错误类型，可以为受众提供更加合适建议。

错误信息有助于问题的解决，当问题发生时，可以详细研究问题的细节描述和发生上下文。


没必要等待抛出异常来发现问题。在代码关键点使用断言以保证一切正常，当断言失败是要提供与异常报告同样详细的信息。

不泄露安全信息，个人隐私，商业机密，或其他敏感信息

提供给用户的信息可以包含一个主键，以便于在日志文件或是审核记录中定位相关内容。



第 8 章    敏捷协作


项目的成功与否，依赖于团队成员是如何一起有效的工作。

38.   定期安排会面时间——沟通时项目成功的关键。不只要跟客户谈话，还应该与开发人员进行良好的沟通。

站会——是将团队召集在一起，并让每个人了解当下进展状况的好办法，参与者不允许在站会中坐着，可以保证会议快速进行。

站会每个人都要回答三个问题：
    昨天有什么收获
    今天计划要做什么工作。
    面临哪些障碍。
只能给予每个发言者2-3分钟
站会都是在每个工作日的早些时候，且大家都在上班时举行，不要把它安排为上班后的第一件事。，要保证会议结束后有足够的时间，让大家在午餐之前做不少工作。大家到公司之后的半个小时到一个小时之内举行是一个不错的选择。

只有团队成员——开发人员，产品所有者和协调者可以发言，并且他们必须回答上述三个问题，而且不能展开深入讨论。管理层可以把问题记下来，但是不能试图将会议从每个人的三个问题引开。

例会的好处：

让大家尽快投入到工作中来
如果某个开发人员在某一点上有问题，他可以乘机将问题公开，并积极寻求帮助。
帮助团队带头人或管理层了解哪些领域需要更多的帮助，并重新分配人手。
让团队成员知道项目其他部分的进展情况。
帮助团队识别收在某些东西上有重复劳动而耗费了精力。或者是不是某个问题有人已经有现成的解决方案。
通过促进代码和思路的共享，提升开发效率。
鼓励向前的动力：看到别人报告的进度都在前进，会对彼此形成激励。

采取站会的形式需要管理层的承诺和参与

站会可以让团队达成共识，保证会议短小精悍不跑题。
会议会占用开发时间，所以尽量保证投入的时间有比较大的产出，站会最长不超过30分钟，10-15分钟比较理想

对于小团队来说可以两天一次，或者一周两次。

要注意报告细节。

迅速的开始可以保证会议短小。

39.   架构师必须写代码


好的设计者必须能够卷起袖子，加入开发队伍，毫不犹豫的参与实际编程。
好的设计者应该指导开发团队提升他们的水平，已解决复杂的问题。


架构师最重要的任务是：通过找到移除软件设计不可逆性的方式，从而去除所谓架构的概念。


主力程序员应该试着担任架构师的角色，而且可以从事多种不同的角色，负责解决设计上的问题，同时也不会放弃编码的工作，

程序员在拒绝设计的时候，也就放弃了思考。


优秀的设计从积极地程序员哪里开始演化，积极的编程可以带来深入理解。

不允许任何单独进行设计。

40.   实行代码集体所有制


任何具备一定规模的应用都需要多人协作进行开发。
任何一位团队成员只要理解某段代码的来龙去脉，就英爱可以对其进行处理。

要强调代码的集成所有制，让开发人员轮换完成系统中不同领域中不同模块的不同任务

不要无意间丧失了团队的专家技能。
代码集体所有制并不是说可以随心所欲，到处破坏。
有些场合时不能采用代码集体所有制的，也许代码需要某些特定的知识，对特定问题领域的了解，比如一个高难度的实时控制系统。

41.   成为指导者

共享自己的知识，让身边的人人变得更好。

与团队的其他人一起共事是很好的学习机会。

通过详细解释自己知道的东西，可以使自己理解更加深入

与别人公事，激励他们变得更加出色，同时可以提高团队的整体实力。

好的知道者在为他人提供建议时会做笔记。

多数时候，成为指导者，是指在帮助团队成员提升水平的同时也提高自己。

不必局限于自己的团队，可以开设个人博客，贴一些代码和技术在上面。

成为指导者意味着要分享——而不是固守——自己的知识，经验和体会。意味着要对别人的所学和工作感兴趣，同时愿意为团队增加价值，一切都是为了提高队友和自己的能力与水平。

成为指导者。分享自己的知识很有趣——付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。


成为指导者是向团队投资的一种极佳方式。

结对编程是一种进行高效指导的很自然的环境。

42.   允许大家想办法


帮助他们学会如何解决问题
除了答案之外，他们科学岛更多东西。
不会在就类似问题反复提问
可能想出你没有考虑到的解决办法或者主意。

给别人解决问题的机会

用问题来问问题，可以引导提问人走上正确的道路。

43.   准备好后在共享代码。

向代码库中提交仍然在开发的代码会带来很多风险

提交的文件应该与一个特定的任务或是一个bug的解决相关。同时提交相关的文件，并且注有日志信息。


使用远程访问。
随身携带
使用带有底座可扩展的笔记本电脑
使用源代码控制系统

44.   做代码复查

代码刚刚完成时，是寻找问题的最佳时机

要寻找深藏不露的程序bug，正式的进行代码检查，其效果是任何已知形式的测试的两倍

通过严格的代码复查过程，可以提交质量极高而且稳定的代码。

通宵复查：可以将整个团队召集在一起，每个月进行一次“恐怖的代码复查之夜”。

捡拾游戏。

结对编程。


代码能否被理解和读懂。
是否有任何明显的错误？
代码是否会对应用的其他部分产生不良影响？
是否存在重复代码？
是否存在可以改进的地方？


复查所有的代码。对于提升代码质量和降低错误来说，代码复查时无价之宝，如果以正确的方式，复查可以产生非常实用而高效的成果。
要让不同的开发人员在每个任务完成后完成代码复查。

不进行思考，类似于橡皮图章一样的代码没有任何价值。
代码复查需要积极评估代码的设计和清晰程度，而不只是考量变量名和代码格式是否正确。

45.   及时通报进展与问题。

接受一个任务，也就意味着做出了要准时交付的承诺。

及时通报进展与问题，有情况发生时就不会让别人感到突然，而且他们也很愿意了解目前的进展情况。

发送电子邮件，用即时贴传递信息，或快速电话通知。

整个团队可以使用信息辐射器来发布他们的状态，代码设计，研究出的好点子等内容。

及时通报进展与问题：发布进展情况，新的想法和目前正在关注的主题。

每日例会可以让每个人都能明确了解最新的进展和形势。
在展示进度状况是要照顾到受众关注的细节程度。