古いコーディングの方法？すべてのルールを前もって定義する—もし正確に説明できれば、自動化が残りを処理します。しかし、新しいパラダイムは脚本をひっくり返します：今は出力が正しいかどうかを確認する方法が必要です。プロセスではなく、テストを定義します。これは、指示を書くことから結果を検証することへのシフトです。

原文表示

このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております（表明・保証をするものではありません）。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。

16 いいね

0/400

SignatureVerifier

· 41分前

つまり、今では問題に対して実際に解決策を設計する代わりに、検証を投げ捨てると言っているのですか？いや、十分な検証がないとやられてしまいます。"テストはローカルでパスする"という災害を見すぎて、プロダクションで崩壊するのを見ました... 信頼するが確認することもここに当てはまります。

原文表示返信0

SundayDegen

· 4時間前

テスト駆動開発は昔からこうやってやっていたのに、今になって新しいパラダイムだと言うのはちょっとおかしいですね。

原文表示返信0

TokenSleuth

· 4時間前

うん、これがAIがプログラマーを代替する兆しなんだろうね...ロジックを書くのからテストケースを書くのに変わって、ちょっとおかしい感じがするなあ

原文表示返信0

SignatureDenied

· 5時間前

これはTDDの古いメロディを繰り返しているだけではないのか、まるで新大陸を発見したかのように見える。

原文表示返信0

AirdropHuntress

· 5時間前

検証結果からルールを逆推する？良さそうですが、この罠の論理をオンチェーンガバナンスとスマートコントラクトに適用するのは少し危険です...歴史的データは、output validationに過度に依存するプロジェクトが境界ケースでつまずくことが多いことを示しています。

原文表示返信0

ForkTongue

· 5時間前

言ってしまえば、命令型プログラミングからテスト駆動に移行するということです。新しく聞こえますが、実際にはこの考え方は以前からありました。主にLLMの出現によって、この罠が本当に実行可能になったのです。

原文表示返信0