關於編程，大學沒有傳授的10件事

我依然記得當我完成學業時，我是多麼的天真。那時我深信本身已經準備好進入任何一家軟件公司，並開始成爲一個頂級的開發人員。顯然，開始工做後沒多久我就意識到，還有不少事是我所不瞭解的。

　　在不斷吸收經驗的同時，我一直在努力學習那些我歷來沒有學過的，但倒是成爲優秀的開發人員所應瞭解的基本知識。如下是我但願本身能在學校就學到的10件事。

　　0. 咱們老是錯的

　　開發人員有着至關大的自我意識，包含了一些其餘的非技術性缺陷，這也正是爲何咱們很難發現咱們作錯了什麼。我看到過不少無休止的設計討論，開發人員不斷地發表本身的想法……呵呵！猜猜怎樣……咱們都錯了，惟一的區別就是咱們犯錯的離譜程度不一樣。

　　理解並接受這個事實很是重要，咱們只有這樣作了，才能敞開心胸去聽聽別人的意見，採用他們的想法，來得出一個更好的解決辦法。

　　1. 事情如有可能出錯，就必定會出錯

　　也就是說「但願驅動開發（hope driven development）」，若是你對於某些事並不肯定，若是你發現本身使用了「應該」這個詞，那你就麻煩了。

　　而這隻有一個解決方案，盡己所能去保證它不會出錯，這可能意味着你須要編寫一個測試、調試並驗證需求……

　　2. 全部的代碼都爛

　　在我抱怨那些我碰到過的代碼十年之久後，我得出了一個精闢的結論，全部的(包括我本身寫的)代碼，都爛。固然，爛仍是有等級之分的，但即使是我見過寫得最好的代碼，也是難以讀懂的。

　　這並不意味着把你的代碼寫得更好是沒有意義的，偏偏相反，最好和最壞的代碼仍是有天壤之別的。

　　3. 錯誤（Bug）總會存在

　　永遠存在！問題只在於要發現它困難與否。

　　4. 客戶最大

　　許多客戶並不在意你在方案中使用了哪些技術，應用程序需不須要作更多的事……或通俗上說，你是否使用了好的實踐方案。

　　也由於我能夠想象，要是我只說了前面那一段，我會收到多少惡評，讓我說得更清楚些……我想說的是，咱們永遠不該該忘記客戶的立場，有時候，開發人員爲了最佳實踐而在項目工程中過分堅持採用（某些）技術，但要記住，若這些技術沒法給客戶帶來價值，那就放棄吧！（編注：關於客戶，做者Alberto在其前幾篇文章《個人10個開發原則》和《程序員常犯的5個非技術性錯誤》都有提到，可見他對這一點的體會。）

　　5. 紙上談兵是行不通的

　　我曾認爲，我能夠在前期就把個人整個設計置於紙上，而後只要將缺漏處填上就好，但這樣根本行不通。

　　軟件開發是複雜的，若不親手去碰碰看，很難看到全部的實際層面以及它們之間的關係。所以，在前期保持規劃與設計是頗有用的，但不要過分堅持，也不要把設計圖表看成合約固守。

　　6. 少便是多

　　或者，你可能知道更好的說法是：「Keep it simple, stupid!」（保持簡單，KISS設計原則）。因此，若是沒有必要的就捨棄吧！由於要記住：「事情如有可能出錯，就必定會出錯。」（編注：除了KISS原則以外，此文還介紹了其餘一些軟件設計原則。）

　　7. 編寫代碼只是咱們所作工做的20%而已

　　請準備好，花80%的時間用於思考、調試、測試、開會、談話……而全部的其餘活動都是很是重要的，因此若要成爲一個優秀的軟件開發人員，你必須培養普遍而全面的技巧（Skill），而不只僅是技術（Technical）。

　　8. 客戶永遠不知道他/她想要的是什麼！

　　客戶如有需求，或是想法，可是他們不知道詳細狀況……軟件開發要作的工做就是，發現細節並去除全部的不肯定性，將這些需求轉換成客戶想要一個應用程序。

　　9. 已經有人作過了

　　因此不要再從新發明輪子，用谷歌找找看，或者更好的方法是，請教你的同事，不少時候他們可能都已經作了相同、或很是相似的事情。