多年来,我一直想写一个完整的案例,融入现代软件工程实践,便于那些没有机会做过完整大项目的大学生、或者是想对现代软件工程方法有深入了解的初中级工程师有一个参考。

不过,想归想,能不能拿出足够的时间和精力来做这个事就是另外一回事了。一个完整案例的工作量很大,我也只熟悉少量技术栈,不少东西也得现学。

但是,机会还是来了,去年ChatGPT的发布,让我原本觉得很难短期内完成的演示项目,有了非常不一样的新的可能。在大模型的帮助下,我仅仅用了1个月的时间,就完成了“共享出行”这个完整案例,去年10月,我把这个案例的代码以开源的形式做了发布(点击文末的查看原文可跳转gitee链接)。在完成开发工作的同时,我刻意地记录了整个开发过程,现在它就变成了下面这本书:

从0到1、从需求到上线:我如何结合大模型和专业素养来完成一个实际项目_开发过程

《大模型辅助软件开发:方法与实战》其实是一本“大模型含量”不怎么高的书。大多数内容都是在讲“端到端软件研发”、“领域驱动”、“测试先行”、”演进式设计” .... 虽然“大模型含量”不高,这也不是一个“蹭热点”的标题。从开发过程来看,与专业能力的结合,大模型大幅加速了开发过程。它是能力放大器。

我不知道在未来,大模型和软件工程的融合,会把软件工程的形态演变成什么新的样子,也许变化会很大。不过,在当下,我认为专业素养仍然是非常重要的,它是发挥大模型能力的最重要的因素。

人类仍然是开发活动的主体

首先可以肯定,软件工程师的“饭碗”,还没有受到威胁。AI短期内还没有取代软件开发的能力。人类,仍然是软件开发的主体。开发大模型或者是大模型辅助软件开发的公司,也仍然需要大量的软件工程师,代码,也仍然是工程师在“写”。

“写”加了个引号,是因为“写代码”的方式真的不一样了。以我自己为例, 现在开发任何一个项目,70%以上的代码,其实是大模型生成的。有些时候,我会借助于copilot这种工具,有时候,则是直接通过聊天对话完成。反正,就是每天工作下来,幸福感增强了很多,终于不用管那么多的开发细节了。更多的精力,可以放在思考“解决什么问题,应该如何解决”这些较为宏观的层面上了。这些事情对我倒是轻车熟路,我在软件开发领域干的时间最长的岗位,本来也是“架构师”。

大模型时代,大多数软件工程师需要从具体的工作细节中解放出来,成为具有全局视野的架构师。

用一个项目来演示

去年夏天,在使用大模型辅助开发了几个较小规模的项目之后,我意识到:大模型开发工具肯定会越来越便利。但是,有一些东西,其实是和具体的工具无关的,那就是软件工程师思考问题和解决问题的方法。

更具体地说,是如何定义问题,如何寻找解决方案,如何把方案描述清楚,以及如何通过演进式设计,持续交付价值的同时,逐步完善解决方案。

和技术细节相比,这些是更难学会的技能。技术细节只有两个状态:不知道/知道。或者至多再加一个:不知道/知道/熟练。例如,我学会了如何使用Kubernetes部署,就是学会了。但是“技能”就不是这样。例如:“演进式设计”究竟意味着什么? 如何把一个大问题拆解成可以一个一个解决的小问题,而且并不会引入过多的附加成本?技能唯有在实践中学习,不断重复,才能持续精进。

我希望能用“共享出行”这个项目来演示上述观点。2023年7月29日,我写下了项目的第一行代码:

从0到1、从需求到上线:我如何结合大模型和专业素养来完成一个实际项目_开发过程_02

共享出行的项目背景

“共享出行”并不是一个虚构的产品。我是真正做过这个产品的,只不过它没有最终成为滴滴,由于外部环境的快速变化,还没来得及正式运营就结束了。

我最早做这个产品是在2015年,虽然项目最终没成功,不过过程中对共享出行业务领域还是有了较多认识,也在当时比较完整的应用了“领域驱动设计”实践。如果我用大模型作为辅助,把这个项目完整的从头开始做一遍,全部使用最新的技能栈,需要多久? 会遇到哪些真实的挑战?这个项目确实需要用到不少技术:

- 后端:Spring Boot、DDD、RESTful API+websocket通信

- 前端:微信小程序

- 身份认证:Keycloak

- 部署平台:Kubernetes

- 持续集成:Jenkins

上述的技能栈,我之前从来没有用过微信小程序和Keycloak,Kubernetes的部署也不是太熟悉。但是,这些技术问题,由于有了大模型的帮助,除了微信小程序上的websocket确实花了点时间把它搞通,其他没有遇到什么真正的挑战。

比较值得一提的是,这个项目麻雀虽小、五脏俱全,算是一个全面的软件工程案例。它涵盖了软件开发的整个生命周期,从定义开发的范围,到最终发布上线,涵盖了完整的需求分析、架构设计、开发、测试、发布等环节。

就这样边开发、边记录——记录是因为要把它整理成真实的开发案例,用了差不多1个月时间,就基本完成了项目的主体内容。这种效率,特别是在我还有很多技术栈不熟悉的情况下,放在没有大模型之前,是完全不可能的。后续当然还有断断续续的修改,但是已经不是主要工作了。

在项目完成之后,我以开源的方式发布了这个项目,详情可见:DDD/精益软件设计案例介绍(精简版)

把过程写成一本书

虽然完整发布了整个项目的所有代码,也包含了项目的提交历史,但是,中间的一些尝试和思考,以及和大模型交互的过程是很难直接体现的。

鉴于我在开发过程中已经刻意地记录了整个过程,把它编排成一本书就很顺利了。我是使用markdown写的,编排起来很快,到11月28日,就已经完成了这本书的第一版:

从0到1、从需求到上线:我如何结合大模型和专业素养来完成一个实际项目_软件开发_03

后面就是漫长的文本完善和出版过程。历时 8 个月之后, 它终于和读者见面了。

值得一提的封面

这本书的封面上有一个冰山。其实这是一个改过好多版的封面,我非常喜欢这个最终版本。7月份的一天,我收到编辑老师的微信,看到了“冰山”这个意象,我的第一反应是:“太棒了!”。

大模型辅助软件开发,表面看得到的,是应用大模型的能力。看不到的,也更基础的,是软件工程的专业素养,是定义问题,解决问题的能力,是说清楚问题和解决方案,以及通过演进式设计逐步逼近的能力。

这本书的“大模型”含量,确实没有那么高。你能看到更多的,是“专业的软件开发技能”,而不是“大模型提示语的写法”,也不是“大模型辅助开发工具的用法”。但是,它仍然值得被称为“大模型辅助软件开发”,这是因为:

大模型时代,人类仍然是、也必将一直是软件开发活动的主体。AI是软件开发强有力的助手。专业技能,包括业务视野和技术视野,以及现代软件工程方法,决定了利用大模型进行辅助开发的效率。