面倒なドキュメンテーションを生成AIでやる

Transcript

1. 面倒なドキュメンテーションを生成AIでやる ご飯を食べながらWeb開発もくもく会＆LT会 虎の穴ラボ株式会社　吉田一貴
2. よしだ 𝕏：@da_yoshi_k 使っている技術 現職：Ruby, Ruby on Rails, React, Google Cloud 前職：Java, RPA(UiPath) 経歴 2023年5月〜　虎の穴ラボ株式会社 2018年4月〜　SI系のSES(PjM半分・開発半分)
3. あるある/つらみ: ドキュメントのない現場 今日から参加するAです！早速開発を始めたいのですが、 ドキュメントはどこですか？ ドキュメント？そんなのはないよ！ やることは山積みだからコード見て開発進めて！ （とんだ魔境に来てしまったのかもしれない） システム開発プロジェクトに参画することになったAさんと現場マネージャーの会話
4. あるある/つらみ: ドキュメントのない現場 幽霊の出る墓場 ※1 コード内にあることが多い、何かがおかしくなるかもしれないと恐れて触れ たり変更したりするのを皆が避ける場所。幽霊の出る墓場は、恐怖と迷信の ために、皆、行動を避けようとするのがその特徴だ。 ▪似た概念：お前、あの祠を壊したんか！？ ※1)https://www.oreilly.co.jp/books/9784873119656/ ※2)https://gigazine.net/news/20200312-chestertons-fence/ チェスタトンのフェンス ※2 「なぜフェンスが建てられたのかわかるまで、 決してフェンスを撤去してはならない」 改修を進めようとしても現行仕様もわからないし、 コードを変更すると全く意図していないところでバグが出る...
5. 安心して開発ができるように、 ドキュメントがないシステムに 生成AIが活用できないか試してみる
6. Cline（Roo Code） • VSCodeなどのエディターで機能する拡張機能 • ユーザーの指示に対して、コード生成やバグ修正を行ってくれるAIエージェ ント。今回はRoo Codeを利用。 • Cline、Roo Codeはいくつかのモードを使い分けている。 ◦ 計画を立てるPlanモード、実行するActモード ◦ コード編集のCodeモード、要求の分析・計画が得意なArchitectモー ド、質問に答えるAskモード、デバッグするdebugモード。 • 比較的0→1の開発が得意（と思う）が、今回は1や10まで成長したシステム を探っていく所に使ってみた。 CLINEに全部賭けろ）https://zenn.dev/mizchi/articles/all-in-on-cline
7. 対象としたソフトウェア • Redmine ◦ Railsで作られているプロジェクト管理のソフトウェア
8. .clinerules # ルール - あなたは熟達したシステムアーキテクトです。 - 既存のドキュメンテーションが存在しない前提で、md ファイルに体系的にまとめることを目的としています。 - 人間にとっても可読性が高い状態となるように、適切な粒度でファイルを分割するように心がけてください。 - 任された Rails アプリケーションに関して、以下のドキュメントがないため保守性を上げるために用意したいと考えています。 - 画面遷移図: ユーザーの操作フローを視覚化します。 - クラス図: モデル間の関係性を示します。 - シーケンス図: 特定の機能におけるオブジェクト間のやり取りを時系列で表現します。 - システムに影響を与えないように、dev_doc フォルダのみに md ファイルを作成してください。 - また、以下のような観点も保守性を上げるために dev_doc/fixme.md に記載していってください。 - コードの重複:同一または類似の処理が複数箇所に存在する場合、メンテナンス性が低下します。これらの箇所を特定し、共通化の可能性 を検討します。 - 一貫性の欠如:命名規則やコードスタイルが統一されていない部分を指摘し、標準化の必要性を示します。 - 複雑なロジック:理解しにくい複雑な条件分岐や長大なメソッドを特定し、簡潔化や分割の提案を行います。 - コメントやドキュメントの不足:コードの意図や仕様が明記されていない箇所を挙げ、適切なコメントやドキュメントの追加を推奨しま す。 - 非効率なアルゴリズムやパフォーマンス問題:処理速度やリソース消費に問題がある部分を特定し、最適化の必要性を示します。 - セキュリティ上の懸念:潜在的な脆弱性やセキュリティリスクが存在する箇所を指摘し、改善策を提案します。 - テストカバレッジの不足:テストが不十分なモジュールや機能を明示し、テストケースの追加を促します。 マークダウンファイルにする mermaid形式で描かせる 危ない場所はメモしておく
9. クラス図
10. シーケンス図
11. インフラストラクチャ構成
12. fixme.md
13. メリット ・今回のドキュメント生成は30分もあればできた（圧倒的工数の削減） ・UMLで描かせることで視覚的にもわかりやすい ・自然言語なので、不明点などをエンジニア以外の人にも聞ける デメリット（注意点） ・リポジトリ全量を見ているわけではない可能性があるので、真偽には注意 ・コードを外部システムに見せることになるのでセキュリティには注意 ・あくまで現時点の仕様なので、最新化していくことが大事 　→ここがとても面倒だが、最新化の労力も減らせそう！ メリット/デメリット
14. Thanks!! 安心してコード変更しよう！ 会社HPも昨年リニューアルしたので見てね https://toranoana-lab.co.jp/