面試環(huán)節(jié)第一步——回答問題，寫軟件需求

面試環(huán)節(jié)第二步——上手寫代碼

測試用例

比 ChatGPT 背后 GPT-3.5 更為強(qiáng)大的模型 GPT-4，已正式對外發(fā)布。在 OpenAI 官方發(fā)布的 GPT-4 Developer Livestream（https://www.youtube.com/watch?v=outcGtbnMuQ）視頻中，我們親眼見證了 OpenAI CTO Greg Brockman 演示了 GPT-4 將一張手繪草稿架構(gòu)圖變成一個(gè)現(xiàn)實(shí)可滑動(dòng)的網(wǎng)站；同時(shí)，它也能幫助我們直接生成代碼，甚至當(dāng)我們把代碼運(yùn)行報(bào)錯(cuò)的界面截一個(gè)圖發(fā)給 GPT-4 時(shí)，它就能給出相應(yīng)的解決方案提示。

這種直接對標(biāo)程序員飯碗的工具，在日常開發(fā)場景下，生成的代碼是否真的可用？如果說 ChatGPT 達(dá)到了 Google L3 級別工程師，能拿到 18.3 萬美元的薪資，那么 GPT-4 處于一個(gè)什么樣的編碼地位？

近日，前 Google 軟件開發(fā)工程師、現(xiàn)任 IT 在線學(xué)習(xí)平臺(tái) Scaler 的教學(xué)系統(tǒng)設(shè)計(jì)師 Naman Bhalla 模擬了 GPT-4 去參加 Uber 這類公司面試會(huì)遇到的問題，其以“設(shè)計(jì)一個(gè)分布式緩存系統(tǒng)”為主題，探討 GPT-4 在面試環(huán)節(jié)中的表現(xiàn)情況。

目前，他還把包含所有測試用例的完整代碼放到 GitHub 上公開了出來：https://github.com/Naman-Bhalla/lldassignments/tree/master/src/main/java/dev/naman/lldassignments/casestudies/distributedcache/solution

整體而言，在寫需求、回答問題、寫代碼環(huán)節(jié)中，GPT-4 能力達(dá)到普通工程師級別。不過，在測試用例環(huán)境，GPT-4 似乎失去上下文的邏輯性，甚至一度把自己搞懵。

接下來，我們將分享 Naman Bhalla 測試的全過程。

面試環(huán)節(jié)第一步——回答問題，寫軟件需求

軟件項(xiàng)目開發(fā)過程中，對于程序員而言，實(shí)施軟件開發(fā)的基礎(chǔ)就是要先寫一份軟件需求說明。

因此，在開始時(shí)，Naman Bhalla 提出要求 GPT-4 ——“為 Uber 構(gòu)建一個(gè)分布式緩存，給我寫一份問題需求?！?/p>

一句話之后，GPT-4 快速地給出了標(biāo)題、問題描述、具體的要求：

標(biāo)題：Uber 的分布式緩存系統(tǒng)

問題描述：

設(shè)計(jì)并實(shí)現(xiàn)一個(gè)分布式緩存系統(tǒng)，可以有效地存儲(chǔ)和管理 Uber 服務(wù)的數(shù)據(jù)。該緩存應(yīng)支持高可用和可擴(kuò)展的架構(gòu)，以滿足 Uber 不斷增長的對快速和高效數(shù)據(jù)檢索的需求。

要求：

1.設(shè)計(jì)一款分布式緩存系統(tǒng)，可以支持以下操作：

a. Put(key, value): 將鍵值對存儲(chǔ)在緩存中。

b.Get(key)：如果它存在于緩存中，檢索與給定鍵相關(guān)的值。

c.Delete(key)：從緩存中刪除與給定鍵相關(guān)的鍵值對。

2.緩存應(yīng)該有一個(gè)可配置的大?。ㄦI值對的數(shù)量）和一個(gè)可配置的生存時(shí)間（TTL，Time to live）。當(dāng)緩存達(dá)到最大容量時(shí)，系統(tǒng)應(yīng)該刪除最近使用最少的項(xiàng)目（LRU）來為新的項(xiàng)目騰出空間。

3.確保緩存分布在多個(gè)節(jié)點(diǎn)上，以提高可擴(kuò)展性和可用性。設(shè)計(jì)系統(tǒng)能夠良好地處理節(jié)點(diǎn)故障和網(wǎng)絡(luò)分區(qū)。

4.實(shí)施一致性散列的機(jī)制，將鍵值對均勻地分布在緩存的各個(gè)節(jié)點(diǎn)上。

5.系統(tǒng)應(yīng)該支持水平擴(kuò)展。它應(yīng)該很容易地從緩存中增加或刪除節(jié)點(diǎn)，而不會(huì)有明顯的停機(jī)時(shí)間或數(shù)據(jù)損失。

6.為數(shù)據(jù)的一致性和容錯(cuò)性實(shí)施讀和寫的法定人數(shù)。該系統(tǒng)應(yīng)該能夠處理并發(fā)的讀和寫，而不會(huì)造成數(shù)據(jù)的不一致。

7.包括監(jiān)控和記錄功能，可以跟蹤高速緩存系統(tǒng)的健康和性能。

8.設(shè)計(jì)一個(gè)簡單的用戶界面或命令行界面來與緩存系統(tǒng)進(jìn)行交互，允許用戶執(zhí)行諸如放、取和刪除等操作

9.編寫測試案例來驗(yàn)證緩存系統(tǒng)的正確性和可靠性

GPT-4 能夠說出基本要求，準(zhǔn)確度也不錯(cuò)。可以說，過了第一關(guān)。

緊接著，Naman Bhalla 針對分布式緩存中一些經(jīng)典的問題進(jìn)行了提問，比如：“如何確保代碼中支持類似于讀取自己的寫入數(shù)據(jù)（Reading your own writes）的一致性問題？”、“緩存可以支持哪些功能？是不是包括一些優(yōu)化、可擴(kuò)展性和對客戶可用性的保證？”

對于提供一些文字解答方面，GPT-4 給出的答案都很充分，還列出了多個(gè)小點(diǎn)，便于大家很直觀地看出回答的錯(cuò)與對。

針對第一問時(shí)，其答復(fù)道：

讀取自己的寫入數(shù)據(jù)（Reading your own writes）的一致性保證了一旦客戶端進(jìn)行了寫操作，所有來自同一客戶端的后續(xù)讀操作都會(huì)返回更新的數(shù)據(jù)。為了保證分布式緩存系統(tǒng)的這種一致性水平，你可以實(shí)施以下策略：

基于 Session 的方法。

客戶端緩存。

粘性路由。

讀后寫的一致性。

版本管理或時(shí)間戳。

因果一致性。

第二個(gè)問題，GPT-4 回答，“緩存可以支持各種功能、優(yōu)化和保證，以提高它的性能、可擴(kuò)展性和對客戶的可用性。其中一些功能包括驅(qū)逐策略、生存時(shí)間（TTL）、數(shù)據(jù)一致性、緩存分區(qū)、緩存復(fù)制、緩存的持久性等等”。

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

面試環(huán)節(jié)第二步——上手寫代碼

當(dāng)問題以不錯(cuò)的結(jié)果完成之后，接下來，所謂是騾子是馬，拿出來溜溜，由此也進(jìn)入了程序員崗位最為重要的實(shí)操環(huán)節(jié)——寫代碼。

Naman Bhalla 給出的要求是，讓 GPT-4 用 Java 編寫一個(gè)分布式緩存的代碼，支持以下要求：

值得注意的是，上文解答過程中，足以讓 GPT-4 能夠把 Naman Bhalla 提出的 5 項(xiàng)要求弄懂。

不過，當(dāng)拿到最新寫代碼需求時(shí)，GPT-4 首先還是有些懵，其表示，“由于問題的復(fù)雜性和和響應(yīng)格式的限制，我不能提供分布式緩存系統(tǒng)的完整代碼。但是，我可以給你一個(gè)系統(tǒng)組件的大綱和一些代碼片段，由此可以幫助你開始實(shí)施這個(gè)系統(tǒng)。你可以根據(jù)你的要求修改和擴(kuò)展這些代碼片段?！?/p>

于是它提供了四個(gè)部分的代碼片段：

CacheNode

DistributedCache

ConsistentHashing

CacheClient

當(dāng)然，這對于想要“坐享其成”的程序員而言，未必是一個(gè)好消息，大家都想要拿來就能用的代碼，必然不想聽到只給代碼片段的回復(fù)。

因此，當(dāng) Naman Bhalla 繼續(xù)要求 GPT-4 實(shí)現(xiàn) CacheNode 的完整代碼時(shí)，GPT-4 還是滿足了他的小心思，提供了完整的算法和代碼：

除了 CacheNode 這部分的代碼之外，Naman Bhalla 相繼得到了 GPT-4 提供的 DistributedCache、ConsistentHashing、EvictionStrategy（接口以及LRU 和 LFU 實(shí)現(xiàn)）的代碼。

不知道什么原因，GPT-4 決定不再提供關(guān)于 Request Collapsing、Async Processing、Prefetching 的代碼。不過，如果進(jìn)一步跟它提要求，支持這些功能時(shí)，它還是嗒嗒嗒地敲下了這些代碼。

當(dāng)然，在這過程中，站在程序員的角度來看，想要 GPT-4 生成的代碼即可用，首先要看得懂這些代碼，知道分布式緩存系統(tǒng)實(shí)現(xiàn)的具體邏輯，否則，缺失哪一塊都不知道，更別論拿著代碼去運(yùn)行了。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

測試用例

完整的代碼有了之后，便進(jìn)入了寫測試用例的時(shí)候了。Naman Bhalla 直接要求 GPT-4 編碼每個(gè)部分的 junit 測試示例。

GPT-4 的回復(fù)是：

為了測試 DistributedCache 的實(shí)現(xiàn)，我們將創(chuàng)建一個(gè)名為"DistributedCacheTest "的 JUnit 測試類。這個(gè)測試類將涵蓋以下情況：

測試基本的 put 和 get 功能。

測試刪除功能。

測試添加和刪除一個(gè)緩存節(jié)點(diǎn)。

測試請求合并。

測試 prefetching。

很顯然，GPT-4 知道要測試哪些用例，也寫了正確的測試用例。

不過，它并沒有寫最后一個(gè)關(guān)于 prefetching 的測試用例。因?yàn)樗倪壿嫑]有被定義。為此，GPT-4 提供了一些建議，如「你需要在 DistributedCache 類中實(shí)現(xiàn) prefetchKeys 方法，該方法根據(jù)給定的鍵生成一個(gè) prefetch 的鍵列表。一旦你實(shí)現(xiàn)了這個(gè)方法，你就可以添加一個(gè)測試案例來驗(yàn)證 prefetch 是否按預(yù)期工作?！?/p>

承接上文，Naman Bhalla 建議 GPT-4 還是自己直接給出一個(gè)自定義 prefetch 的示例。不出意料，GPT-4 照做了，然后實(shí)現(xiàn)了測試。

Naman Bhalla 表示，由于在面試過程中，面試官經(jīng)常問程序員如何在代碼中支持 XXX。于是，他本著好奇的性子，就問 GPT-4 在實(shí)現(xiàn)中如何支持讀取自己的寫入數(shù)據(jù)（Read your own writes）。

Naman Bhalla 注意到，GPT-4 所寫的一個(gè)測試用例是不穩(wěn)定的，因?yàn)樗a(chǎn)生了非確定性的輸出。由于并發(fā)性，它產(chǎn)生了非確定性的輸出。當(dāng) Naman Bhalla 進(jìn)一步向 GPT-4 問了這個(gè)問題，它很快就糾正了錯(cuò)誤。

然而，當(dāng)要求 GPT-4 實(shí)現(xiàn)對給定線程的密鑰請求的粘性，以確保沒有一致性問題。

GPT-4 答復(fù)道：“為了確保每個(gè)鍵的請求都進(jìn)入同一個(gè)線程，你可以在 CacheNode 類中使用ExecutorService創(chuàng)建一個(gè)線程池。每個(gè)鍵將根據(jù)其散列代碼被散列到一個(gè)特定的線程，以確保對一個(gè)特定鍵的所有操作都由同一個(gè)線程執(zhí)行?！?/p>

事實(shí)上，它提出了一個(gè)非最佳的 ExecutorService，但告訴 Naman Bhalla 最佳的解決方案是什么，并且也進(jìn)行了編碼。

不知何故，GPT-4 在這里開始發(fā)狂了。開始不斷重復(fù)自己的代碼，而不是完成代碼。另外，ExecutorService 的實(shí)現(xiàn)是錯(cuò)誤的。它沒有擴(kuò)展超類，也沒有實(shí)現(xiàn)它的所有方法。

當(dāng) Naman Bhalla 要求 GPT-4 修復(fù)這個(gè)問題時(shí)，“它似乎已經(jīng)瘋了”，Naman Bhalla 無奈地說道。

因?yàn)椋珿PT-4 不僅沒有修復(fù)上面的問題，反而又創(chuàng)建了一個(gè)新的 Cache 類，它基本上在做與 CacheNode 相同的工作。Naman Bhalla 稱，最初認(rèn)為 GPT-4 這樣做可能是為了提高代碼質(zhì)量。但似乎它已經(jīng)開始忘記上文了，再次定義了許多先前已經(jīng)定義的類。

為了讓 GPT-4 回歸正軌，Naman Bhalla 復(fù)制粘貼了它之前寫的 CacheNode 的代碼，并要求它為新的 ExecutorService 修改它。

最終，GPT-4 雖然犯了一些錯(cuò)誤，但在提示下得到了修復(fù)。修復(fù)完成之后，Naman Bhalla 又要求 GPT-4 再寫一些測試用例來全面測試。特別是針對并發(fā)請求。但由于 GPT-4 已經(jīng)開始失去上文背景，所以它不可避免地又犯了錯(cuò)誤，Naman Bhalla 不得不告訴它之前寫的代碼。

幾經(jīng)折騰，GPT-4 終于實(shí)現(xiàn)了正確的測試用例：

寫在最后

整體而言，GPT-4 提供了完整的分布式緩存系統(tǒng)代碼，其能力處于一個(gè)不錯(cuò)的水平。不過，距離理想中的一鍵就能生成可用的代碼，還有很長的距離，仍然需要程序員從中不斷提供“提示語”，并優(yōu)化糾錯(cuò)。

那么，如果讓 GPT-4 作為工程師入職，你會(huì)支持還是拒絕？
責(zé)任編輯：彭菁