クソコードは人を育てるか？ - ミッションたぶんPossible

　結論から言えば、「条件付きで『あり』」になります。

　一年くらい携帯コンテンツの開発というか運用保守をやってきていたんですが、最近になってまた業務システムに従事するようになりました。大手企業さんの社内システムで、既に3年ほど稼働しているものですから、システムとしてもそれなりに規模が大きく、仕様も膨大で複雑です。後発のオレとしては覚えることが多くてなかなか大変なんですけれども、昔取った杵柄、まぁそれなりに楽しくやってます。立場的にはPG兼SE。要するに「何でもやりますよ」ってことですね。

　このシステムでオレが一番気に入らないのは「ソースコード」。PHPで構築されているんですが、まーーーーー、ひどい。今まで見てきた中で文句なしのブッチギリでNo.1を獲得したクソコードです。オレ自身大したプログラマじゃないので偉そうなことを言えないんですが、その立場をいけしゃあしゃあと棚上げしてでも、このソースコードを書いた輩をハートマン軍曹ばりに全力で罵倒したい程度には憎悪の対象になっています。*1

　どの程度酷いかというと、MVCモデルのはずがMVCになってない、メソッドの切り出し方が不適切、コメントが書いてない、なんてのは軽いジャブで、そもそもM(Model)が存在せずSQLが業務ロジックにベタ書き、SQLに「*(アスタリスク)」を使っている*2、トランザクション実装がいいかげんでロールバックのタイミングがおかしい、Viewの中がロジックで膨れ上がっている、Viewで定義したデータ項目が業務ロジックにもModelにも存在しない、ポップアップ画面など共通部品として切り出してあるロジックの中に業務ロジックがめいいっぱい書いてある*3、などなど。クソコードにありがちなアンチパターンが満載です。じぇんきんす？　てすとこーど？　なにそれ美味しいの？　Framework使っててどうしてここまで酷いコードになるのか、オレにはちょっと分からないですねぇ。もう「究極のクソコードを生むスタンド」が発動されたとしか思えない。
　先日ちょっとした不具合が出て、今までの経験から「本番反映まで見て、まぁ多めに見ても2人日程度じゃないですかねぇ」と回答したんですが、実際に改修すると半月以上かかりました。改修自体も大変でしたけど、数人がかりでチェックしたのにも関わらず、本番反映直後に派手にデグレード起こしちゃったんですよねぇ。どうしてこうなった？
　もうこれは「クソコードの百貨店」「ゴミコードの宝石箱」と呼ぶに相応しい。オレが彦摩呂面でディスプレイと向き合っている姿をご想像頂けると、現場の愉快な臨場感が伝わるんじゃないかと思われます。ファッキンシット。

　こういうクソコードに出会うと、おそらく大半のプログラマが「捨てたい！」「書き直したい！」と強烈に思うはずです。それはオレでもご多分に漏れずそう思うわけで、システムリニューアルなんか待たずにちょっとずつでも変えてやろう、とか密かに企んでます。このままだと、とてもじゃないけどメンテナンスコストが大きすぎて話にならない。自分の理想にちょっとでも近づけたいなぁと思うんですよね。

　じゃあオレの「理想のソースコード」ってなんなのさ？　ってことを自問すると、当たり前ですけど自分の想像力を超えない範囲にとどまるわけですよ。もっと読みやすくしよう、とか、ちゃんとMVCを分離しよう、とか、仕様書読まなくてもある程度どんなデータ引用しているか分かるようにしよう、とか、それぞれの役割をもっと明確にしよう、とか、可能な限り性能を上げよう、とか。情報源としては、これまで読んだ技術書だったり、勉強会で聞いた話だったり。

　オレの場合は拠り所になりそうなのは「かつて開発に携わったシステム」です。前職では大手SIerの下で大規模開発に携わってきましたが、ああいう現場は一度にたくさんの人が集まることもあって、技術者の技量が十把一絡げ、中にはどーしょーも無いのが往々にして混ざります。そういうのでもある程度のレベルで開発してもらう為に、大手の現場ではあらかじめ開発標準やなんかがちゃんと準備されています。頭の良い人が考えてるだけあってその仕組みはしっかりしていて、そういう現場で見るコードは破綻があまり見られません。(ちゃんとしてないこともそれなりにありますが、そういうのはだいたい、仕組みが破綻するくらい酷い原因が別にあって、結果コードも引きずられる、というケースですね。)そういう「仕組み」のありがたみって、当時はわかりませんでした。恩恵が無くなって分かる、失って初めて気付く、ということなんでしょうな。

　じゃあ、そういうのを参考にしようと思うんですが、当時のオレは「準備される側」であって「準備する側」ではありませんでした。輪郭は分かるけど中身までは分からない。分からないなら調べるしかないわけです。そんなわけでオレは今更ながら「エリック・エヴァンスのドメイン駆動設計」を読み始めたり、テストの書き方考えたり、機能の切り出し方を検討したり、確認用のドキュメント作ったり、とできる範囲で学習と準備を進めています。

　さて、冒頭の問いに戻りますが、「クソコードがプログラマを成長させることがあるか？」というと、あることはあるんじゃないかな、と思います。ただし、いくつか条件があります。

　最低限満たしていないといけないのは「クソコードに対する嫌悪感」です。これが無くてクソコードを受け入れてしまうようだと話はそこで終了です。お疲れ様でした、次のプロジェクトで逢いましょう。
　次に、クソコードがクソコードだと気付く程度の知識・経験が必要です。敵が何者だか分かってないのに戦うことはできません。
　最後に、クソコードと戦う覚悟と闘争心。嫌悪感だけでは何も始まりません。「一行残らず駆逐してやる！」という憎悪をはらんだ決意が人を前へ進めます。

　これらが揃えば、プログラマが学習するための「動機」として、「クソコード」はなかなか悪くない存在なのではないでしょうか。なにせ目の前にあり続け、延々と苛み続ける迷惑極まりない存在なのですから。めいいっぱい良い表現をすれば、クソコードはさながらスポーツにおけるライバルのような存在かもしれません。まぁクソコードのことを「強敵」と書いても「とも」とは死んでもルビを振りたくはありませんが。

　ケーススタディがオレ1人分しかなくて恐縮ですが、おそらくクソコードに苦しめられている人は非常に多いはず。どうせ向き合わなくちゃいけないのなら、前向きに向き合いたいものです。クソコードと戦う際には、くれぐれもデグレードにはご注意あれ。