[轉]高品質的工程代碼怎麼寫

標籤：自己   如何   查詢   目的   比較   系統設計   功能   規則   成績   

轉自：http://kb.cnblogs.com/page/558087/

 

之所以想起寫這篇文章，是因為最近看到的一個著名的開源項目在內部使用時的各種問題，不得不說，很多的開源的東西思想是不錯的，但離真正工程化都有不小的距離，所以沒什麼商業公司採用的開源產品如果要引入的話一定要謹慎，通常會有N多的坑等著你去填，而比較成功的開源項目的背後多數都會有商業公司在背後不斷的改進。

　　遙想我2000年開始學習寫asp代碼時，覺得寫代碼也不難呀，無非就是學學文法規則、庫就可以寫出來，記得有一次我實習面試的時候是讓我在一個下午左右的時間寫一個完整的留言板，那也就是刷刷刷就寫好了，但隨著後來工作，尤其是加入阿里以後，越來越明白高品質的工程代碼為什麼難寫。

　　在寫代碼初期，最關注的是如何用代碼實現需求，如果是僅僅實現業務需求的話，即使是剛上手的程式員，只要解題能力還OK，基本上都是可以寫出代碼來的。所以我自己一直認為數學成績是程式員的一個非常重要的要求，數學好的人通常解題和邏輯思維能力是還不錯的。

　　上面的這個基本的寫代碼的過程中，寫的更好的同學的體現會在對業務的深刻理解以及抽象上，寫出的代碼會具備一定的複用能力，這個在這裡不多加探討。

　　但代碼是不是實現了業務需求就結束了呢，其實遠沒有，這其實只是寫代碼的開始，除了正向的邏輯實現外，任何一個點的異常的分支邏輯怎麼處理才是工程化的代碼中更難處理的部分，這個問題在單機式的系統中會相對還好處理，在分布式的環境會變得非常的複雜，例如調用其他機器的功能逾時了，出錯了，到底該怎麼處理，這也是為什麼有了那麼多的分布式的理論的東西出來，在增加了異常分支的處理邏輯後，通常會發現這個時候正向邏輯的代碼在整個代碼的佔比中會大幅下降。

　　異常分支邏輯處理好後，通常還需要增加必要的日誌資訊，以便在出問題時方便排查，而不是到了要排查問題的時候，一點目前系統的狀況都搞不清楚，所以吃掉重要的異常資訊不拋出這種行為在寫代碼中是非常可恥的。

　　在處理好上面異常的相關動作後，代碼的健壯性也要處理好，這個主要指：

　　1. 自我保護能力

　　對外提供的介面是否具備足夠的自我保護能力，就是即使使用的人沒仔細看API文檔隨便亂用也不會導致系統出問題，這種案例非常的多，例如對外提供了一個批量查詢介面，結果使用者一下傳了一個裡面有上千個使用者id的數組，查詢一下直接把記憶體耗光，像這種情況下不能怪使用的人，而應該怪實現API的這一端的保護做的不夠好，按照這樣的標準去看，會發現開源的很多東西的API都不太合格。

　　還有一種就是能力保護，如果超出了處理的並發量的能力，這個時候會發生什麼。

　　2. 對資源的使用限制

　　這也是代碼新手或一些開源產品中做的比較差的地方，很容易出現規模一上去，資源使用量也一直漲，沒有限制，然後導致系統掛掉，很常見的案例是對線程池的使用，例如像Java中的Executors.newCachedThreadPool，這個介面很多人會用到，但很多用的人都沒有仔細想過會不會在某種情況下這裡建立出巨多的線程；還有例如用Map做cache，也沒考慮大小限制的問題，結果就是隨著資料量增長，某天突然就掛了。

　　健壯性是代碼中比較複雜的部分，通常也是比較展現代碼能力的部分，可能看起來就幾行代碼，但其實背後反映的差距是巨大的。

　　開源產品除了在健壯性上的差距外，通常還會出現的一個巨大差距就是整個系統的設計的伸縮能力，伸縮能力不夠的話通常會導致結構性的重構，另外常見的就是在並發的處理上不夠高效，例如鎖的合理使用、無鎖演算法的引入等等，而這些需要非常強的系統設計和代碼功底能力。

　　除了上面說的這些外，高品質的工程代碼還需要考慮可維護（例如監控資訊暴露）、安全性等，對我而言，我一直認為所謂的工程化其實就是把一些玩具性質的代碼變成可在商業系統中真正健壯啟動並執行代碼。

　　上面的內容寫的比較簡略，不過應該也能看出，對於高品質的工程代碼而言，其實實現商務邏輯只是其中佔比很小的一部分，甚至花的時間是相對最少的一部分，所以我確實非常贊同面試的時候讓同學寫代碼，這個時候很容易看出同學寫代碼的功力；有些時候為了考察同學寫代碼的熟練程度，我會問問IDE的快速鍵，或者讓手寫一段不是太複雜的代碼。

[轉]高品質的工程代碼怎麼寫