ChatGPT强悍的编程能力,让我吓出一身冷汗!

最近有好几个人给我安利ChatGPT,说老刘快你去看看吧,这货实在太强了,搞不好我们程序员都失业了。

刚开始我都是微微一笑,怎么可能?我之前的观点一直都是在我的有生之年,AI绝对不可能干掉程序员。

但是安利的人实在是太多了,我忍不住要去注册个账号去看一下。

没想到这货竟然没对中国开放,网上有些攻略,我嫌麻烦,赶紧呼叫在国外的好兄弟,请他帮忙注册一个账号。 

尝试开始,我决定跳过那些简单的问答,例如:

如何反转一个字符串?

如何发起一个HTTP调用?

因为这种东西对于阅码无数的AI来说太小儿科了,根本测试不出来它的本事有多大。

程序员的一个核心能力就是拿到需求,能作出优雅的设计,咱们就拿这一点考考它。

先问一个简单的问题:

55134327d1532ce19ec0532cee8710be.png

(点击看大图)

不出所料,它“背诵”得非常好!

它说的最后一个原则是:尽量使用合成/聚合的方式,而不是继承来达到复用目的。 这确实是面向对象一个重要的设计原则。

ChatGPT能运用这样的原则吗?

先问问它会不会做设计:

7cf1188a4bc16066070f6a254407f688.png

说得真不错,咱们开始放大招,我手头正好有一个经典案例:薪水支付,这是从经典书《敏捷软件开发:原则,模式和实践》中提取出来的。 

这个案例的需求是这样的:

该系统由一个公司数据库以及和员工相关的数据组成,系统需要准时地按照规则给员工支付薪水

员工有三种类型

1.钟点工,每个小时有固定报酬,他们每天提交工作时间卡,其中记录了日期以及工作小时数,如果每天工作超过8小时,按1.5倍进行支付。每周五对他们进行支付。

2.月薪员工,工资固定,每个月的最后一个工作日对他们进行支付

3.销售人员,有固定工资,但会根据他们的销售情况,支付给他们一定数量的佣金,他们会提交销售凭条,其中记录了销售的日期和数量。每隔一周的周五对他们进行支付。

员工可以选择支付方式,可以把支票邮寄到他们指定的邮政地址,也可以保存在财务那里随时支取,或者要求直接存入他们指定的银行账户。

看了这个需求以后,一般的设计是这样的:

53c49cc9b49e1556b9148e9dc0bca638.png

Employee 作为基类,不同类型的雇员类来继承。

但是这个需求会有变更,客户要求员工类型可以变更,例如从钟点工变成月薪雇员,这样上面的设计就不行了。

这个时候应该做个抽象,,用一个类PaymentClassification来表达支付分类,然后让Employee类持有这个实例,简单说就是用组合代替继承。

5983df8c88103429c8b448973d93cc6c.png

这相当于是个陷阱了,我们程序员能识别,抽象,这个ChatGPT可以吗? 我还真有点好奇。

先问最初的需求,ChatGPT的回答是这样的:

ab9243c63b7e243d671f1087fcfe64ed.png

(点击看大图)

你别说,还真是不错,它“理解”了需求,从中抽取出了名词进行类的设计,并且设计好了类的继承关系。

已经达到了面向对象设计的初级水平。

接下来是重点,给他挖坑:

9c986c3f37179102f8b39bd17773ffe0.png

b97dab564a4e59bebb3af6b72fd36478.png

0de670b2e9c14105e3f6bc95b606a40f.png

非常惊艳,这货竟然学会了抽象!

虽然它抽象出的类型叫EmployeeType,不如PaymentClassification那么精确,但是大方向是一致的:用EmployeeType来管理支付规则,员工类型发生变化时,Employee类不需要变化。

说实话,我看到它给出这个结果,内心是很吃惊的,可以说,能超越相当多的程序员了。

接下来我又问它关于支付周期怎么处理:

58162b06bad93ade2f5eed3f9b153caf.png

这一次它的抽象更加厉害,直接给出了精确的名称:PaymentSchedule,还有相关的伪代码!

e9a35c68a277e48567ad3673a50c8e1c.png

它还特别提到了,当需要修改支付周期时,只需要更改PaymentSchedule即可,不用修改原有的员工类,组合优于继承,再次体现出来。

这和书中的例子几乎一样了:

6b6b06f919ddc5d5c9089619886c267d.png

继续问支付方法的处理方式:

41eb5697b54c3bb571d63118cae54540.png

不出所料,它的设计依然很棒:

40f50fb87fc57df3e1f8a152f0b63530.png

实际上,ChatGPT的设计,已经非常接近书中的最终方案了:

f96a5008b05f59865ffadb2e24273e8a.png

尝试到这里,心里有一丝失落和不甘,这个ChatGPT实在是太强悍了,展示出来很强的设计能力,并且对话过程非常流畅。

人工智能真的能理解需求,学会了抽象,能设计出漂亮的类结构了吗?程序员的核心能力被替代,程序员的危机真的来了?

我又问了它一个问题,让它把类图画一下:

bd6e5e1ec2f6b629d5146cea350fd6b4.png

037290394c33d2869c0d045ccc2725d0.png

bf16e089771ad5e7b20cc215ed3e630b.png

等等,这里的类名怎么和之前的不一样了,怎么出现了一个新的概念:工会成员? 我在这次对话中,可是从来没有告诉过它这个概念啊!它从哪里知道的?

最大的可能是,这货并没有理解我告诉它的需求,它之前应该学过这个案例,依然是在“背诵”它学习的东西,自作主张把工会成员也给我弄出来了,从而露出了马脚。 

我关掉了ChatGPT网站,再次登录,重新用同样的内容和它交互,这次的结果彻底地把它暴露了。

7af8318a3666534ae3ea95c0cea74dcc.png

566f262a97d9b5860f9dfc902826611f.png

看到没有,这次它根本没有抽象出PaymentClassification/EmployeeType,它竟然推荐了面向过程的思路,添加一个type的属性,用switch来解决问题。这比之前的方案要差太多了。

最后聊一下感受吧!ChatGPT确实很厉害,应该是学习了海量的数据,肚子里货很多,但是它依然没有真正的理解需求,它告诉我们的答案就是在现有知识中做提炼和整合。

如果抛给它一个完全全新的领域问题,估计它会懵的,大家可以拿实际业务问题来玩一下。

所以,ChatGPT是一个好帮手,但是你要想完全依赖它,可要掂量掂量了,它告诉你的可能是优雅的代码,也可能是垃圾代码。

(完)

点击下方图片,查看更多精彩

bad4687662f586cb2b2fefe5b1efe889.png

44dea097fc520dfa22e3714906a0a3a5.png

f3b1a9c67a3efcf1bd08ae3ccd3e8f35.png

9062f2f18bc07f4e6cb318a104e1930c.png

c8064a82200b6f02167866151791357e.png

文章出处登录后可见!

已经登录?立即刷新

共计人评分,平均

到目前为止还没有投票!成为第一位评论此文章。

(0)
乘风的头像乘风管理团队
上一篇 2023年12月27日
下一篇 2023年12月27日

相关推荐