コードは書かれるよりも読まれる時間が長い
プログラミング言語は一度書いたら終わりではなく、他のエンジニアが読みます。
（あるいは、そのコードを読むのは一月後のあなたかもしれません）
その時に、「どこから読んだらいいかわからない」「追いかけるスタート地点が見えない」となるケースは避けたいはずです。
（これについてはリーダブルコードが未だ人気を誇っている点からも共通認識と考えて良いでしょう）
「コードは書かれるよりも読まれる時間が長い」というのは、オブジェクト指向 vs 関数型プログラミングのメイントピックだと思います。
オブジェクト指向は難しすぎると思った。
まず、オブジェクト指向は難しすぎると思いました。
そもそもオブジェクト指向の中心にあるプログラム側はclassという概念ですが、
このクラスには「プロパティ」と「メソッド」が含まれます。
class Car:
def __init__(self):
self.x = 0
def move(self, n):
self.x += n
自分がオブジェクト指向を難しいと思っている理由は、この「プロパティ」と「メソッド」をどのように利用すれば良いかは、このクラスを作成した人間しかわからないのではないか? と考えているからです。
可能なら長いドキュメントは読みたくない
仮にどのように動作するかをドキュメントで説明しようとすれば、今度はこのドキュメントを読む必要があります。
このドキュメントが受け手に正しく解釈されるかどうかは自然言語の書き手と読み手に依存してしまいます。
このドキュメントは長ければ長いほど誤解を生む原因になると思いますし、そもそもドキュメントとコードが一画面に収まらなければ読みきれません。
少なくとも長いドキュメントは読みたくない...
AWSの公式ドキュメントもとても親切丁寧に書いてますが、理解できるかどうかはまた別の問題ですね。
人間はラプラスの悪魔にはなれない
ラプラスの悪魔という概念があります。
もしもある瞬間における全ての物質の力学的状態と力を知ることができ、かつもしもそれらのデータを解析できるだけの能力の知性が存在するとすれば、この知性にとっては、不確実なことは何もなくなり、その目には未来も（過去同様に）全て見えているであろう。
あらゆる状態を完全に理解した個体をラプラスの悪魔と呼び、
この個体は未来のあらゆる事象を予見できると言います。
裏を返せば、
未来の事象を完全に予測するためには全ての状態を理解する必要がある ということです。
プログラマーはコードを理解できるチェックポイントの一つとして、「コードが想定通りに動くという点が挙げられますが」
オブジェクト指向における「現在の事象」は「プロパティ」のことだと考えます。
つまり、オブジェクト指向で書かれたプログラムの動作を予測するためには全てのプロパティとその動かし方を熟知しなければなりません
先ほどのCarクラスは、プロパティが一つの単純なクラスでしたが、ここに燃料の概念を加えるとどうでしょう？
class Car:
def __init__(self):
self.x = 0
self.fuel = 0
self.fuel_max = 100
def move(self, n):
self.x += n
self.fuel -= n
def fill_fuel(self):
self.fuel = self.fuel_max
moveメソッドは座標だけでなく、燃料の概念も管理しなくてはならなくなってしまいました。
今の状態であれば管理は可能ですが、プロパティの数が増えるに従って、人間の理解を超えてしまいます。
ラプラスの悪魔みたいなエンジニアもいますが、全てのエンジニアがそうではありません。
でもオブジェクト指向とは付き合っていかないとね...
そうはいっても「全てのプロパティ」を理解しなければならない時もあると思います。
フロントエンド開発をしている時、あらゆるプロパティを useStateで管理しなければなりません。
大変ですね〜
じゃあどうするの？
ここまでの内容をまとめると
- コードは書かれるよりも読まれる時間が長い
- 長いドキュメントは読みたくないし、コードは短い方がいい
- 人間は全てのプロパティを理解できない
となりました。
これを解決するためには、関数型プログラミングが必要だと考えていますが、それはまた別のお話...。