ホームページ > 記事 > テクノロジー周辺機器 > ChatGPT はプログラマの中核機能を脅かし始めています。
ChatGPT はプログラマの中核機能を脅かし始めています。
- 王林転載
- 2023-04-04 11:50:051488ブラウズ
より重要な問題は、その答えが正しいかどうかをどのように識別するかということですが、現在、標準的な答えが手元にあり、それを評価することができます。実際のプロジェクトでは未知の部分に直面することがありますが、経験がなければ、GPT-4 で与えられた設計が有効であるかどうかをどうやって知ることができるのでしょうか。それで問題は解決できるでしょうか？
ChatGPT はプログラマーにとって優れたヘルパーですか?それともプログラマーを殺したいですか？
コードを生成する能力だけではなく、より重要なのは、強力な設計能力を備えているかどうかだと思います。
設計機能には 2 つのレベルがあり、1 つはアーキテクチャ設計やシステム設計などの高レベルです。
1 つは比較的低レベルの設計機能で、主に特定のクラスとインターフェイスを設計します。
今日は、これら 2 つの側面でのパフォーマンスを見ていきます。
ChatGPT の回答は特に長文なので、一部の詳細を削除し、重要な部分のみを残します。
会社の機密保持のため、実際のプロジェクトを使用することはできず、テストには書籍に掲載されているケースのみを使用できます。
#1. アーキテクチャ設計 ここで使用するケースはカスタマー サービス チケットですシステム は、「プログラマーからアーキテクトへ」という本から抜粋したもので、実際の事例がたくさん載っているので、皆さんにもお勧めです。 カスタマー サービス作業指示システムのおおよその要件は次のとおりです。 MySQL データベースを使用するカスタマー サービス システムがあります。毎年発生する作業指示書は、品目数が3,000万件以上、各作業指示書には5～6件の作業があり、これらの作業も記録する必要があるため、年間1億5,000万件以上の作業記録が存在することになります。 カスタマー サービスが作業指示書を表示するためにシステムを開くと、速度が非常に遅く、開くまでに 10 秒かかります。現在、SQL ステートメント、インデックスなどが最適化されています。極端であり、これ以上改善することはできません。 現在、システムのパフォーマンスが顧客サービスの処理効率に深刻な影響を及ぼしており、顧客はこの問題を 1 週間以内に解決することを要求していますが、これは非常に短い期間です。 業務プロセスを分析した結果、作業指示書が処理されると「終了」ステータスが追加されることがわかりました。このような作業指示書は年に数回オープンできるわけではありません。 チームはこれまでデータベース パーティショニングを使用したことがなく、1 週間以内に解決できるかどうか確信が持てず、データベース パーティショニング計画を断念しました。 この問題に対する、本書の解決策は「ホット データベース」と「コールド データベース」の分離です。「ホット データベース」の毎日の操作により、「クローズされた」作業指示書が新しい「コールド データベース」に移動されますが、ホット データとコールド データ プロセス中に、データの一貫性の問題に対処する必要があります。 この要件を GPT-4 に投げて、それがどのように答えられるかを確認してください。 GPT-4: この場合、パフォーマンスの問題を解決するには次の 2 つの方法をお勧めします: 1. データベースのアーカイブ : 以降クローズされたチケットの大部分はアクセスする必要がなくなり、チケット データをメイン データベースからアーカイブ データベースに移動できます。このようにして、メイン データベースのサイズが大幅に削減され、クエリ速度が向上します。アーカイブ データベースは定期的に (毎月または四半期ごとなど) 更新でき、終了した作業指示書をアーカイブ データベースに移動できます... 具体的な操作手順は次のとおりです。##a. アーカイブ データを保存するための新しい MySQL データベースを作成します。
b. 終了した作業指示書とそれに関連する操作記録をマスター データ データベースからアーカイブ データベースに定期的に移動し、データの一貫性を確保するスクリプトを作成します。
c. 顧客サービス システムを変更して、デフォルトでメイン データベース内のアーカイブされていないデータのみをクエリするようにします。
d. カスタマー サービス担当者が必要に応じてアーカイブ データ ライブラリ内のデータをクエリできるように、別のインターフェイスまたはツールを提供します。
キャッシュ:...わずかに...はい、すぐに要点を捉えました、データベースアーカイブスキームと具体的な操作手順が示されています。
ただし、要件にはヒントがあり、この解決策は簡単に思いつきます。
Liu Xin: 操作手順で、データの一貫性を確保するにはどうすればよいですか? ここでは 2 つのデータベースを操作する必要があります
GPT-4 : それデータの一貫性を確保するために非常に重要です。 2 つのデータベースを操作する場合、次の方法を使用してデータの一貫性を確保できます。
トランザクションを使用する: トランザクションを使用すると、一連の操作がすべて成功するかすべて失敗するかを確認できます。 .....省略....Liu Xin: トランザクションを使用する場合、2 つのデータベースにまたがるトランザクションをどのように開始できますか?
GPT-4: 申し訳ありませんが、前の回答で間違いがありました。 MySQL では、2 つの異なるデータベース間で単一のトランザクションを直接使用することはできません。この場合、データの一貫性を確保するために他の戦略を使用することを検討してください。考えられるアプローチの 1 つは、2 フェーズ コミット (2PC) を使用することです。 ....省略....
Liu Xin: 2 フェーズ コミット プロトコルは非常に脆弱です。メインデータベース。アーカイブデータベースに?
GPT-4: 申し訳ありませんが、以前のソリューションはニーズを完全には満たしていませんでした。ここでは、メッセージ キュー (RabbitMQ、Kafka、Amazon SQS など) を使用してデータ移行プロセスの一貫性を確保する新しいソリューションを提供します。このアプローチでは、データ移行プロセスを 2 つの別々のステップに分割し、何か問題が発生した場合に簡単にロールバックできるようにします。 .....省略....
Liu Xin: MQ を使用せずに自分でコードを作成する場合、データ移行プロセス中の一貫性をどのように確保できますか?
GPT-4: メッセージ キューを使用したくない場合は、次の方法を使用して独自のコードを作成し、データ移行中の一貫性を確保できます。
- ロック フィールドとマーク フィールドを使用する:
a. レコードが移行されたかどうかをマークするために、「is_maigrated」という名前のブール フィールドを作業指示書テーブルと操作レコード テーブルにそれぞれ追加します。
b. 移行条件を満たすレコードをマスター データベースにクエリするためのスクリプトまたはプログラムを作成します (たとえば、終了した作業指示書と "is_maigrated" が false)。
......少し......
まあ、この時点で、ようやく解決策が見つかりました。これは、この本と多少似ています。これは、フィールドを使用して「移行されたかどうか」をマークすることです。
しかし、どのように促しても冪等にする方法は提案されないので、諦めました。
Liu Xin: アーカイブ データベースのデータ量は非常に多く、クエリは非常に遅いですが、クエリは基本的に「顧客 ID に基づいて作業指示書を検索し、 「作業指示書 ID に基づいて作業指示書を見つけます」「すべての処理レコードが単独で発生します」これを解決する方法はありますか?
GPT-4: このクエリ モードでは、アーカイブ データベースのクエリ パフォーマンスを最適化するために次の戦略を採用できます。
- は顧客 ID です。および作業指示書 ID インデックスの作成: ......省略...
- データベース テーブル パーティション: ......省略...
- データベース ビュー:... .. ..わずかに...
- 結果キャッシュ:...わずかに...
- 読み取りと書き込みの負荷を分割:.... .わずかに...
- ハードウェアと構成の最適化:...少し...
これらの解決策は、問題を効果的に解決することはできません。正しい解決策は、HBase のような NoSQL データベースを使用することです。予想外です。
2. 詳細設計
私が使用するケースはやはり給与支払いです。これは古典的な書籍『アジャイル ソフトウェア開発: 原則、パターン、実践』から抜粋されたものです。
このケースの要件は次のとおりです:
システムは企業データベースと従業員関連データで構成されます。時間通りに更新される ルールに従って従業員に給与を支払う
従業員には 3 つのタイプがあります
1. 時給制の従業員。固定給が支払われます。 1時間当たりの賃金を毎日提出し、労働日と労働時間を記録したカードを提出し、1日8時間以上働いた場合は1.5倍の賃金が支払われます。毎週金曜日に給料が支払われます。
2. 月給制の従業員、給与は固定で毎月の最終勤務日に支払われます
3. 売上高給与は固定ですが、売上に応じて一定額の歩合給が支払われ、売上日と売上数量を記録した領収書を提出します。給料は隔週金曜日に支払われます。
従業員は支払い方法を選択でき、指定した住所に小切手を郵送したり、財務部門に保存しておいていつでも引き出すことができ、または直接入金をリクエストすることもできます。指定された銀行口座に振り込みます。
この要件を読んだ後の一般的な設計は次のようになります:
Employee は、さまざまな種類の従業員クラスが継承する基本クラスとして機能します。
ただし、この要件は変更されます。顧客は、従業員タイプを変更できることを要求しています (たとえば、時間給従業員から月給従業員に)。そのため、上記の設計は機能しません。
現時点では、抽象化を作成し、PaymentClassification クラスを使用して支払い分類を表現し、このインスタンスを Employee クラスに保持させます。簡単に言うと、継承ではなく組み合わせを使用します。 。
- 基本クラス Employee: ......省略...
- Employee クラスから継承された HourlyEmployee クラス: ......省略...
- Employee クラスから継承された SalariedEmployee クラス: ......省略... #SalariedEmployee クラスから継承された SalesEmployee クラス: ......省略... ...
- PaymentMethod クラス: わずか
#この設計では、元のクラス構造にいくつかの調整を行う必要があります。
基本クラス Employee を保持します:- 新しいメソッド: set_salary_strategy、従業員の給与計算戦略の設定に使用されます
- 給与計算戦略の基本クラスとして抽象クラス SalaryStrategy を追加しました。
- 新しい特定の戦略クラスを追加しました:
- SalaryStrategy クラスから継承された HourlySalary クラス
SalariedSalary クラス、SalaryStrategy クラスから継承
SalesSalary クラス、SalaryStrategy クラスから継承
上記の調整により、次のことができるようになります。従業員クラスの場合、給与計算方針は動的に変更されます。従業員が時間給から月給に変更する場合は、新しい給与計算ポリシーを設定するだけです。
GPT-4 は非常に強力であると言わざるを得ません。
戦略パターンを使用して給与計算戦略 SalaryStrategy を抽象化します。
2 番目の UML 図と比較すると、名前が異なることを除いて、基本的に同じです。
これができれば多くのプログラマーを超えることができると言えます。
#支払いサイクルの問題に対処していないことに気づきました。 Liu Xin: 当初の要求には支払い時間も含まれていました。たとえば、時間給労働者の給与は毎週金曜日に支払われます。これはどのように設計すべきですか? GPT-4: さまざまなタイプの従業員の支払い時間を処理するために、給与を支払う必要があるかどうかを決定する抽象メソッド should_pay_today を SalaryStrategy 基本クラスに導入できます。現在の日付に基づいて。次に、このメソッドを特定のストラテジー クラスに実装します。 ......少し...... ここで間違いがあり、支払いサイクルが給与に組み込まれてしまいました。コンピューティング戦略では、「保守と拡張が容易」とも言われます。 Liu Xin: 支払い時間と給与計算戦略は両立しない 2 つの概念です。最大限の柔軟性を実現するにはどうすればよいでしょうか? GPT-4: おっしゃるとおり、支払い時期と給与計算戦略は 2 つの異なる概念です。設計をより柔軟にするために、給与計算戦略から支払時間を分離し、支払時間のロジックを処理する新しい抽象クラス PaymentSchedule を作成できます。このようにして、従業員ごとに給与計算戦略と支払時期戦略を個別に設定できます。 次は、調整されたクラス構造です: 基本クラス Employee:Attributes: name、ID、address## を保持します。
- #メソッド: set_payment_method、従業員の支払い方法の設定に使用されます
- メソッド: set_salary_strategy、従業員の給与計算方針の設定に使用されます
新しいメソッド: set_payment_schedule、従業員の給与計算方法の設定に使用されます従業員支払時間戦略
抽象クラス SalaryStrategy とその特定の戦略クラスは変更せずに保持されます。 抽象クラス PaymentSchedule を支払い時間戦略の基本クラスとして追加します:... わずかに...- 特定の支払い時間戦略クラスを追加し、PaymentSchedule を継承します:
- WeeklyPayment クラス...わずかに...
- MonthlyPayment クラス...わずかに...
BiweeklyPayment クラス...わずかに...
PaymentMethod クラスとそのサブクラスを変更せずに保持します。
-
とても素晴らしい!PaymentScheduleとSalaryStrategyが分離されていて、私が何を考えているかを理解しているようです!
# これまでのところ、この本の中でおそらく最高の最終的なデザインが完成しています。
##3. 概要 詳細設計レベルでは、 GPT-4 のパフォーマンスは、アーキテクチャ設計よりもはるかに強力です。 プログラマーになった古い読者は、私が昨年給与支払いのケースで GPT-3.5 をテストしたことを知っています。要件。 。 しかし、GPT-4 は異なります。その設計機能はさらに一歩進んでおり、プログラマーの指示に従って、彼は懸念事項を分離することを学びました。 アーキテクチャ設計の観点から見ると、GPT-4 は多くの知識を習得していると感じますが、複雑な問題に効果的に適用することはできません。GPT-4 が提供するソリューションは非常にわかりにくく、遠くにあります。私たちが望むものから、遠くまで。 より重要な問題は、その答えが正しいかどうかをどのように識別するかということですが、現在、標準的な答えが手元にあり、それを評価することができます。実際のプロジェクトでは未知の部分に直面することがありますが、経験がなければ、GPT-4 で与えられた設計が有効であるかどうかをどうやって知ることができるのでしょうか。それで問題は解決できるでしょうか？
以上がChatGPT はプログラマの中核機能を脅かし始めています。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。