【要約】「カレーを作るな、カレールーを入れた煮込みを作れ」：超新人エンジニア向け 抽象化と命名の話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
以下のような設計上の課題を指摘している。
- 抽象化過剰：
- ・特定の対象に依存した命名（例:
makeCurry）による、再利用性の欠如。 - ・類似した処理の量産による、修正コストの増大と修正漏れのリスク。
- ・抽象化の失敗による、コードの意図が不明瞭になる問題。
- 抽象化過剰：
makeMeal のように、何をするか不明な状態。// Approach
「対象」ではなく「操作」に注目した設計への転換を推奨している。
1.共通する手順を特定する。
- 材料を切る、煮込む、味付けする、といった工程を抽出。2.命名を「操作」に基づかせる。
- cutCarrot ではなく kiru($carrot) とする。3.具体的な対象は引数で制御する。
- cookNikomi($zairyoList, $ajitsuke) のように設計。4.抽象化の粒度を適切に保つ。
- 何をしているか具体的にイメージできる関数名にする。// Result
適切な抽象化により、以下の改善が見込める。
- ・汎用性の向上：カレー以外にシチューやポトフにも適用可能。
- ・保守性の向上：共通処理の修正が1箇所で完結する。
- ・可読性の向上：関数名から具体的な操作が判別でき、安心感のあるコードになる。
Senior Engineer Insight
> 抽象化の「度合い」の制御こそが、シニアエンジニアの腕の見せ所である。過剰な抽象化は、コードをブラックボックス化させ、デバッグコストを跳ね上げる。一方で、抽象化の欠如は技術負債を蓄積させる。現場では「同じ処理を2回書いたら抽象化を検討する」という著者の基準は、極めて実用的かつ健全な指針だ。実装においては、関数名から「何をするか」が即座に判別できる粒度を維持し、スケーラビリティと可読性のバランスを厳格に管理すべきである。