「Comment」https://icyfenix.cn/tricks/2021/arch/

[fenixsoft]

「Comment」https://icyfenix.cn/tricks/2021/arch/

[cypggs]

从软件的历史看架构的未来

第一次软件危机 1950 年代末期

• 机器强大到世界上最聪明的人都无法为它编写出合适的程序了

• 面条式代码转向结构化编程 1970 年

• 世界上最聪明的科学家/工程学家在开发软件

第二次软件危机 1970 年[北约 NATO 会议]

• 每个人都有自己的理解与认知，如何让各个模块能准确地协同工作成了一场灾难

• 面向对象编程逐步取代了面向过程的结构化编程 1990 年代面向对象的设计方法成为主流

• 社会中的高智商高学历的精英群体在开发软件

第三次软件危机 2010 年左右开始兴起

• 只要软件系统由大量人员共同研发，并使其分布在云中大量节点协同运行，随着项目规模的增大、时间变长，就肯定会有人疏忽犯错，会有代码携带缺陷，会有电脑宕机崩溃，会有网络堵塞中断，总之，必然会受到墨菲定律的无情打击

• 从单体到微服务的最根本的推动力，是为了方便某个服务能够顺利地“消亡”与“重生”

• 如何采用不可靠的部件来构造出一个可靠的系统，是软件架构适配云与分布式算力发展的关键所在

• 允许更平庸的开发者也同样能写出可运行、可用于生产的软件产品，同时又对精英开发者提出更多、更复杂的技术要求 CRUD Boy

软件发展的下一个关键矛盾将会是算力规模超过人应掌握合理知识的极限

• 云原生、微服务、不可变基础设施、弹性计算、服务网格、无服务器架构、高低零代码

• 设法把那些重要但普适的知识标准化并下沉

• 把复杂的问题尽量关进笼子，由专业人员去看护，才能让普通程序员更好参与软件开发，甚至通过低/零代码工具的支持，让那些没有太多编程知识，却有丰富领域知识的业务专家，也能够独立制造出优秀的软件产品

[prchann]

算力不断提升，人们当然想充分利用起来。为了达到目标，工程师采用了架构这种工具；架构不断演化：无架构 -> 过程编程（结构化可复用） -> 对象编程（人类**友好） -> 微服务。目的是控制住算力提升带来的软件复杂度。

云原生时代，算力接近无限。业务开发中依然需要处理很多非业务问题，导致开发较复杂。如果能将非业务能力沉淀为基础设施，业务开发就只需处理业务。如果是这样，工程师可能会两极分化，解决基础设施问题的高端架构师/专业人才，以及写业务代码的编码工人。

[cnhuz]

“但并内部却没有什么人所不知道的事情” 这里的“并”是不是写错了

[jollykingCN]

在当前节点, 做技术的更需要努力奋斗, 要么成为深耕业务行业成为跨领域的复合型人才, 要么成为云Mesh技术专家. 否则, 今天的CRUD Boy, 明天的流水线工人.