Skip to content

yaNote_DevGuide.md

Latest commit

 

History

History
118 lines (81 loc) · 7.92 KB

yaNote_DevGuide.md

File metadata and controls

118 lines (81 loc) · 7.92 KB

yaNote Generative AI 開発ガイド

このガイドは、生成AIに yaNote の開発作業を依頼する際、どのように情報を伝え、各所に必要なメタ情報や出力フォーマット（ソースコード以外のドキュメントは Markdown 形式で）を残せば、効率的かつ正確に開発できるかをまとめたものです。
このガイドは、チャットのやり取りおよび既存ドキュメント（仕様書、help.md、README.md）の情報を元に作成されています。

1. 目的

  • 生成AIに対する指示を明確にし、yaNote の機能実装およびドキュメント生成を一貫性のある品質で自動化する。
  • 各機能の動作仕様、入力・出力形式、関連ドキュメントとの統一性を保つための指針を示す。

2. 開発プロセス

  1. 初期準備

    • 新しいバージョンの開発開始時に、新バージョン開発用のプロジェクトをChatGPTもしくはClaudeで作成し、プロジェクトファイルにその時点での最新のソースコードとドキュメントをアップロードする。Cloudeの場合はリポジトリのファイルを登録。

  2. 機能追加・修正の議論

    • 追加・修正したい機能について、その仕様や実装方法を生成AI（ChatGPT / Cloude）と議論する。

  3. 議論内容のまとめ

    • 議論内容がまとまったら、生成AIに仕様をまとめてもらう。

  4. 開発指示の実施

    • まとめてもらった内容をもとに具体的な修正箇所（修正や追加するコードとその場所）をまとめてもらう
    • プロジェクトに必要な情報がアップロードされていると、特に具体的な指示をしなくても適切な修正箇所を支持してくれることが多い。
    • 修正箇所が少ない場合はコードの該当部分のみを出力してもらい、手動で修正・追加する。
    • 修正箇所が多く適用難易度が高い場合は、ガイドラインに沿ってコード全体を出力してもらい、適用する。
      • 最近はコード量が増えてきたため、全体を更新することはほぼなくなり、修正箇所のみを手動で実装するか、上記のまとめを元にClineに修正してもらっている。GitHub Copilotでも可能かもしれないが、試していない。

  5. 生成AIによるコードレビュー

  • 修正したコードを生成AIにレビューしてもらい、正しく実装されていることを確認する。

  1. 動作テスト

    • 機能が正しく動作するかテストを行う。

  2. フィードバックと再議論

    • テストで問題が見つかった場合、生成AIと議論し、解決策を検討する。
    • 問題が解決するまで、議論（ステップ2）から反復して改善を進めることもある。

  3. 機能開発の完了

    • 問題が解決すれば、その機能開発は完了する。

  4. 複数機能の開発

    • 同一バージョン内で他の機能も追加する場合は、上記のプロセスを各機能ごとに繰り返す。
    • 最近ではなるべくバージョンアップは細かくしている。

  5. 最終ドキュメント作成

    • 全ての機能開発が終了したら、これまでの内容をもとに、各種ドキュメント（仕様書、help.md、README.md）とリリースノートを生成AIに作成してもらう。
    • 操作に影響しない修正の場合はリリースノートのみ作成して終了することもある。

  6. ドキュメントのフィードバックと改善

    • 生成されたドキュメントに不備があれば、機能開発と同様のプロセスで反復し、ドキュメントの改善を行う。

  7. リリース

    • 全て完了したら、最終成果物を GitHub でコミットし、リリースする。

3. 生成AIとのコミュニケーション

3.1 明確な要件提示

  • 各機能や修正点について、具体的な要件と動作仕様を記述すること。
    例：「Cmd/Ctrl+A による全オブジェクト選択機能を実装したい。テキスト編集中はブラウザの全選択動作もさせたいが、どう思う？」

3.2 出力形式と粒度の統一（ソースコード以外のドキュメント）

  • 仕様書、help.md、README.md などのソースコード以外のドキュメントは必ず Markdown 形式で出力し、既存の文書と同一の文体・粒度で記述する。

3.3 コンテキストの提供

  • プロジェクトの背景、仕様書、help.md、README.md など、関連情報を十分に提供する。
  • 生成AIが現状や既存文書と矛盾なく作業できるよう、必要な情報は過不足なく記述する。

4. 情報の残し方と出力例

4.1 【DO NOT MODIFY】コメントの解説

ソースコード冒頭に記載されている【DO NOT MODIFY】コメントは、yaNote の開発における基本方針と実装ルールを示すものです。
生成されるソースコードには、この【DO NOT MODIFY】コメントを必ず原文のまま残すことが求められます。
以下、各項目の解説です：

  1. セクション分けとコメントの徹底

    • 各機能やクラスごとに明確なセクション分けを行い、必要な箇所にコメントを追加すること。
    • 生成AI は、コード生成時に各部分の役割が明確になるよう、適切なコメントを挿入してください。

  2. 擬似モジュール化

    • IIFE や名前空間オブジェクトを活用し、コードを論理的に分割することでグローバル名前空間の汚染を防止する。
    • 生成AI は、各機能が独立して管理できるよう、モジュール化されたコードを出力してください。

  3. 一元管理された設定と定数

    • バージョン番号や設定値、定数などは、コード冒頭または専用の設定ファイルにて一元管理すること。
    • 生成AI が出力するコードでは、設定値が散乱しないよう、一元管理された形で定義されることが必要です。

  4. テスト・デバッグ

    • DEBUG フラグを利用して、重要な状態変更やイベント発火時にログ出力を行うことが推奨されます。
    • 生成AI は、トラブルシューティング用のログ出力コードを適切に生成してください。

  5. コーディング規約の遵守

    • 既存のコードフォーマット（命名規則、インデント、改行など）は変更せず、必要な箇所のみを修正すること。
    • 生成AI は、既存のスタイルガイドに沿ったコードを生成するよう努めること。

4.2 ドキュメント出力例

  • 出力されるドキュメントは、既存の仕様書、help.md、README.md と同一の文体・粒度で具体的に記述する。
  • 例として、全オブジェクト選択機能の動作仕様、使い方、注意点などを含む形式を参考にする。

5. 注意事項

  • 明示的な指示: 曖昧な表現は避け、必要な情報は具体的に記述すること。
  • フォーマットの統一: 生成されるすべてのドキュメントおよびソースコードは、既存の仕様書、help.md、README.md と同一の文体・粒度にすること（ソースコード以外のドキュメントは Markdown 形式で出力する）。
  • 既存情報の尊重: ソースコード冒頭の【DO NOT MODIFY】コメントなど、重要な情報は原文のまま残すこと。

このガイドに沿って生成AIに指示を出すことで、yaNote プロジェクトの開発が円滑に進み、各種ドキュメントおよびソースコードが一貫性のある品質で生成されることを期待します。