「夢斷代碼」中對軟件工程所面臨的種種困難與艱難的描述，即便再過5年讀也許都不過時。因為正如原作者所說，書中描寫的是一隊人馬并肩扛起代碼大石，雖歷經(jīng)磨難仍欲將其推上山頂?shù)墓适拢沁@種故事成就著今天全世界億萬臺服務器和PC機上運行的各種軟件，成就著人類不斷超越實現(xiàn)更偉大的夢想。

當人們夢想把軟件變成流水線式的工作,他們常會期盼標準化的插件.新西蘭學者詹姆斯.諾博爾和羅伯特.畢多有時用'后現(xiàn)代程序員'的筆名共同協(xié)作,他們把這夢想叫做"樂高假設(shè)":"未來,程序?qū)⒂煽煞玫牟考M合而成.軟件部件將在全球范圍內(nèi)提供.軟件工程將從編程的窠臼解放出來." 從架子上取幾樣零件,拼在一起,馬上就能得到可用的軟件--不用在痛苦的編碼了!

一幫牛人，不缺技術(shù)不缺錢，最終的結(jié)果卻不如人愿。剛開始看的時候，還是很輕松很調(diào)侃的在看老外大牛們的囧事?？墒窃娇丛桨l(fā)現(xiàn)這本書里的很多事情其實每天都發(fā)生在自己的身邊,讓人后怕.

想要走向這種編程烏托邦之路的程序員大多都發(fā)現(xiàn)此路不通.諾博爾和畢多的研究指出了最大的路障.他們同另外兩名同事一起研究了采用面向?qū)ο蠹夹g(shù)的真實程序中的大量軟件對象,發(fā)現(xiàn)這些構(gòu)建快完全不像是樂高積木.如果軟件組件像樂高積木塊,那么它們就該細小、不能再分、可被替代;它們互相之間應該更為相像;它們應該"只能與有有限相鄰組件拼合."然而,當諾博爾和畢多觀察真實程序時,他們卻發(fā)現(xiàn),真實程序中的組件在尺寸上,功能上以及與其他組件的可拼合數(shù)量上差異甚大.它們"大小不一,就像不規(guī)則的形體,不像樂高積木."諾博爾和畢多發(fā)現(xiàn)了它們稱之為"普遍多樣性"的現(xiàn)象:目力所及之處,有常者惟無常. 想想看一套樂高積木,其中一些積木塊只有半英寸長,而其他積木塊則長達半英里:有些用硬塑料制成,有些則是液態(tài)或氣態(tài);有些積木塊藉由大家熟悉的凹凸就夠相互連接,而另一些則用上了焊接,膠水或繩索

「夢斷代碼」雖然是2008年出版的書,但是也反映了很多現(xiàn)實中開發(fā)的問題,比如比較火的React JS的開發(fā)模式正是組件化開發(fā),寫好組件后就可以像搭積木一樣拼在一起使用,看起來很美,但是實際開發(fā)工作中,由于React 生態(tài)并不完善,組件庫不多,比如輪播圖組件在社區(qū)里都找不到,還得自己造輪子.而且由于不同組件之間需要通信,組件多了通信就容易變得復雜,又不得不引入flux這種架構(gòu)模式來管理狀態(tài)和處理不同組件間的通信,個人感覺這種方式給組件增加了耦合度

可復用軟件之夢有一個悖論：幾乎總能找到一段滿足大部分需要的代碼。但這些拿來的代碼所不能做到的部分，恰恰是項目與眾不同的創(chuàng)新之處----也是創(chuàng)建這個項目的出發(fā)點。

這些程序組件倉庫可能是軟件世界中最接近樂高之夢的部分了.但它卻遠不及最熱心的貢獻者們所期盼的那樣有用并且被采用.在同一類組件庫中,往往有許多種不同選擇,每種選擇還有許多不同版本.可用的代碼以及每種代碼包所能做的事如此之多,多到連老手們有時都會忘記有哪些可用代碼;他們停止了四處找尋,轉(zhuǎn)而從頭開始編寫某些其實是現(xiàn)成的功能.

盡管有g(shù)ithub這個開源社區(qū),但是很多前端er往往會因為各種理由選擇造社區(qū)已經(jīng)很成熟的輪子,比如因為性能或體積問題,選擇自己造輪子,問題是這些輪子往往質(zhì)量很差,不能在其他人的項目中使用

生產(chǎn)出通用構(gòu)造塊式軟件包并不容易,這顯而易見.盡管屢遭失敗,樂高之夢仍然在現(xiàn)代編程史上投射下長長的影子.對于路上的每一個障礙,一代又一代程序員總能找到借力之法,避免自行開拓之苦.

模塊化和組件化是軟件人員的夢想，誰都想把幾個模塊插到一起就可以完美的運行并完成任務，但現(xiàn)實卻相當殘酷，可以運行的模塊通常不能與自己想寫的程序配合工作，好的源代碼由于商業(yè)利益也不太容易找到，程序員只能自己另起爐灶，搭建自己的模塊，但結(jié)果還是一樣，做出來的東西難以讓他人共享，這個現(xiàn)象周而復始，不斷地在多個程序員身上上演,讓人深思.

要打造一個產(chǎn)品，遠比最初估計的難得多 不要過度設(shè)計，重造車輪，框架，頂層設(shè)計，從可行的簡單方案開干；