今日は Solidity 契約の書き方を試してみました。具体的にはどうすればいいのでしょうか？
- するべきことを小さなセグメントに分割します。
- 各セグメントごとに何をするかをテキストで説明します。
- そして AI に尋ね、AI の回答を 1 つ受け取り、関数を書きます。
- すぐにコードをテストし、テストコードも生成できます。
- テストが完了し、関数が完成し、エラーが少ないです。
- 次の小さなセグメントに進みます。
この方法の利点は：
- アイデアが整理されます。
- 小さなセグメントごとに再開する可能性が低く、どのようにしても使用できます。
- エラーが少なく、全体的なエラーも少ないです。
- 進捗が速く見えますが、実際には進捗がかなり速いです。
- いつも集中しており、毎回問題を解決し、徐々に理解が深まります。
続けて使用する予定です。しばらく契約コードを見ていないと、スマートコントラクトのハードルが上がっていることに気づきました。主な理由はおそらく：
- Solidity 自体がまだそこまで馴染んでおらず、特定の使用方法にはまだ慣れていない部分があります。
- 契約の品質要件が高いです。
- 契約間の呼び出しが増えており、各契約には多くのメソッドがあり、異なる契約を理解するのに時間がかかります。
- 契約自体のビジネスは複雑で理解しにくい部分もあります。
- 発展が速いですが、国内ではなくなってしまい、ハードルが徐々に高くなっています。
最終的な考えは、何事も継続的に追跡する必要があるということです。継続しないと、後に追いつくのがますます難しくなります。