之前看过类似的书很快就忘了，这样的书，真正上班加入实际的项目开发中才有真正的感同身受。
切身体会。
做事
blame doesn‘t fix bugs。
在我们项目中出现问题的时候，经常容易不把解决问题放在最优先级，而是指责犯错者上面的纠缠，如果你说的话会让事态更复杂，这无疑是在问题火上浇油，宁可不说出这样的话
我们要问问自己为了解决这个问题，我能够做些什么。
真实场景，当项目中的员工未能按照约定的时间完成工作的时候，
我们更多是需要如何帮助他完成，而不是指责他效率比较低说这样伤人的话。
永远不要在会议中说出伤人的话，指责不会修复bug。
如果大部分团队成员（特别是开发领导者）的行为都不职业，你就应该主动从这个团队中离开，寻找更适合自己发展的团队。
真实场景，领导只会画大饼，只会告诉你这个完成这个项目很简单，只需要学习XX技术就可以了，而无法给你更多帮助，或者领导层已经混乱了，无法确定项目的进展，
你就应该离开，这是一个有远见的想法，没必要眼睁睁地看着自己陷入一个“死亡之旅”的项目中。
欲速则不达 Beware of land mines 防微杜渐
千里之提溃于蚁穴，一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成一个危险的沼泽地，最终会吞噬整个项目的生命。
不要坠入快速的简单修复之中，要投入时间和精力保持代码的整洁、敞亮，说明谁是优秀程序员，谁是拙劣的代码搬运工。
真实场景，我们经常会遇到这种情况，出现了一个bug，快速修复确实可以解决他，只要新加一行代码或者注释掉某行，它就可以工作，但是我们这样不假思索的改完代码真的好？
这样+1，-1的操作会留下隐患。
代码复审，不要让开发人员完全孤立地编写代码，花点时间确保团队成员写的代码是可读和可理解的。
场景，像公司的需求会议评审、功能实现评审、代码评审，这些真的能很好发现自己代码的问题，不要害怕自己出错，而应该积极的记录错误，并完善问题所在。
我们写的代码更多的是让别人能看明白和理解，而不是只有自己明白。
单元测试，帮助你自然地把代码分层，分成很多可管理、更清晰、更易于理解的小块（待续）
对事不对人
巧妙的提出问题，避免尴尬，
那样做很蠢（否定个人能力）
那样很蠢，你忘记考虑他要线程安全（之处明显的缺点，并否定其观点）
谢谢，先生，但是我想知道，如果两个用户同时登陆会发生什么情况（询问你的队友，并提出你的顾虑）
第三种方式还能巧妙避免是自己理解错误的尴尬，
排除万难，奋勇前进
当发现问题时，不要试图掩盖这些问题，而要有勇气的站起来，不是向别人抱怨代码有多么糟糕，而是给出相应的解决方案，重写原因，重写优点等等。
往往项目中会发现一些代码无法很好地重用，我们更多的是充满勇气的重构它，而不是复制修改，尽可能减少项目重复的代码。最近在项目中就犯了这样的错误。
做正确的事情，要诚实，要有勇气去说出实情，有时，这样做很困难，所以我们要有足够的勇气。