なんとなーくソフトウェアの設計って「難しいなあ」って思ってたんだけど、実は「抽象化（ちゅうしょうか）」をどう使うかがポイントらしいんだよね💡
え、抽象化って？…って感じだけど、カンタンに言うと「細かい部分をうまく隠して、全体をシンプルに見せること」みたいなもの✨ これがうまくできると、コードがスッキリして管理しやすくなるんだって🥺
でもね、逆に抽象化を「使いすぎちゃう」と、複雑な迷路みたいになっちゃうこともあるらしくて。つまり、ソフトウェアアーキテクチャって『抽象化をどこで使うか』にお金（リソース）をかけること＝「spending abstractions」ってことなんだって👀
抽象化が多いとどうなるの？
-
良いとこ
- コードの重複を減らせる
- 変更が楽になる（修正箇所が減る）
- チームでの認識合わせがしやすい
-
悪いとこ
- どこに何があるか分かりにくくなる
- 学習コストが高くなる（新人泣かせ）
- 実際の動きを追うのが大変になる
このバランスを見極めるのが、設計者の腕の見せどころなんだなあって思うよ😳
どうやって「使いどころ」を見つけるの？
わたしもまだまだ初心者だから難しいけど、記事に書いてあったのは…
- 抽象化には「コスト」がある ってことを忘れないこと
- 簡単に思えることも、無駄に抽象化しすぎないこと
- ちゃんと「何のために抽象化するのか？」理由を意識すること
みたいな感じ✨
なんだか社会で「コスパ」考えるのと似てる気がして、ちょっと面白かったよ💭
ちょっと身近な例で考えてみると…
たとえば毎朝のメイク道具を全部一緒にボックスに入れて管理したとするよね？
それが「抽象化」だとすると、
「リップ」「アイシャドウ」「チーク」…みんなまとめて『メイク道具』ってくくって管理できる。便利じゃん？💗
でも、もしボックスの中がごちゃごちゃで取りづらいと、逆にイライラしちゃうかも💦
だから「どこまでまとめるか」ってすごく大事になるよね〜って話✨
ソフトウェア設計だって、これに似てるんだなあって気づいたよ😆
というわけで、ソフトウェアアーキテクチャは「抽象化を使う場所を賢く選ぶ」ことがすごく大事って話でした💡
これからプログラミングとか設計に関わる人は、ぜひ「抽象化コスト」も意識してみてほしいなって思うよ🥺
また何か気づいたら、ゆるーくじゃなくてちゃんと書くね（笑）✨
読んでくれてありがとう💗
はてな
