但不知从什么时候起，随着各种开源框架、中间件、平台、系统等越来越响，从企业界到学术界不断鼓吹云的各种神力，通过这种神力如何让软件全生命周期变的更加简单高效，普通业务软件研发的注意力出现了很多转移，谈论软件工程、软件质量方法、设计模式等命题的热度越来越低。谈论越来越多的是如何利用现有的开源代码，快速把需要的系统整出来，快速完成从0到1的产品交付。似乎利用类似Spring的编程框架和K8S平台等等，就不再需要考虑复杂的设计模式，就可以完成满足中小型业务需要，完成具备较复杂的系统开发和构建了。
不可否认，大量的开源代码和各种开发框架、系统、平台等，加速了软件产品从0到1的构建，但由于对这些代码和框架的不熟悉，在出现需要研究代码才能定位的问题，或系统复杂度突破某个阈值后，功能或性能才会出现的较复杂问题时，由于对常见的设计模式或软件架构方法等不熟悉，会花费大量的时间去处理问题，甚至出现很长时间毫无头绪的情况。另外，由于缺乏必要的软件工程知识，开发的代码缺少必要的设计和架构，导致后续需求增加或需求变化，需要在原有代码上进一步做增加或修改，出现各种补丁式模块和代码，导致系统加速腐化。越来越多的类似情况出现在很多软件公司从几个人到几十个人、再到上百个人不断壮大过程中，很多公司过了A、B，甚至C轮，但发现团队人员压力越来越大，软件产品bug没完没了，需求变更的研发周期越来越不可控。
为什么会出现类似情况，还是软件工程能力，软件架构能力等各种软件能力不过关，开源代码让很多公司或个人在支撑业务初期的软件系统方面看起来很牛，但随着软件系统复杂度的增加，开源代码代码在某些地方会出现瓶颈，甚至很多公司对开源代码破坏性的修改，会加速这个结果的到来。深入去研究很多优秀的开源代码，里面体现很强的软件架构能力和软件工程能力——优雅的架构、完备的测试用例、简洁的编码风格…..
忽然想起了（个人YY，勿喷），回观“盗版windows”对中国OS研发进程的影响，会不会“开源代码”也会对中国的软件研发能力带来一些负面的影响呢？
今年春节在老家胡思乱想，决定在软件工程及软件架构等方面继续深入学习和研究。从老家回来后，从书架中又翻出了《软件工程—实践者的研究方法》第七中文版，准备全面、系统的再次学习软件工程，也结合自己十几年的一线大厂的软件设计和开发经验，谈谈自己的理解，当然如果能影响更多的人一起去聚焦软件产品的基础能力，而不是只是简单的照葫芦画瓢，那就太幸运了。
