《高效程序员的45个习惯》摘要与心得
注：【】部分为笔者心得，非原文摘抄。
* 越早发现问题，就越容易修复问题。
* 敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
* 【小步规划、小步前进、小步修正，只要持续这个循环过程，就能积小步以至千里。】
* 为了节省项目的时间而走愚蠢的捷径是会付出巨大代价的。
* 敏捷依赖人，而不是依赖项目的甘特图和里程表。
* 【先选择目标，再制定路线。】
* 重点是做事。
* 勇于承认自己不知道答案。
* 一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。
* 只有理解了问题，才能进行有效的改变。
* 不要让开发人员完全孤立地编写代码。
* 投入时间和精力保持代码的整洁。
* 在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题。
* 负面的评论和态度会扼杀创新。
* 把重点放在解决问题上，而不是去极力证明谁的主意更好。
* 你不需要很出色才能起步，但是你必须岂不才能变得很出色。——Les Brown
* 能容纳自己并不接受的想法，表明你的头脑足够有学识。——亚里士多德
* 团队中的每个成员都应该意识到权衡的必要性。
* 设计充满了妥协，成功属于意识到这一点的团队。
* 鼓起勇气去面对，是扫除障碍的唯一途径，否则问题就会进一步恶化下去。
* 即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。——Will Rogers
* 如何才能跟上技术变化的步伐：
*
* 迭代和增量式的学习；
* 了解最新行情；
* 参加本地的用户组活动；
* 参加研讨会议；
* 如饥似渴地阅读。
* 不同才能和背景的人混在一起，是一个非常理想的学习环境。
* 优秀的管理者会重用那些能提高其他团队成员价值的人，因此帮助别人提高也直接有助于你的职业生涯。
* 相比硬件，开发者的时间才是紧缺和昂贵的资源。
* 在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。
* 不能只满足于别人告诉你的表面现象，要不停地提问直到你明白问题的根源。
* 更加具备远见，保持不同的开发节奏，这样敏捷项目的所有事情就不会突然同时发生，也不会随机发生，时间也不会不可预知。
* 真正的敌人是变化。
* 开发者及项目经理能做的一个最重要的决定就是：判断哪些是自己决定不了的，应然让企业主做决定。
* 开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
* 如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。——约翰·冯·诺依曼
* 好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。
* 【根据需要而不是根据喜好或流行趋势来选择技术。】
* 任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
* 在代码提交之前，找出可以避免破坏系统的方法。
* 保证你的系统随时可以编译、运行、测试并立即部署。
* 代码集成是主要的风险来源，要想规避这个风险，只有提早集成，持续而有规律地进行集成。
* 质量保证人员要像测试应用一样测试部署。
* 软件开发的成功就在于最后你离客户的期望有多近。
* 对付大项目，最理想的办法就是小步前进。
* 发布带有最小且可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。
* 让团队和客户一起，真正地在当前项目中工作，做具体实际的评估，由客户控制他们想要的功能和预算。
* 如果没有到位的单元测试，不要进行任何设计和代码修改。
* 测试驱动开发（Test Driven Development）可以让你编写代码之前深思熟虑将如何用它，这会迫使你去思考它的可用性和便利性，并让你的设计更加注重实效。
* 不同的环境，就有不同的问题。
* 为核心的业务逻辑创建测试。
* 每一个抱怨的背后都隐藏着一个问题。
* 代码要清晰地表达意图。
* 设计软件有两种方式：一种是设计得尽量简单，以至于明显没有缺陷；另一种则是设计得尽量复杂，以至于没有明显的缺陷。——Charles Antony Richard Hoare
* 代码清晰程度的优先级应该排在执行效率之前。
* 【“用代码说话”的第一步是编写“会说话”的代码。】
* 考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其它因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
* 在很短的编辑-构建-测试循环中编写代码。
* 除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
* 让类的功能尽量集中，让组件尽量小。
* 将警告视为错误。
* 我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。——伍德罗·威尔逊
* 架构师必须写代码。
* 实行代码集体所有制。
* 站着开会可以让团队达成共识，并保证会议言简意赅而不跑题。
* 新系统的设计者必须要亲自投入到实现中去。——Donald E. Knuth
* 给别人解决问题的机会。
* 绝不要提交尚未完成的代码。
* 要寻找深藏不露的Bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知办法。——《估算软件成本》Capers Jones
* 及时发布进展状况、新的想法和目前正在关注的主题，而不要等着别人来问项目状态如何。
* 一灯能除千年暗，一智能灭万年愚。——慧能
* 越早发现问题，就越容易修复问题。
* 敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
* 【小步规划、小步前进、小步修正，只要持续这个循环过程，就能积小步以至千里。】
* 为了节省项目的时间而走愚蠢的捷径是会付出巨大代价的。
* 敏捷依赖人，而不是依赖项目的甘特图和里程表。
* 【先选择目标，再制定路线。】
* 重点是做事。
* 勇于承认自己不知道答案。
* 一次又一次的快速修复，每一次都不探究问题的根源，久而久之就形成了一个危险的沼泽地，最终会吞噬整个项目的生命。
* 只有理解了问题，才能进行有效的改变。
* 不要让开发人员完全孤立地编写代码。
* 投入时间和精力保持代码的整洁。
* 在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题。
* 负面的评论和态度会扼杀创新。
* 把重点放在解决问题上，而不是去极力证明谁的主意更好。
* 你不需要很出色才能起步，但是你必须岂不才能变得很出色。——Les Brown
* 能容纳自己并不接受的想法，表明你的头脑足够有学识。——亚里士多德
* 团队中的每个成员都应该意识到权衡的必要性。
* 设计充满了妥协，成功属于意识到这一点的团队。
* 鼓起勇气去面对，是扫除障碍的唯一途径，否则问题就会进一步恶化下去。
* 即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。——Will Rogers
* 如何才能跟上技术变化的步伐：
*
* 迭代和增量式的学习；
* 了解最新行情；
* 参加本地的用户组活动；
* 参加研讨会议；
* 如饥似渴地阅读。
* 不同才能和背景的人混在一起，是一个非常理想的学习环境。
* 优秀的管理者会重用那些能提高其他团队成员价值的人，因此帮助别人提高也直接有助于你的职业生涯。
* 相比硬件，开发者的时间才是紧缺和昂贵的资源。
* 在学习一门新技术的时候，多问问自己，是否把太多旧的态度和方法用在了新技术上。
* 不能只满足于别人告诉你的表面现象，要不停地提问直到你明白问题的根源。
* 更加具备远见，保持不同的开发节奏，这样敏捷项目的所有事情就不会突然同时发生，也不会随机发生，时间也不会不可预知。
* 真正的敌人是变化。
* 开发者及项目经理能做的一个最重要的决定就是：判断哪些是自己决定不了的，应然让企业主做决定。
* 开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
* 如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。——约翰·冯·诺依曼
* 好的设计应该是正确的，而不是精确的。也就是说，它描述的一切必须是正确的，不应该涉及不确定或者可能会发生变化的细节。
* 【根据需要而不是根据喜好或流行趋势来选择技术。】
* 任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
* 在代码提交之前，找出可以避免破坏系统的方法。
* 保证你的系统随时可以编译、运行、测试并立即部署。
* 代码集成是主要的风险来源，要想规避这个风险，只有提早集成，持续而有规律地进行集成。
* 质量保证人员要像测试应用一样测试部署。
* 软件开发的成功就在于最后你离客户的期望有多近。
* 对付大项目，最理想的办法就是小步前进。
* 发布带有最小且可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。
* 让团队和客户一起，真正地在当前项目中工作，做具体实际的评估，由客户控制他们想要的功能和预算。
* 如果没有到位的单元测试，不要进行任何设计和代码修改。
* 测试驱动开发（Test Driven Development）可以让你编写代码之前深思熟虑将如何用它，这会迫使你去思考它的可用性和便利性，并让你的设计更加注重实效。
* 不同的环境，就有不同的问题。
* 为核心的业务逻辑创建测试。
* 每一个抱怨的背后都隐藏着一个问题。
* 代码要清晰地表达意图。
* 设计软件有两种方式：一种是设计得尽量简单，以至于明显没有缺陷；另一种则是设计得尽量复杂，以至于没有明显的缺陷。——Charles Antony Richard Hoare
* 代码清晰程度的优先级应该排在执行效率之前。
* 【“用代码说话”的第一步是编写“会说话”的代码。】
* 考虑性能、便利性、生产力、成本和上市时间。如果性能表现足够了，就将注意力放在其它因素上。不要为了感觉上的性能提升或者设计的优雅，而将设计复杂化。
* 在很短的编辑-构建-测试循环中编写代码。
* 除非有不可辩驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
* 让类的功能尽量集中，让组件尽量小。
* 将警告视为错误。
* 我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。——伍德罗·威尔逊
* 架构师必须写代码。
* 实行代码集体所有制。
* 站着开会可以让团队达成共识，并保证会议言简意赅而不跑题。
* 新系统的设计者必须要亲自投入到实现中去。——Donald E. Knuth
* 给别人解决问题的机会。
* 绝不要提交尚未完成的代码。
* 要寻找深藏不露的Bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知办法。——《估算软件成本》Capers Jones
* 及时发布进展状况、新的想法和目前正在关注的主题，而不要等着别人来问项目状态如何。
* 一灯能除千年暗，一智能灭万年愚。——慧能
有关键情节透露
