最近电视剧，电影，动画片看腻了，便买了本《高效程序员的45个习惯》来读。至于为什么买这本书而不买其它书呢，我想主要原因是最近项目组开始了某些SCRUM。在这笔记中我想我一开始还只是把书上的一些建议抄下来。算是给自己一个加深映像吧。也不怎么准备发表过多的自己的看法，毕竟经验有限，也提不出太多的建议。好了，开始吧。
一、做事
不良习惯：出了问题，第一重要的是确定元凶。找到那个白痴！一旦证实了是他的错误，就可以保证这样的问题永远不会再发生了。
良策：指责不会修bug。把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。
切身感受：勇于承认自己不知道答案，这会让人感觉放心。一个重要的错误应该被当作是一次学习而不是指责他人的机会。团队成员在一起工作，应相互帮助，而不是互相指责。
平衡艺术：
- “这不是我的错”，这句话不对。“这都是你的错”，这句话更不对。
- 如果你没有犯过任何错误，就说明你可能没有努力去工作。
- 开发者和QA争论某个问题是系统本身的缺陷还是系统增强功能导致的，通常没有多大的意义。与其如此，不如赶紧去修复它。
- 如果一个团队成员误解了一个需求，一个API调用，或则最近一次会议做的决策，那么，也许就意味着团队的其他成员也有相同的误解。要确保整个团队尽快消除误解。
- 如果一个团队成员的行为一再伤害了团队，则他表现得很不职业。那么，他就不是在帮助团队向解决问题的方向前进。这种情况下，我们必须要求他离开这个团队。
- 如果大部分团队成员（特别是开发领导者）的行为很不职业，并且他们对团队目标都不感兴趣，你就应该主动从这个团队中离开，寻找更适合自己发展的团对。
二、欲速则不达
不良习惯：你不需要真正地理解那块代码，它只要能够工作就可以了。哦，它需要一个小小的调整。只要在结果中再加上几行代码，它就可以工作了。干吧！就把那几行代码加进去，它应该可以工作。
良策：不要坠入快速的简单修复中。要投入时间和精力保持代码的整洁，敞亮。
切身感受：在项目中，代码应该很亮堂的，不应该有黑暗死角。你也许不知道每块代码的每个细节，或者每个算法的每个步骤，但是你对整体的相关知识有很好的了解。没有任何一块代码被警戒线或者“切勿入内”的标志隔离开。
平衡艺术：
- 你必须理解一块代码是如何工作的，但是不一定需要成为一位专家。只要你能使用它进行有效的工作就足够了，不需要把它当作毕生事业。
- 如果有一位团队成员宣布，有一块代码其他人都很难看懂，这就意味着任何人（包括原作者）都很难维护它。请让它变得简单些。
- 不要急于修复没能真正理解的代码。这种+1/-1的病症始于无形，但是很快就会让代码一团糟。要解决真正的问题，不要治标不治本。
- 所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码功能，这样就可以理解系统各个功能块之间是如何交互的。
- 如果系统的代码已经恶化，可以阅读习惯四。
三、对事不对人
不良习惯：你在这个设计上投入很多精力，为它付出很多心血。你坚信它比其他任何人的设计都棒。别听他们的，他们只会把问题变得更糟糕。
良策：对事不对人。让我们骄傲的应该是解决问题，而不是比较谁的主意更好。
切身感受：一个团队能够很公正地讨论一些方案的优点，你不会因为拒绝了有太多缺陷的方案而伤害别人，也不会因为采纳了某个不甚完美（但是更好的）解决方案而被人嫉恨。
平衡艺术：
- 尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。
- 脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过吗是否经常发生？
- 也就是说，像这样说是不够的：我们不能采用这个方案，因为数据库厂商可能会倒闭。或者：用户绝对不会接受那个方案。你必须要批判那些场景发生的可能性多大。想要支持或者反驳一个观点，有时候你必须先做一个原型或者调查出它有多少的同意者或者反对者。
- 在开始寻找最好的解决方案之前，大家对“最好"的含义要达成共识，在开发者眼中的最好，不一定就是用户认为最好的，反之亦然。
- 只有更好，没有最好。尽管”最佳实践“这个术语到处在用，但实际上不存在”最佳“，只有在某个特定条件下更好的实践。
- 不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。
四、排除万难，奋勇前进
不良习惯：如果你发现其他人的代码有问题，只要你自己心里知道就可以了。毕竟，你不想伤害他们，或者惹来麻烦。如果他是你的老板，要更格外谨慎，只要按照他的命令执行就可以了。
良策：做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
切身感受：勇气会让人觉得有点不自在，提前鼓足勇气更需要魄力。但有些时候，它是扫除障碍的唯一途径，否则问题就会进一步恶化下去。鼓足你的勇气，这能让你从恐惧中解脱出来。
平衡艺术：
- 如果你说天快要塌下来了，但其他团队成员都不赞同。反思一下，也许你是正确的，但你没有解释清楚自己的理由。
- 如果你说天快要塌下来了，但其他团队成员都不赞同。认真考虑一下，他们也许是对的。
- 如果设计或者代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决办法，但代码仍然令人费解，唯一的解决办法是重构代码，让它可读性更强。如果你没有马上理解那段代码，不要轻易地否定和重构它们。那不是勇气，而是鲁莽。
- 当你勇敢地站出来时，如果受到了缺乏背景知识的抉择者的抵触，你需要用他们能够听懂的话语表达。”更清晰的代码“是无法打动生意人的。节约资金、获得更好的投资回报，避免诉讼以及增加用户利益，会让论点更有说服力。
- 如果你在压力下要对代码质量作出妥协，你可以指出，作为一名开发者，你没有职权毁坏公司的资产（所有代码)。