寫給新入行的同事們

最近跳槽了，老闆但願我留些心得體會。我想了幾天，零散總結了一點東西。若是寫的莫名其妙的，還望各位不要笑話。

1

首先說下軟件行業在我看來是怎麼回事。軟件行業是個很是年輕的行業，大概只有四五十年吧。四五十年是很短的，一個只有四五十年曆史的行業是很不成熟的。成熟的行業是個什麼樣子的呢，咱們能夠看看汽車、紡織和建築等等存在了成百上千年的行業，它們在製做工藝、產品質量、從業資質、銷售模式等等方面都有很是成熟的標準，符合標準的產品基本上都不會出現明顯的質量問題，也就是說這些行業的產品具備穩定可控的質量。反觀軟件行業，在質量控制方面還在摸索之中，沒人能保證軟件項目或產品必定能達到什麼水平。從瀑布模型到敏捷開發，從 CMM 到 Scrum 等等工具，人們都在摸索，在這個摸索過程當中，沒人能保證某個組織使用過的某個成功的軟件開發方式，必定能適用於其餘組織或其餘項目。這是第一個方面，軟件行業還沒找到生成可靠的產品的方式。而另外一方面，隨着近幾年智能手機平常化，軟件開始爆發式的侵入人們的生活，天天都有新的應用出現——急劇擴張的勢頭也是年輕行業的一個典型特徵。第三個方面，軟件行業內部的職位也在不斷變化，前端工程師在十年前大概還不存在，隨着職位劃分愈來愈多，全棧工程師的概念也被提出來探討。最後，新的技術不斷的出現並受到熱烈追捧，好比大數據和雲平臺，它們甚至已經成了軟件業中的一個小產業。總之，只要你關注下行業動態，就會發現這個行業天天都在變。這正是其年輕的象徵。

2

研究如何讓一個軟件團隊產生高質量的軟件，這樣的學問叫軟件工程。軟件工程是團隊運做的基礎，是公司運做的基礎，更是整個行業運做的基礎。不像技術那樣突飛猛進的更新，這種基礎性的東西發展是很慢的。三十多年前的《人月神話》每一年都再版，到如今仍然是程序員的必讀啓蒙書。還有一本《人件》也是必讀，前者告訴你軟件開發是什麼，後者告訴你程序員是什麼。它們跟《Thinking in Java》的區別在於後者是初中生都能看懂的純技術書，而前者只有成年人能看懂，它們是關於人的書。

3

有本書上說，最好的程序員要比最差的程序員強 28 倍。而實際上，最好的程序員薪水也拿不到是最差的程序員的 28 倍那麼高，因此老闆喜歡好的程序員——效率高，單位薪水卻相對低。好的程序員好在哪裏？可能存在不少方面，但我以爲最重要的一點是：手段多。在這世上，無論哪一個問題，解決的手段確定都不止一種。解決問題的手段越多，遇到問題的時候就越駕輕就熟，遊刃有餘，知道哪一種手段最適合解決當前的問題。比方說，用什麼數據庫？唰的手一揮，各類數據庫擺在面前來挑；用什麼處理 JSON？jackson，gson，fastjson 都擺在你面前讓你挑。怎麼讀 Excel？jxl，POI，隨你挑。用戶屬性多變怎麼辦？橫表，豎表，隨你挑。是吧，不慌不忙,臨危不懼，指點江山，遊刃有餘，這個小小的程序員揮手言語間就不經意的透露出一種王者霸氣。

嗯嗯，那麼怎麼積累這些手段？一方面是實際的工做經驗，但這遠遠不夠，更重要的是本身去找，凡是能幫助本身解決未來可能遇到的問題的框架，工具，類庫，都去用下熟悉下，那麼到了遇到問題的時候，就知道拿什麼工具去處理了。關注業界的動態，你會看到天天都有不少新的工具出現。其中有的能夠用來代替原有的工具，由於它們更好用，效率更高。

4

軟件工程是跟人有關的學問，但軟件開發自己仍是跟電腦打交道的。不是每一個人都適合跟電腦打交道，要跟它好好打交道的話，你得是一個冷靜客觀誠實的人，至少培養本身的這方面品質。

比方說冷靜，有的人不冷靜，不冷靜的人遇到問題就是慌的，腦子裏只想着一件事：

怎麼會這樣怎麼會這樣別這樣別這樣……

他們甚至但願時間能幫他們解決問題。說實話，在生活當中，確實很多問題靠時間就能解決——晾在一邊便可。但在軟件行業行不通，電腦的耐性絕對比你強。因此遇到問題第一個反應就是要找緣由，冷靜（下來）與其說是一個動做，不如說是在整個解決問題的過程當中都要始終保持的一種狀態。

第二個客觀是什麼意思呢？在電腦看來，全部的運行結果都是正常的，不存在對錯之分。若是你編寫的代碼行爲與你的預期不一致，那麼有兩種可能：要麼你寫了錯誤的語句（比方該加的時候減），要麼出現了你沒有預料到的情況（好比參與計算的某個條件是空的）。軟件運行的時候會遇到各類各樣的情況，對計算機來講沒有差異，成功和失敗都是正常的結果。而對某種情況是否處理，決定權在你手裏，你會根據本身的喜愛來決定。

第三個誠實。計算機是最誠實的，這點本該毫無疑問，但不知道爲何我總看到有人懷疑計算機。當計算機報告一個錯誤發生時，他不相信，他不去看錯誤信息，而是嘗試從別的地方找緣由，處處找緣由，就是不看錯誤信息。直到全部的嘗試都徒勞無功，他纔會看下到底哪裏錯了。我徹底沒辦法理解這種人內心是怎麼想的。

5

代碼是什麼，代碼是軟件開發的成果，是程序員心血的結晶。但它又是那麼的捉摸不透，我敢保證，每當你寫完一段代碼，端起杯子喝口水的時候，你都會不禁自主的思考兩個問題：

1. 這段代碼對嗎？
2. 這段代碼牛逼嗎？

剛入行的程序員對「代碼質量」是毫無概念的，但我仍是想嘗試說明一下什麼是代碼質量：

一段代碼，你假設它是一個故事。這個故事，有頭，有尾，有通過，有分支。程序員就是講故事的人。代碼質量好很差，就是故事說的好很差。有的程序員講出來的故事，別人半天看不懂，這樣的代碼就是低質量的。

高質量的代碼，或者說牛逼的代碼有什麼樣的標準呢？我介紹一個簡單的檢查方式，就是從新閱讀你的代碼，看可否作到：

1. 30 秒內看完並徹底理解。
2. 閱讀的過程當中只往下看，不會去從新看前面的內容。

不說必定要達到這個標準，也要以它爲努力的方向去寫代碼。關於代碼質量的書，推薦下面幾本：

• 《重構：改善既有代碼的設計》這本書主要介紹糟糕的代碼到底哪裏糟糕，以及如何改進；
• 《實現模式》這本書介紹代碼表達能力；
• 《設計本來》這本書介紹「設計」與「構思」自己是什麼樣的思惟活動，設計風格是怎麼回事，經驗在設計當中起什麼做用，一個已經完成的設計又會出現什麼樣的演化。

最後一本書很是的抽象，很是的裝逼，但你一旦理解了，就會發現它很是的有用！由於它幫助你審視本身的思考方式。一個程序員變得牛逼的過程，就是其思考方式不斷進化的過程。牛逼的書是一會兒看不懂的，只能每隔一段時間拿出來翻下，也許就能慢慢理解。

另外還有被稱爲 「設計模式六大原則」 的設計準則能夠用做對代碼質量的評價參考。

6

怎麼用 logger 框架寫日誌。經常使用的框架有 log4j，commons-logging 和 slf4j，它們的做用就是在日誌文件中記錄某個業務處理過程的狀態。日誌是很重要的，若是日誌記得好，咱們就能清楚的看到業務處理怎麼開始怎麼結束，前因後果都清楚；一旦出現 BUG 或故障，光靠看日誌就能獲得足夠的信息，定位問題出在哪裏。日誌記得很差，出了問題什麼日誌裏面都看不出，只能用別的更耗時間的手段來處理了。

如何記好的日誌，一個簡單的原則就是：每次出現分支的時候都記一條日誌，標明流程往哪一個分支走了。遵照和不遵照這個原則，你會感覺到天堂與地獄般的巨大的差異。

7

有兩句話絕對不要相信：

1. 代碼看不懂不要緊，能用就好了。
2. 全部的軟件都不過是增刪改查。

若是開發團隊中有成員堅決的抱有這樣的態度，項目負責人應該儘早將這種人驅離開發團隊。