软件行业先辈们的吐血的经验总结，不看会后悔一辈子，逐步更新中。。。。

很多时候，我们犯下了很多的错误，但是我们没有去总结，我们为什么犯这样的错误；因此后果是，我们不断经常犯同样的错误；

貌似我们很努力，但是却收效甚微；为什么么底是为什么很多，但是有一个原因却很容易被忽略，那就是

我们没有站在巨人的肩膀上. 我们把软件前辈大佬们，用毕生心血和经验的一些总结当成是耳边风，感觉和我们无关，而正是

这些总结，可能在某个偶然的时刻，改变我们的程序员的一生的命运。。。。。。。。。。

1.别给糟糕的代码加注释–重新写吧。—Brian W.Kernighan 和 P.J.Plaugher

2.如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来，
像是专为解决那个问题而存在的话，就可以称之为漂亮的代码—Ward Cunningham，Wiki的发明者

3.我喜欢优雅和高效的代码。代码逻辑直接了当，叫缺陷难以隐藏；尽量减少依赖关系，使之便于维护；
根据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没有规矩的优化，搞出一堆混乱来。
整洁代码只做好一件事情。Bjarne Stroustrup C++语言发明者

4.对象是过程的抽象，线程是调度的抽象。—James O Coplien

5.The Primary Goals of API Design：Solve my problem, with minimal effort from me, and don’t get in my way.
—Jakob Jenkov 

6.   上一个8年程序员的11条工作心得 
解决bug的思路，思维不要太狭隘，不要局限在一两个方向。
  道路前面有个坑， 汽车怎么才能不陷入坑里。
  6.1.拉一车土过来，把坑填上。————–改善自己的缺陷。
  6.2.增强汽车的能力，让汽车能进入坑里，然后再从坑里爬出来。增加对方的能力
  6.3.增强汽车的能力，让汽车变成坦克，能够跨越大坑。增加对方的能力
  6.4.在坑的前面树一个牌子，”前方有坑，无法通过”.(告知可能有问题）。提示用户后果
  6.5.在坑的前面树一排墙。“前方有坑，此路不通”（明确不让通过）。限制功能
  6.6在坑的前面改道。   绕过问题.
  6.7.在坑的面前安排一个交警。告诉客户怎么通过坑，避免陷入到坑里。指导用户小心使用
  6.8.在坑的上面铺上一层钢板。————–改善自己的缺陷。
  6.9.只让有超强能力的汽车通过。限制部分汽车通过。限制部分用户使用
  6.10.在坑的旁边，安排几个民工，当汽车掉进坑里时，几个民工将汽车拉出来。事后解决。
  6.11.修改坑，将坑改成一个上坡和一个下坡。

7.Apache项目的Rich Bowen所说，

“一个正确的、功能齐全的、经过测试的、有注释的例子，胜过一页的乏味介绍。” 

8.重构：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，
降低其修改成本。

9.Kent Beck

我不是一个伟大的程序员，我只是一个有着一些优秀习惯的好程序员。

10. Don Robert的三次法则

对于重复的代码，第一次做某事的时候只管去做；第二次做类似的事就会产生反感，但是无论如何还是可以去做；第三次在做类似的事情的时候，你就应该去重构。