プログラマーが保守し辛いクソコードに出会ったらどうすべきか?

プログラマーをやってますと、レガシーコード(クソコード)という言葉を耳にします。

一般的には理解しづらい・変更しにくいコードの意味で使われますが・・・

とある本ではテストのないコードとも紹介されています。

TaNA
クソコードには出会いたくないですが、プログラマーやってると必ず出会います。

そもそも自分がクソコードを書いてることもあります。

そんなクソコードに出会った時、プログラマーはどうすれば良いのでしょうか?

クソコードとは何か?

私の中でのクソコードとは、理解しづらい = 保守しづらいコードです。

なぜそんなクソコードで書かれたシステムが生まれるのか?

TaNA
時間が無かったとか、出来る人がいなかったとか、理由もそれぞれですね。

ちなみに以前参画した現場では、クソコードを生み出す特徴に以下がありました。

・コピペの嵐

・インデントされてない

・フレームワーク未活用

・変数名とか適当

・事なかれ主義

挙げればキリがありませんが、最低限自分はこうならないと意識したいです。

クソコードによる弊害

とある現場では、コピペ文化により、PHPでNotice、JavaScriptでundefinedが多発。

またIDEを活用せず、vim開発でしたので、適切にインデントされておらず。

変数・メソッド名も適当、不要コメントの嵐。

予期せぬ不具合に出会った時、バグ解析に多大な工数を割かざるを得ませんでした。

POINT他人の保守しづらいコードは、解析するにも時間・労力・ストレスが膨大。

コーダーとデザイナーの役割が分割され、折角テンプレートエンジンがあるのに活用されず。

コンソール作業の関係上、結局出来るコーダーに役割(デザイン業務)が集中することも。

POINT一部の出来る人に負荷がかかる傾向アリ。

本番不具合の緊急対応で、とにかく暫定対応などのTODOコメントが乱立。

いつまで経っても改善されず、忘れた頃にソレが起因となって障害発生。

POINT誰もシステムの全容を知らず、時間の経過と共にブラックボックス化。

そんな現状に嫌気が差し、徐々に人がいなくなります。

事実から目を背けない姿勢

逃げても問題は解決しませんから、とにかく現実を直視すること。

TaNA
ただ一人で出来る事も限られるので、背負い過ぎても仕方がない。

巨大なクソコードに出会った時、まずコレを心掛けています。

・今以上に生み出させない

・毎日少しずつでも改善する

・同じ思いを持つ仲間を集める

まあ請負側では権限も限られますが。

すぐに出来る具体的改善策

今以上にクソコードを生み出さないため、使えるツール・ノウハウを最大限活用。

・IDEのコードフォーマッター

・リーダブルコードを読む

・コーディング規約(PSR準拠)

・githubでのプルリク文化

・テストコードを書く文化

少なくともインデントや変数名は改善されます。

ただプルリク文化も確認者が忙しかったり、時間が経つと形骸化する可能性もアリ。

テストコードを書く文化

これは自分も大反省すべき話題。

冒頭とおり、レガシーコードとはテストのないコードと言われています。

TaNA
少なくともユニットテストくらいは書きたいものです(汗)

そしてブラックボックス化したシステムでのリファクタリングは更に大変。

一応正常動作している現行に悪影響を及ぼすと、ミイラ取りがミイラに(汗)

リファクタリング後のデグレ検証も、ブラックボックス化していると難しい。

TaNA
後輩がデグレ試験のためにSeleniumに挑戦しましたが、日常業務の忙しさに襲われ断念してました。

最近ではテスト専門の会社もあり、そんな会社に委託する現場もしばしば。

作り変える選択肢

昔、Cherry Blossomsインターネットで働いていた頃。

古いPHP(ver3,4)で書かれたシステムを、PHP7に書き換えてました。

少しづつAPI化し、現行サービスに影響を与えず移行。

TaNA
時間と労力はかかりますが、一つの方法だと感じましたね。

ただ作り変えるにしろ、仕様の全容を理解する必要があります。

コレがまた大変で、クソコードでブラックボックス化したシステムは、設計書が更新されていなかったり、そもそも設計書すら存在しない事もしばしば。

逆に中途半端な設計書があることで迷ったり、メンテに時間を取られたり・・・

こーなると一人ではどーにもならんのですが。