大模型时代，程序员的技能演进——盘点那些“更重要的”和“不再重要的”能力...

本文转载自公众号演进式设计，作者张刚，著有《软件设计》。本文从多个方面分析大模型时代，程序员的技能演进。

PART.

01

“程序员”的工作，还是不是“写程序”？

曾经，“程序员”的职责是非常明确的：编写和调试代码，让应用程序正常工作。在这个意义上，胜任“程序员”的工作其实并不是太难：掌握计算机和软件的基本原理、至少一门编程语言，以及若干流行的框架，就可以上手了。

但是专业的“程序员”并不止步与此。

软件的长期维护特征和与生俱来的复杂性，使得高效、高质量地编写可长期维护的软件是非常困难的。所以，专业能力，例如编写高内聚、低耦合的代码、掌握演进式设计的能力等，是“专业程序员”，更确切地说，是“软件工程师”的一个更为重要的能力要求。

坦率地说，今天的许多程序员，未必都能达到“专业”程序员的要求。只不过，在软件行业对人才的巨量需求面前，“不那么专业”并不是一个严重的问题。

大模型时代的到来，或许将从根本上改变这一现状。在过去的几个月中，在ChatGPT的辅助下，我可以轻松上手不同的前端框架（基于TypeScript），“熟练”使用Go语言和Python语言，了解机器学习算法，了解云原始基础设施，使用各种我以前没有用过的组件，似乎它们并不比我已经使用了十几年的C语、Java语言有啥区别。语言、框架和基础设施的经验，似乎不再重要。全栈，曾经是一个非常遥远的目标，今天已经唾手可得。

大模型时代的到来，让程序员的效率也有了本质的提升。基于ChatGPT和Github Copilot，我可以直接要求ChatGPT编写Swagger接口文件，连续按几次Tab键就可以写好大多数的服务端代码，差不多一个小时能完成过去需要几天才能完成的工作。

大模型时代，正在催生“超级个体”。这些超级个体效率极高，熟练使用各种工具，快速交付业务价值。

PART.

02

大模型时代，什么才是“软件工程师”的真正能力？

我曾经在去年出版的《软件设计：从专业到卓越》一书中，列举了“专业的软件工程师”应该掌握的一组关键技能，以及这些能力之间的关系，我称它们为“精益软件设计实践”，如下图：

我把它们概括为一个根本挑战、两大核心价值、三大设计原则和对应的软件设计实践。

一个根本挑战是软件与生俱来的复杂性。

两大核心价值指的是软件开发的当前业务价值（满足业务需求）和长期资产价值（复用和演进）。

三大设计原则是分而治之、持续演进和内建质量。

在此基础上，上图还列出了彼此互为支撑的软件设计实践，分别为高质量需求、领域模型、由外而内的开发、设计分解、接口和契约、测试先行，以及演进式设计和内建质量中包含的系列软件实践，具体包括契约式设计、防御式编程、代码评审、结对编程、简单设计、测试驱动开发、重构和持续集成。

在我看来，上述这样的一个能力体系是一名“软件工程师”在“编程能力”之上的更重要的工程技能。不过，我没能在那个时刻预计到大模型时代的到来。从GPT-4发布到现在，我一直在使用GPT-4和Copilot在工作，通过这3个月的尝试，我觉得可以写一下自己的理解了。

让我们首先从问题出发：软件开发的复杂性问题。

PART.

03

软件开发的复杂性没有消失

简单地说，一个坏消息，一个好消息。

所有关于软件开发“复杂性”的讨论，都可以回溯到布鲁克斯在《没有银弹》一文中关于软件开发的本质困难的论证。布鲁克斯从以下四个方面论证了软件开发的本质困难：复杂性、符合性、可变更性、和不可见性。具体来说：

复杂性：业务领域本身就是复杂的，软件是服务于业务的，因此无论如何优化工程方法，软件开发都不可能比业务更简单。也正因为如此，软件开发才会有如此多的挑战。

符合性：软件系统不是孤立系统，它需要和客观世界、其他系统、人类规范等等打交道。不幸的是，这些标准和规范本质上没啥规律，就是“遵守”。

可变更性：软件天生就是为变更而存在的，因此它必须能够适应变化。但是，如果缺乏好的工程实践， 可变更其实并不容易做到。

不可见性：软件是信息，而不是物理实体，这使得它的理解和维护变得尤其困难。更糟糕的是，每一行代码都包含了信息....

大模型时代，上述4个根本困难改变了吗？

我的理解是：

业务的复杂性问题不减反增。大模型必然加速人工智能应用的到来，业务场景将大幅扩展。同时，由于软件开发的成本降低（大量AI助手的应用）， 软件将更加无处不在，业务连接更为广泛，这些都将扩大业务的复杂性。

符合性问题更为突出。更多的连接和交互会带来更多的边界， 虽然人工智能会在边界的兼容性上有所作为，但是其实会对管控提出更高的要求。

可变更性依然存在，解法会有升级：软件天生就是“软”的，这个没法改变。不过，大模型会对“如何变更”带来全新的方法。也就是说，这个问题仍然在，但是解法有了更多的选择。

不可见性有望得到根本改变：其实真正的“不可见”并不是信息实体导致的，而是我们人脑对复杂问题理解的能力导致的。计算机的记忆力比人类强很多，现在有了人工智能的理解力的加持，或许，不可见在未来不再是一个根本问题。

总结一下的话，就是一个坏消息和一个好消息。

一个坏消息：由于人工智能的到来，复杂性没有降低，而且还会增加。

一个好消息：由于人工智能的到来，我们的武器变强了，有了更多应对手段。

PART.

04

需求分析能力将更为重要

有句话叫“好的开始是成功的一半”。需求分析其实从来就是一个极度重要的问题。需求分析从澄清业务目标、到设计需求方案，到明确业务规则，都需要非常结构化的方法。

人工智能能够在需求分析领域提供不小的帮助。类似于ChatGPT这样的大模型，已经阅读了这个世界上的大多数文字素材，知识很广博，对于通用的需求把握并不弱于人类专家。甚至已经有一些基于大模型的需求分析辅助工具，可以帮助我们编写看起来很不错的需求文档。

所以，如果善用人工智能辅助，需求分析的效率和质量都会有本质提升。

但是人工智能没法解决的问题，是目标的定义和特定业务的问题。这也是优秀的产品经理的价值所在。本文不展开产品经理的话题，但它是否为优秀的开发工程师的更好机会呢？我的看法是：是的。由于大模型的出现，软件开发的生产力将会大幅上升，全栈已经可以不仅仅是技术域的全栈了，而是可以向前延伸到需求和业务领域的全栈。所以，如果你本来就是一名优秀的开发工程师，我的看法是：绝好的机会来了。

“善用人工智能辅助”仍然是有门槛的。这时候，结构化的需求分析能力，就会变得非常重要。关于这个问题，我推荐何勉老师的“需求分析金字塔”给大家：

每个金字塔的层次下，都还包含了很多关键实践。这些实践本身很重要，我也看到了许多由于人工智能的引入带来的新的实践方法的机会，本文写不下这部分内容，我们后续专门展开。

PART.

05

领域模型：非常关键！

在我看来， 在软件开发领域，再也没有一个其他问题，和领域模型一样重要但是却容易被忽略了。要不是沾了微服务和DDD的光，我相信到现在为止，很多技术人员也未必知道领域模型。

领域模型反映了一个领域中的关键概念及其之间的关系，是我们对现实世界的简化和思维映射，其实也是对布鲁克斯关于软件开发的本质复杂性的直接回应。没有好的领域模型， 软件开发势必是混乱的。只不过，由于造成软件开发效能损失的方面实在是太多了， 而由于很多人根本就不知道很多问题居然是因为缺乏好的领域模型导致的， 更加没法归因到它上面而已。

在大模型时代，软件开发必然会加速，而且需要人类和人工智能有效协同。那么，这时候是不是能很好地利用领域模型，就会成为一个重要的效率分水岭。用一个容易理解的比方，就是工具就像放大镜一样， 会放大不同能力的人和组织的差距。

当然，大模型时代的领域模型，如何定义，如何维护，这个是一个非常值得探讨的话题.......

PART.

06

模块化、接口和契约，非常重要

相信凡是试验过使用ChatGPT编写代码的伙伴们都注意到了， ChatGPT对于小规模程序手到擒来，对于大规模的程序，如果直接让它编写，基本上没法工作。背后的原因很容易理解：

人类需要对复杂的问题分而治之，其实人工智能也是如此。

分而治之是我们简化复杂性的重要手段。通过将大问题分解成高内聚、低耦合的小问题，把大问题模块化，然后定义清楚它们之间的边界，逐一解决，各个击破。同时由于模块化，我们还可以复用之前已经完成的工作，提高效率，避免重复劳动。

在人工智能时代，这一点变得更加重要。其实人工智能是可以帮助我们更好地做模块化的，但是它仍然需要人类工程师的指引和协作。你现在就好比是人工智能的老板，它是你的下手。作为老板，如果你自身对好的模块化理解很到位，自然助手也很高效。如果强大的人工智能面对的是个没啥品味的“老板”，结果自然可想而知....

模块化的意义还远不止如此。类似于LangChain等技术方案，已经为我们展示了在大模型时代的一些更好的服务协同和服务能力组装的方式。

高质量的模块化、接口和契约，对于如何能发挥人工智能的架构能力，是一个特别值得重要的问题。

PART.

07

演进式设计，问题不变，方式值得重新思考

可变更性是软件的根本特征，持续演进能力，正如自然界的进化一样，都是本质。

涉及演进式设计的实践太多，我们无法逐一论述，选我认为重要的，直接给一些结论吧。

重构：重构在过去是一个极为重要的敏捷实践。这一点看Martin Fowler的经典著作《重构》的流行度就可以知道。重构在大模型时代，在契约明确的情况下，这个实践很可能会有重大变化。换句话说，当重写的成本极低，而且可靠性极高的情况下，小步重构的手法和重要性可能不再重要。

自动化测试：自动化测试是契约的保障，重要性不会降低。

测试驱动开发：经典的测试驱动开发方法会发生变化。更可能的方向：一个是人类用测试表达契约，或者在人工智能的辅助下表达契约，然后人工智能来负责具体的实现。另外，给大家报告一下，作为测试驱动开发的积极实践者，我最近使用测试驱动开发写代码的频率其实在降低——因为测试驱动开发的一个重要作用是降低认知负担，而人工智能已经可以在这方面提供许多帮助。

结对编程：一个好消息，如果你过去就认同结对编程的理念，也熟悉结对编程的方法，现在你一定是如鱼得水，因为你有了一个知识非常渊博的编程助手。人和人的结对编程不再是唯一的模式。更好的模式是和AI结对编程。

持续集成：仍然重要。

整洁代码：最近的体会是，人工智能帮我写出来的代码，比我看到的“专业的人类程序员”写出来的，好太多。整洁代码，作为软件开发的入门级实践，或许真的已经不再那么重要了。相比过去推广起来的困难，训练一个学习能力更强的机器助手，其实容易得多。

PART.

08

语言和框架

这几天我产生了一个念头——或许，ChatGPT产生在今天，而不是10年前，真的是命中注定——今天我们有了非常丰富的适合各种场景的编程语言，有了丰富的编程框架，有了类似于K8s这样的平台，人工智能在编程领域才有用武之地啊。如果没有这些，那么，靠AI自己创造语言，自己搭建平台吗？这个难度就太大了。

或许，我们这一代程序员，真的只是通向未来人工智能的BootLoader....

但是，作为技能，语言和框架的重要性未必降低，学习难度大幅下降了。基本的状态就是，对一名有一定积累的程序员——随便什么语言，在AI的帮助下都可以轻松编写和阅读！写起来也快多了，现在已经是Tab-Tab-Tab了，也许，过不了多久，就真的很少动手亲自写了，大多数工作，都是人工智能代劳。

作为建议：扩大对设计能力的投资，降低对语言和框架的投资。

如果你本来就是语言和框架的专职维护者的人除外。

最后，继续推荐一下我自己的《软件设计：从专业到卓越》。

昨天图灵的武老师告诉我说，这本书再次重印了。看起来还不错，其实我觉得还是没反映出它本来的价值，应该被更多人看到。这本书写了很久，凝结了我过去十几年对软件设计的思考，很开心的看到，大多数实践在大模型时代仍然有价值，而且很多价值更加凸显。所以如果没有读过的同学，建议看一下，应该有一定的参考价值。我尽量写的深入浅出，如果有内容上的意见和建议，也欢迎通过在公众号下面留言提出。