B-Teck!

お仕事からゲームまで幅広く

【本】AWSで実現するモダンアプリケーション入門を読んだ

目次

  1. モダンアプリケーションとは何か
  2. サンプルアプリケーションの紹介
  3. アプリケーション開発におけるベストプラクティスを適用
  4. データの取得による状況の可視化
  5. サーバーレスやコンテナテクノロジーによる運用改善
  6. CI/CDパイプラインによるデリバリーの自動化
  7. 要件にあったデータベースの選択
  8. モダンアプリケーションパターンの適用によるアーキテクチャの最適化

個人的な想定読者

  • インフラを含めたアプリケーションの全体設計に興味を持った若手
  • 運用経験があるがAWS上で構築されるアプリケーションの知見が少ない中堅

感想とか

5年間は生き続ける考え方が凝縮された良書「AWSで実現するモダンアプリケーション入門」 | DevelopersIO で興味を持ったので読んでみた。
架空のサービスを設定し、様々な機能拡張や顕在化する課題の解決を行うことで、少しずつモダンなアプリケーションへ近づいていくという構成。
同じような用途でも複数の実現方法が提示されたり、なぜそのサービスを利用するのかという部分がちゃんと説明される*1ので、納得と理解を持って読み進められる。

トランクベース開発の紹介や、CI/CDの説明、サーバーレスについての解説など、全体を通して、小さく頻繁に変更し、運用負荷が低い状態を保つという意識が通底している気がする。
個人的に知見の薄いマイクロサービスに関連する部分は、分散トランザクションやイベントソーシングなどのトピックも取り上げられていて学びがあった。

現実でここまで色々組み合わせた構成にするのは大変だろうなと思いつつ、このページ数で解説できていることがすごい。 一方で、ハンズオンやサンプル環境などが存在しないので、全体像を想像しながら読めるバックボーンが必要な本ではあると思う。 オンプレ開発の経験が長く、現職でなんとか会話についていこうとしている自分にとって、この本があと1, 2年早く出ていたらかなりショートカットできただろうなと思える良い一冊だった。

*1:サービスメッシュの解説では、あえて「利用しなくてもよい」ような状態も説明されていたり

【ふりかえり】2023年1月

前回のふりかえり
【ふりかえり】2022年8月 - B-Teck!

夏頃以降気力がなくて何もできていなかったけど、回復してきたので色々再開し始めています。
とりあえず毎月ふりかえりを書けるくらい何かをしたい。

Input・Output

ブログ

勉強会

趣味とかその他

所感

仕事

12月から作業し始めたタスクが年末年始にかけてようやく動く形になってきて、まずは一安心という感じ。
10月半ばくらいから現在までフロントエンドのタスクに関わることが多く、毎日わかんねーって言いながらどうにか倒しています。
なんとなく最近課題に思っているのは、未知に対してどれだけ精度高く見積もることができるかと、見積もりを外れたときにどうリカバリするかというところ。
意思決定者がどういう情報を求めているのか、どういう進め方をすれば納得してもらえるのか、みたいな部分がまだまだ弱いなーと感じています。

プライベート

プライベートではだいぶ気力がなくなっていたのですが、12月頃からちょっと元気になってきました。
腰を据えてやる娯楽(長編のゲームとか)も様子見つつやっていきたいなーという感じ。 文字を書く元気も出てきたし、久しぶりにKotlin触りたいなーという気持ちで Kotlin サーバーサイドプログラミング実践開発 を読んだり触ったりしてみています。
継続して勉強できる姿勢を続けていきたいなあ。

仕様書について考えてる

継続して提供されるサービスであれば、仕様や意思決定の経緯を残したい。
どういう形ならあとからそれらを辿れるかなあというのを考えてるメモです。中身はあまりない。

イメージしてるのはこんな感じ。

要求仕様・機能要件

開発アイテムが発生した際に書くドキュメント。
ステークホルダーと合意した要件やその案件で満たすべき仕様を記述する。
対外的に機能紹介をするときにここだけ読めば伝わる状態だと良い。

親ページにはおおまかに下記が書いてあって、関連する小ページへのリンクを貼る。

  • ペルソナ
  • やること・やらないことのスコープ
  • デザイン
  • 開発範囲の外部仕様
    • 画面上の挙動や制約、注意点など

設計ドキュメント

内部的な設計資料がぶらさがってるイメージ。
テーブル設計や各種リソースの構成図、APIのIFなど。
議論が発生した場合は議事録側にメモを残し、リンクされているとよい。
文字数とか操作の制約とかがあればなぜなのか書いてあるとうれしい。

調査ドキュメント

機能開発や設計において調査した結果のメモ。
行った調査や意図が記録されていてほしい。

議事録

部署間のMTGからチーム内の議論まで、「案件に関わる意思決定」に関連する会話のメモ。
参加者、会話内容、意思決定、もしあれば次のアクションアイテムが書かれていると良い。

仕様書

機能が開発されたあと継続してメンテされていくドキュメント。
追加開発や改修が発生した際は開発完了時にこのドキュメントに反映される。
文言や分岐、各種バリデーションとかエラーとかが網羅されていてほしい。

更新フロー

開発中は常時意思決定や設計ドキュメントが更新され、開発完了時にそれらの差分が機能ドキュメントに反映されてほしい。
更新時は相互にリンクされてると最高。

ここまで書いて思うこと

自分はドキュメントを書くのが苦ではない方なので困らないけど、あんまりドキュメント書かないタイプの人に全部書いてっていうと嫌がられる。
仕様として残す範囲の挙動も個人に依存しそうで、かといってガチガチにすると多分メンテされなくなる。
そもそも単機能が肥大化してしまっている場合、この形ではおそらく記述しきれないし、複数ラインで同じ機能の開発が走ったときに開発中機能の仕様記述がコンフリクトしそう。
細かい仕様はどこまで残すのかとかも含めて何もわからん。
そもそもすでに機能があるけどドキュメントがないみたいなときどうする問題もある。
こういうドキュメンテーションがうまくいってる事例をもっと知りたい。