最近有好几个人给我安利ChatGPT，说老刘你去看看，这个产品好厉害，说不定我们程序员要失业了。一开始只是笑笑，怎么可能？我以前的观点一直是在我有生之年，AI绝对不可能杀死程序员。不过安利的人太多了，忍不住注册个账号看看。出乎意料的是，这款产品并未对中国开放。网上有一些攻略。我觉得很麻烦。我连忙打电话给我在国外的好兄弟，让他帮忙注册一个账号。为了开始，我决定跳过简单的问题和答案，例如：如何反转字符串？如何进行HTTP调用？因为这种东西对于读过无数代码的AI来说太幼稚了，根本无法测试它的威力有多大。程序员的核心能力之一就是拿到需求，做出优雅的设计。我们拿这个来测试一下。先来个简单的问题：（点击放大）果然“背诵”得很好！它最后说的原则是：尽量使用合成/聚合而不是继承来实现复用。这确实是面向对象的一个??重要设计原则。ChatGPT可以应用这些原则吗？先问能不能做设计：那真不错，我们开始做规模化。正好手头有一个经典案例：工资支付，摘自经典书籍《敏捷软件开发：原则，模式和实践》。本案例需求如下：系统由公司数据库和员工相关数据组成。系统需要按时按规定给员工发工资。员工分为三种。工作时间卡，记录日期和工作小时数，如果每天工作超过8小时，则支付1.5倍。他们每周五领薪水。2.月薪员工，固定工资，每月最后一个工作日发给他们3.销售人员，有固定工资，但会根据销售情况支付一定的佣金，并提交销售凭证，它记录了销售的日期和数量。他们每隔一个星期五发薪水。员工可以选择他们想要的支付方式，将支票邮寄到他们指定的邮寄地址，将支票保存在财政部以备随时提取，或者要求直接存入他们指定的银行账户。看了这个需求，大致的设计是这样的：以Employee为基类，继承不同类型的employee类。然而，这一要求将会改变。客户要求员工类型可以改变，比如从兼职员工变成月薪员工，所以上面的设计不行。这时候我们应该做一个抽象，用一个类PaymentClassification来表达支付分类，然后让Employee类持有这个实例。简单的说就是用组合代替继承。这相当于一个陷阱。我们的程序员可以识别和抽象。这个ChatGPT可以工作吗？我真的很好奇。先问最开始的需求，ChatGPT的回答如下：（点击看大图）别说了，真好，它“看懂”需求，从中提取名词进行类设计，设计类的继承关系。已达到面向对象设计的初级水平。接下来是重点，给他挖个坑：厉害了，这家伙竟然学会了抽象！虽然它抽象出来的类型叫做EmployeeType，没有PaymentClassification那么精确，但是大方向是一样的：用EmployeeType来管理支付规则，当员工类型改变时，Employee类不需要改变。老实说，当我看到这个结果时，我非常惊讶。可以说是可以超越不少程序员了。接下来问它支付周期怎么处理：这次它的抽象更强大，直接给出了准确的名字：PaymentSchedule，以及相关的伪代码！还特别提到，当需要修改支付周期时，只需要修改PaymentSchedule，不需要修改原来的employee类。组合优于继承，再次体现。这个和书上的例子差不多：继续问支付方式是怎么处理的：果然，它的设计还是很棒的：其实ChatGPT的设计很接近书上的最终解决方案：try说到这里，心里有一丝失落和不甘。这个ChatGPT真的很强大，展现了很强的设计能力，对话过程也很流畅。人工智能真的能理解需求、学习抽象、设计漂亮的类结构吗？程序员的核心能力被取代，程序员的危机真的要来了吗？我又问了它一个问题，让它画类图：等等，为什么这里的类名和之前的不一样，为什么会出现一个新的概念：unionmember？在这次谈话中，我从来没有告诉它这个概念！它从哪里知道的？最大的可能就是这家伙没听懂我跟它说的需求。这个案子它应该早就知道了，它还在“背诵”所学，主动给我找工会会员，这样就暴露了底线。我关闭了ChatGPT网站，重新登录，再次以同样的内容与之交互，这次结果彻底暴露了。看，这次完全没有抽象PaymentClassification/EmployeeType，居然推荐了一个面向过程的思路，加一个type属性，用switch来解决问题。这比之前的计划差多了。最后说说感受！ChatGPT确实很强大。应该是它学习了海量数据，肚子里有很多货，但还是没有真正的理解需求。它告诉我们的答案是提炼和整合现有知识。如果你丢给它一个全新的领域问题，估计它会一头雾水，拿实际业务问题来玩。因此，ChatGPT是个好帮手，但如果要完全依赖它，就得权衡一下了。它可能告诉你优雅的代码或垃圾代码。
