读书笔记 - 《高效程序员的45个习惯》
《所有学习上的成功，都只靠两件事：策略和坚持，而坚持本身就应该是最重要的策略之一》
《难以坚持下去的事情基本上都是因为没有迫切的欲望和激情。坚持一件事，至少要有明确的目的，例如健身，为了减肥，塑形等，这样才能驱使着人们一直坚持下去。没有动机，没有欲望，哪来的毅力呢？》
恶魔：代表错误的想法。
天使：代表正确的想法。
敏捷 ----- 高效软件开发之道
不管路走了多远，错了就要重新返回
很多时候，开发人员发现自己走错路后，却不愿意立即回头，而是抱着迟早会步入正规，或者后期再解决这个事情的时候，这种侥幸心理。
敏捷开发 ----- 由来
2001年的2月，有17名之多的软件工程师在美国犹他州的Snowbird举行会议，讨论一个新的软件开发趋势，这个趋势被不严格地称为：“轻量型软件开发过程”
世界上应该有一种更好的软件开发方法 ---- 只关注真正重要的事情，少关注那些占用大量时间而无甚裨益的重要的事情。
这些志愿者给这个方法取名为敏捷。他们审视了这种新的软件开发方法，并且发布了敏捷软件开发宣言： 一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
这标志着敏捷开发的诞生，这一模式随后被硅谷创业公司大量应用，并于近几年被引入国内，让中国的工程师们有机会接触这一新奇的开发模式。
它要求团队中的每一个人（包括与团队合作的人）都具备职业精神，并积极地期望项目能够成功。它并不要求所有人都是有经验的专业人员，但是必须具有专业的工作态度-----每个人都希望最大可能做好自己的工作。
态度决定一切
1、做事
在出了问题后应该如何做：
恶魔：
出了问题，第一重要是确定元凶，找到那个白痴！
天使：
如果只是一味的抱怨或者上海他人的感情，那么你无疑是在火上浇油。
指责不会修复BUG，把矛头对准解决问题的办法，而不是人。这才是真正有用处的正面效应。
一个重大的错误应该被当作一次学习而不是指责他人的机会，团队成员在一起工作，应互相帮助，而不是互相指责。
在敏捷开发过程成功，如果你向团队中的同事抱怨，他们会说：“好，我能帮你做些什么？”他们把精力直接放在解决问题上，而不是抱怨。
如果你找人帮忙，却没有人积极响应，那么你应该主动引导对话。解释清除你想要什么，并清晰地标明你的目的是解决问题，而不是指责他人或者争辩。
2、欲速则不达
恶魔：
你不需要真正理解那块代码，它只要能工作就行了，不用理解它，凑合开发就行了，反正也没人管。
我们经常会遇到这种情况，出现一个bug，时间紧迫。使用打补丁或者临时的方案快速解决。
拙劣的代码工人会这样不加死锁地该玩代码，然后迅速转向下一个问题。
优秀的程序员会挖掘更深一层，尽力去理解为什么这里必须加1，更重要的是他会明白会产生什么其他影响。
天使 ：
不要堕入快速的简单修复之中，要投入时间和经历保持代码的整洁、敞亮。
千里之堤-毁于蚁穴，一次又一次的快速修复，每一次都不探究问题根源、代码的清晰度就不断降低。
很可能在你的公司就有人这样告诉你：“无论如何，千万不能碰那个模块的代码。写代码那哥们已经不在这儿，没有人看懂他的代码。” 久而久之形成一个危险的沼泽地，最终吞噬整个项目。
3、对事不对人
天使：
对事不对人，让我们骄傲的应该是解决了问题，而不是比较谁出的主意比较好。
在一个团队中，如果能稍加注意礼貌待人，将会有益于整个团队关注真正的价值，而不是勾心斗角。
如果你准备提出一个想法，却担心有可能被嘲笑，丢面子，那么你就不会主动提出自己的建议了。
然而好的软件开发作品与设计，都需要大量创造力和洞察力。分享并融合各种不同的想法和观点，远胜于单个想法为项目带来的价值。
我们每个人都会有好的想法，和不对的想法，团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也是能对最终解决问题有所帮助，不要害怕受到批评。
任何一个专家都是从这里开始的。“你不需要很出色才能起步，但是你必须起步才能变得出色。”
尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气，不要因为只是想体现自己的想法而拟定的好思路画蛇添足。
4. 排除万难，奋勇前进
恶魔：
如果你发现其他人代码有问题，自己心里知道就好了，毕竟你不想 惹来麻烦。
天使：
有时，绝妙的计划会因为勇气不足而最终失败，尽管前方很危险，你必须有勇气向前冲锋，做你认为对的事情。
假如你发现其他人编写的有块代码很难理解也不好使用，你是应该继保留这些脏乱的代码，并跳出来告诉周围的人，那些代码是多么糟糕，但那只是抱怨和发泄，并不能解决问题。
相反你应该重写这些代码，并比较重写前后的优缺点。
动手证明是最有效的方式，把糟糕的代码放到一边，立刻重写。列出重写的理由，会有助于你的老板（以及同事）认清当前形势，帮助他们得到正确的解决方案。
当发现问题时，不要试图掩盖这些问题。而要有勇气站起来。
学无止境
即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。
逆水行舟不进则退，那不仅是赛马场上的真理，它更适合我们当今的程序员。
软件开发行业是一个不停发展和永远变化的领域。虽然有一些概念一直有用，但还有很多知识很快就会过时。
从事软件开发行业就像是在跑步机上，你必须一直跟上步伐稳步前进，否则就会摔倒出局。
5. 跟踪变化
恶魔：
软件开发行业变化不大，核心的就那些。继续用你熟悉的语言做你的老本行吧，没问题的，也能跟上技术变化的脚步。
天使：
如何才能跟上技术 变化的步伐呢？
-
迭代和增量式的学习:
每天计划用一段时间学习新技术，不需要很长时间，但需要经常进行。
记下那些你想学习的东西，例如当你听到一些不熟悉术语或短语时，简要地记录下载，然后在计划的时间中深入研究它。 -
了解最新行情:
互联网上有大量关于学习新技术的资源，选择一些优秀的技术博客，经常去读一读。 -
参加活动，会议:
计算机大会，研讨会，技术社区会等。 -
阅读:
找一些关于软件开发和非技术的好书，也可以是一些专业的期刊和商业杂志等。 -
你不可能精通每一项技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。
-
只要你在某些方面成为专家，就能使用同样的方法，很容易成为新领域的专家。
6. 对团队投资
恶魔 ：
不要和别人分享你的知识 --- 自己留着，你是因为这些知识而成为团队中佼佼者，只要自己聪明就可以了，不用管其他失败者。
不要和别人分享你的知识 --- 万一自己分享的是错误的，丢脸了怎么办，是吧。
天使：
通过分享不但可以让自己对知识了解更透彻，也能帮助到别人。
7. 懂得丢弃
在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。
打破旧习惯很难，更难的是自己还没有意识到这个问题。丢弃的第一步，就是要意识到你还在使用过时的方法，这也是最难的部分。另一个难点就是要醉倒真正的丢弃旧习惯。思维定式是经过多年摸爬滚打才构建成型的，已经根深蒂固，没有人可以很容易就丢弃它们。
在学习一门新技术的时候，要丢弃会阻止你前进的习惯。毕竟，汽车要比马车车厢强的多。
8. 打破砂锅问到底
恶魔 ：
接受别人给你的解释。别人告诉你问题出在什么地方，你就去看什么地方。不需要再浪费时间追根究底。
天使：
不能满足别人告诉你的表面现象，要不停地提问直到你明白问题的根源。
9. 把握开发节奏
恶魔：
随意安排工作计划，是比较好的，有利于方便开发。
天使 ：
在许多不成功的项目中，基本都是随意安排工作计划，没有任何的规律.
解决任务，在事情变得一团遭之前，保持时间之间稳定重复的间隔，更容易解决常见的重复任务。
交付用户想要的软件
- 提早集成，频繁集成
10. 让客户做决定
天使：
让你的客户做决定。开发者。经理或业务分析师不应该做业务方面的决定。用业务负责 人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
记录客户做出的决定，并注明原因。好记性不如烂笔头。可以使用工程师的工作日记或日志、wiki 、邮件记录或者问题跟踪数据库。
如果业务负责人回答"我不知道"，也许是他们还没有想那么远，只有看到实物才能评估出结果。尽你所能为他们提供建议，实现代码的时候也要考虑可能出现的变化。
11. 让设计指导而不是操纵开发
恶魔：
代码工人不需要做任何决定，只要简单地把设计转化成代码就可以了。
天使：
-
设计满足实现即可，不必过于详细
如果设计师们把自己的想法绘制成精美的文档，然后把它们扔给程序员去编码，程序员会在压力下，完全按照设计或者图画的样子编码。
就作者本人而言，没有一个愿意在这样的团队中做纯粹的打字员。 -
战略级别的设计不应该具体说明程序方法、参数、字段和对象交互精确顺序的细节。
良好的战略设计应该扮演地图的角色，指引你向正确的方向前进。 -
好的设计应该是正确的，而不是精确的。
也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。它是目标，不是具体的处方。
12. 合理地使用技术
恶魔：
你开始了一个新项目，在你面前有一长串关于新技术何应用框架的列表，这些都是好东西，你都需要，并给还能在简历上留下漂亮的一笔。
天使：
当你在考察一个框架（或任何技术）的时候，也许会被它提供的各种功能吸引。但是你真的需要这些功能吗，这很想站在结账处一时冲动而买些无用的小零碎。
如果你发现自己在做一些花哨的东西，那就应该认真评估下，是否值得去做。
比如，使用后是否被栓住了，一些技术是贼船，一旦你使用了它，就会被它套牢，很难回头。
比如，维护成本是怎样，会不会随着时间的推移，它的维护成本会非常昂贵。
根据需要选择技术，首先决定什么是你需要的，接着为这些具体的问题评估使用技术。
13. 保持可以发布
天使：
保持你的项目时刻可以发布，保证你的系统可随时编译、运行、测试。
14. 提早集成，频繁集成
天使：
敏捷的一个主要特点是持续开发，而不是三天打鱼两天晒网似的工作，特别是几个人一起开发同一个功能的时候，更应该频繁地集成代码。
代码集成是主要的风险来源，要想规避这个风险，只有提早集成，持续而有规律地进行集成。
15. 提早实现自动化部署。
天使：
有了自动化部署系统后，在项目开发的整个过程中，会更容易适应互相依赖的变化。
这些工作都应该是无形的。系统的安装或者部署应该简单、可靠以及可重复。一切都很自然。
16.使用演示获得频繁反馈
17.使用短迭代，增量发布
魔鬼：
我们为后面的3年制定了漂亮的项目计划，列出了所有的任何和可交付的时间表，只要我们那时候发布了产品，就可以占领市场。
天使：
大部分用户都是希望现在就有一个够用的软件，而不是一年之后得到一个超级好软件。确定使产品可用的核心功能，然后把它们放在生产环境中，越早交到用户的手里越好。
18. 敏捷反馈
小步前进，不停地收集反馈，时刻矫正自己。
24. 倾听用户的声音
魔鬼：
用户就是会抱怨，用户太蠢了，连使用手册都看不懂，它不是一个bug，只是用户不知道如何使用而已。
天使：
每一个抱怨的背后都隐藏一个事实，找出真相，修复真正的问题。
没有愚蠢的用户，只有自大的开发人员。
25. 代码要清晰的表达意图
开发代码时，应该更注重可读性，而不是图自己方便。代码阅读的次数要远远超过编写的次数。
是要编写清晰的而不是讨巧的代码。向代码阅读者明确表达你的意图。
不要明日复明日，如果不现在做的话，以后你也不会做的。
26. 用代码进行沟通
使用细心选择有意义的命名，用注释描述代码意图和约束。注释不能替代优秀的代码。
·#### 27. 动态评估取舍
考虑性能，便利性，生产力、成本和上市时间。
如果性能表现足够了，就将注意力放在其它因素上，不要为了感觉上的性能提升或设计优雅，而将设计复杂化。
·#### 28. 保持简单
开发可以工作的、最简单的解决方案。除非有不可辩狡的原因，否则不要使用模式、原则和高难度技术之类的东西。
29. 编写内聚的代码
让类的功能尽量集中，让组件尽量小。要避免创建很大的类或组件，也不要创建无所不包的大杂烩类，每个类或组件只做一件事，而且要做得很好。
34. 警告就是错误
签入带有警告的代码，就跟签入有错误或没有通过测试的代码一样，都是极差的做法。
35.对问题各个击破
在解决问题的时候，要将问题域与周边隔开，特别是大型应用中。
37. 提供有用的错误信息
提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节。
41. 成为指导者
分享自己的只是很有趣，付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实例。
给予别人教导，也是提升自己学识的一种方式，并且其他人亦开始相信你可以帮助他们。
42. 允许其他人自己想办法
授人以鱼不如授人以渔，告诉团队成员解决问题的方法，也要让他们知道如何解决问题的思路，这也是成为指导者的一部分。
指给它们正确的方向，而不是直接提供解决方案，每个人都能从中学到不少东西。
43. 代码复查
对于提升代码质量和降低错误率来说，代码复查是无价之宝。如果以正确的方式进行，复查可以产生非常实用而高效的成果，要让不同的开发人员在每个任务完成后复查代码。
45. 及时通报进展与问题
发布进展状况，新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。
