這個問題其實很難簡單一兩句話說清楚。我就結(jié)合自己的經(jīng)歷掰扯幾句吧。
剛畢業(yè)參加工作的時候，去了一家小公司（其實是大集團控股的一個子公司，然而完全獨立），公司有位特別厲害的技術(shù)總監(jiān)，代碼水平一流，人也特別好。當時還是 J2EE 的時代，Struts 還是 1.x ，Spring 才剛剛出現(xiàn)，遠沒有像后來一樣成為 Java 企業(yè)開發(fā)的標準。后來總監(jiān)自己寫了一個名叫 Common 的框架，主要也是基于 IOC 和 AOP 的理念，在公司內(nèi)部推廣使用。感覺在 Common 框架的基礎(chǔ)上開發(fā)公司的業(yè)務(wù)代碼有種很爽的感覺，比起完全從頭自己掄，在各方面的優(yōu)勢都很大。那個時代開源技術(shù)還不像現(xiàn)在這么風行，能有一個靠譜的框架使用，真是一件很幸福的事情。沒事的時候讀讀框架源碼學習學習，還能時不時的提幾個 bug，貢獻幾個fix，不亦樂乎。
后來去了業(yè)內(nèi)的另一家大公司，那家公司也有一個自研的框架，叫 Appframe。然而正因為公司比較大，這個框架在公司內(nèi)部也沒有完全推廣開來。我大概了解了一下框架的理念，它是一個一站式的框架，感覺設(shè)計者想從頭到尾就用這一個框架把整個項目都完全實現(xiàn)。然而給人的感覺是這個框架并不靈活，侵入性過強，也很讓人擔心如果用在項目中的話，能否適應(yīng)快速變化的業(yè)務(wù)需求。加上存在著一定的學習曲線，所以我的團隊在項目中也沒有使用它，而是轉(zhuǎn)而采用當時正流行的 Spring，Struts 2，Hibernate 這些開源框架了。事后看確實完全沒有采用這個自研框架的必要，因為看不出來它對項目開發(fā)的進度和質(zhì)量有太多正面的影響。而一旦采用，就會被局限到這個框架里，反而失去了嘗試各種開源框架的機會。
再后來去了一家巨無霸公司，連 Java 都是他家的，但在團隊里開發(fā)項目主要也是用的開源框架。唯一限制的是當時開發(fā)前端界面用的是 JSF。不過我自己好像也沒怎么學，至少現(xiàn)在完全想不起來當時是怎么用的了。
再后來……因為呆的公司都比較小，就沒有機會用自研框架了。而且我用到的技術(shù)也不局限于 Java，PHP，NodeJS，Python 相關(guān)的也都用了很多。還是自由的感覺比較好，碰到一個任務(wù)，可以選擇一個趁手的工具來解決問題，而不是手里只有錘子，看什么都像釘子。
然后時間到了今天。去年我又加入了一家大公司，不出意料地公司也有自研框架，而且還有領(lǐng)導要求，必須要使用這個框架。于是乎我開始學習這個龐大的框架。框架的組件很多，我碰到的最大的問題就是文檔寫得不夠具體，缺乏指導性，而且是內(nèi)部使用的東西，也沒辦法自己去網(wǎng)上找答案，平時最好用的 Stackoverflow 也沒救了。更為惡心的是，出于所謂知識產(chǎn)權(quán)的考慮，源代碼即使在公司內(nèi)部也沒有公開。加上公司太大，我們和負責開發(fā)框架的同事溝通也非常不方便，無論是在物理空間上還是網(wǎng)絡(luò)上都是分離不互通的。因此嘗試用了幾個組件之后我對使用這個框架就沒有任何熱情了……
我能理解所有公司自研框架的初衷，都是為了規(guī)范和統(tǒng)一代碼的實現(xiàn)，避免業(yè)務(wù)開發(fā)中的重復勞動，也節(jié)約測試和運維的成本。然而理想是美好的，現(xiàn)實是骨感的。在實際的工作中，公司自研框架的開發(fā)維護人員，和實際業(yè)務(wù)的開發(fā)人員，兩者的目標未必是一致的。即使靠領(lǐng)導從上至下的強行推廣，也很可能是怨聲載道，未必能對項目帶來良好的效果。特別可怕的是那種大而全的框架，想一切包辦代替的，這種框架往往未必滿足項目的實際需求，硬要用它來開發(fā)反而就像穿了一雙不合適的鞋在賽跑。磨不磨腳，只有程序員自己心里知道。
