ChatGPT是程序员的好帮手？还是要干掉程序员？

我觉得不仅要看它生成代码的能力，更关键的是要看它是否具备强大的设计能力。

设计能力有两个层面，一个是高层的，例如架构设计，系统设计。

一个是相对低层的设计能力，主要设计具体的类和接口。

今天我们看看它在这两个方面分别表现如何。

由于ChatGPT的回答特别啰嗦，我会删除一些细节，只保留重要部分。

出于公司保密的原因，没法用真实项目，只能用书籍中公开的案例来考考它。

01

架构设计

这里我使用的案例是客服工单系统，是从一本书《从程序员到架构师》中提取出来的，这本书有很多实战案例，顺便向大家推荐一下。

客服工单系统的大概需求是这样：

有个客服系统，用的MySQL数据库，每年产生的工单有3000多万条，每个工单会有5~6次操作，这些操作也要记录下来，这样每年就会有超过1.5亿条操作记录。

现在客服打开系统查看工单的时候，速度非常慢，10秒才能打开， 现在对SQL语句，索引等已经优化到了极致，无法再继续提升。

现在系统性能已经严重影响了客服的处理效率，客户要求一周之内解决这个问题，时间很短。

经过分析业务流程发现，工单如果处理完成，就会增加一个状态“关闭”，这样的工单，一年都打开不了几次。

团队没有用过数据库分区，一周内没有任何把握搞定，就放弃了数据库分区的方案。

对于这个问题，书中的解决方案是“冷热分离”，日常操作“热数据库”，把“关闭”的工单移入新的“冷数据库”，但是在数据冷热分离过程中，需要处理数据一致性问题。

把这个需求抛给GPT-4，看它如何回答。

GPT-4：在这种情况下，我建议采用以下两种方法来解决性能问题：

1. 数据库归档：由于大部分已关闭的工单基本上不再需要访问，可以将这些工单数据从主数据库中移动到一个归档数据库中。这样，主数据库的大小将大大减小，从而提高查询速度。归档数据库可以定期（如每月或每季度）更新，将已关闭的工单移动到归档数据库中......

具体操作步骤如下：

a. 创建一个新的MySQL数据库，用于存储归档数据。

b. 编写一个脚本，定期将已关闭的工单及其相关操作记录从主数据    库移动到归档数据库，并确保数据一致性。

c. 修改客服系统，使其默认仅查询主数据库中的未归档数据。

d. 提供一个单独的界面或工具，供客服人员在需要时查询归档数据    库中的数据。

1. 缓存：...略...

不错，它一下子就抓住了重点，给出了数据库归档的方案，还有具体的操作步骤。

不过，需求中有一定的提示，这个方案也容易想到。

刘欣：在你的操作步骤中，如何保证数据一致性，这里需要操作两个数据库啊

GPT-4 ：确保数据一致性是非常重要的。在操作两个数据库时，可以采用以下方法来保证数据一致性：

1. 使用事务：事务可以确保一组操作要么全部成功，要么全部失败。.....略....

刘欣：你在使用事务的时候，怎么能开启一个跨越两个数据库的事务？

GPT-4: 抱歉，我在之前的回答中确实犯了一个错误。在MySQL中，我们无法直接在两个不同的数据库之间使用单个事务。在这种情况下，可以考虑使用其他策略来确保数据一致性。一个可行的方法是使用“两阶段提交协议”(Two-Phase Commit, 2PC)。....略....

刘欣：两阶段提交协议很脆弱，有别的安全的办法来实现数据从主数据库移动到归档数据库吗？

GPT-4:  抱歉之前的方案没有完全满足您的需求。这里我提供一个新的方案，使用消息队列（例如RabbitMQ、Kafka或Amazon SQS）来确保数据迁移过程的一致性。这种方法可以将数据迁移过程分为两个独立的步骤，确保在出错时可以方便地回滚。.....略.....

刘欣：如果不使用MQ，完全自己写代码实现，如何保证数据迁移过程中的一致性？

GPT-4: 如果您不想使用消息队列，您可以使用以下方法自行编写代码来确保数据迁移过程中的一致性：

1. 使用锁和标记字段：

a. 为工单表和操作记录表分别添加一个名为“is_migrated”的布尔字段，用于标记记录是否已迁移。

b. 编写一个脚本或程序，从主数据库中查询满足迁移条件（例如，已关闭的工单且“is_migrated”为false）的记录。

......略......

嗯，到此为之，它终于找到了一个方案，和书中有点类似，就是用一个字段来标记“是否已迁移”。

但是，无论我怎么提示，它也不会提出如何做幂等性的方案，我就放弃了。

刘欣：归档数据库数据量很大，查询非常慢，但查询基本上都是"根据客户ID查出工单，然后根据工单ID查出该工单所有的处理记录"，这有什么办法来解决？

GPT-4 ：针对这种查询模式，可以采取以下策略来优化归档数据库的查询性能：

1. 为客户ID和工单ID创建索引：......略......

2. 数据库表分区：......略......

3. 数据库视图：......略......

4. 结果缓存：......略......

5. 拆分读写负载：......略......

6. 优化硬件和配置：......略......

这些方案都无法有效解决不了问题，正确的方案是用HBase这样的NoSQL数据库，它是想不到了。

02

详细设计

我使用的案例依然是薪水支付，这是从经典书《敏捷软件开发：原则，模式和实践》中提取出来的。 

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

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

员工有三种类型

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

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

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

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

看了这个需求以后，一般的设计是这样的：

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

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

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

这是一个陷阱，也是给ChatGPT挖的一个坑，看看它是如何处理的。

正式开始，我把需求告诉它，让它设计。

没想到，它一上来就给我写Python代码，这太多细节了，我马上让它停止输出。

刘欣：不用展示代码，把类描述出来就可以。

GPT-4 : 好的，根据您的需求，我们可以设计以下类和相关的属性和方法：

1. 基类 Employee: ......略......

1. HourlyEmployee 类，继承自 Employee 类：......略......

2. SalariedEmployee 类，继承自 Employee 类：......略......

3. SalesEmployee 类，继承自 SalariedEmployee 类：......略......

4. PaymentMethod 类：略

还真是不错，它“理解”了需求，从中抽取出了名词进行类的设计，它设计出来的Employee，HourlyEmployee，SalariedEmployee，SalesEmployee和第一个UML图几乎是一样的。

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

接下来开始挖坑：

刘欣：上面的类设计得很好，但是如果一个人刚开始是钟点工，后来变成了月薪员工，上面的设计就无法支持这种变更了，这该怎么办呢？

GPT-4 ：为了解决您提到的问题，我们可以将员工的薪水计算策略从 Employee 类中分离出来，使用策略模式进行设计。这样，我们可以在不修改 Employee 类的情况下，为其动态更改薪水计算策略。

在这种设计下，我们需要对原来的类结构进行一些调整：

1. 保留基类 Employee:

• • 新增方法：set_salary_strategy，用于设置员工的薪水计算策略

1. 移除原来的子类 HourlyEmployee、SalariedEmployee 和 SalesEmployee，因为我们将薪水计算策略从 Employee 类中分离出来。

2. 新增抽象类 SalaryStrategy，作为薪水计算策略的基类

3. 新增具体策略类：

• • HourlySalary 类，继承自 SalaryStrategy 类

• • SalariedSalary 类，继承自 SalaryStrategy 类

• • SalesSalary 类，继承自 SalaryStrategy 类

通过以上调整，现在可以在不修改 Employee 类的情况下为其动态更改薪水计算策略。当员工从钟点工变为月薪员工时，只需为其设置新的薪水计算策略即可。

不得不说，GPT-4非常厉害！

它用上了策略模式，把薪水计算策略SalaryStrategy给抽象了出来。

和第二个UML图相比，除了名称不同，基本上一样了。

可以说，能做到这一步，就可以超越很多程序员了。

我注意到，它一直没有处理支付周期的问题。我开始继续发问：

刘欣：原来的需求中还有支付的时间，例如钟点工每周五支付，这个该怎么设计？

GPT-4: 为了处理不同类型员工的支付时间，我们可以在 SalaryStrategy 基类中引入一个抽象方法 should_pay_today，该方法根据当前日期判断是否应该支付薪水。接着，在具体的策略类中实现这个方法。

......略......

这里它犯了一个错误，把支付周期放到了薪水计算策略中，还美名其曰“易于维护和扩展”。

刘欣：支付时间和薪水计算策略是两个概念，放在一起不太好，怎么才能达到最大的灵活性呢？

GPT-4 ：您是对的，支付时间和薪水计算策略是两个不同的概念。为了使设计更具灵活性，我们可以将支付时间从薪水计算策略中分离出来，创建一个新的抽象类 PaymentSchedule，用于处理支付时间的逻辑。这样，我们可以为每个员工分别设置薪水计算策略和支付时间策略。

以下是调整后的类结构：

1. 保留基类 Employee:

• • 属性：姓名、ID、地址

  • 方法：set_payment_method，用于设置员工的支付方式

  • 方法：set_salary_strategy，用于设置员工的薪水计算策略

  • 新增方法：set_payment_schedule，用于设置员工的支付时间策略

1. 保留抽象类 SalaryStrategy 及其具体策略类，不做改动。

2. 新增抽象类 PaymentSchedule，作为支付时间策略的基类：...略...

3. 新增具体支付时间策略类，继承PaymentSchedule：

• • WeeklyPayment 类 ...略...

• • MonthlyPayment 类 ...略...

• • BiweeklyPayment 类 ...略...

1. 保留 PaymentMethod 类及其子类，不做改动。

非常惊艳! 它似乎知道我脑海中所想，PaymentSchedule 和 SalaryStrategy 给分开了！

到目前为止，它已经实现了书中最终的，也可能是最好的设计：

03

小结

在详细设计层面上，GPT-4的表现远远强于架构设计。

码农翻身的老读者知道，我在去年用薪水支付案例测试过GPT-3.5， 当时它就是在背诵答案，甚至会给出超出需求之外的设计。

但是GPT-4不同了，它的设计能力更进了一步，在程序员的提示下，他已经学会了分离关注点。

在架构设计上，感觉GPT-4掌握了很多知识，但是无法有效地应用到复杂问题上，出的解决方案很混乱，离我们想要的还比较远。

更关键的问题是如何识别它的回答是正确的，我现在手头有标准答案，可以对它做考核。而在实际项目中，面对的都是未知数，如果没有经验，如何知道GPT-4给出的设计是有效的？是能解决问题的？

（完）

3月30日 13:30 - 18:30 亚马逊云科技创新大会线上线下（北京）同步开启，主题是全面拥抱Serverless时代，30+热点技术话题，涵盖了Serverless应用战略、架构进化、数据与分析、开发工具，可谓是一场Serverless盛宴，不容错过。

在北京的同学强烈推荐到现场看看，面对面交流，没法到现场的可以关注线上直播。

扫描下方二维码，立刻报名

点击下方图片，查看更多精彩文章