読みやすいコードとはなにか？未来の自分とチームへの思いやり

読みやすいコードとはなにか？未来の自分とチームへの思いやりじょうげん / React Tokyoミートアップ 2025/12/12

私は誰？ 👋 じょうげんと申しますフリーランスエンジニア React Tokyo サポーターコードの可読性にこだわりあり

https://zenn.dev/bmth/articles/interface-props-ex tends

コードの迷宮

Co-locatio n 関連するコードは近くに配置する

それぞれのコードが遠くにある機能ごとにバラバラの場所に配置されている。 Directory Structure (Bad) あっちこっちへファイルジャンプが必要全体像が見えにくい「hooks」や「types」フォルダに縛られている

ディレクトリを近くに Package by Feature 機能単位でまとめる（コロケーション）。 Package by Feature (Good) 関連ファイルが隣にある安心感
ディレクトリ構造が浅くなる機能の削除や移動が簡単

関連するコードは近くにそのファイルでしか使わないなら、同じファイルに定義してしまう。「1ファイル1コンポーネント」のルールに縛られすぎない。文脈が分断された短いファイルより、文脈が繋がった長いファイルの方が読みやすい場合が多い。 user-list. tsx

同じ関数内に定義する単純な処理なら、無理に外へ切り出さずコンポーネント内（または `useCallback`）に留める。 Component Internal コードジャンプの認知負荷を減らすロジックのスコープを限定する

なぜコードを遠ざけてしまうのか見かけ上のわかりやすさファイルが短いと「整理されている」と錯覚してしまう。過去の慣習 MVCフレームワークなどの、役割ごとにディレクトリを分ける古い制約の名残。

ファイル内での宣言順序上から下へ、物語のように

Anti-Pattern: Bottom-Up 結論が最後にある最後まで読まないと「ファイルの目的」がわからない。ヘルパー関数が延々と続き、読む気を削ぐ。 user-actions. tsx

コードは「新聞」のように見出し（結論） → リード（概要） → 詳細

Top-Down Approach 結論から書くファイルを開いた瞬間に「何をするモジュールか」が理解できる。 user-actions. tsx

宣言順序の制約 Reactコンポーネントはモジュールのトップレベルで呼ばれることはないので、アロー関数でも下に定義して問題ない。 Function Declaration (Hoisting OK) Arrow Function (NG)

脳内のリソースを意識しようワーキングメモリを節約する記述

order-status.tsx Before 認知負荷が高い「ユーザーがいて、品目があって、残高があって...」複数の前提条件を同時に記憶しながら読み進める必要がある。

order-status.tsx After 早期リターン不要な条件（異常系）を先に排除する。考慮事項を捨てながら読み進められる関数の最後は必ず正常系という統一感

まとめ未来の自分への思いやりを。 01 Co-location 関連するコードは近くに。ディレクトリを分けすぎない。 02 Top-down 重要な処理を先頭に。新聞のような構成を意識する。

Image Sources https://static.vecteezy.com/system/resources/previews/002/907/976/non_2x/maze-background-blue-labyrinth-backdrop-abstract-hi-tech-mosaic-background-modern -technology-backdrop-vector.jpg Source: www.vecteezy.com https://media.istockphoto.com/id/1201229921/vector/vintage-newspaper-design.jpg?s=612612&w=0&k=20&c=Nrqwcj0uZ2SMz8BKY9wXjWR3nEXv0JRVc12RvxhvAc8= Source: www.istockphoto.com

読みやすいコードとはなにか？未来の自分とチームへの思いやり

読みやすいコードとはなにか？未来の自分とチームへの思いやり

じょうげん

More Decks by じょうげん

Featured

Transcript