之所以想起寫(xiě)這篇文章，是因?yàn)樽罱吹降囊粋€(gè)著名的開(kāi)源項(xiàng)目在內(nèi)部使用時(shí)的各種問(wèn)題，不得不說(shuō)，很多的開(kāi)源的東西思想是不錯(cuò)的，但離真正工程化都有不小的距離，所以沒(méi)什么商業(yè)公司采用的開(kāi)源產(chǎn)品如果要引入的話一定要慎重，通常會(huì)有N多的坑等著你去填，而比較成功的開(kāi)源項(xiàng)目的背后多數(shù)都會(huì)有商業(yè)公司在背后不斷的改進(jìn)。

遙想我00年開(kāi)始學(xué)習(xí)寫(xiě)asp代碼時(shí)，覺(jué)得寫(xiě)代碼也不難呀，無(wú)非就是學(xué)學(xué)語(yǔ)法規(guī)則、庫(kù)就可以寫(xiě)出來(lái)，記得有一次我實(shí)習(xí)面試的時(shí)候是讓我在一個(gè)下午左右的時(shí)間寫(xiě)一個(gè)完整的留言板，那也就是刷刷刷就寫(xiě)好了，但隨著后來(lái)工作，尤其是加入阿里以后，越來(lái)越明白高質(zhì)量的工程代碼為什么難寫(xiě)。

在寫(xiě)代碼初期，最關(guān)注的是如何用代碼實(shí)現(xiàn)需求，如果是僅僅實(shí)現(xiàn)業(yè)務(wù)需求的話，即使是剛上手的程序員，只要解題能力還OK，基本上都是可以寫(xiě)出代碼來(lái)的，所以我自己一直認(rèn)為數(shù)學(xué)成績(jī)是程序員的一個(gè)非常重要的要求，數(shù)學(xué)好的人通常解題和邏輯思維能力是還不錯(cuò)的。

上面的這個(gè)基本的寫(xiě)代碼的過(guò)程中，寫(xiě)的更好的同學(xué)的體現(xiàn)會(huì)在對(duì)業(yè)務(wù)的深刻理解以及抽象上，寫(xiě)出的代碼會(huì)具備一定的復(fù)用能力，這個(gè)在這里不多加探討。

但代碼是不是實(shí)現(xiàn)了業(yè)務(wù)需求就結(jié)束了呢，其實(shí)遠(yuǎn)沒(méi)有，這其實(shí)只是寫(xiě)代碼的開(kāi)始，除了正向的邏輯實(shí)現(xiàn)外，任何一個(gè)點(diǎn)的異常的分支邏輯怎么處理才是工程化的代碼中更難處理的部分，這個(gè)問(wèn)題在單機(jī)式的系統(tǒng)中會(huì)相對(duì)還好處理，在分布式的環(huán)境會(huì)變得非常的復(fù)雜，例如調(diào)用其他機(jī)器的功能超時(shí)了，出錯(cuò)了，到底該怎么處理，這也是為什么有了那么多的分布式的理論的東西出來(lái)，在增加了異常分支的處理邏輯后，通常會(huì)發(fā)現(xiàn)這個(gè)時(shí)候正向邏輯的代碼在整個(gè)代碼的占比中會(huì)大幅下降。

異常分支邏輯處理好后，通常還需要增加必要的日志信息，以便在出問(wèn)題時(shí)方便排查，而不是到了要排查問(wèn)題的時(shí)候，一點(diǎn)目前系統(tǒng)的狀況都搞不清楚，所以吃掉重要的異常信息不拋出這種行為在寫(xiě)代碼中是非常可恥的。

在處理好上面異常的相關(guān)動(dòng)作后，代碼的健壯性也要處理好，這個(gè)主要指：

1. 自我保護(hù)能力

對(duì)外提供的接口是否具備足夠的自我保護(hù)能力，就是即使使用的人沒(méi)仔細(xì)看API文檔隨便亂用也不會(huì)導(dǎo)致系統(tǒng)出問(wèn)題，這種案例非常的多，例如對(duì)外提供了一個(gè)批量查詢(xún)接口，結(jié)果用戶(hù)一下傳了一個(gè)里面有上千個(gè)用戶(hù)id的數(shù)組，查詢(xún)一下直接把內(nèi)存耗光，像這種情況下不能怪使用的人，而應(yīng)該怪實(shí)現(xiàn)API的這一端的保護(hù)做的不夠好，按照這樣的標(biāo)準(zhǔn)去看，會(huì)發(fā)現(xiàn)開(kāi)源的很多東西的API都不太合格；

還有一種就是能力保護(hù)，如果超出了處理的并發(fā)量的能力，這個(gè)時(shí)候會(huì)發(fā)生什么；

2. 對(duì)資源的使用限制

這也是代碼新手或一些開(kāi)源產(chǎn)品中做的比較差的地方，很容易出現(xiàn)規(guī)模一上去，資源使用量也一直漲，沒(méi)有限制，然后導(dǎo)致系統(tǒng)掛掉，很常見(jiàn)的案例是對(duì)線程池的使用，例如像Java中的Executors.newCachedThreadPool，這個(gè)接口很多人會(huì)用到，但很多用的人都沒(méi)有仔細(xì)想過(guò)會(huì)不會(huì)在某種情況下這里創(chuàng)建出巨多的線程；還有例如用Map做cache，也沒(méi)考慮大小限制的問(wèn)題，結(jié)果就是隨著數(shù)據(jù)量增長(zhǎng)，某天突然就掛了；

健壯性是代碼中比較復(fù)雜的部分，通常也是比較展現(xiàn)代碼能力的部分，可能看起來(lái)就幾行代碼，但其實(shí)背后反映的差距是巨大的。

開(kāi)源產(chǎn)品除了在健壯性上的差距外，通常還會(huì)出現(xiàn)的一個(gè)巨大差距就是整個(gè)系統(tǒng)的設(shè)計(jì)的伸縮能力，伸縮能力不夠的話通常會(huì)導(dǎo)致結(jié)構(gòu)性的重構(gòu)，另外常見(jiàn)的就是在并發(fā)的處理上不夠高效，例如鎖的合理使用、無(wú)鎖算法的引入等等，而這些需要非常強(qiáng)的系統(tǒng)設(shè)計(jì)和代碼功底能力。

除了上面說(shuō)的這些外，高質(zhì)量的工程代碼還需要考慮可維護(hù)（例如監(jiān)控信息暴露）、安全性等，對(duì)我而言，我一直認(rèn)為所謂的工程化其實(shí)就是把一些玩具性質(zhì)的代碼變成可在商業(yè)系統(tǒng)中真正健壯運(yùn)行的代碼。

上面的內(nèi)容寫(xiě)的比較簡(jiǎn)略，不過(guò)應(yīng)該也能看出，對(duì)于高質(zhì)量的工程代碼而言，其實(shí)實(shí)現(xiàn)業(yè)務(wù)邏輯只是其中占比很小的一部分，甚至花的時(shí)間是相對(duì)最少的一部分，所以我確實(shí)非常贊同面試的時(shí)候讓同學(xué)寫(xiě)代碼，這個(gè)時(shí)候很容易看出同學(xué)寫(xiě)代碼的功力；有些時(shí)候?yàn)榱丝疾焱瑢W(xué)寫(xiě)代碼的熟練程度，我會(huì)問(wèn)問(wèn)IDE的快捷鍵，或者讓手寫(xiě)一段不是太復(fù)雜的代碼。