WEB+DB PRESS Vol.134

著者 : 柴田芳樹 宮脇駿 石井雅人 牧大輔 曽根壮大 きしだなおき 麦島一 石上晋 西山和広 須藤将史 五十嵐進士 池澤春菜 和田卓人 日高正博 はまちや2 竹原

制作 : WEB+DB PRESS編集部 

• 技術評論社 (2023年4月22日発売)

感想・レビュー・書評

[あろ@新潟エンジニアマンさんの感想 · 2023年6月2日]

学びになった部分
・JWTについて：JOSEという規格は初見。5つの規格があり、JWTはそのうちの一つ。
・削除フラグのリファクタリング：削除フラグを実用している案件に携わる機会があったので、自分でリファクタするならどうするか考えながら読むことできて良かった。
・CSS詳細度：今まで何となくCSS定義をしていたので、適用順位について意識する必要性を認識できた。
・その他：「AI 2041」は気になったので読むぞ。

[ザク山チョコ太郎さんの感想 · 2023年7月14日]

<API設計>
APIはまず仕様書を作る。API仕様書が存在しない場合、フロントエンド側の開発の負担が大きくなる。(開発者はAPIの仕様知るために、コードを読む必要が発生する。エラーケースがわからないなど)

APIを作成する際は、1. 仕様書の作成、2. テストコードの作成、3. 実装の順で行う。

仕様書には、サービスの概要、エンドポイントの正常な動作、引数・戻り値、エラーの説明を含める

テストコードの作り方にも言及。まず、API仕様書に記載したエラーを返すテストコードを作成し、エラーが発生しなくなるように実装を行う。(つまり入力のバリデーション部分を実装する）
実装されたコードの前半部分はバリデーションコードとなり、正常な処理にバリデーションコードが含まれてなくなる。

<DB 削除フラグに立ち向かう>
特定のカラムの値でデータが削除されたか判定する = 論理削除

論理削除はクエリの複雑化、パフォーマンスの低下、制約を活用できないなどの問題を引き起こす

リファクタリング方法として、ユーザの状態別にテーブルを用意する。
この際、移行方法は2パターンある。
1: 既存のテーブルから新規テーブルへ移行
2: 既存のテーブルを子テーブルへ分割
1の場合、ダブルライト処理が必要となる。

削除フラグで達成できるケースはあるが、削除フラグ以外の設計でも対応できる。また、エンドユーザーからみれば削除ではなく、非表示など、開発側とユーザ側とで目的を分離する必要がある。
ともかく、最適な設計を心がけることが必要で、安易にフラグなどの状態を持たせてはいけない。

参考サイト・文献
https://soudai.hatenablog.com/
「ユーザ情報を保存する時のテーブル設計」https://soudai.hatenablog.com/entry/2018/05/01/204442
「アジャイル開発とデータベース設計」https://agilejourney.uzabase.com/entry/2022/07/28/103000
「PostgreSQLアンチパターン」https://www.slideshare.net/SoudaiSone/postgre-sql-54919575