こんにちは、エンジニアの竹田です。

この記事は、Enigmo Advent Calendar 2022の15日目の記事です。

さっそくですが、エンジニアのみなさまは一流のエンジニアとはどんなエンジニア像をお持ちでしょうか。
自分は「障害を未然に防ぎ、継続的に安定運用可能なシステムを構築できるエンジニア」を一流のエンジニアだと考えています。

ひとえに障害と言っても、仕様と異なる動作をしない、リソース不足等によるシステム停止が発生しない、などいろいろと定義はあるかなと思います。
今回のエントリでは前者の「仕様と異なる動作をしない」という点について、業務を通じて見識を深められる場面がありましたのでご紹介したいと思います。

検索システムのリプレイス

今期は、とある検索システムのリプレイスに注力していました。
エニグモでは検索システムにApache Solrを利用しており、今回リプレイスするシステムについても構成としては過去にこちらのブログで紹介したものと近い構成となります。
自分は検索システムへのデータ投入、および検索リクエストを行って結果を整形する箇所(主にRails)の改修を担当しています。

リプレイスに当たり、RailsからSolrへの直接リクエストではなく、中間媒体として検索APIを経由する形式に変更しました。
このため、まずは既存コードやログを調査してリクエスト方法や動作仕様をまとめ、いざコード改修に移りました。

コード改修

調査した仕様を元に一旦コード改修を完了し、ある程度動作するものができました。

その後、既存のテストコードを元に新コードのテストコードに移植を進める中で、細かな動きを実装できていないことに気付きました。
(画像はイメージです)

型が数値なのか文字列なのか
nil許容するのか
調査しきれていなかったリクエスト方法や利用箇所がある
中には、えっ、そんな動きするの、みたいなものまで...

コードやログを目視しただけでは分からなかったことが次々とでてきました。

テストコードの重要性の再認識

テストコードを動作させることで、より詳細な動作を知ることができました。
後から考えると、もっとしっかりとコードチェックをしていれば把握できていた点もあると思いますが、やはり作業しているのが人ですので、どうしても見落としは避けられないと思います。

テストコードがなければデグレを引き起こしていた可能性があり、「仕様と異なる動作をしない」点を満足できない状態にしてしまうところでした。

普段コードを書く際、テストコードも意識して書いてはいたものの、作成に当たってはコードカバレッジ、モックの使用、境界値や複雑なパターンの網羅をどこまで厳密にするか等、、考慮することが多いです。
それなりに時間を要しますし、テストコード自体の視認性に納得がいかなかったりと、正直あまりテストコードを書くことは好きではありませんでした。

ですが、今回、多くの点をテストコードに助けられました。
テストコードの意義などを検索すると様々な方の記事がヒットするためその辺りの言及はしませんが、理屈としては理解できるもののなかなか溜飲を下げられないものだと思っています。
その点においても、実際にテストコードに助けられたという体験は非常に貴重なものでした。