レガシ―プロジェクトを引き受けた時、最初に準備するべき七つのこと

「営業一課で使っている■■ってPHPアプリがあるんだけど、メンテナの○○さんが退職するから、4月からは君に任せるよ」

そして、ソースを見てビックリ!!

テストは無い、リリース時の手順書も無い、仕様書ももちろん無い。

一方で「ログインできません」「なんか『Internal Server Error』って出てます」「表が崩れます」という不具合報告の数々。

ここで、プレッシャーに押しつぶされて「とりあえず、簡単な不具合から早く直そう!」と思うかもしれませんが、ちょっと待った!その前にやっておくべきことがあります。

※この記事でイメージしているのは「社員25人に使われている」という程度のレガシーアプリです。「3度の会社合併を経た40年もののCOBOL製基幹システム」には役立たないかもしれません。

1. 協力者を確保する

以下の人たちを確保してください。他のプロジェクトと兼業で構いません。

  • アプリの仕様を知っている人(前任者 or ユーザー)
  • コードレビュワー
  • テスト担当者
  • インフラ担当者

コーディングは自分でやるとしても、専門外の分野では無理せずその道の人に頼りましょう。 相談できる人がいると大いに助かります。

また、ユーザーや偉い人と交渉する時に、1人より5人の方が交渉しやすいでしょう。

2. 仕様をドキュメント化する

ユーザーに聞いたり、コードを読んだりして、アプリの仕様をドキュメントにしましょう。

ここでは、完璧な仕様書を目指す必要はありません。 正確性・網羅性よりも、ともかくドキュメントを作ることが大事です。

というのも、ドキュメントが無い状態だと、みんな想像で物を言うので、議論が迷走しがちになるからです。

ドキュメントという形に結晶化すれば「ここの記述は実態と違う」とか「ここを変えましょう」と、生産的な議論ができるようになります。

3. 手動テストをドキュメント化する

最終的には各種自動テストでカバーするべきですが、最初は手動でテストしなければいけません。しかし、レガシープロジェクトの場合は、手動テストもロクに無いことがあります。

とにもかくも、既存のテストケースを、ドキュメントに起こしてください。 TestRailなどの管理ツールが望ましいですが、Excelでも構いません。

テストもドキュメント化しなければ生産的な議論はできません。

  • どの部分のテストが足りていないか?
  • テストケースが重複していないか?
  • ユニットテストで確認できる内容ではないか?

等など。

また、テストケースが一覧になっていれば、テストにかかる工数を正確に見積もれるようになりますし、 必要に応じて複数人で分担して実施できるようになります。

4. Jenkinsを導入する(CIツールを導入する)

レガシープロジェクトでは常に時間が足りなくなります。

Jenkinsからボタン1個で、ビルド、ユニットテスト、リリース、コーディング規約チェックなどの定形作業をできるようにしてください。Jenkinsはシェルスクリプトをコピペするだけでジョブが作れます(そもそも、定形作業がスクリプト化されていないこともありますが・・・)。

なお、別のCIツールでもよいですが、Jenkinsは汎用的でお手軽なので、とりあえずJenkinsを使うのがベターでしょう。

5. コーディング規約をチェックするツールを導入する

さて、ようやくコーディングの準備が整ってきました。しかし、タブとスペースが混在したようなコードを編集しようとしても、ストレスが溜まりますし、つまらないミスも犯してしまいます。

コーディング規約を定め、全てのコードが規約に従うようにしてください。

ここで、どのコーディング規約を採用するかはあまり重要ではありません。 規約をRubocopやCheckstyleのようなツールで自動的にチェックできることが重要です(コードレビューの際にスタイルについて指摘する/されることほど不毛なことはありません)。

むしろ、ツールに合わせて規約を選択するくらいでよいと思います。

ツールは以下の基準で選んでください

  • 簡単に使えること
  • 簡単な内容(スペースなど)は自動修正できること
  • チェック対象にしないファイルを指定できること(全ファイルを一度に書き直すのは時間がかかるので、あまり変更しないファイルを後回しにできるとよい)

また、ツールにはスタイルを細かく設定できるものもありますが、時間の無駄なので、デフォルト設定のまま使いましょう。

6. 便利な新言語(less・scss・haml・slim・TypeScript・Kotlin など)を導入する

WEBアプリであれば、大量のHTML・CSSJavaScript のソースが含まれているはずですが、 これらは決して書きやすい言語ではありません。

書きにくい言語と格闘してもしょうがないので、less・scss・haml・slim・TypeScriptなどを導入してストレスを減らしましょう。これらの言語はHTML・CSSJavaScriptの上位互換なので、拡張子を変える以外の作業は要りません。

また、alt-JavaのKotlinは、文法的にはJavaの上位互換ではありませんが、Javaから自動変換することができます。

なお、拡張子の変更・自動変換であっても、変更の後にはテストが必要になりますが、それは他の変更のテストのついでにやればよろしい。

7. (まともな)テスト環境を(複数)用意する

まれによくあることですが、サーバーが本番環境の1台しかなく開発者のマシンで適当にテストした後いきなり本番適用する(そしてバグる)。

あるいは、テスト環境と称する環境はあるが本番環境と設定が違ってしまっているので、テストがテストになっていない。

本番環境とできるだけ同じ設定のテスト環境を作りましょう。 その際にAnsibleなどを使うと後々便利ですが、ともかく「テスト環境が無い」では話にならないので方法にはこだわらずに急いで用意しましょう。

また、テスト環境は複数作っておくべきです。後々、テスターの人数が増えたり、自動テストを導入したりしたときには、テストを並列で行うことになるからです。

終わりに

ユーザーや上司からは、とっとと不具合を直せと言われるかもしれません。

しかし、戦いには準備が必要です。 初見のコードにいきなり手を付けても、直しきれなかったり、エンバグしてしまう可能性大です。

また、メンテは長丁場です。あなたはきっと、何年もメンテを続けなければなりません。 ですから、最初の時点で、作業する時のストレスを減らす手立てを講じてください。

広告を非表示にする