クソコードはエンジニアを貧乏にする

ミノ駆動

何が書かれているのか理解が難しく、イレギュラーな方法で裏技的に実装され、ちょっと触ればバグと化す、クソコード。
プログラマ諸氏なら誰しもが見たことのあるクソ忌々しいアイツだ。

クソコードはエンジニアを貧乏にしてしまう。
なぜ貧乏になってしまうのか、その理由について、怒りをぶつけながら以下に書き連ねる。


本記事の構成

■理由①：プロダクトが利益を出せなくなる
■理由②：エンジニアが資産蓄積できなくなる　（←ココ重要）
■クソコードを滅ぼし豊かになろう
■ソフトウェア開発に携わる方々へ


理由①：プロダクトが利益を出せなくなる

まずこちらの理由は簡単だ。３項目に分けて説明する。

【クソコードは読みにくい】
どんなロジックなのか理解が容易ではない。ロジックそのものは簡単であっても、tmpと名付けられた正体不明な変数、非推奨なAPIによる意図不明な実装などにより、読み解くのを難しくさせてしまう。
「クソコードを読み解いていたら日が暮れていた」、そんな経験、山のようにあるのではないか。そう、クソコードは理解に要する時間を浪費させ、開発コストを増大させるのだ。

【クソコードはバグになりやすい】
クソコードは極めてアンバランスでトリッキーな実装であることが多く、ちょっと変更しただけで即バグになってしまう。さながらゲームオーバー直前のジェンガのようだ。
仕様変更等によりコード修正するとき、バグ化しないよう極めて慎重な検討を要する。つまり検討時間を浪費してしまう。そう、またしても開発コストが増大するのだ。

【バグがどこに埋まってるか分かりにくい】
上記の「クソコードは読みにくい」と同様に、クソコードはバグがどこにあるのか理解を難しくさせるのだ。そうしてバグが埋まったままプロダクトがリリースされたらどうなるか。顧客がバグに苦しむことになるのだ。修正対応のため更に開発コストがかさむ。重大インシデントを起こそうものなら顧客からの信頼を失い、そもそもプロダクトが売れなくなってしまうのだ。

以上３因子により開発コストが増大し、プロダクトが売れなくなる。
折角プロダクトが売れても高騰した開発コストで利益が薄くなる。
プロダクトが売れなくてそもそも利益が出なくなる。
こうして折角開発したプロダクトが利益を出せなくなるのだ。
当然それはエンジニアの給与にも響く。利益が出ないのだから給料が上がるワケがない。

こうしてクソコードによりエンジニアは貧乏になるのだ。

理由②：エンジニアが資産蓄積できなくなる

本記事で最も主張したいのはこちらの方で、深刻。エンジニアにとって非常に重要なのでよく読んでほしい。

【エンジニアにとっての資産とは何か】
ちょっと考えてみてほしい、「エンジニアにとっての」資産とは。貯蓄が沢山あること？高年収であること？
人によってお金の使い方は異なるから貯蓄額の多寡は「エンジニアにとっての」資産とは違うように思える。年収に関しても、経済の浮き沈みでいくらでも変わるものだから、「エンジニアにとっての」本質的な資産とは異なるだろう。
ではエンジニアにとっての資産とは何か。それは技術力に他ならないと私は考える。貯蓄がゼロだろうと何だろうと、技術力があればどこでも稼いでいけるのがエンジニアであり、まさに富を生み出す源泉に他ならない。何にも代え難いエンジニア自身の貴重な資産だと考える。
しかし、クソコードは資産の蓄積、即ち技術力の蓄積を妨げてしまう恐ろしい存在なのだ。その理由を以下に説明する。

【クソコードに人は引きずられやすい】
新入社員や後任担当者が、とあるクソコードプロダクトの開発を担当したとする。先輩社員や前任者が書いたコードがクソコードだと気付かず、むしろ「これが先輩のお手本だ」とか「前任者の流儀だ」とか勘違いを起こし、クソコードと同じ書き方で更にクソコードが量産されることが非常に多く見られる。技術力が未熟な新入社員は特に顕著だ。クソコードを書くプログラマをクソコーダーとかウンコーダーとか揶揄する表現があるが、クソコードはクソコーダーを育ててしまうのだ。エンジニアを低スキルに貶めてしまうのだ。

【クソコードは高品質設計を妨げる】
中にはクソコードのマズさに気付くエンジニアもいる。なんとか設計的なテコ入れを試みたりするだろう。しかし設計に理解あるエンジニア諸氏なら分かると思うが、理由①でも述べたようにクソコードは極めてアンバランスでトリッキーな実装であることが多く、設計改善が非常に困難。プロジェクトの納期等の都合により、設計改善を諦めてしまうことが本当に多いのだ。結局高品質な設計実装の経験を積めなくなり、エンジニアが設計スキル向上を果たせなくなるのだ。

【クソコードは設計工数を減少させる】
理由①で述べたようにクソコードは理解に多大な時間を要する。一方時間は有限である。従って、その分本来設計に充てられるべき時間が目減りしてしまうのだ。
十分な設計時間が与えられずに経験を積めず、やはり設計スキル向上を果たせなくなるのだ。

以上、クソコードは設計スキル向上の妨げになり、エンジニアにとって大事な、本 当 に 大 事 な 資産を蓄積できなくしてしまうのだ。
そして、エンジニアにとって技術力は収入に直結する。クソコードはエンジニアを低スキルのまま推移させ、稼げなくしてしまうのだ。

こうしてクソコードによりエンジニアは貧乏になるのだ。

誰が好き好んで貧乏になりたいだろうか。
クソコードはまさにクソであり、クソに触れたエンジニア全てを貧乏にしてしまうのだ。
それだけではない。プロジェクト炎上により長時間労働が慢性化し、エンジニアの心身を滅ぼしてしまう。そしていつしかこうなるのだ。

(上記は拙作ゲーム、バグを退治するRPG「バグハンター2」の1シーン)
クソコードはエンジニアの生命、財産を脅かす。だから私はクソコードに対し大きな怒りを覚えるのだ。

クソコードを滅ぼし豊かになろう

クソコードがいかにエンジニアを貧しくするかお分かり頂けたかと思う。
そしてここから導き出されることとして、クソコードとは真逆。理解が容易でバグを埋め込みにくく、良きお手本となってエンジニアを育てる、いわゆるエレガントコードを書ける技術というのは、それだけでもお金になる。技術力が収入に直結することが、本記事の記述から容易に想像できると思う。

そして幸いなことに、エレガントコードを書く技術や、クソコードを滅ぼしエレガントコードへ昇華させる(リファクタリングする)技術が存在する。それらの技術を学べる書籍を以下に列挙する。私も重宝している。是非お役に立ててほしい。

【初学者～中級者向け】

どのようにコードを書いたり設計すれば良いかについて、簡単なソースコードを実例に、極めて平易な言葉で分かりやすく記述された良書。
未熟なコードを少しずつエレガントコードへ成長させていく過程とその意図がとても分かりやすく、私的にはプログラミング初心者必読の書だと思っている。
また、クラスの設計方法についてもおさえるべきポイントが分かりやすく解説されており、高品質設計を所望する中級者にも是非オススメ。

コードを読みやすくし、意図をより正確に伝えやすくするノウハウに溢れた名著。ベストセラー。これもプログラミング初心者必読。

【中級者向け】

リファクタリングとは、外部から見た動作を変えず、ソースコードの内部構造を整理することである。
本書では様々な種類のクソコードそれぞれ対応するリファクタリング技法について解説しており、クソコードを滅ぼすための戦闘指南書。
「どんなコードがクソコード？」…観点がないとそもそもクソコードかどうかを認識できない。見えないのだ。クソコードを知ることで、クソコードが見えるようになる。そんな「認識のメガネ」を入手できるのも本書の良いところ。

これも書籍「リファクタリング」と同様、クソコード事例集及びその対策集。クソコードの認識力を高め、クソコードを発見できるようになろう。そしてこの書に倣い、クリーンでエレガントなコードを書けるようになろう。

書籍「リファクタリング」よりも更に実戦的に、バトルモードでクソコードを滅ぼす方法が書かれた本。「影響スケッチ」や「試行リファクタリング」などクソコードの弱点を見破る手法や、「スプラウトメソッド」や「ファイアウォール」などクソコードからダメージを受けずに機能追加する手法に関しても記述がアツイ。

書籍「レガシーコード改善ガイド」が実装レベルの戦術論である一方、こちらの「レガシーソフトウェア改善ガイド」は、リファクタリングをどのように進めていくか、計画や組織にフォーカスした戦略論。
いざリファクタリングしようにも、「動いてるコードに触るな」とか現場の反発を受けたり、そもそもどこから着手すれば良いか分からないといった、組織上の課題や計画上の課題がある。そうした課題の解決方法が書かれているのが本書。

【中級～上級者向け】

ソフトウェア開発とは常に複雑さとの戦いである。そんな複雑さと戦い抜き、ソフトウェアの価値を最大化するための戦術、戦略、思想について深く追求されている書。内容は極めて抽象的で、本書の理解にはソフトウェア開発の様々な実践経験を要するが、本書を少しでも読み解いて自分なりに解釈し、実践(実際の設計、プログラミング)へ活かすことで、エンジニアとして更に大きく成長を果たすことができるであろう。

【オマケ】

バグやクソコードに対する怒りのあまり、私が制作したゲーム「バグハンター」
バグを退治するRPGで、敵として登場する様々なバグやクソコードを、プログラミング技術で退治する、という内容のゲーム。クソコードや技術名、設計原則などを学べるちょっとした教養作品になっているのが特徴。
Windows版しか対応していないが、無料なので手に取って遊んでみてほしい。

更に続編、バグ退治RPG「バグハンター2」。前作と同様コンセプトで、物語形式でバグとの戦いを楽しめる作品。ニンテンドー3DSで無料でプレイ可能。(下記はダウンロード方法)

ソフトウェア開発に携わる方々へ

最後に私からのメッセージである。

【これからIT関係へ就職、転職する方へ】
クソコードが書かれ、苦しんでいる現場はいくらでもある。そしてそれは企業の規模に関係ない。私のようにクソコードを滅ぼすのが大好きなよっぽどの物好きでない限り、クソコードは単に貧乏になるだけで何も良いことがない。そんな会社には就職したくないだろう。
クソコードを書く会社を見分ける方法がある。現場のエンジニアがどんな専門書を読んでいるか、最も大きなクラスのソースコード行数は何行か、現状の設計課題は何かなどを面接官に尋ねてみるといい。答えを濁したりマトモに答えられないならその会社はNGだ。椅子を蹴って早々に立ち去った方が良い。こういう回答ができるのは現場のエンジニアしかいないから、面接官にエンジニアがいなければ、それだけでもアウトだ。
また、これから転職する方にも同様のことが言えて、現職製品のソースコード行数やコードメトリクス、設計課題を認識し、課題に対し自分なりにどう工夫し解決を試みているか説明できるようにしておくことが、採用を勝ち取る方法のひとつだと考える。

【一部の勘違いエンジニアへ】
私も勘違いエンジニアかも知れないので書くのがはばかられるが、どうしても書いておきたい。
「我々にはどこに行っても通用する技術力がある」と宣っていた開発責任者が私の前職にいた。数千数万行単位の長大なクソコードを修正して、慢性的な長時間労働を解決してから言えと。上述したようにどんなコードがクソコードか認識できなければ、クソコードがそもそも見えないのだ。中、上級を名乗るエンジニアでも、今一度上に挙げたような専門書を学習し、自分たちがクソコードを書いてないかどうか顧みて欲しい。
また、難解なクソコードを書いておきながら「この程度のコードも読めないなんてプログラマじゃないでしょ」と宣う者もいた。周りからしたら迷惑でしかないから悦に浸るヒマがあったら読める形に直してほしいものだ。
また、マニアックなAPIを使いこなしてトリッキーな実装できる俺スゲーと悦に浸る者もいた。頼むから普通に設計実装する場面でマニアックな非推奨APIを使うのはやめてほしい。ちゃんと設計すれば解決できるような技術課題を、マニアックなAPIで無理くり裏口を開けて解決するようなマネは、設計改善を本当に困難にさせるからやめてほしい。

【アーキテクトの方へ】
開発メンバー全てがエレガントコードを書けるとは限らない。中には入社したばかりの未熟なプログラマもいる。未熟なプログラマが書いたコードは往々にして品質が悪い。そうしたコードが他に伝搬しないよう、影響が局所化するようにレイヤー設計をしてほしい。
局所化されていればプロダクトへの悪影響が最小限で済むため、未熟なプログラマが安心して技術向上できる。また、他のメンバーの心理的安全性が向上する。
また、書籍「Clean Architecture」の記述にあるように、アーキテクトはプロダクトの設計品質責任者。営業部隊やお偉いさんからの無理な変更要求により品質毀損の危険性があるなら、怯まず戦ってほしい。

【経営者の方へ】
経営サイドで、プログラミングに熟達してない方がこの記事をお読みであれば、我々エンジニアが常にクソコードの恐怖に怯え、エンジニアとして成長できるか否か、つまり資産蓄積できるかどうかに頭を悩ませていることを認識してほしい。
そして経営者であれば費用対効果を気にするはずだ。本記事で説明したように、クソコードは費用対効果を著しく悪化させる。
もし経営者であるあなたがソフトウェア開発に投資し、利益を最大化したいと願うならば、設計品質の知識に明るいエンジニアを高給で雇うべきだ。日本経済が「失われた20年」などと言われ続けて久しいが、こうした技術的テコ入れにより企業は潤うし、ひいては経済回復へ繋がることであろう。ぜひ賢明なご判断を願う。

いいなと思ったら応援しよう！