不要なコードを生まない体制作り
目次
はじめに
株式会社じげん沖縄支店の座喜味です。
ライフサポートDiv.という部署でエンジニアマネージャーをやっています。ライフサポートDiv.は主にリフォーム会社の情報・見積比較サービスを展開している「リショップナビ」、プロパンガス会社の情報・見積比較サービスを展開している「エネピ」をはじめとする、住環境に特化したサービスを運営しています。
体制としては日本のエンジニア9名、ベトナムのエンジニア2名、デザイナー2名で開発を行っています。
不要なコードによりひき起こされた弊害
私たちのチームでは、複数のサービスの開発・運用保守を実施しています。直近M&Aで取得したサービスも含めて、5年以上運営しているものも複数あります。
元々は1サービスに対し1~2人の開発者で開発を進めていたのですが、規模も大きくなり新規の開発者や、ベトナムのチームが参画したりと、開発者が増えていく中で技術的負債の問題が発生してきました。
今回は不要なコードにより引き起こされた問題を共有していきたいと思います
新規開発に余計な開発工数がかかる
私たちは日々既存のコードを改修し、サービスの改善を行っています。
既存の仕様、コードを理解し改修を行う必要がありますが、
不要なコードが多くあることで読み解く時間や、コミュニケーションが増加することがあります。特にベトナムのチームに実装を依頼する際には、顕著になります。日本語でのコミュニケーションだと技術者チーム内で解決できることも多いですが、ベトナムチームの場合、日本語からベトナム語、ベトナム語から日本語への翻訳コストがかかるため、なるべく実装着手した後は極力ベトナムチーム内で完結させられるように意識しています。
パフォーマンス障害の発生
不要なコードを残したことでパフォーマンス障害が発生しました。
あるテーブルのデータを諸事情により早急に削除する必要が出てきたのですが、
その対応の中でデータの削除だけを実施し、テーブル、及びコードを残したままという対応を行いました。
その結果、検索のindexが効かなくなりディスクへの書き込みが増え、データベースのディスクのIOPSバーストが高頻度で発生。I/Oクレジットが枯渇し、深刻なパフォーマンス劣化を起こしてしまいました。
不要なコードが生まれる理由
私たちのサービスでは下記の理由が主でした。
- 担当した開発者がチームから離れてしまい、コードの経緯がわからなくなってしまった。
- 1サービスを1人で開発・保守されていた時期があり、他の人の目が入らないコードが発生していた。
- 開発工数の不足やリリース納期の関係で、暫定的な対応としてリリースした対応がそのまま残り続けてしまった。
不要なコードを生まない体制づくり
問題に対して、現在下記の対応を実施しています。
- 開発Issueの番号に対して開発ブランチ名を紐づけるような開発ルールを適用する。
このルールにより、コミットログから開発Issueを確認することができ、そのコードが書かれた意図は追いやすくなっています。
- PullRequestをレビューしApprovedしなければリリースできないようにする。
上記のルール設定のため、現在は1サービス1人で開発・保守する状態はなくなりました。
今後実施していきたいと思っている対応です。
- 既存機能改修時に、経緯不明のコードを発見した際にはチーム全体へ確認し、すぐにわかりそうになければ調査タスクを起票する。
- 暫定的な対応が残ってしまう問題については、リファクタリングに必要な追加工数が必要であれば可能な限り工数を調整する
- どうしても急ぎでリリースしなければならない場合、TODOコメントを残しリファクタリングのタスクをIssue化するといったルールを運用していく。
- コードの静的解析を導入。
今後について
今後ますますサービスを発展させ、価値をお客様に素早く提供するためにはコードを綺麗に保ち、開発速度をあげていく必要があります。
不要なコードは技術的負債の一例ですが、今後よりよいサービスを提供していくため機能開発とのバランスも見つつ、技術的負債の返済にも取り組んでいけたらと考えています。