世の中には2種類のエンジニアがいる。
具象思考しかできないエンジニアと、抽象思考ができるエンジニアだ。
プロダクトがごくごく小さければ、例えば0->1の初期実装の段階では、「動作する」という点だけから見れば、どちらも大した差はない。
皿回しで例えると、初期段階、皿を4つくらい回す程度なら、大した違いがない。
が、16、32と増えていくとどうなるか。
具象思考は、1つ1つを回す。
64、128と増えていったら?
破綻する。
抽象思考は、ある程度の皿のグループをまとめて、回し続けるための仕組みを作る。
皿が追加されるまで棒を立てないとしても、どういう皿が用意されているかあらかじめ確認をして、配置などの準備をしておく(本来は、これをDDDのドメイン分析という) 。
64、128と増えていったら?
まとめたグループをさらにまとめて回す仕組みを「予定通り」作る。
作っておいてもいいが。
どのレベルのグループの数も、8を超えないように調整しつつ(だいたい5を超えないようにしている。平均的な認知能力を超えないように)。
256、512、1024……。
具象思考のエンジニアは、「今の段階でそこまで実装する必要はない」という。
が、設計もしない。
なぜなら考えられないから。
棒を立て(実装)なくても、配置や仕組みなどを「設計」し、区画を分ける。
プログラマ上がりの中には、手が早いだけで具象思考しかできないエンジニアが大量に混じってる。
ググって、今目の前にある皿を最適に回せる棒を探して、空いた場所に立てて、回し始める。
その一連の「処理」は早い。
けど、それぞれ思い思いの棒を立てるから、それぞれの皿の回転状態をメンテし続けるのは大変だ。
この棒はこうやって操作する。
その棒はこうやって操作する。
そういう、何種類もある「処理」からパターンにマッチした処理を手早く行う。
そのパターンの数を誇って「優秀なエンジニアでござい」と鼻をおっ広げる。
バカ言え w
数が増えれば限界が来る。
皿が落ち、割れ始める。
逃げる。