「梦断代码」中对软件工程所面临的种种困难与艰难的描述，即便再过5年读也许都不过时。因为正如原作者所说，书中描写的是一队人马并肩扛起代码大石，虽历经磨难仍欲将其推上山顶的故事，而正是这种故事成就着今天全世界亿万台服务器和PC机上运行的各种软件，成就着人类不断超越实现更伟大的梦想。
当人们梦想把软件变成流水线式的工作,他们常会期盼标准化的插件.新西兰学者詹姆斯.诺博尔和罗伯特.毕多有时用'后现代程序员'的笔名共同协作,他们把这梦想叫做"乐高假设":"未来,程序将由可服用的部件组合而成.软件部件将在全球范围内提供.软件工程将从编程的窠臼解放出来." 从架子上取几样零件,拼在一起,马上就能得到可用的软件--不用在痛苦的编码了!
一帮牛人，不缺技术不缺钱，最终的结果却不如人愿。刚开始看的时候，还是很轻松很调侃的在看老外大牛们的囧事。可是越看越发现这本书里的很多事情其实每天都发生在自己的身边,让人后怕.
想要走向这种编程乌托邦之路的程序员大多都发现此路不通.诺博尔和毕多的研究指出了最大的路障.他们同另外两名同事一起研究了采用面向对象技术的真实程序中的大量软件对象,发现这些构建快完全不像是乐高积木.如果软件组件像乐高积木块,那么它们就该细小、不能再分、可被替代;它们互相之间应该更为相像;它们应该"只能与有有限相邻组件拼合."然而,当诺博尔和毕多观察真实程序时,他们却发现,真实程序中的组件在尺寸上,功能上以及与其他组件的可拼合数量上差异甚大.它们"大小不一,就像不规则的形体,不像乐高积木."诺博尔和毕多发现了它们称之为"普遍多样性"的现象:目力所及之处,有常者惟无常. 想想看一套乐高积木,其中一些积木块只有半英寸长,而其他积木块则长达半英里:有些用硬塑料制成,有些则是液态或气态;有些积木块藉由大家熟悉的凹凸就够相互连接,而另一些则用上了焊接,胶水或绳索
「梦断代码」虽然是2008年出版的书,但是也反映了很多现实中开发的问题,比如比较火的React JS的开发模式正是组件化开发,写好组件后就可以像搭积木一样拼在一起使用,看起来很美,但是实际开发工作中,由于React 生态并不完善,组件库不多,比如轮播图组件在社区里都找不到,还得自己造轮子.而且由于不同组件之间需要通信,组件多了通信就容易变得复杂,又不得不引入flux这种架构模式来管理状态和处理不同组件间的通信,个人感觉这种方式给组件增加了耦合度
可复用软件之梦有一个悖论：几乎总能找到一段满足大部分需要的代码。但这些拿来的代码所不能做到的部分，恰恰是项目与众不同的创新之处----也是创建这个项目的出发点。
这些程序组件仓库可能是软件世界中最接近乐高之梦的部分了.但它却远不及最热心的贡献者们所期盼的那样有用并且被采用.在同一类组件库中,往往有许多种不同选择,每种选择还有许多不同版本.可用的代码以及每种代码包所能做的事如此之多,多到连老手们有时都会忘记有哪些可用代码;他们停止了四处找寻,转而从头开始编写某些其实是现成的功能.
尽管有github这个开源社区,但是很多前端er往往会因为各种理由选择造社区已经很成熟的轮子,比如因为性能或体积问题,选择自己造轮子,问题是这些轮子往往质量很差,不能在其他人的项目中使用
生产出通用构造块式软件包并不容易,这显而易见.尽管屡遭失败,乐高之梦仍然在现代编程史上投射下长长的影子.对于路上的每一个障碍,一代又一代程序员总能找到借力之法,避免自行开拓之苦.
模块化和组件化是软件人员的梦想，谁都想把几个模块插到一起就可以完美的运行并完成任务，但现实却相当残酷，可以运行的模块通常不能与自己想写的程序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己另起炉灶，搭建自己的模块，但结果还是一样，做出来的东西难以让他人共享，这个现象周而复始，不断地在多个程序员身上上演,让人深思.
要打造一个产品，远比最初估计的难得多 不要过度设计，重造车轮，框架，顶层设计，从可行的简单方案开干；
