一、最佳實踐？不如多用用你的大腦 唯一的“最佳實踐”並不是使用各種各樣被前人總結過的各種設計方法、模式，框架，那些著名的方法、模式、框架只代碼贊同他們的人多，並不代表他們適合你，你應該更多的去使用你的大腦，獨立地思考那些方法、模式、框架出現的原因和其背後的想法和思想，那纔是“最佳實踐”。事實上來說，那些所謂的“最佳實踐”只不過是限制那些糟糕的程序員們的破壞力。 二、學會享受編程帶來的快樂 如果你對編程沒有感到一種快樂，沒有在你空閒的時候去以一種的輕鬆的方式去生活，無論是編程，還是運動，還是去旅遊，只要你在沒有從中感到輕鬆和愉快，那麼你只不過是在應付它們。而你無時無刻不紮在程序堆中，這樣下來，就算是你是一個非常聰明，非常有才華的人，你也不會成爲一個優秀的編程員，要麼只會平平凡凡，要麼只會整天紮在技術中成爲書呆子。當然，這個觀點是有爭議，熱情和能力的差距也是很大的。不過我們可以從中汲取其正面的觀點。 三、糟糕的註釋毫無意義 註釋應該是註釋Why，而不是How和What，就像《程序員的十大技術煩惱》中所說，代碼告訴你How，而註釋應該告訴你Why。但大多數的程序並不知道什麼是好的註釋，那些註釋其實和Code是重複的，毫無意義。 四、XML被高估了 XML可能被高估了。XML對於Web上的應用是不錯的，但是我們把其用到了各種地方，好像沒有XML，我們都不會編程了。 五、不是所有的程序員都一樣 這是那些“初級”經理或是流程愛犯的錯，他們總是認爲，DeveloperA == DeveloperB，只要他們的Title一樣，他們以爲他們的能力、工作速度、解決問題的方法，掌握的技能等等都是一樣的。而且在某些時候，就算是最差的程序員，因爲Title，他們也會認爲其比別人強十倍，這就是很表面的愚蠢的管理。 六、“Google”會害死你 不可否認，查找知識是一種能力。但Google只會給你知識，並不會教給你技能。那裏只有“魚”，沒有“漁”，過度的使用Google，只會讓你越來越離不開他，你越來越需要要它立馬告訴你答案，而你越來越不會自己去思考，自己去探索，去專研。如果KFC快餐是垃圾食品，對我們的身體沒有好處，那麼使用Google也一種快餐文化，對我們的智力發展大大的沒有好處。因爲我們過度地關注了答案，而不是尋找答案的技術和過程。 七、只懂一種語言的程序員不是好程序員 如果你只懂一種語言，準確的說，如果你只懂一類語類，如：Java和C#，PHP和Perl，那麼，你將會被侷限起來，只有瞭解了各種各樣的語言，瞭解了不同語言的不同方法 ，你纔會有比較，只有了比較，你纔會明白各種語言的長處和短處，纔會讓你有更爲成熟的觀點，而且不整天和別的程序員在網上鬥嘴爭論：是Windows好還是Unix好，是C好還是C++好，有這點工夫能幹好多事了。世界因爲不同而精彩，只知道事物的一面是有害的。 八、不要保守，學着嘗試新東西 你的工作不是保守，那種教會徒弟，餓死師父的想法，是相當短淺的。因爲，在計算機世界裏，你掌握的老技術越多，你就越沒用，因爲技術更新的太快。你對工作越保守，這個工作就越來越離不開你，你就越不越不能抽身去學新的東西，你也就越來越OUT了。記住：如果你是不可替代的，那麼你就很難再去成長。 九、“設計模式”弊大於利 很多程序員把設計模式奉爲天神，他們過度的追求設計模式，以至都都忘了需求是什麼，結果整個系統設計被設計模式搞得亂七八糟，我們叫這種編程爲“設計模式驅動編程”，正如第一點所說，如果你不懂得用自己的大腦思考的話，知其然，不知所以然的話，那麼你不但得不到其好處，反而受其所累。 十、單元測試不會幫助你寫出更好的代碼 其實，單元測試的主要目的是，爲了防止你不會因爲一個改動而引入Bug，但這並不會讓你能寫出更好的代碼。這隻會讓你寫出不會出錯的代碼。同第一點，這樣的方法，只不過是防止糟糕的程序員，而並不是讓程序員或代碼質量更有長進。反而，程序員通常會借用“單元測試”來爲自己代碼做辯解，而此時，單元測試報告成了一種託辭。
最有爭議的十大編程觀點
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.