站在巨人的肩上
Standing on the Shoulders of Giants。
读了《高效程序员的45个习惯》，我觉得我学到的不只是知识，更重要的是一种学习能力、团队协作能力、以及一种为人处世的道理。
有些习惯很容易养成，有些则很难。我们常常许愿，做计划，比如要学会C语言那个做出一个项目，参加实践活动，每周至少两篇博客（为我上周落下的博客默哀）……然后在计划落空的时候安慰自己。
所以我觉得我目前最重要的是获得学习能力，并保持良好的心态。开拓视野开拓眼界，并且做好将来的规划，灵活运用学到的知识，而不是死读书读死书，以后才有可能真正用到这些知识。
下面我给大家分享一下这本书的四十五种良好的习惯。
第1章 敏捷--高效软件开发之道
不管路走了多远，错了就要重新返回。
敏捷开发宣言：
个体和交互胜过过程和工具
可工作的软件胜过面面俱到的文档
客户协作胜过合同谈判
响应变化胜过遵循计划
敏捷的宗旨：以人为本、团队合作、快速相应变化、可工作的软件
敏捷不要求所有人都是具有经验的专业人员，但必须具有专业的工作态度。
评语：态度决定敏捷是否可以推行，并直接影响推行的结果；如果团队对敏捷的态度总体持怀疑态度，不如尽早停止敏捷以避免对敏捷的抵触；如果个别成员排斥敏捷需要先将个人排除到敏捷之外，用效果感化他让他由强烈的敏捷意愿；不管对团队还是个人，引导和宣传敏捷使其能转换思维是上策，达不到就排除这些反对派，否则反对派会向毒瘤一样迅速腐化团队斗志。
引导+自愿是敏捷团队的组成方式。
敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
第2章 态度决定一切
选定了要走的路，就是选定了它通往的目的地。
习惯1：做事
敏捷团队中只有一个角色：软件开发者。项目需要你做什么你就做什么，包括设计、编码、文档、工具。
指责不能修复BUG，把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。
评语：回溯bug时，注意是批评行为，而不是批评个人。时刻注意两者的差别。
习惯2：欲速则不达
不要坠入快速的简单修复中之中。要投入时间和精力保持代码的简洁、敞亮。
习惯3：对事不对人
没有谴责、没有批判，只是简单地表达自己的观点，会让团队成员意识到这个问题而不是扫他的面子。
负面的评论和态度扼杀了创新。
你是一个掌舵者，一定要把握方向，深思熟虑，吸取各方的意见。
设计充满了妥协，成功属于意识到这一点的团队。
对事不对人，让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。
习惯4：排除万难，奋勇前进
当发现问题时，不要试图掩盖这些问题，而要有勇气站起来。
做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
第3章 学无止境
习惯5：跟踪变化
迭代和增量式的学习。每天计划用一段时间来学习新技术，它不需要很长时间，但需要经常进行。记下那些你想学习的东西----当你听到一些不熟悉的术语或者短语时，简要的把它记下。然后在计划的时间中深入研究它。
通过优秀技术博客了解最新行情。
跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
避免在一时冲动的情况下，只是因为想学习而将应用切换到新的技术、框架或开发语言。开发一个小的原型系统，是对付技术狂热者的一剂良药。
习惯6：对团队投资
一个学习型的团队才是较好的团队。
每周，要求团队中的一个人主持讲座。他会给大家介绍一些概念，演示工具，或者作出团队感兴趣的任何一件事情。
提供你和团队学习的更好平台。
习惯7：懂得丢弃
在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法应用到了新技术上。
学习新的东西，丢弃旧的东西。在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。
习惯8：打破砂锅问到底
不停的问为什么，不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
习惯9：把握开发节奏
在许多不成功的项目中，基本上都是随意安排工作计划，没有任何的规律。
运用有规律的开发节奏，会更容易达到目标，并确保项目不停的前进。
解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。
就像是减肥一样，一点点的成功也是一个很大的激励。小而可达到的目标会让每个人全速前进。
第4章 交付用户想要的软件
没有任何计划在遇敌后还能继续执行。
习惯10：让客户做决定
开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不了的，应该让企业主做决定。
让你的客户做决定。开发者、经理或者业务分析师不应该做业务方向的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，让他们做决定。
习惯11：让设计指导而不是操纵开发
在做设计的时候，你需要花时间去思考各种不同选择的缺陷和益处，以及如何做权衡；下一步才考虑是否需要开始编码。
设计及其代码实现会不停的发展和变化。
严格的需求-设计-代码-测试开发流程源于理想化的瀑布式开发方法，它导致在前面进行了过度的设计。
设计可以分为两层：战略和战术。前期的设计属于战略，战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节，那应该保留到战术设计阶段。
好设计是一张地图，它也会进化。设计指引你向正确的方向前进，它不是殖民地，它不应该标识具体的路线。你不要被设计或者设计师操纵。
好的设计应该是正确的，而不是精确的。它描述的一切不应该涉及不确定或者可能会发生变化的细节。
如果深入编码只是为了学习或者创造原型，只要你随后能把这些代码扔掉，那也是一个不错的办法。
习惯12：合理的使用技术
如果需要，先做一个小的原型。
确保不会被新的技术拴住；不要使用缺乏可取消性的技术；考虑技术是开放技术还是专利技术；考虑新技术的维护成本。
你的代码写的越少，需要维护的东西就越少。
根据需要选择技术：首先决定什么是你需要的，接着为这些具体的问题评估使用技术。对于任何要使用的技术，多问一些挑剔的问题，并真实的作出回答。
新技术就应该像是新的工具，它可以帮助你更好的工作，而不应该成为你的工作。
不要开发那些你容易下载到的东西。
习惯13：保持可以发布
提交代码流程：在本地运行测试----检出最新代码----提交代码。
保持你的项目时刻可以发布。保证你的系统随时可以编译、运行、测试并立即部署。
习惯14：提早集成，频繁集成
使用Mock对象来隔离对象之间的依赖。
提早集成，频繁集成。代码集成是主要的风险来源，要想规避这个风险，只有提早集成、持续而有规律的进行集成。
习惯15：提早实现自动化部署
一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员（QA）要像测试应用一样测试部署。
系统的安装或部署应该简单、可靠及可重复。
习惯16：使用演示获得频繁反馈
清晰可见的开发。在开发的时候，要保持应用可见。每隔一周或者两周邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
习惯17：使用短迭代，增量发布
询问用户，哪些是使产品可用且不可缺少的核心功能。不要为所有可能需要的华丽功能而分心，不要沉迷于你的想象，去做那些华而不实的用户界面。
增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1-4周左右迭代周期。
习惯18：固定的价格就意味着背叛承诺
基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由用户控制他们要的功能与预算。
第5章 敏捷反馈
习惯19：守护天使
使用自动化的单元测试。好的单元测试能够为你的代码提供及时的警报。如果没有到位的单元测试，不要进行任何设计和代码修改。
单元测试是有用的设计工具。
不编写单元测试的很多借口，都是因为代码中的设计缺陷。通常，抗议越强烈，说明设计越糟糕。
习惯20：先用它再实现它
先用它再实现它。将TDD作为设计工具，它会为你带来更简单更有实效的设计。
只在有具体理由的时候才开始编码。你可以专注于设计接口，而不会被很多实现的细节干扰。
习惯21：不同环境，就有不同问题
不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极的寻找问题，而不是等问题来找你。
习惯22：自动验收测试
为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
习惯23：度量真实的进度
度量剩下的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的代办事项。
不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。
诚实非常重要，隐瞒真相毫无意义。本次的估算失误能作为下一次的参考。
习惯24：倾听用户的声音
每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正地问题。
没有愚蠢的用户；只有愚蠢、自大的开发人员。
第6章 敏捷编码
习惯25：代码要清晰的表达意图
要编写清晰的而不是讨巧的代码。向代码阅读者明确表明你的意图。可读性差的代码一点都不聪明。
习惯26：用代码沟通
使用细心选择的，有意义的命名；用注释描述代码意图和约束。注释不能替代优秀的代码。
建立代码文档无外乎两种方式：利用代码本身；利用注释沟通代码外的问题。
源代码可以被读懂，不是因为其中的注释，而是因为它本身的优雅而清晰----变量名使用正确、空格使用得当、逻辑分离清晰，以及表达式简洁。
良好的命名能向读者传递大量的正确信息；不好的命名不会传递任何信息；糟糕的命名则会传递错误的信息。
注释可以为读者指定一条正确的代码访问路线图。为代码中的每个类或模块添加一个短小的描述，说明其目的以及是否有任何别的需求。
解释代码做了什么的注释用处不大；相反，注释要说明为什么会这样写代码。
习惯27：动态评估取舍
考虑性能、便利性、生产力、成本和上市时间，如果性能表现足够了，就将注意力放在其他因素上，不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
习惯28：增量式编程
在很短的编辑-构建-测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作要好的多；可以创建更加清晰、简单、易于维护的代码。
所开发的代码基于及时的反馈，这些反馈来自以小步幅方式编写代码和测试的过程。
习惯29：保持简单
开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
相比一个过分复杂、拙劣的解决方案，简单的方案通常更难以获得。
优雅的代码第一眼看上去，就知道它的用处，而且很简洁。
习惯30：编写内聚的代码
让类的功能尽量集中，让组件尽量小。要避免创建很大的类或者组件，也不要创建无所不包的大杂烩类。
内聚性会影响组件的可重用性。
习惯31：告知、不要询问
不要抢别的对象或者是组件的工作。告诉它做什么，然后盯着你自己的指责就好了。
作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态。
命令与查询相分离模式（command-query separation）
使用信息传递的概念，而不是方法调用。告知、不要询问感觉是你在发消息，而不是调用函数。
习惯32：根据契约进行替换
通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性，多使用委托而不是继承。
Liskov替换原则：任何继承后得到的派生类对象，必须可以替换任何被使用的基类对象，而且使用者不必知道任何差异。
如果新类可以替换已有的类，并且它们之间的关系可以通过is-a来描述，就要使用继承；
如果新类只是使用已有的类，并且两种之间的关系可以通过has-a或者use-a，就使用委托吧。
第7章 敏捷调试
习惯33：记录问题解决日志
维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。
习惯34：警告就是错误
将警告视为一种错误。签入带有警告的代码，就跟嵌入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何告警信息。
习惯35：对问题各个击破
在解决问题时，要将问题域域其周边隔离开，特别是在大型项目中。
习惯36：报告所有的异常
处理或是向上传播所有的异常。不要将他们压制不管，就算是临时这样做也不行，在写代码时要估计到会发生的问题。
习惯37：提供有用的错误信息
展示有用的错误信息。提供更易于查找错误细节的方式，发生问题时要展示出尽量多的支持细节，不过别让用户陷入其中。
调试信息非常宝贵且不易获得，不要轻易将其丢弃。
缺陷分类：程序缺陷，程序员解决；环境问题，系统管理员解决；用户错误，用户修正。
习惯38：定期安排会面时间
使用立会。例会可以让团队达成共识，保证会议短小精悍不跑题。
立会在大家到公司后的半个小时或者一个小时内举行，是个不错的选择。
立会益处：让大家尽快投入到一天的开发工作中来；积极寻求帮助；帮助团队带头人了解哪些领域需要更多的帮助并重新分配人手；让团队成员知道项目其他部分的进展；鼓励向前的动力。
习惯39：架构师必须写代码
优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师。不知道系统的真实情况，是无法展开设计的。
要鼓励程序员参与设计。主力程序员应该试着担任架构师的角色。程序员在拒绝设计的同时，也就放弃了思考。
习惯40：实行代码集体所有制
要强调代码的集体所有制。让开发人员轮换完成系统不同领域中不同模块的不同任务。
习惯41：成为指导者
分享自己的知识很有趣--付出的同时便有收货。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
习惯42：允许大家自己想办法
给别人解决问题的机会。指给他们正确的方向，而不是直接提供解决方案。每个人都能从此能够中学到不少东西。
用问题回答问题，可以引导提问的人走上正确的道路。
习惯43：准备好后再共享代码
绝不要提交尚未完成的代码。故意签入编译未通过或者是没有通过单元测试的代码，对项目来说，应视为玩忽职守的犯罪行为。
习惯44：做代码复查
复查所有代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果。要让不同开发人员在每个任务完成后复查代码。
要寻找深藏不露的bug，正式进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷唯一的已知方法。
代码复查需要积极评估代码的设计和清晰程度，而不只是考量变量名和代码格式是否符合组织的标准。
使用Similarity Analyzer或Jester这样的代码分析工具。
习惯45：及时通报进展与问题
发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。
第9章 引入敏捷
当项目岌岌可危时，应该先引入一系列习惯来稳定目前的状况。
敏捷开发是要让开发人员的工作变得更加轻松。