［コードリーディング］コードは極力読まない👀
Hideyuki Fujihara書籍『世界一流エンジニアの思考法』を読んでいる中でつらつらと感じ、考えたことを書いてみようと思います。
Hideyuki Fujihara大規模な開発に携わったり、途中からジョインしたりする際、プロダクトコード全体は長大になっているもの。
そしてこれらを端から端まで全てに目を通し、完璧に理解せねばならないとの観念に囚われてしまいそうになるかも知れない。
Hideyuki Fujiharaただここで重要なのは、
『コードは極力読まない』
ということ。
本著ではそれを同僚の方の名を冠して『クーパーメソッド』と呼ばれていました。
それは実装した開発者を信じて、子細な部分には極力触れず、
斜め読みをしてざっくり理解すると言うこと。
Hideyuki Fujihara例えば、関数やメソッドの中のステートメント全てに隈無く目を通すのではなく、
それとコミュニケーションをしているコード同士のインターフェースを意識する。
それの振る舞いを意識する。
クラスやオブジェクトで言えば、
それがどんな役割、責務、関心事からなるものであり、
どんなプロパティからなるものか、
どんな振る舞いをするのかに意識をすると言うこと。
アーキテクチャで言えば、各レイヤーのコード全てを隈無く見るのではなく、
レイヤー間がどの様な役割、責務、関心事により抽象的に分割され、
コミュニケーションをしているのか、
依存の矢印がどのように向いているのか、
これを理解すること。
Hideyuki Fujihara仔細具象なことに囚われるのではなく、
それは必要性が生まれた時にフィーチャーし、
抽象的に捉えること。
つまり、『一言で言うと何なのか？』を理解することに注力し、
その中身にはあまり踏み込み過ぎないこと。
ある意味、ホワイトボックスではなくブラックボックスで眺めること。
これが肝になってくる。
Hideyuki Fujihara逆に言うと、それがスッキリ出来ない時。
例えば関数名が冗長であったり具象に踏み込んでいたり、実装も長大であったりなどで要約的になっていない時。
レイヤーの境目が見えづらく、それらが互いに重なっていたり、または消失しているように感じられる時。
そう言った時は、
そのコードやアーキテクチャを見直すタイミングになっている、とも言い得るものと思われる。
なぜなら、自分以外の他人もそう思っている可能性が高いからだ。
多少の差こそあれ、認知上の負荷には上限があるからだ。
つまり、自分だけが理解できないもの、ではないのだ。
Hideyuki Fujiharaこう言ったものと相対する時は、
枝葉末節に拘りすぎず、
抽象的で大きなストーリーを意識する。
それがしやすくなるように、ボーイスカウトルールで手直しをしていく。
そして何より自己卑下的になってしまわぬように、
皆もまたそうなのだと理解すること。
上手く行かない時はそれは自分が劣っているからではなく上手く行かない方法を行っているからであり、
そしてそれは誰がやっても同じであるから、
より上手く行く方法を真似ることが重要なのだろう。