この4月、新生活を迎えた人も多いことでしょう。
OpenWork開発部門でも新入社員エンジニア6名を迎え、フレッシュな風が吹いています。
彼らが早く一人前のエンジニアとして活躍できるよう、全社員でサポートしていきますので、どうぞよろしくお願い致します。
新入社員自らも近々ブログ記事を書いてくれるそうなので、お楽しみに。
さて今回は、不要になったソースコードを20,000行も削除したときのことについて書きたいと思います。
不要なコードとは
そもそも不要なソースコードはどのようにして生まれるのでしょうか？
今回の場合は弊社のあるサービスが終了したためでした。
それ以外には、終了したABテスト、使用されていないバッチ処理・データ定義などがあり得ます。
不要なコードを削除する理由
OpenWorkのサービスは常に機能改善と機能追加を繰り返しており、プログラムは変化し続けるものです。
その際に不要なコードが残っていると、余分なテストの工数がかかったり、不具合の元となり、開発の妨げになってしまいます。
特に今回期限を決めて削除を決行したのは、Symfony（PHP上で動作するアプリケーションフレームワーク）のバージョンアップを控えていたからでした。
SymfonyやPHPのバージョンアップをする際には、エンジニア総出ですべての機能のテストと修正対応をしています。
そのときまでに不要なコードがない状態にすれば対応工数を減らすことができるのです。
(バージョンアップの詳細については後日投稿予定です)
削除するだけなら簡単？
いいえ、そんなに簡単ではありません。
Deleteキーを押すだけなら簡単ですが、消すための手続きや、消した後の動作を保障することが大変なのです。
削除するときに気を付けること
以下のことに気を付ける必要があります。
- 本当に削除して問題ないか？の確認
- 消し忘れがない
- 消してはいけないコードまで消さない
そして当然ですが「不具合」を起こさないことです。
削除の進め方
以下の手順で作業を進めました。
1.作業の洗い出しと細分化
grep（文字列検索コマンド）で削除対象の洗い出しをします。
すべてを一度に作業するのはとても大変かつ漏れがでやすいので、Backlog（プロジェクト管理ツール）の課題チケットを細かい作業単位で作成していきます。（作業は20個ほどになりました！）
2.作業順序を決める
1で作成した作業をどのような順で進めるか決めます。重要箇所や共通箇所は後になるようにしました。
3.確認・手続き
関連する部署や担当者に、本当に削除して良いかの確認を取ります。
主に確認が必要だったのは、社内管理画面の機能とデータベースのテーブルも削除して良いか？ということでしたが、
前者は削除することにし、後者の一部は一定期間残すことにしました。
ここで気を付けることは、使っていた人が「もう使わない」と言ったから削除して良いということではなく、エンジニア観点でも検討することです。
4.コードの削除作業、テストケース作成
優秀な学生アルバイトの岡田君に、2で決めた作業順で以下を進めてもらいました。細分化したチケットごとに作業してもらうのがコツです。
岡田君自身でも確認しながら、スピーディーかつ正確に進めてくれました。
- コードを削除する作業
- TestRail（テスト管理ツール）にテストケースを作成し、テストを実施する
5.作業単位でレビュー
岡田君の1つの作業が終わる度に、今度は私がコードとTestRailのレビューをします。
完了した作業は親ブランチにマージし、もし作業リストに漏れがあることに気付いた場合は作業チケットを追加します。
6.リリースブランチの確認
すべての作業が終わった時点で以下の確認をします。
- マージ漏れがないか（マージコミット）
- 削除漏れがないか（grep）
- TestRailのテストを再実施
- 自動テストの実施
7.リリース
私と岡田君が担当していたサービスの削除行数は約14,000行で、同時並行で村岡さんが進めていた別のサービスの削除行数が約6,000行でした。
スケジュールの関係でこれらを同時にリリースすることになったため、合計で約20,000行になりました！
リリース作業時は3人で手分けしてTestRailと自動テストの確認を行い、不具合なく無事にリリースすることができました！
削除しやすいソースコードとは
削除しやすいソースコードとは、すなわち変更しやすいコードだと思います。以下のようなことに気を付けると良いでしょう。
高凝集、疎結合である
互いに関連する機能や情報があちこちに分散していると、対象のコードを探すのが大変です。これらの機能や情報が閉じたクラス内に収まっていたり、意味のあるディレクトリでまとまっていることが望ましいです。
また、クラスやメソッド間で依存度が上がってしまうと、変更による不具合が起きやすくなってしまいます。変更しやすいように適切に役割を分割し、互いに依存させないことが望ましいです。
表記揺れがないこと
クラス名、ファイル名、ディレクトリ名、コメント等に表記揺れがあると検索漏れが起きやすいです。また、全く別の機能や情報なのに同じ名前を使うのも避けたいですね。
今回削除した機能は歴史のあるソースコードで、高凝集、疎結合とは言えず作業が膨大になってしまいましたが、名称では探しやすかったのが幸いでした。
最後に
さて、Webエンジニアの仕事は新しい機能を開発することだけではないことがおわかりいただけたでしょうか。
OpenWorkのWebアプリチームでは、定期的な勉強会で変更しやすい設計やコーディングについても学んでいます。
また、技術的負債を解消すべくリファクタリングを専門に行っているプロジェクトもありますので、興味のある方はぜひ一緒に働きませんか？
https://vorkers.jp/recruit/job
