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

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

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

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

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

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的三次法则

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