クソコードとかいうおぞましい何かについて

仕事がしんどい。

というのも、最近アホみたいに長いクラスに機能追加で実装をやっているからだ。

その行数は2000行。

いや、この程度の行数ならまだマシだろと思うかもしれない。

私はまだ3つしか案件を経験しておらず、ベテランの方からしたら経験が浅いからこの行数がしんどく見えるかもしれない、が。

よく分からない分岐、コメントの少なさ、状態遷移の多さ、そしてそれに対してのドキュメントの少なさ…など、理解に時間がかかりまくった。

そしてようやく理解した頃には、もうそのコードを見るだけで頭がぼーっとするくらい、生産性がだだ下がっていた。

何故このような事態になってしまったのか？

私が今回体験したケースでは、以下の2つの要因があると考えられる。

開発手法

今回、現場ではアジャイル開発でシステムの開発が進行していた。

そして、アジャイル開発は仕様の変化に柔軟に対応するため、機能追加を前提としている。

そう考えると、機能追加に柔軟に対応できる実装をそもそもしなければならない。

だが、機能追加対象のクラスは一つしか定義されておらず、その中にすべての処理が実装されていた。Utilなんてものは存在しない。

クラス設計？なにそれおいしいの？状態だった。

技術者の知識不足

以下のような実装が例だ。

1. あるステータス(ここではAとする)がクラスフィールド変数として定義された状態になっている

2. そのステータスに依存する形のステータスBが存在している。

3. Bはクラスフィールド変数として宣言されておらず、ゲッター関数に処理を記載し、取得可能。

ゲッターに複雑な処理を書くのは、本来単純な値返却関数である命名規則の意図から反したものだ。

しかも、「フィールド変数として定義されていない」ということは、フィールド変数から対象クラスが持っている状態について把握することがとても難しくなってしまう。

つまり、可読性が落ちる。

ただ、可読性に関しては、タイトなスケジュール設定がされていればしょうがないかもしれない…。

でも、せめてコメントに残すくらいの努力はしてほしい。

私達はクソコードに対して何ができるのか

ここで、クソコードに関する、あるストーリーを紹介しよう。

megamouthさんが書かれているブログの一記事である。

www.megamouth.info

クソコードによって疲弊するプログラマに対する敬意を感じる、素晴らしい記事である。

この記事によって幾人のプログラマが救われたことか…

ただ、クソコードに立ち向かい、理解しようともがくプログラマからは、夏の終わりのような哀愁を感じる。

少しでもこのようなことが減ってほしい。

だが現実問題、上記の記事のようなことは多いと思われる。

私が今回経験した案件もそうだが、それ以前にアサインしていた案件に関しても似たような経験がある。

前の案件で、その時上司に言われたのは「動けばいいから、とりあえず早く終わらせて」の一言だった。

上司自身もプログラマ経験があったはずなのに、なぜそのような思考になってしまったのか。

ここで、私はプログラマは大きく以下の5つに分類されるものと考えている。

• 生活型プログラマ

自分、あるいは家族など、生活のためにプログラマをやっている人をこう呼ぶ。

特徴としては、あくまで「プログラミング」を自身の生活の中で「仕事」というカテゴライズを行い、仕事以外のものと分類を行っているところか。

自身の中で「プライベート」と「仕事」のスイッチングをすることで、プログラミングをする。

• 上昇型プログラマ

明確な目標があり、それを達成するためにプログラミングをする。

プライベートでも仕事でも、目標のためにプログラミングの勉強をする。

• 無気力型プログラマ

自身で考えることを放棄し、コピペやプログラミング系ブログやQiitaからの引用のみで実装をする。

左から右へ受け流すのみというところか。

• 趣味型プログラマ

趣味でやっていたプラグラミングが、そのまま仕事になったタイプ。

プログラミングに関しては非常に優秀。

目標に対する意識より、プログラミング自体の楽しさを優先。

• 複合型プログラマ

上記のタイプの複合系。

例えば、趣味でプログラミングしており、かつ自分でサービスを作りたいエンジニアは上昇型と趣味型の複合である。

さて、ざっと分類はできた。

私の上司を例に取れば、「生活型と無気力型の複合」といえるだろう。

話を戻そう。

なぜクソコードを許す環境が出来てしまうのか？

まず、許されない環境には、上昇型エンジニアの存在が不可欠である。

クソコードが生成されてしまう背景には「とりあえず今を乗り切れればいい」という意識が存在するからだ。

なので、目標設定ができ、コードがそれに沿っているか判別できる上昇型エンジニアは必要だ。

つまり、先を見据えてしっかり意見を出すことが、クソコードの生成を減らすための最も効率的な対処法なんだ！

あと、クソコードに対する対処はぜひこの本を読んで欲しい。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)