為什麼程式員總是寫糟糕的代碼？

我最近一直在想我們作為一個行業為什麼總是産出糟糕代碼的原因。

1.明顯原因……

我一下子想到的最明顯的原因是，有好的程式員，也有不那麼好的程式員，有的人技術水準高，有的人水準卻低，有人對這門技藝感興趣，但也有的人卻不願意在工作之外學習其他。

好了，我就不深入探讨了。

那麼是不是在這表層之下還有更多的問題呢？有沒有導緻糟糕代碼的根本性原因？我覺得有必要深入探究一下。

2.低預期……

對于這一點，衆所承認的是，我們在大學中，通過自學或書籍學到的東西，并不能比對現實世界的真正需求。

是以，可以想象初學者總是需要在工作中學習如何産出好的代碼。我們也相信，真正的程式設計知識隻能通過經驗累積才能獲得。因而，初學者甚至覺得他們能寫出的就是糟糕的代碼！

當初學者預期他們将産出品質不好的代碼，通常，那就是你将得到的結果！

雖然上述推理有部分是真理，但這個假設我不願意接受，原因很多，但主要是以下三個：

1. 期望低标準的職業生涯起點，也就是說品質變成了一個不重要的因素。低入口門檻的直接結果是低品質開發人員的大量湧入，并導緻下面的第2點。
2. 通過強迫他們和大多是低品質的開發者一起工作，我們讓那些關心工藝和對自己的工作品質感到自豪的人過得苦不堪言。
3. 上述兩個因素的結合導緻了我們現在這個狀況，每個人都認為他們會寫代碼，但是我們更信任如同品牌商品一樣的專業開發者。

我們得對初學者有更高的預期。試問，哪家醫院會聘用一個以前沒有做過手術的醫生，或者說，哪家航空公司會雇用一個不會緊急降落的飛行員？我們根本不能接受這樣的醫生和飛行駕駛員。那麼，為什麼軟體行業要接受低品質的程式員呢？

那麼，低品質開發者的根本原因是什麼呢？

3.程式設計書籍

幾天前，我正找一些我以前看過的舊書的時候，恰巧找到了幾本關于Java的書——一本針對學習Java的初學者，另一本針對于SCJP認證。對于接下來要講的話題，具體書名我就不說了。

不幸的是，初學者參考的那些書籍總是在不經意間準确描繪了差的代碼應該是怎麼樣的。

任何程式設計語言的初學者書籍，大多滿是壞的代碼。如《Clean Code》和《Pragmatic Programming》就是如此，但這些書籍卻被廣泛用于教導大多數的初學者。

一些糟糕代碼的例子……

3.1糟糕地命名類、變量和方法

i, ii, j, k用于循環；SampleChapter1用于類名；等等

3.2不分離關注點

三頁長的main()方法囊括了一切，沒有根據責任不同分成不同的方法。

3.3不好的編碼實踐

沒有如包含驗證或異常處理這樣好的編碼實踐。相反，他們通常使用一個包含所有代碼在類内的大的通用的try()..catch(Exception e)塊。

大量使用if-else，switch，goto語句等。

3.4走捷徑

這些書籍還需要擺脫“快速修複”的程式設計風格。例如，方法中有10個參數并不罕見。

需要做兩種類型的計算？沒問題，傳遞一個布爾參數，并添加一個if-else結構即可。需要增加新的功能呢？哈哈，那就添加更多的代碼到那個已經長達兩頁的方法中去！這裡隻舉幾個走捷徑例子。

學習程式設計的一個好方法是掌握語言的文法，高效開發所需的工具，以及組成代碼的元件和子產品的設計——以這種順序。

不幸的是，大多數書籍停留在文法上，而不觸及工具和設計改進的話題。雖然這些書的意圖和目的是要教導程式設計語言的文法，但是閱讀的人同時也會學習編碼風格和方法。

在初學者學習代碼的時候，教導他們明白一件事非常重要，那就是，代碼是為其他人閱讀和了解而寫的，而并非是為了編碼器而寫。

希望你們中的一些人在閱讀了這篇文章之後，如果将來寫程式設計書籍的話，請務必要記得在書中寫好代碼！學着産出高品質的代碼不應該隻限于專家級的書籍中，而應該是每本關于程式設計的書的重要組成部分！

當初學者用來學習的書籍中包含低品質的代碼時，我們怎麼能期待學自這些書的人會産出高品質的代碼呢？