チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

勤怠計算ロジックのリファクタリング、はじめました

こんにちは。QAエンジニアの石原です。
この記事では、私が現在所属しているTSFエンジニアリングチームのサブチームである勤怠計算リファクタリングチームの活動ついてご紹介したいと思います。

勤怠計算リファクタリングチームのミッション

出社時刻や退社時刻などをもとに労働時間の算出をする機能が勤怠計算です。
多くのお客様にご利用いただいているTeamSpiritの勤怠管理機能の中で特に重要な機能の1つです。

先日投稿した下記の記事でも触れましたが、ドメイン知識習得などが容易でないことから勤怠計算機能は限られたメンバしか開発やテストができないという課題を抱えており、特に開発に関する部分では、長きにわたり勤怠計算機能の開発に携わっているメンバしかソースコードの内容を把握できていないという課題があります。

teamspirit.hatenablog.com

そこで、他のメンバとも分担して勤怠計算機能の開発をできるようにするため、勤怠計算ロジックのリファクタリング(プログラミングの挙動を変えずに内部のコードを読みやすくする)を行うことになりました。
勤怠計算リファクタリングチームでは、この勤怠計算ロジックのリファクタリングを行い、最終的に製品パッケージに組み込んでリリースすることを目標としています。

どうリファクアリングを進めるか?

現在のソースコードは、

  • 構造的な課題により、テストのカバレッジを増やそうとするとSalesforceのガバナ制限に抵触してしまうためテスト数が増やせない
  • 勤怠管理機能の肝とも言えるロジックであるため、いきなり現行ソースコードを修正することのリスクが高い

ということから、現行のソースコードの外側で新しく作り直すという方針をとりました。

大まかには、

  1. 今までより詳細な勤怠計算ロジックの仕様書と、より網羅的な勤怠計算テストの仕様書を作成する
  2. 1.にもとづき、新しい勤怠計算ロジックとそのテストコードを作成する
  3. バックエンド(コントローラー)から、新しい勤怠計算ロジックと旧(=現行)ロジックの両方に接続するよう改修し、並行稼動させる
  4. 新旧それぞれの計算結果の差分を検出し、新しい勤怠計算ロジックの品質を向上させる
  5. 差分がなくなったタイミングで新しい計算ロジックに切り替える

というステップで進めていきます。

新旧ロジック差分検出のイメージ図

チーム内の役割分担

現在、勤怠計算リファクタリングチームはリーダ1名、開発者3名、QA2名の計6名の構成となっています。
開発者は主に勤怠計算ロジックの仕様書整備やリファクタリング、テストを自動化するための基盤構築や実行環境の整備などを行い、QAは主にテスト仕様書作成およびテストコードの実装を行いました。
勤怠計算のテストケースは、TeamSpiritの設定や入力パターンの多さからかなりの件数となったため(勤怠計算は勤怠管理機能の中でも特に重要な機能であり、法要件への適合やTeamSpiritをご利用のお客様の給与計算にも影響しますので、テストをしっかり行う必要があります)、テストコード実装のピーク時には開発者と外部メンバにも参画してもらいました。

現在の状況は?

新しい勤怠計算ロジックの実装とテストケースの実装が完了し、アルファテストとして開発環境に新しい勤怠計算ロジックをデプロイして、過去に実装済みのテストコードと今回実装したテストコードをそれぞれ実行しています。
アルファテスト開始直後は現行ロジックとの差分が何件も検出されましたが、改修とテスト実行を重ね、検出される差分もかなり少なくなってきました。
また、テストを自動で実行できるようにクラウド環境(AWS)や自動化ツール(Jenkins)を利用した環境整備も進めており、現在では大部分のテストを自動で動かせるようになってきました。

最後に

まだまだテストは続きますが、新しい勤怠計算ロジックをリリースできるようチーム一丸となって頑張っていきます!