「夢斷程式碼」中對軟體工程所面臨的種種困難與艱難的描述，即便再過5年讀也許都不過時。因為正如原作者所說，書中描寫的是一隊人馬並肩扛起程式碼大石，雖歷經磨難仍欲將其推上山頂的故事，而正是這種故事成就著今天全世界億萬臺伺服器和PC機上執行的各種軟體，成就著人類不斷超越實現更偉大的夢想。

當人們夢想把軟體變成流水線式的工作,他們常會期盼標準化的外掛.紐西蘭學者詹姆斯.諾博爾和羅伯特.畢多有時用'後現代程式設計師'的筆名共同協作,他們把這夢想叫做"樂高假設":"未來,程式將由可服用的部件組合而成.軟體部件將在全球範圍內提供.軟體工程將從程式設計的窠臼解放出來." 從架子上取幾樣零件,拼在一起,馬上就能得到可用的軟體--不用在痛苦的編碼了!

一幫牛人，不缺技術不缺錢，最終的結果卻不如人願。剛開始看的時候，還是很輕鬆很調侃的在看老外大牛們的囧事。可是越看越發現這本書裡的很多事情其實每天都發生在自己的身邊,讓人後怕.

想要走向這種程式設計烏托邦之路的程式設計師大多都發現此路不通.諾博爾和畢多的研究指出了最大的路障.他們同另外兩名同事一起研究了採用面向物件技術的真實程式中的大量軟體物件,發現這些構建快完全不像是樂高積木.如果軟體元件像樂高積木塊,那麼它們就該細小、不能再分、可被替代;它們互相之間應該更為相像;它們應該"只能與有有限相鄰元件拼合."然而,當諾博爾和畢多觀察真實程式時,他們卻發現,真實程式中的元件在尺寸上,功能上以及與其他元件的可拼合數量上差異甚大.它們"大小不一,就像不規則的形體,不像樂高積木."諾博爾和畢多發現了它們稱之為"普遍多樣性"的現象:目力所及之處,有常者惟無常. 想想看一套樂高積木,其中一些積木塊只有半英寸長,而其他積木塊則長達半英里:有些用硬塑料製成,有些則是液態或氣態;有些積木塊藉由大家熟悉的凹凸就夠相互連線,而另一些則用上了焊接,膠水或繩索

「夢斷程式碼」雖然是2008年出版的書,但是也反映了很多現實中開發的問題,比如比較火的React JS的開發模式正是元件化開發,寫好元件後就可以像搭積木一樣拼在一起使用,看起來很美,但是實際開發工作中,由於React 生態並不完善,元件庫不多,比如輪播圖元件在社群裡都找不到,還得自己造輪子.而且由於不同元件之間需要通訊,元件多了通訊就容易變得複雜,又不得不引入flux這種架構模式來管理狀態和處理不同元件間的通訊,個人感覺這種方式給元件增加了耦合度

可複用軟體之夢有一個悖論：幾乎總能找到一段滿足大部分需要的程式碼。但這些拿來的程式碼所不能做到的部分，恰恰是專案與眾不同的創新之處----也是建立這個專案的出發點。

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

儘管有github這個開源社群,但是很多前端er往往會因為各種理由選擇造社群已經很成熟的輪子,比如因為效能或體積問題,選擇自己造輪子,問題是這些輪子往往質量很差,不能在其他人的專案中使用

生產出通用構造塊式軟體包並不容易,這顯而易見.儘管屢遭失敗,樂高之夢仍然在現代程式設計史上投射下長長的影子.對於路上的每一個障礙,一代又一代程式設計師總能找到借力之法,避免自行開拓之苦.

模組化和元件化是軟體人員的夢想，誰都想把幾個模組插到一起就可以完美的執行並完成任務，但現實卻相當殘酷，可以執行的模組通常不能與自己想寫的程式配合工作，好的原始碼由於商業利益也不太容易找到，程式設計師只能自己另起爐灶，搭建自己的模組，但結果還是一樣，做出來的東西難以讓他人共享，這個現象周而復始，不斷地在多個程式設計師身上上演,讓人深思.

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