記事「最小限のコードで動く最も汚いコードから始める」を読んで

要約

ゴール: 最終成果物は読みやすく他人に理解されるコードに。
問題点: 最初から完璧を目指して書こうとすると行き詰まる
対処方法の一つ: 荒削りの動くコード(型エラー・リントエラーも一旦pending)をリファクタリングして完成度を高める
題材
- 典型的なCRUD app
- 機能
- ユーザ一覧の表示
- 指定したユーザの編集
- 同削除
エントリポイントに、べた書きのコンポーネントを書く
- 最小限のHTMLとべた打ちの要素
- 少し要素を増やしてみる
ユーザ一覧を取得する関数(Hook)を呼び出す
- ひとまず最初のコンポーネントと同じ場所に
- ダミーデータを返す (GitHub Copilotを活用)
- 型を作成 → ダミーデータを生成
- 現時点での優先度は、コンポーネントでフックを呼び出せるか確認 >> 戻り値の型は一旦pending
- ロールの表示を日本語にするため、ラベル用のオブジェクトを用意
- 気になる点があっても、一旦pending
ユーザ一覧のAPIをコール
- fetch()関数を使ってAPIをコール
- 戻り値がundefinedのときはloadingの表示
見通しが悪くなってきたと感じたときに、リファクタリング
- コードを別のファイルに分割
- コンポーネント
- Hook
- 型情報
- 元のコードを移行先にコピペ & 関連ファイルをインポート / 必要に応じてexportも
- リファクタリングの前後でUIの表示が壊れていないか確認
- PRの変更が大きいとレビューが大変になる
ユーザの編集モードの表示
- 要件
- 編集ボタンを押したら、該当する行が編集モードに
- 編集対象(例: ユーザ名・ロール)を明らかに
- 更新・キャンセルボタンを表示
  - 更新でAPIをコールして、ユーザを更新
  - キャンセルで編集モードを終了して、元の表示に戻る
- 編集中の行を表す状態を持つ + ボタンが押されたら、ユーザidをセット
- handleEditButtonClickを用意して、編集ボタンのonClickプロパティに渡す
  - いきなり状態を更新せずに、console.log()でIDを確認
  - 状態を更新
- 編集用のユーザidとテーブルのユーザidが一致したら、編集用のフォームを表示
  - 前段階としてまずはメッセージを表示するだけ
  - 確認できたらフォームと置き換え
コンポーネントに分割
- 一般的には、条件分岐の中身は1つのコンポーネントを配置しておくのが良い
- 細かいコンポーネントを同一 / 異なるファイルに配置するかは好みで
- コンポーネントを切り出す + 今必要なことに集中 + 画面を確認
ユーザの更新
- 更新ボタンを押したときに、APIをコールしてユーザを更新する処理を書く
- フォームで編集した値を取得
- onEvent={(e) => e.target.value}
- handleEvent()では、console.logで属性が表示されるか確認
- fetch()関数の呼び出しに置き換え
- PUTメソッドを使う
- headerのContent-Typeをapplication/jsonに
- body: JSON:stringfyを使って更新する値をwrap
- トーストメッセージで保存完了を表示
- ユーザの一覧の再取得が必要
- Reactの場合は、refetchが必要
- 戻り値の型を変更
- 編集用のコンポーネントで、ユーザの更新が完了したことを親コンポーネントから渡ってくるように
  - ユーザの再取得と編集モードの終了をonSaved()で処理
ユーザの削除
- 削除ボタンを押したら、確認ダイアログの表示 + OKを押したらAPIをコールしてユーザを削除
- 削除が完了したら、ユーザ一覧を再取得
リファクタリング
- コンポーネントを別ファイルに
- ロールの配列を定義 + mapで
- fetchの呼び出し部分をHookで抽象化
- 壊れていないか確認
Userの属性 (役割にデフォルト値、Railsみたいに作成・更新の情報を持っている)
- id: number
- name: string
- role: "admin" | "editor" | "viewer"
- createdAt: string
- updatedAt: string

感想

TDDの手法を応用しており、言語によらず汎用的
- backendだけでなく、frontendのようなUIを伴うコードも同様の考え方が適用できると気がつけた点が大きい
プロのエンジニアがコードを徐々に洗練させていく過程を見られる
- そのコードを書くときに何を考えているか / 何に気を付けるべきかという観点がとても参考になる
まずはシンプルに書いてみる + 動かしてから考えるスタンス
- 自分の場合は真逆で、少し考えてから実装することが多い
気になる点があっても今考える必要があることがあれば、それ以外のことは一旦pendingしておく
- TDDだとノートなどに書き出して、忘れるという方法が取られていた気がする
少しずつ拡張していくので、バグってもどこが怪しいかすぐに特定しやすい (=それまで動いていたなら、変更した部分に原因がある)
常に動いているコードがある、という安心感

Keep

Problem

何をどう書いたいいか分からない or 実現しようとしているタスクがやや大きいと感じる場合がある

Try

コードを書く前に日本語で必要な処理を書き出してみる
言語やFWの基本的な機能を流し読みしてみる + 必要だと思われる機能を注意深く読んで理解する
最低限動作する汚いコードを書いて、リファクタリング + 動作チェックを習慣化
fetchの典型的な書き方を調べる

出典

https://azukiazusa.dev/blog/start-with-the-ugliest-code-that-works/

KATO-Hiro / Daily-hit

記事「最小限のコードで動く最も汚いコードから始める」を読んで #1291

要約

感想

Keep

Problem

Try

出典