更關鍵的問題是如何辨識它的回答是正確的，我現在手邊有標準答案，可以對它做考核。而在實際專案中，面對的都是未知數，如果沒有經驗，如何知道GPT-4所給的設計是有效的？是能解決問題的？
ChatGPT是程式設計師的好幫手？還是要幹掉程式設計師？
我覺得不僅要看它產生程式碼的能力，更關鍵的是要看它是否具備強大的設計能力。
設計能力有兩個層面，一個是高層的，例如架構設計，系統設計。
一個是相對低層的設計能力，主要設計具體的類別和介面。
今天我們來看看它在這兩個方面分別表現如何。
由於ChatGPT的回答特別囉嗦，我會刪除一些細節，只保留重要部分。
出於公司保密的原因，沒法用真實項目，只能用書中公開的案例來考考它。
一、架構設計
這裡我使用的案例是客服工單系統，是從一本書《從程式設計師到架構師》中提取出來的，這本書有很多實戰案例，順便向大家推薦一下。
客服工單系統的大概需求是這樣：
有客服系統，用的MySQL資料庫，每年產生的工單有3000多萬條，每個工單會有5~6次操作，這些操作也要記錄下來，這樣每年就會有超過1.5億筆操作記錄。
現在客服打開系統查看工單的時候，速度非常慢，10秒才能打開， 現在對SQL語句，索引等已經優化到了極致，無法再繼續提升。
現在系統效能已經嚴重影響了客服的處理效率，客戶要求一週之內解決這個問題，時間很短。
經過分析業務流程發現，工單如果處理完成，就會增加一個狀態“關閉”，這樣的工單，一年都打開不了幾次。
團隊沒有用過資料庫分割區，一週內沒有任何把握搞定，就放棄了資料庫分割的方案。
對於這個問題，書中的解決方案是“冷熱分離”，日常操作“熱數據庫”，把“關閉”的工單移入新的“冷數據庫”，但是在數據冷熱分離過程中，需要處理資料一致性問題。
把這個需求丟給GPT-4，看它如何回答。
GPT-4：在這種情況下，我建議採用以下兩種方法來解決效能問題：
1.資料庫歸檔：由於大部分已關閉的工單基本上不再需要訪問，可以將這些工單資料從主資料庫移動到一個歸檔資料庫中。這樣，主資料庫的大小將大大減小，從而提高查詢速度。歸檔資料庫可以定期（如每月或每季）更新，將已關閉的工單移至歸檔資料庫中...
具體操作步驟如下：
a. 建立一個新的MySQL資料庫，用於儲存歸檔資料。
b. 撰寫一個腳本，定期將已關閉的工單及其相關作業記錄從主資料 函式庫移至歸檔資料庫，並確保資料一致性。
c. 修改客服系統，使其預設只查詢主資料庫中的未歸檔資料。
d. 提供一個單獨的介面或工具，讓客服人員在需要時查詢歸檔資料 資料庫中的資料。
- 快取：...略...
#不錯，它一下子就抓住了重點，給出了資料庫歸檔的方案，還有具體的操作步驟。
不過，需求中有一定的提示，這個方案也容易想到。
劉欣：在你的操作步驟中，如何保證資料一致性，這裡需要操作兩個資料庫啊
GPT-4 ：確保資料一致性是非常重要的。在操作兩個資料庫時，可以採用以下方法來確保資料一致性：
- 使用事務：事務可以確保一組操作要么全部成功，要么全部失敗。 .....略....
劉欣：你在使用交易的時候，怎麼能開啟一個跨越兩個資料庫的交易？
GPT-4: 抱歉，我在先前的回答中確實犯了一個錯誤。在MySQL中，我們無法直接在兩個不同的資料庫之間使用單一事務。在這種情況下，可以考慮使用其他策略來確保資料一致性。一個可行的方法是使用「兩階段提交協議」(Two-Phase Commit, 2PC)。 ....略....
劉欣：兩階段提交協定很脆弱，有別的安全的辦法來實現資料從主資料庫移動到歸檔資料庫嗎？
#
GPT-4: 抱歉之前的方案沒有完全滿足您的需求。這裡我提供一個新的方案，使用訊息佇列（例如RabbitMQ、Kafka或Amazon SQS）來確保資料遷移過程的一致性。這種方法可以將資料遷移過程分為兩個獨立的步驟，確保在出錯時可以輕鬆回滾。 .....略.....
劉欣：如果不使用MQ，完全自己寫程式碼實現，如何保證資料遷移過程中的一致性？
GPT-4: 如果您不想使用訊息佇列，您可以使用下列方法自行編寫程式碼來確保資料遷移過程中的一致性：
- #使用鎖定和標記欄位：
a. 為工單表和操作記錄表分別新增一個名為「is_migrated」的布林字段，用於標記記錄是否已遷移。
b. 編寫一個腳本或程序，從主資料庫中查詢滿足遷移條件（例如，已關閉的工單且「is_migrated」為false）的記錄。
......略......
嗯，到此為之，它終於找到了一個方案，和書中有點類似，就是用一個欄位來標記「是否已遷移」。
但是，無論我怎麼提示，它也不會提出如何做冪等性的方案，我就放棄了。
劉欣：歸檔資料庫資料量很大，查詢非常慢，但查詢基本上都是"根據客戶ID查出工單，然後根據工單ID查出該工單所有的處理記錄"，這有什麼辦法可以解決？
GPT-4 ：針對這種查詢模式，可以採取下列策略來最佳化歸檔資料庫的查詢效能：
- 為客戶ID和工單ID建立索引：......略......
- 資料庫表分割區：......略......
- 資料庫檢視：.. ....略......
- 結果快取：......略......
- 分割讀寫負載：..... .略......
- 優化硬體和配置：......略......
這些方案都無法有效解決不了問題，正確的方案是用HBase這樣的NoSQL資料庫，它是想不到了。
二、詳細設計
#我使用的案例依然是薪水支付，這是從經典書《敏捷軟體開發：原則，模式與實踐》中提取出來的。
這個案例的需求是這樣的：
#該系統由一個公司資料庫以及和員工相關的資料組成，系統需要準時地依照規則給員工薪水
員工有三種類型
#1.鐘點工，每個小時有固定報酬，他們每天提交工作時間卡，其中記錄了日期以及工作小時數，如果每天工作超過8小時，按1.5倍進行支付。每週五對他們進行支付。
2.月薪員工，薪資固定，每個月的最後一個工作日對他們進行支付
3.銷售人員，有固定工資，但會根據他們的銷售情況，支付給他們一定數量的佣金，他們會提交銷售憑條，其中記錄了銷售的日期和數量。每隔一周的周五對他們進行支付。
員工可以選擇付款方式，可以把支票郵寄到他們指定的郵政地址，也可以保存在財務那裡隨時支取，或者要求直接存入他們指定的銀行帳戶。
看了這個需求以後，一般的設計是這樣的：
Employee 作為基底類，不同類型的僱員類別來繼承。
但是這個需求會有變更，客戶要求員工類型可以變更，例如從鐘點工變成月薪僱員，這樣上面的設計就不行了。
這時候應該要做個抽象，，用一個類別PaymentClassification來表達支付分類，然後讓Employee類別持有這個實例，簡單說就是用組合取代繼承。
這是一個陷阱，也是給ChatGPT挖的一個坑，看看它是如何處理的。
正式開始，我把需求告訴它，讓它設計。
沒想到，它一上來就給我寫Python程式碼，這太多細節了，我馬上讓它停止輸出。
劉欣：不用展示程式碼，把類別描述出來就可以。
GPT-4 : 好的，根據您的需求，我們可以設計以下類別和相關的屬性和方法：
- 基底類別 Employee: ......略......
- HourlyEmployee 類，繼承自Employee 類別：......略......
- SalariedEmployee 類，繼承自Employee 類別：......略......
- SalesEmployee 類，繼承自SalariedEmployee 類別：......略.. ....
- PaymentMethod 類別：略
#還真是不錯，它「理解」了需求，從中抽取了名詞進行類別的設計，它設計出來的Employee，HourlyEmployee，SalariedEmployee，SalesEmployee和第一個UML圖幾乎是一樣的。
已經達到了物件導向設計的初級水準。
接下來開始挖洞：
劉欣：上面的類別設計得很好，但是如果一個人剛開始是鐘點工，後來變成了月薪員工，上面的設計就無法支援這種變更了，這該怎麼辦呢？
GPT-4 ：為了解決您提到的問題，我們可以將員工的薪水計算策略從 Employee 類別中分離出來，使用策略模式進行設計。這樣，我們可以在不修改 Employee 類別的情況下，為其動態更改薪水計算策略。
在這個設計下，我們需要對原來的類別結構做一些調整：
新增方法：set_salary_strategy，用於設定員工的薪水計算策略
- 移除原來的子類別HourlyEmployee、SalariedEmployee 和SalesEmployee，因為我們將薪水計算策略從Employee 類別中分離出來。
- 新增抽象類別 SalaryStrategy，作為薪水計算策略的基底類別
- 新增特定策略類別：
HourlySalary 類，繼承自SalaryStrategy 類別
SalariedSalary 類，繼承自SalaryStrategy 類別
SalesSalary 類，繼承自SalaryStrategy 類別
透過以上調整，現在可以在不修改Employee 類別的情況下為其動態變更薪水計算策略。當員工從鐘點工變成月薪員工時，只需為其設定新的薪水計算策略即可。
不得不說，GPT-4非常厲害！
它用上了策略模式，把薪水計算策略SalaryStrategy抽象化了出來。
和第二個UML圖相比，除了名稱不同，基本上一樣了。
可以說，能做到這一步，就可以超越很多程式設計師了。
我注意到，它一直沒有處理支付週期的問題。我開始繼續發問：
劉欣：原來的需求中還有支付的時間，例如鐘點工每週五支付，這個該怎麼設計？
GPT-4: 為了處理不同類型員工的支付時間，我們可以在 SalaryStrategy 基類中引入一個抽象方法 should_pay_today，該方法根據當前日期判斷是否應該支付薪水。接著，在具體的策略類別中實作這個方法。
......略......
這裡它犯了一個錯誤，把支付週期放到了薪水計算策略中，還美名其曰「易於維護與擴展」。
劉欣：支付時間和薪水運算策略是兩個概念，放在一起不太好，怎麼才能達到最大的彈性？
GPT-4 ：您是對的，支付時間和薪水計算策略是兩個不同的概念。為了讓設計更具彈性，我們可以將支付時間從薪水計算策略中分離出來，建立一個新的抽象類別 PaymentSchedule，用於處理支付時間的邏輯。這樣，我們可以為每位員工分別設定薪水計算策略和支付時間策略。
以下是調整後的類別結構：
保留基底類別Employee:
方法：set_payment_method，用於設定員工的付款方式
##方法：set_salary_strategy，用於設定員工的薪水計算策略
新增方法：set_payment_schedule，用於設定員工的支付時間策略
保留抽象類別SalaryStrategy 及其具體策略類，不做改變。 - 新增抽象類別 PaymentSchedule，作為支付時間策略的基底類別：...略...
- 新增特定支付時間策略類，繼承PaymentSchedule：
-
WeeklyPayment 類別...略...
MonthlyPayment 類別 ...略...
BiweeklyPayment 類別 ...略...
保留PaymentMethod 類別及其子類，不做改動。 -
非常驚艷! 它似乎知道我腦海中所想，PaymentSchedule 和 SalaryStrategy 給分開了！
到目前為止，它已經實現了書中最終的，也可能是最好的設計：
##三、小結
在在詳細設計層面上，GPT-4的表現遠強於架構設計。
碼農翻身的老讀者知道，我在去年用薪水支付案例測試過GPT-3.5， 當時它就是在背誦答案，甚至會給出超出需求之外的設計。
但是GPT-4不同了，它的設計能力更進了一步，在程式設計師的提示下，他已經學會了分離關注點。
在架構設計上，感覺GPT-4掌握了很多知識，但是無法有效地應用到複雜問題上，出的解決方案很混亂，離我們想要的還比較遠。
更關鍵的問題是如何辨識它的答案是正確的，我現在手邊有標準答案，可以對它做考核。而在實際專案中，面對的都是未知數，如果沒有經驗，如何知道GPT-4所給的設計是有效的？是能解決問題的？
以上是ChatGPT開始威脅程式設計師的核心能力了！的詳細內容。更多資訊請關注PHP中文網其他相關文章！
