轉：十條不錯的編程觀點。（出處：酷 殼 – CoolShell.cn）

標籤：

在Stack Overflow上有這樣的一個貼子《What’s your most controversial programming opinion?》，翻譯成中文就是“你認為最有爭議的編程觀點是什嗎？”，不過，在400多個主回貼，以及千把個子回貼中，好像並不是很有爭議，而是令人相當的茅塞頓開，下面羅列一些，並通過我自己的經曆和理解發揮了一些，希望對你有協助。

1） The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”並不是使用各種各樣被前人總結過的各種設計方法、模式，架構，那些著名的方法、模式、架構只代碼贊同他們的人多，並不代表他們適合你， 你應該更多的去使用你的大腦，獨立地思考那些方法、模式、架構出現的原因和其背後的想法和思想，那才是“best practice”。事實上來說，那些所謂的“Best Practice”只不過是限制那些糟糕的程式員們的破壞力。

2）Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你對編程沒有感到一種快樂，沒有在你閒置時候去以一種的娛樂方式去生活，無論是編程，還是運動，還是去旅遊，那麼你只不過是在應付你的工作， 無時無刻不紮在程式堆中，這樣下來，就算是你是一個非常聰明，非常有才華的人，你也不會成為一個優秀的編程員，要麼只會平平凡凡，要麼只會整天紮在技術中 成為書獃子。當然，這個觀點是有爭議，熱情和能力的差距也是很大的。不過我們可以從中汲取其正面的觀點。

3）Most comments in code are in fact a pernicious form of code duplication.

注釋應該是注釋Why，而不是How和What，參看《惹惱程式員的十件事》，代碼告訴你How，而注釋應該告訴你Why。但大多數的程式並不知道什麼是好的注釋，那些注釋其實和code是重複的，毫無意義。

 

4）XML is highly overrated

XML可能被高估了。XML對於Web上的應用是不錯的，但是我們把其用到了各種地方，好像沒有XML，我們都不會編程了。

5）Not all programmers are created equal

這是那些junior經理或是流程愛犯的錯，他們總是認為，DeveloperA == DeveloperB，只要他們的title一樣，他們以為他們的能力、工作速度、解決問題的方法，掌握的技能等等都是一樣的。呵呵。更扯的是，在某些時 候，就算是最差的程式員，他們也會認為其比別人強十倍，這就是現代的SB管理。

6）”Googling it” is okay!

Google只會給你知識，並不會教給你技能。那裡只有“魚”，沒有“漁”，過度的使用Google，只會讓你越來越離不開他，你越來越去要去立馬 告訴你答案，而你越來越不會自己去思考，自己去探索，去專研。如果KFC快餐是垃圾食品對我們的身體沒有好處，那麼使用Google也一種快餐文化對我們 的智力發展大大的沒有好處。

7）If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一種語言，準確的說，如果你只懂一類語類，如：Java和C#，PHP和Perl，那麼，你將會被局限起來，只有瞭解了各種各樣的語言， 瞭解了不同語言的不同方法 ，你才會有比較，只有了比較，你才會明白各種語言的長處和短處，才會讓你有更為成熟的觀點，而且不整天和別的程式在網上鬥嘴爭論是Windows好還是 Unix好，是C好還是C++好，有這點工夫能幹好多事了。世界因為不同而精彩，只知道事物的一面是有害的。

8）Your job is to put yourself out of work.

你的工作不是保守，那種教會徒弟，餓死師父的想法，不但是相當短淺的，而且還是相當腦殘的。因為，在電腦世界裡，你掌握的老技術越多，你就越沒 用，因為技術更新的太快。你對工作越保守，這個工作就越來越離不開你，你就越不越不能抽身去學新的東西，你也就越來越OUT了。記住：If you can’t be replaced then you can’t be promoted!

9）Design patterns are hurting good design more than they’re helping it.

很多程式員把設計模式奉為天神，他們過度的追求設計模式以至都都忘了需求是什麼，結果整個系統設計被設計模式搞得亂七八糟，我們叫這種編程為“設計模式驅動編程”，正如第一點所說，如果你不懂得用自己的大腦思考的話，知其然，不知所以然的話，那麼你不但得不到其好處，反而受其所累。

10）Unit Testing won’t help you write good code

準確地說，我們可以認為這是Test-Driven開發，其實，這種開發就是先寫unit test case，這樣的開發方式的主要目的是，為了防止你不會因為一個改動而引入Bug，但這並不會讓你能寫出更好的代碼。這隻會讓你寫出不會出錯的代碼。同第 一點，這樣的方法，只不過是防止糟糕的程式員，而並不是讓程式員或代碼品質更有長進。反而，通過Unit Test會為程式員的為自己代碼做辯解的一種託辭。

最後，順便說一下，以前去那個敏捷的公司面試，發現那個公司的某些技術人員中毒不淺，具體表現在上述的1）9）10）觀點上。

（轉載：作者和出處 酷 殼 – CoolShell.cn ）

轉：十條不錯的編程觀點。（出處：酷 殼 – CoolShell.cn）