Upgrade to Pro — share decks privately, control downloads, hide ads and more …

密集_ドキュメントのコロケーション_with_AWS_Lambda

 密集_ドキュメントのコロケーション_with_AWS_Lambda

Satoshi Kaneyasu

February 07, 2025
Tweet

More Decks by Satoshi Kaneyasu

Other Decks in Programming

Transcript

  1. 4 やってみたコロケーションのイメージ ➢AWS LambdaとPythonによるバックエンドのプログラムでやってみました / ├── app │ ├── function_a

    │ │ ├── handler.py │ │ └── README.md │ ├── function_b │ │ ├── handler.py │ │ └── README.md │ └── function_c │ ├── handler.py │ └── README.md ├── docs │ ├── database.md │ └── system_diagram.drawio └── README.md 業務ごと(=AWS Lambda関数ごと)でディレクトリを分けている これが設計書、いわゆるプログラム設計書に相当 プログラム テーブル定義、構成図など機能・業務を跨ぐものはここ
  2. 6 現在の構成に至るまでに考えた他の構成候補 / ├── app │ └─── functions │ ├──

    function_a.py │ ├── function_b.py │ └── function_c.py ├── docs │ ├── database.md │ ├── function_a.md │ ├── function_b.md │ ├── function_c.md │ └── system_diagram.drawio └── README.md / ├── app │ └─── functions │ ├── function_a.md │ ├── function_a.py │ ├── function_b.md │ ├── function_b.py │ ├── function_c.md │ └── function_c.py ├── docs │ ├── system_diagram.drawio │ └── database.md └── README.md 実案件ではもっと関数が多い 場所が遠くで探しづらい functions配下が煩雑 実際には関数の名前はもっと不規則 なのでかなり見づらい
  3. 7 この構成における設計書で書くもの ➢ Markdownで書く ➢ 機能の概要 ➢ 何をする機能か ➢ 大まかな処理の流れ

    ➢ 入出力内容 ➢ パラメータ ➢ 出力するファイル・データのフォーマットなど ➢ 使用方法/テスト方法 ➢ フローチャートやシーケンス図は開発者からの需要がなく、メンテ負荷になったのでカット ➢ Marmaidも不採用、AWSを使用してるのでアイコンが揃ってるdraw.ioで書いた方が良いとなった
  4. 8 メリットとデメリット メリット デメリット ➢ 目論見通り、見やすい ➢ プルリクエストで設計書がレビューできる ➢ 設計だけできてるのか?実装まで済んでるの

    いか?がツリーに表れる ➢ 設計書の配置に関してはやり切った感があり、 最近設計書の配置に関する無駄な議論がない ➢ ディレクトリ構造そのものに工夫を入れてい るので、他のPJにも展開できると言い切れな い(AWS Lambdaを使用してるからできてる とも感じる) ➢ レビュアーがGitに入らないといけない