高效程序员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 一灯能除千年暗，一智能灭万年愚。