IT業界で気づいたことをこっそり書くブログ

くすぶってる系アプリエンジニアが、日々気づいたことを適当に綴っていきます(受託→ベンチャー→フリー→大企業→ベンチャー→起業(仮))

抽象度のコントロールが出来るプログラマーになる

多くのプログラマーは抽象度をコントロールできていないのでは?説

「抽象化」って結構揺れが有る言葉ですね。
抽象化 (計算機科学) - Wikipedia
今特に言いたいのは主に共通化です。
 
例えば、ある処理をメソッドにするか、メソッドにする場合どのくらいの抽象度にするか、どこを共通化するか。
など、抽象度を選択するシーンは常に存在します。

抽象度を高くすると、より汎用的に、何でもできるようになります。
抽象度を低くすると、より具体的に、それしかできないようになります。

f:id:otihateten3510:20181002122422j:plain

これを適切に判断、コントロールしているケースをあまり見かけません。
(固定抽象度になっている)

 

抽象度が高い=善ではない

抽象度は使いやすさとトレードオフします。
具体的な方が「それしかできない」ため理解しやすく、「その他」について論じる必要がありません。

what 汎用 専用
将来に対して 開いている(発展) 閉じている(収束)
作るのは 難しい 簡単
考えることが 増える、難しくなる 減る、簡単になる
新しいものを追加する時 足並みを揃える必要がある 足並みをそろえる必要は少ない
必要なシーンは ライブラリ、ユーティリティ、パーツなど 製品、具体的な画面など

「オレの最強抽象度」を持ってはいけない

デザインパターンやイケてるコードにこだわりすぎると、抽象度はいたずらに上がってしまいます。
抽象度が上がると、すべてのパターンを網羅するのが大変になります。

簡単な例を考えてみます。
ある四角形の面積が100だとして、「100」という数字を使いたいとします。
仕様上、四角形が1つしかなくて固定である場合は、「100」を定義しても良いと思います。
代わりの案として、四角形が長方形なら、100ではなく「縦と横」を定義する方法です。
我々は長方形の面積が縦×横だと分かっているので、面積を直接定義するのと大差はありません。
抽象度の高く、行き過ぎた案としては、あらゆる四角形の面積を求める関数を作成することです。
100という数字が欲しいだけなのに、関数が正しいことをテストしたり、不必要な想定に対処しなければなりません。
動くのにバグが有る状態になって、バグが潜伏したりもします。
 
 

いつ抽象度を上げ、いつ抽象度を下げるのか

 
例えば汚いコードをキレイにしていくときは、抽象度を下げるべきだと思います。余計に混乱を生んでしまいます。
ライブラリを作る際には抽象度を上げるべきでしょう。より汎用的なものになります。
あとから抽象度を上げられるなら、まずは抽象度を下げて取り組むべきでしょう。
 

・・・と、これ以上はまだちゃんと考えていないんですが(本題の「なるには」の部分)
「抽象度は選択するもので、利便性とはトレードオフである」っていうの、どう思われてるんだろうとの疑問でした。
また考えが進んだら書きます。