本書では、「ソースコード読め」と言うヤツラの欺瞞っぷりについて述べる。 反対意見があるのは理解するが、ここはそれを議論する場ではなくて我輩が 一方的に持論を吐く場なので、是非反対意見は自分とこで展開して頂きたい。
世の中のオープンソースソフトウェア(「オープンにしてやってんだぜー」という 上から目線を感じるから、我輩はこの呼び方が嫌い)には、仕様書が無い。 これをもってその動作を知ろうとする人に、「ソースコードあるんだから読みゃ いいじゃん」「コメント入ってるんだからさ」とか吐く人々が居る。 みんな感覚的にこういうのがイヤなのは分かってるんだろうが、 「オマエソースコードも読めんのか」と指摘されて恥ずかしい思いするんじゃないかと 心配して誰もツッコま(め)ないんだろうと思う。そんなピュアな人々のために、 我輩が代わりにツッコんであげます。
「ソースコード読め」と吐く人は、以下の三種類の人間のみだ。 それ以外は居ない(断言)。
相手を鍛えてやろうと思っているのかもしれないが、そんな『ライオンの子を谷底に 突き落として殺してしまう』ような鍛え方は間違っている。それはそれで 相互理解能力の欠如という重篤な障害を抱えている人だ。
ソースコード読めば全てが理解できるというのは大間違いだ。ソースコードは 最小単位の論理と事実の列挙であって、それ以上ではない。極く細部の詳細な動作を 知るのには向いているが、概要や大域の論理、そのようにコードされている理由を 知るのは極めて難しい。たとえば、B-Treeを実現するソースコードがあったとして、 B-Treeとはこういうものだという前知識なしにそのコードを読んで、それが実現 しうる機能について理解できるだろうか。そのコードのメリットデメリットに ついて、あるいはそのコードが採用された理由について、知ることができるだろうか。 絶対に無理だ。それは少々イケてるエンジニアであろうがなかろうが変わらない。
※B-Treeくらいメジャーなアルゴリズムなら、ソース上のラベル名から ググル先生に聞くなどすれば、概要を知ることはできるだろう。でも、じゃぁ マイナーなアルゴリズムだったら？ 独自機能の実現コードだったら？ どうしてBinary-TreeじゃなくてB-Treeなの？ ちゃんと検証したの？ その結果は？ つまり結局、ソースコードからそういうのを網羅的に知ることはできないのだ、 ということ。
我輩は日常的にLinux kernelのソースコード(ドライバ込みだと1500万行超えたね)を 追いかけているが、これをもって「Linux知りたい？じゃぁソースコード読め」なんて 口が裂けても絶対に言えない。前述のように、ソースコードから全体像を得るのは 極めて効率が悪い上に、それはそもそも本質ではないからだ。Linuxに限って言えば、 スケジューラの部分あたり、参照できるのがソースコードだけだったら、どういう 仕組みで動いてるのか正確に知るのに何日もかかってしまうし、 当然さまざまなアルゴリズムの前知識も必要になる。 それでもLinuxコミュニティが回ってるように見えるのは彼らがスーパーエンジニア だからであって、そうではない人々に裾野を広げるにはそれ以外の考え方が 必要なんですよ！
業務プログラムを作ったことがある人なら知っているだろう。ソフトウェア エンジニアリングが何故大事か？ 要求仕様・外部使用・モジュール仕様などなど、 なぜ仕様書が大事か？ そのプログラムを他人が使う・メンテする上で 絶対必要になるからだ。「ソースコード全部あげる、メンテしてね、仕様書ないけど」 というのを我輩はメリケンで何度か見てきたが、途中で瓦解する可能性はなんと 102％((C)ピロチ)。 一度などは、彼らがサジを投げてしまったので仕方なく我輩(※客だったはず)が メンテするというなにこの逆転現象、みたいなことも起こった。
我輩は「仕様書が必要だ」ということを言いたいんじゃない。 「安易にソースコード読めと言うな」と言いたい。せめて機能概要を示し、 読破が必要な場所を明確化した上で「詳細はここを見てね」とポイントするくらいに しとかないと、それは相手の時間を単純に浪費させるだけの意地悪ばぁさん的所業に なってしまう。このアリスチャンめ！
考えもなしに「ソースコード読めば？」とか言うヤツは、一度Linuxカーネルの 中身全部読んで理解して我輩にカンペキに説明してくれ(最近OCFS2のdlm周りのバグで 苦労してるので、特にそのへんお願い(※私信))。それができないなら言うな。 もしできるなら、キミにはその資格があると認めよう。ただし、出来ない子の 苦労がわかんない冷血漢だと認定するおまけ付きで。
はっきり言おう、ヤツラが「ソースコード読め」とノタマウのは、 以下の三つが根底にある。
何パーセントかは、本当に相手の実力を読んで、こいつならソースコードの ここを読めば何日くらいで理解できるはずだ、その方が彼の技術力向上につながる だろうし、という親心がある人が居るのは居るだろう。だったら、初めからそう言え。 「XXの箇所を読んでごらん、三日以内にわかんなかったらまた聞いてくれ」。 これで世の中丸く収まる。やりすぎて聞く方が甘えてしまってはいけないので さじ加減は難しいが、このくらいのやわらかい突き放しっぷりなら、言われた方も 「よし、読んでみるか」という気になる。
なんでこんなことを書くのかというと、今のソフトウェア業界に危機感を覚えるから。 できる人はどんどん先に進んでしまうのだけど、そうでない人がおいてけぼりに なってしまっている。で、ちょっとでも前む努力のために先人に聞いたら、 冷たく「ソースコード読めば？」といわれてしまう。それでモチベーション低下し、 結局這い上がれない人がいつまでも同じ場所にとどまってしまう。それじゃ ダメなんだ。大局で見た時に、団体や、国が凋落してしまう。底上げは絶対に必要だ。
だから、聞くほうも聞かれるほうも、もう少し大人になろう。特に聞かれる方。 聞かれるということはキミは周囲から認められている、ということだ。 周囲を巻き込んでその技術レベルの底上げができるかどうか、今一度考えて みて欲しい。「ソースコード読め、以上！」ではなく、「ああそれはＸＸって 機能を実現してんだよ、詳細は○○って本に載ってるから読んでみな、ソースコードは △△の部分ね」くらいは吐けるようになろうよ。
ということで、「ソースコード読め」は悪だ。吐く方の頭と心根の悪さも表している。 もっとみんながシヤワセになれる提案をしてくれ。言いたいのはホントそれだけ。