[[133974]]

想要成為優秀的開發人員很難。那我們就來說說如何成為一個糟糕的開發人員！

只學一遍

想要實現功能，想要讓功能正常工作，呵呵，你的方法是不是這樣子的呢：

不接觸、不思考、也不去想能不能改善

為什么要我來解決問題？沒有損壞的部分就用不著修復了吧？進展程度慢，無所謂，代碼不可讀或者是從程序的其他部分復制粘貼來的，也無所謂，哪怕是摘自于一些見不得人的網站的，也可以。只要能解決問題，那就萬事大吉了。

照此推論，我們的做法是：不讀書，不讀博客、文章，不接受他人的見解，也不看網絡廣播。為什么要你來解決這個難題呢，很顯然你的知識是最匹配的，看上去非你不可，所以……你覺得根本用不著浪費時間——一旦掌握這知識之后，完全沒必要深入學習嘛！

順便說一句，你也不需要學習新的編程語言。 Groovy？ Clojure？ Scala？呸，通通都是騙人的！看看那些只會 COBOL 的家伙：不是依然干得風生水起么！

不要鉆研自己學到的東西

好吧，不管怎么說，你畢竟學到了點東西。在 StackOverflow 上搜索解決方案，偶然發現 Martin Fowler 的一篇文章講得還挺吸引人，又或者覺得過于無聊而將《The Clean Coder》束之高閣。

反正你學到什么都不要去鉆研。是的，只需要盲從這些死板的內容就可以了：不要去驗證這些知識的真假，也不要檢查它是否適合你的風格！凡事只學一遍哦親！

從不同的角度觀察，然后思考出一些獨特的見解……何苦呢，應用了，解決問題了，那就可以輕輕松松回家玩游戲了。以后的事以后再說，得過且過知道不？

不接受他人的見解和指導

這是顯而易見的，因為……難道他們的話就一定正確嗎？

你已經學會如何解決這個問題。并且很管用。那不就成了。別人憑什么質疑你的編碼方式？你也沒有必要去學習解決問題的其他途徑！

倚老賣老，喋喋不休什么的真心是太討厭了，還會傷害偶們的自我意識。所以，不要聽這些家伙的羅里吧嗦。

不需要讓你的代碼變得可讀

仔細想想：為什么要讓代碼變得可讀呢？說的好像我們還要常回去看看一樣？你的代碼已然是非常棒，又能工作，所以我們不需要再去碰觸它。

此外，對于計算機而言，它才不管這些代碼是否可讀呢，只要能運行程序就成。你的代碼不是為了方便其他程序員閱讀而寫的。事實上，***只有你能讀得懂，這樣這份工作就非你不可了，不是嗎？

不寫測試

Loser 才需要測試。測試是愚蠢者的墓志銘。

請相信自己的代碼是***的！你永遠不會犯錯誤——有也是因為編程語言有缺陷，或者是機器的錯。

如果代碼能在你的機器上運行，那么沒有理由不能在其他地方正常運行，永***久地正常運行。

除了寫代碼，其他的啥也別干

為什么要分析需求，了解業務，寫測試，學習如何在自己電腦之外的地方部署呢？

況且，這些事對你寫代碼一點好處也沒有，是吧？完成這些任務除了浪費時間，有幫助嗎？

不要幫助別人

不要幫助別人：讓他們自己想辦法。也許他們會問你是如何解決他們眼中的難題的，但是你為什么要多費唇舌呢？反正已經搞定了，不是嗎？

而且，搞不好那個程序員也和你一樣根本聽不進其他人的建議：“不接受他人的見解和指導”這一條，沒忘記吧？

幫助他人不但費時，還會讓你懷疑自己的知識和能力，這是不應該出現的情況。所以，各人自掃門前雪莫管他人瓦上霜。

結論

掌握了上述所有技巧，那么你就成功成為了一個糟糕的開發人員。糟糕但活得舒服的開發人員。別謝我！

為此干杯！

…

咦，你說你不想成為一個糟糕的開發人員？

好吧，但是首先，我要鄭重告訴你，這條路絕對會走得很艱難，請做好心理準備：

對于上面如何成為“糟糕開發人員”的技巧完全要反著來。沒錯，我指的是所有，每一條！
經常性地反省和自我批評：這有效嗎？為什么有效？為什么無效？還有沒有改進的可能呢？思考的過程或許會讓人無比頭大，但也會讓你不斷地進步。
閱讀 Robert C. Martin 寫得《The Clean Coder》。這不是在推銷。如果你有志于成為一名真正的專業開發人員，而不是糟糕的開發人員，它絕對對得起你花的每一分錢。

好了，現在就向著目標出發吧！