《高效程序员的45个习惯》这本书是朋友推荐的。
近期在工作中认识到自己的一些不足，于是把它翻出来想好好看一下， 并记录一些重点持续更新，与大家共勉。
第一章 敏捷——高效软件开发之道
-
敏捷的精神：它要求团队中的每一个人（包括与团队合作的人）都具备职业精神，并积极地期望项目能够获得成功。它并不要求所有人都是有经验的专业人员，但必须具有专业的工作态度——每个人都希望尽最大可能做好自己的工作。
-
敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
第二章 态度决定一切
专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，围绕最后的成功开展工作。
做事
- 最高优先级应该是解决问题。
- 一个重大的错误应该被当作是一次学习而不是指责他人的机会。
- 符合标准不是结果。敏捷团队重结果胜于重过程。
指责不能修复bug 。把矛头对准问题的解决办法，而不是人。
欲速则不达
- 不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。
- 代码审查、单元测试等。
- 不要急于修复一段没能真正理解的代码。这种 +1/-1 的病症始于无形，但是很快会让代码一团糟。要解决真正的问题，不要治标不治本。
- 所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。
对事不对人 让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。
- 分享并融合各种不同的想法和观点，远胜于单个想法为项目带来的价值。
- 消极扼杀创新。
- 不要害怕批评。不需要很出色才能起步，但是必须起步才能变得很出色。
- 能欣赏自己并不接受的想法，表明你的头脑足够有学识。
- 大家对“最好”的含义要达成共识。
技巧：
-
设定最终期限 防止陷入无休止的理论争辩之中。没有最好的答案，只有更合适的方案。
-
逆向思维 先是积极地看到它的正面，然后再努力地从反面去认识它。目的是要找出优点最多缺点 最少的那个方案，而这个好办法可以尽可能地发现其他缺点。
-
设立仲裁人 仲裁人的责任就是确保每个人都有发言的机会，并维持会议的正常进行。
-
支持已经作出的决定 我们的目标是让项目成功满足用户需求。客户并不关心这是谁的主意--他们关心的是，这个软件是否可以工作，并且是否符合他们的期望。结果最重要。
-
我们每个人都能有一些极好的创新想法，同样也会萌生一些很愚蠢的想法。
-
脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太容易发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过吗？是否经常发生？
排除万难、奋勇前进 绝妙的计划会因为勇气不足而最终失败。
-
当发现问题时，不要试图掩盖这些问题，而要有勇气站出来。
-
做正确的事。要诚实，要有勇气去说出事情。有时，这样做很困难，所以我们要有足够的勇气。
-
当勇敢地站出来时，如果受到了缺乏背景知识的抉择者的抵制，你需要用他们能够听懂的话语表达。“更清晰的代码”是无法打动生意人的。节约资金、获得更好的投资回报、增加用户利益，会让论点更有说服力。
第三章 学无止境
关键词：跟踪变化，对团队投资，懂得丢弃，把我开发节奏。
跟踪变化
-
迭代和增量式学习
-
了解最新行情
-
参加本地的用户组活动
-
参加研讨会议
-
如饥似渴地阅读
-
跟踪技术变化。你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
-
许多新想法从未变得羽翼丰满，成为有用的技术。即使是大型、热门和资金充裕的项目也会有同样的下场。你要正确把握自己投入的精力。
对团队投资
一个学习型的团队才是较好的团队。
share, share, share
-
你参加了一个课程或者研讨班之后，所学的知识如果不用，往往就会忘记。所以，你需要和其他团队成员分享所学的知识，把这些知识引入团队中。
-
坚持有计划有规律地举行讲座。持续、小步前进才是敏捷。稀少、间隔时间长的马拉松式会议非敏捷也。
懂得丢弃
-
敏捷的根本之一就是拥抱变化。
-
在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。
-
打破旧习惯很难，更难的是自己还没有意识到这个问题。丢弃的第一步，就是要意识到你还在使用过时的方法，这也是最难的部份。
打破砂锅问到底
不停地问为什么
把握开发节奏
- 解决任务，在事情变得一团糟之前。保持事件之间稳定重复的间隔，更容易解决常见的重复任务。
- 在每天结束的时候，测试代码，提交代码，没有残留的代码。
第四章 交付用户想要的软件
成功的软件开发-取决于识别和适应变化的能力。
提早集成，频繁集成。
提早实现自动化部署。
使用演示获得频繁反馈。
使用短迭代，增量开发。
让客户做决定
-
判断哪些是自己决定不了的，应该让企业主做决定。
-
让你的客户做决定。开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
让设计指导而不是操纵开发
-
计划是没有价值的，但计划的过程是必不可少的。避免过度设计。
-
一旦开始了编码，一切都会改变。设计及其代码实现会不停地发展和变化。
-
好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
-
即使初始的设计到后面不再管用，你仍需设计：设计行为是无价的。正如美国总统艾森豪威尔所说：“计划是没有价值的，但计划的过程必不可少。”在设计过程中学习是有价值的，但设计本身也许没有太大的用处。
合理地使用技术
-
考虑引入新技术或框架之前，要先考虑几个方面：
- 这个技术框架真能解决这个问题吗？
- 你将会被它拴住吗？一些技术是贼船，一旦你使用了它，就会被它套牢，再也不可能回头了。
- 维护成本是多少？
-
每一门技术都会有优点和缺点，无论它是开源的还是商业产品、框架、工具或语言，一定要清楚它的利弊。
保持可以发布
-
简单的工作流：在本地运行测试 -> 检出最新的代码 -> 提交代码
-
任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
-
在团队里工作，修改一些东西的时候必须很谨慎。你要时刻警惕，每次改动都会影响系统的状态和整个团队的工作效率。
提早集成，频繁集成
代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
-
绝不要做大爆炸式的集成。
-
提早集成，频繁集成。代码集成是主要的风险来源。要想规避这个风险，只有提早集成，持续而有规律地进行集成。
-
如果你集成得不够频繁（比如一周一次，甚至更糟），也许就会发现整天在解决代码集成带来的问题，而不是在专心写代码。如果你集成的问题很大，那一定是做得不够频繁。
提早实现自动化部署
-
一开始就实现自动化部署应用。使用部署系统安装你的应用，在不同的机器上用不同的文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。
-
部署一个紧急修复的bug 应该很简单，特别是在生产服务器的环境中。你知道这会发生，而且你不想在压力之下，在凌晨三点半，你还在手工部署系统。
使用演示获得频繁反馈
- 演示是用来让客户提出反馈的，有助于驾驭项目的方向。
- 维护一份项目术语表。在项目的开发过程中，从术语表中为程序结构——类、方法、模型、变量等选择合适的名字，并且要检查和确保这些定义一直符合用户的期望。
- 清晰可见的开发。在开发的时候，要保持应用可见（而且客户心中也要了解）。每隔一两周，邀请所有的客户，给他们演示最新完成的功能，积极获得他们的反馈。
使用短迭代，增量发布
-
分析、设计、实现、测试和获得反馈，所以叫做迭代。
-
增量开发。发布带有最小却可用功能块的产品。每个增量开发中，使用1～4周左右迭代周期。
固定的价格就意味着背叛承诺
-
软件项目天生就是变化无常的，不可重复。如果要提前给出一个固定的价格，就几乎肯定不能遵守开发上的承诺。
-
基于真实工作的评估。让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
第五章 敏捷反馈
守护天使
-
一些开发者会对单元测试有意见：毕竟，有“测试”这个词在里面，毫无疑问这应该是其他人的工作。从现在开始，忘掉“测试”这个词。就把它看作是一个极好的、编写能产生反馈的代码的技术。
-
使用自动化的单元测试。好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何代码设计和代码修改。
-
人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常，抗议越强烈，就说明设计越糟糕。
先用它再实现它
-
设计的一个重点是：确定什么是成功地实现特定功能的最低成本。程序员很容易走向另一个极端——一些不必要的过于复杂的事情——测试优先会帮助我们，防止我们走偏。
-
先用它再实现它。将TDD 作为设计工具，他会为你带来更简单更有实效的设计。
不同环境，就有不同问题
不同环境，就有不同问题。使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
度量真实的进度
-
判断工作进度最好是看实际花费的时间而不是估计的时间。
6分钟作为一个时间单位，它的颗粒度太细了，这不是敏捷的做法
一周或一个月的时间单位，它的颗粒度太粗了，也不是敏捷的做法
-
我们不应该去计算工作量完成的百分比，而应该测定还剩下多少工作量没有完成。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
-
在你最后真正完成一项任务时，要清楚知道完成这个任务真正花费的时间。在为下一个任务估计工作量时，可以根据这次经验调整评估。
倾听用户的声音
- 每一个抱怨的背后都隐藏了一个事实。找出真相，修复真正的问题。
- 不管它是否是产品的bug ，还是文档的 bug ，或者是对用户社区理解的 bug ，它都是团队的问题，而不是用户的问题。
自动验收测试
-
为核心的业务逻辑创建测试。让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
第六章 敏捷编码
代码要清晰地表达意图
- 开发代码时，应该更注重可读性，而不是只图自己方便。代码阅读的次数要远远超过代码编写的次数，所以在编写的时候值得花点功夫让它读起来更简单。
- 要编写清晰的而不是讨巧的代码。向代码阅读者明确表明你的意图，可读性差的代码一点都不聪明。
用代码沟通
-
用注释沟通。使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能代替优秀的代码。
动态评估取舍
-
动态评估权衡。考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其他因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
-
如果现在投入额外的资源和精力，是为了将来可能得到的好处，要确认投入一定要得到回报（大部分情况下，是不会有回报的）。
-
过早的优化是万恶之源。
增量式编程
- 在很短的编辑、构建、测试循环中编写代码。这要比花费长时间仅仅做编写代码的工作好得多。可以创建更加清晰、简单、易于维护的代码。
- 要像重构你的代码那样，重构你的测试，而且要经常重构测试。
保持简单
- 开发可以工作的、最简单的解决方案。除非有不可辨驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
- 要将目标牢记在心：简单、可读性高的代码。强行让代码变得优雅与过早优化类似，统一会产生恶劣的影响。
编写内聚的代码
- 让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不用创建无所不包的大杂烩类。
告知，不要询问
- 面向过程的代码取得信息，然后做出决策。面向对象的代码让别的对象去做事情。
- 作为某段代码的调用者，开发人员绝对不应该基于被调用对象的状态来做出任何决策，更不能去改变该对象的状态。这样的逻辑应该是被调用对象的责任，而不是你的。
- 告知，不要询问。不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
根据契约进行替换
-
通过替换代码来扩展系统。通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。
第七章 敏捷调试
记录解决问题的日志
日志需要记录的一些内容
-
问题发生日期
-
问题简述
-
解决问题详细描述
-
引用文章或网址，以提供更多细节或相关信息
-
任何代码片段、设置或对话框的截屏，只要它们是解决文案的一部分，或者可以帮忙更深入地理解相关细节
- 维护一个问题及其解决方案的日志。保留解决方案是修复问题过程的一部分，以后发生相同或类似问题时，就可以很快找到并使用了。
- 如果通过搜索Web ，发现没人曾经遇到同样的问题，那也许是搜索的方法有问题。
警告就是错误
-
将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。
对问题各个击破
- 很多应用的代码在编写时没有注意到隔离问题这一点，使得分离变得特别困难。此时，最好花一些时间把关注的代码提取出来，而且创建一个可让其工作的测试环境。
- 对问题各个击破。在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中。
报告所有的异常
- 处理或是向上传播所有的异常。不要将它们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题。
提供有用的错误信息
-
展示有用的错误信息。提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
第八章 敏捷协作
定期安排会面时间。
使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。
虽然大多数团队需要每天都碰头，但对于小型团队来说，这样做可能有点过头了。不妨两天举行一次，或者一周两次，这对小团队来说足够了。
站会的内容
-
昨天有什么收获？
-
今天计划要做哪些工作？
-
面临着哪些障碍
-
只能给与每个参与者很少的时间发言（大约两分钟）。如果要详细讨论某些问题，可以在站会结束之后。
-
站会的时间最长不超过30分钟，10-15分钟比较理想。
-
要报告细节。给出具体的进度，但不要陷入细节之中。
架构师必须写代码
-
设计会随着时间而演进，如果忽略了应用的现状（它的具体实现），要想设计一个新的功能，或者完成某个功能的提升，是不可能的。
-
优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。
-
不要运行任何人单独进行设计，特别是你自己。
实现代码集体所有制
相比找出谁的主意更好、谁的代码很烂，解决问题竟让应用满足用户的期望更为重要。
成为指导者
-
与团队其他人一起共事是很好的学习机会。
-
成为指导者。分享自己的知识很有趣——付出的同时便有收货。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
-
如果一直在就同一个主题向不同的人反复阐述，不妨记录笔记，此后就此主题写一篇文章，甚至是一本书
允许大家自己想办法
这么做的好处
-
你在帮忙它们学会如何解决问题
-
除了答案之外，他们可以学到更多东西
-
他们不会再就类似问题反复问你
-
这么做，可以帮助他们在你不能问答问题时自己想办法
-
他们可能想出你可能没有考虑到的解决问题或主意。这是最有趣的——你也可以学到新东西。
准备好后再共享代码
- 准备好后再共享代码。绝不要提交尚未完成的代码。故意签入编译未通过或是没有经过单元测试的代码，对项目来说，应被视为玩忽职守的犯罪行为。
做代码复查
- 复查所有的代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成功。要让不同的开发人员在每个任务完成后复查代码。
- 同样的功能，不同开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码变得更好，否则不要随意批评别人的代码。
- 如果不及时跟进讨论中给出的建议，代码复查是没有实际价值的。可以安排跟进会议，或者使用代码标记系统，来标识需要完成的工作，跟踪已经处理完的部分。
及时通报进展与问题
- 及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。
第九章 走向敏捷
