スーパーマンではなかったオッサンは荒れ果てた環境でどうリファクタリングできるのか

さあ終盤 12月23日 だ。「レガシーのメンテばかりは嫌だ」 でも予告したとおりリファクタリング本を主題に読書記録を書く。コードの不吉な臭いは有名だな。なのだけど、

• 開発者が自分たちのプログラムをリファクタリングしようと思わない理由
• リファクタリング、再利用、現実

という最後の章を皆さんご存知だろうか。ベストプラクティスだ理想論だのような話に「とは言ってもね～～～」と思ってしまう私にはぴったりだ。あまり評されていない気がするが端的には、思い描いた理想とあまりにも荒れ果てた現実のギャップを埋めるのがこの章だと思っている。

余談

もちろん話の前提は新卒１年目が荒れ果てた開発環境に１年間でCIを導入し単体テストを布教した話 だ。誰もがすごいと思うでしょう？そしてそれに対して

こういうのを見るたびに、英雄とかメシアが現れるのを待っている開発体制ってどうなのさと思う

なんてコメントを読んじゃう。そんな誰かを待つしか出来ていなかった「周りの人間」、ともすれば先輩なんて呼ばれる実質オッサンな立場¹ としては突きつけられる。当たり前だがこれを猛省しないといけない。前置きが長くなった。我々はただメシアを待っていたのか考えたい。

既存ツールをもう一度メンテナンスしたい

スーパーマンではなかった時既にオッサンな私の課題

色々な理由でまだまだ使いこなせていないツールが、数あるので挙げてみる。

• 開発環境におけるコネクション開放漏れの検知
• バッチジョブ異常終了の検知
• メモリ使用量監視
• サーバ容量監視
• ログの監視
• リリース用ドキュメントのチェック

等...

これだけでも話し足りなそうだ。問題は、これらすら既に社内では古くなって、活用しきれていないこと。

始めることも大事だけど、続けること

始めることは楽しいからできる。筋トレでも英会話でもそうだ。
しかしどうすれば続けられるか、せっかくその元ネタがあるのだから来年は、ツールをメンテナンスしていきたい。

リファクタリング第13章 に学ぶ、荒れ果てた環境に挑み続けることのコツ

さて「開発者が自分たちのプログラムをリファクタリングしようと思わない理由」を覗く。
以下取り上げているのはマーティン・ファウラー、新装版リファクタリング² のものなのでその点のみ注意を。
https://gitpress.io/@riekure/refactoring_memo

現実の壁（P.380）

誰かが「理解できない」とコメントしたり、単に伝わらなかった場合は、「われわれ」のせいなのだ
伝えるように一所懸命努力する責任がある

リファクタリングの意義も伝わるまで周りを説得しないといけない。

開発者が自分たちのプログラムをリファクタリングしようと思わない理由（P.381）

プログラムを書き直すことはできます。しかし一体誰がこの費用を負担するのでしょう。どうやって、元のシステムがしていたすべてのことを、新たなシステムでも行うことを保証できるでしょうか。

例えば以下のような理由がある、と考えられている。

1. リファクタリングのやり方が分からない
2. 利益が長期的なものなら、何も今頑張ることもない。長期というなら、利益を得る前に、自分は今のプロジェクトを去っているかもしれない
3. コードはリファクタリングするのは余計な作業だ。給料は、「新たな」機能を書くことに対して支払われている
4. リファクタリングは既存のプログラムを壊してしまう

ソフトウェアを再構築する上で、「設計の治験をより明らかに示し、フレームワークを開発し、再利用可能なコンポーネントを抽出し、ソフトウェアアーキテクチャを明確にし、追加を行いやすくするよう準備する」。時間がかかるのは事実だ。そしてもちろん、注意しないとプログラムを壊してしまう。

リファクタリングする方法と場所を理解する（P.382）

プログラマが自分のコードをリファクタリングすべきであると納得する前提として、リファクタリングするところとその方法を理解する必要がある
自動化ツールは、プログラム構造を解析し、構造を改善するためのリファクタリングを指摘
自動化ツールは、構造的な解析に基づいた指摘であっても、本当に実行したいものは、プログラマが判断する

プログラムを解析するツールを作り、lintをかける。とりあえず当たってみて、どの指摘を採用するかを決める。把握するだけでもまず第一歩ということがわかる。

リファクタリングのオーバーヘッドを減らす（P.389）

いくつかのツールや技法を使えば、リファクタリングは短時間で済む
プログラム開発における他フェーズでの労力の現象と、空き時間でまかなって余りあるもの

最初は余計な作業項目とうつるかもしれない。しかし習慣の一部にする必要がある。

安全にリファクタリングを行う（P.390）

プログラマは誰でも誤りうる
コンパイラでは補足できないエラーがある
継承に関わるスコープエラーは、コンパイラでは補足できない
プログラムにありうるすべての実行経路をテストすることは。計算決定不能な問題
テストスイートがすべての状況を補足することは保証できない
コードレビュアーもプログラマ同様、過ちを犯す

だから、誰もが失敗する前提で、謙虚に物事をすすめる。

解決策：自分はスーパーマンではないから

誰もが皆「優秀」で「すごいこと」ができるわけではない。
でも、続けること、学ぶことにこだわって地道に、でも楽しく開発していきたいと思う。
「新卒」がこの会社で働きたいと思ってもらえるようになれるよう、オッサンな我々こそが謙虚にかえりみて来年を迎えたいとおもったですぞ。

---

1. 筆者は女性だが「いわゆるオッサン」的老害になり得る立場というジェンダーを超えた意味で書いています。 ↩

2. 最新は リファクタリング第二版 にかかれている通り結構書き直されている。 ↩