高效程序员100条建议总结
1 不管路走多远，错了就要重新返回。
2 开发要持续不断，切勿时断时续。
3 持续注入能量。
4 敏捷开发就是一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
5 先难后易。
我们首先要解决困难的问题，把简单的问题留到最后。
6 选定了要走的路，就是选定了它通往的目的地。
7 指责不能修复bug。
把矛头对准问题的解决办法，而不是人。这是真正有用处的正面效应。
8 防微杜渐。
9 不要孤立地编码。
10 使用单元测试。
单元测试帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。
11 不要坠入快速的简单修复之中。
要投入时间和精力保持代码的整洁、敞亮。
12 消极扼杀创新。
负面的评论和态度扼杀了创新。
13 有效的特殊技术：
设定最终期限。
逆向思维。
设立仲裁人。
支持已经做出的决定。
14 对事不对人。
让我们骄傲的应该是解决了问题，而不是比较出谁的主意更好。
15 做正确的事。
要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要有足够的勇气。
16 即使你已经在正确的轨道上，但如果只是停止不前，也仍然会被淘汰出局。
17 如何才能跟上技术的步伐呢？
迭代和增量式的学习。
了解最新行情。
参加本地的用户组活动。
参加研讨会议。
如饥似渴地阅读。
跟踪技术变化。
18 提供你和团队学习的更好平台。
通过午餐会议可以增进每个人的知识和技能，并帮助大家聚集一起进行沟通交流。
19 根深蒂固的习惯不可能轻易地就丢弃掉。
20 学习新的东西，丢弃旧的东西。
在学习一门新技术的时候，要丢弃会阻止你前进的旧习惯。毕竟，汽车要比马车车厢强得多。
21 不停地问为什么。
不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
22 解决任务，在事情变得一团糟之前。
保持事件之间稳定重复的间隔，更容易解决常见的重复任务。
23 没有任何计划在遇敌后还能继续执行。
固守昨天的计划而无视环境的变化会带来灾难。
24 决定什么不该决定。
25 让你的客户做决定。
开发者、经理或者业务分析师不应该做业务方面的决定。用业务负责人能够理解的语言，向他们详细解释遇到的问题，并让他们做决定。
26 设计满足实现即可，不必过于详细。
27 如果你自己都不清楚所谈论的东西，就根本不可能精确地描述它。
28 战略设计与战术设计。
29 好设计是一张地图，它也会进化。好的设计应该是正确的，而不是精确的。
30 盲目地为项目选择技术框架，就好比是为了少交税而生孩子。
31 不要开发你能下载到的东西。
你的代码写的越少，需要维护的东西就越少。
32 新技术就应该像新的工具，可以帮助你更好地工作，它自己不应该成为你的工作。
33 已提交的代码应该随时可以行动。
任何时候只要你没有准备好，那就是敌人进攻你的最佳时机。
34 保持你的项目时刻可以发布。
保证你的系统随时可以编译、运行、测试并立即部署。
35 千万不能让系统既不可以发布，又不可以撤销。
36 绝不要做大爆炸式的集成。
37 提早集成，频繁集成。
代码集成是主要的风险来源。要想避免这个风险，只有提早集成，持续而又规律地进行集成。
38 质量保证人员应该测试部署过程。
39 一开始就实现自动化部署应用。
使用部署系统安装你的应用，在不同的机器上用不同的配置文件测试依赖的问题。质量保证人员要像测试应用一样测试部署。
40 需求就像是流动着的油墨。
41 给客户演示所完成功能的时间与得到客户需求的时间间隔越长，那么你就会离最初需求越来越远。
42 清晰可见的开发。在开发的时候，要保持应用可见。
每隔一周或者两周，邀请所有客户，给他们演示最新完成的功能，积极获得他们的反馈。
43 演示是用来让客户提出反馈的，有助于驾驭项目的方向。
如果缺少功能或者稳定性的时候，不应该拿来演示，那只能让人生气。
44 给我一份详细的长期计划，我就会给你一个注定完蛋的项目。
45 增量开发。
发布带有最小却可用功能块的产品。每个增量开发中，使用1~4周左右迭代周期。短迭代让人感觉非常专注且具效率。
46 固定的价格就是保证要背叛承诺。
软件项目天生就是变化无常的，不可重复。如果要提前给出一个固定的价格，就几乎肯定不能遵守开发上的承诺。
47 基于真实工作的评估。
让团队和客户一起，真正地在当前项目中工作，做具体实际的评估。由客户控制他们要的功能和预算。
48 一步行动，胜过千万专家的意见。
49 编写能产生反馈的代码。
50 单元测试的理由：
单元测试能及时提供反馈。
单元测试让你的代码更加强壮。
单元测试是有用的测试工具。
单元测试是让你自信的后台。
单元测试是解决问题时的探测器。
单元测试是可信的文档。
单元测试是学习工具。
51 使用自动化的单元测试。
好的单元测试能够为你的代码问题提供及时的警报。如果没有到位的单元测试，不要进行任何设计和代码修改。
52 编码之前，先写测试。
53 好的设计并不意味着需要更多的类。
54 先用它再实现它。
将TDD作为设计工具，它会为你带来更简单更有效的设计。
55 使用自动化会节省时间。
56 不同环境，就有不同问题。
使用持续集成工具，在每一种支持的平台和环境中运行单元测试。要积极地寻找问题，而不是等问题来找你。
57 为核心的业务逻辑创建测试。
让你的客户单独验证这些测试，要让它们像一般的测试一样可以自动运行。
58 专注于你的方向。
59 度量剩下的工作量。
不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
60 每一个抱怨的背后都隐藏了一个事实。
找出真相，修复真正的问题。
61 没有愚蠢的用户。
只有愚蠢、自大的开发人员。
62 如果代码问题解决不了，也许可以考虑通过修改文档或者培训来弥补。
63 任何一个笨蛋都能够让事情变得越来越笨重、越来越复杂、越来越极端。
需要天才的指点以及许多的勇气，才能让事情向相反的方向发展。
64 设计软件有两种方式。
一种是设计得尽量简单，并且明显没有缺陷。另一种方式是设计得尽量复杂，并且没有明显的缺陷。
65 PIE原则：
代码必须明确说出你的意图，并且必须富有表达力。这样可以让代码更易于被别人阅读和理解。代码不让人迷惑，也就减少了发生潜在错误的可能。一言以蔽之，代码应意图清晰，表达明确。
66 要编写清晰的而不是讨巧的代码。
向代码阅读着明确表明你的意图。可读性差的代码一点都不聪明。
67 不要明日复明日。
如果现在不做的话，以后你也不会做的。
68 有意图的编程并不是意味着创建更多的类或者类型。这不是进行过分抽象的理由。
69 不要用注释包裹你的代码。
70 良好的命名可以向读者传递大量的正确信息。
要尽量避免使用神秘的变量名。
71 用注释沟通。
使用细心选择的、有意义的命名。用注释描述代码意图和约束。注释不能替代优秀的代码。
72 没有最佳的解决方案。
73 动态评估权衡。
考虑性能、便利性、生产力、成本和上市时间。
74 过早的优化是万恶之源。
75 要休息的话，就好好的休息。休息时请远离键盘。
76 简单不是简陋。
直觉不是魔术，它是经验和技能的厚积薄发之产物。
77 开发可以工作的、最简单的解决方案。
除非有不可辨驳的原因，否则不要使用模式、原则和高难度技术之类的东西。
78 简单、可读性高的代码。
79 让类的功能尽量集中，让组件尽量小。
要避免创建很大的类或组件，也不要创建无所不包的大杂烩类。
80 当你需要一只袜子的时候，一盒棉线不能带给你任何帮助。
81 将命令与查询分离开来。
82 告知，不要询问。
不要抢别的对象或是组件的工作。告诉它做什么，然后盯着你自己的职责就好了。
83 针对is-a关系使用集成；针对has-a或uses-a关系使用委托。
84 相对继承来说，委托更加灵活，适应力更强。
85 通过替换代码来扩展系统。
通过替换遵循接口契约的类，来添加并改进功能特性。要多使用委托而不是继承。
86 你也许会对木匠那毫无差错的工作印象深刻。
但我向你保证，事实不是这样的。真正的高手只是知道如何亡羊补牢。
87 不要在同一处跌倒两次。
88 维护一个问题及其解决方案的日志。
保留解决方案是修复问题过程的一部分，以后发生相同或类似的问题时，就可以很快找到并使用了。
89 警告就是错误。
将警告视为错误。签入带有警告的代码，就跟签入有错误或者没有通过测试的代码一样，都是极差的做法。签入构建工具中的代码不应该产生任何警告信息。
90 用原型进行分离。
91 对问题各个击破。
在解决问题时，要将问题域与其周边隔离开，特别是在大型应用中。
92 处理或是向上传播所有的异常。
不要将它们压制不管，就算是临时这样做也不行。在写代码时要估计到会发生的问题。
93 展示有用的错误信息。
提供更易于查找错误细节的方式。发生问题时，要展示出尽量多的支持细节，不过别让用户陷入其中。
94 使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。
95 不可能在PowerPoint幻灯片中进行编程。
96 教学相长。
成为指导者。分享自己的知识很有趣—付出的同时便有收获。还可以激励别人获得更好的成果，而且提升了整个团队的实力。
97 准备好后再共享代码。
绝不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码，对项目来说，应被视作玩忽职守的犯罪行为。
98 做代码复查。复查所有代码。
99 及时通报进展与问题。
100 一灯能除千年暗，一智能灭万年愚。