  |
自分で書くのとどちらが辛いかといえば、読むほうが３倍ぐらい辛い。
だからプログラムを勉強しようとして、コードリーディングから始めようとする人はまずいないし、おすすめできない。
■問題なのは行数じゃないのだ。理解できるかどうかなのだ。ここになぜこの変数があるのか、
なぜインクリメントしているのか。ここの配列はここで定義されているけど、どこにも使ってないのはなぜか。
ここの処理はなぜこんな場所にあるのか。
大体においてコメントは残されている。
/* ここでxにyを代入する */
いやそんなの見ればわかるって。私が聞きたいのは「ここで」「なぜ」「そんな」処理をしたかだ。
■プログラムのアーキテクチャに正解はない。あるのは哲学だけだ。
アルゴリズムとは違う。アルゴリズムには正解がある。最適解を出す最適な方法は1つしかない。
アーキテクチャの哲学とはシーケンスの流し方、データの扱い方であり、プログラムの骨格に当たるもので、
書いた人の人格そのものである。だから他人のコードはわからなくて当たり前なのだ。
■現実問題として、プログラマはそんなコードと対峙しなくてはならない。
書いた人は既に退職していない、そんことはザラにある。バグだらけ？大いに結構。
重要なのは機能なのだ。中身がどうなっていようが、そんなの気にもとめられない。
もしかして１から作ったほうが速いのではないか、プログラマなら１度は思ったことがあるはずだ。
だがそんな工数はどこにも用意されない。
■流用だ。すべての問題を悪化させているのは、特化されたソフトウエアの流用だ。
前記の理由で１から作るのを諦めたプログラマはそこから地獄のコードリーディングが始まる。
訳の分からない変数、配列、処理の羅列。データはあっちに飛び、こっちに飛び。全体を理解したころには
既に開発は終了間近。機能を無理やり作りこみ、素知らぬ顔でプロダクトを送り出す。
■だからこそ共通となるフレームワークやライブラリが必要なのだ。
ソフトウエアの優劣など正直どうでもいい。それを扱える人間の汎用性こそが重要なのだ。
１から理解する必要がなくなるというだけで、どれほどの炎上プロジェクトが鎮火するだろうか。
間違っても社内フレームワークやオレオレライブラリなどは作っちゃいけない。
■結論にいきたい。
他人のコードを読むのは辛い。だったら読まなくてもいいようにすればいいのだ。
用意された欄に数字や文字を書いて提出するお役所の書類のような、そんなコードライティングを目指すべきだ。
そして欄がない場合は、欄外に殴り書きするのではなくて、新たに欄を作るべきだ。そしてそれがプログラマの
本当の仕事になるべきだ。欄は共用の財産となり、テストして改良されるか、あるいは無用として削除されるだろう。
いい加減コードなんて不要なもの作ればいいじゃない
「クソコードの」コードリーディングは辛いって話でしょ。そりゃそうよ。 Linux、Apache、MySQLについては仕事上必要な箇所だけ斜め読みした経験があるが 十分に意図は汲み取れた。 Word...
11
