社内に詳しい人がいない領域のコードを触る時 ( N = 2 )
はじめて触るコードでも、特に大きなバグを出さずリリースまで持っていく人もいれば、毎回必ずバグやデグレを引き起こす人もいる。「この差は何だ？」と思っていたところ、こにふぁーさんの記事を読んで「コードを理解するためのアプローチの差かも」と思い、私のアプローチを整理してみた。
前提
コードを読み始める前に「過去の情報ややりとりを収集して整理する」といった作業を行うが、こにふぁーさんの記事の「自分用メモを作る」と「過去のドキュメント・やりとりを探す」と実施内容がほぼ同じため、この記事では割愛する。
GitHub のコードを読む
コードを読むときは 試行リファクタリング をしながら理解を深めていくことが多い。試行リファクタリングとは、開発者がコードの理解を深めるために行うリファクタリングのことで、『レガシーコード改善ガイド』 で紹介されている既存コードを把握するプラクティスの 1 つである。事前に収集・整理した情報とコードから得られた情報が一致すれば OK で、一致しない場合は仕様に詳しい人に質問するなどして差分を埋めていく。
他の人の作業に首を突っ込む
これは将来に備えて知らない領域を減らすための取り組みである。
たとえば、Slack 上では自分が担当していないチケットに関するやりとりも行われるが、スルーせず必ず目を通すようにしている。スルーすることは 理解できない領域を増やす ( 属人化を育む ) 行為 であり、属人化を嫌うのであれば NG 行動である。ただし解決までガッツリ関わるわけではなくて、決めたリミット内 ( 30-60 分ほど ) で将来の保守・運用に備えてやり取りやコードなどを把握する程度にとどめる。担当者にとって有益と思われる情報が得られれば共有はする。
ちょっとした改善活動をする
これも将来に備えた取り組みである。
他の人の作業待ちとか定時後の 30-60 分とかで既存コードや環境のイケていないところを改善することも、コードの理解につながる。実際に私が取り組んだ事例を 2 つ紹介する。
ローカル環境構築用スクリプトの改善
私が現在開発しているサービスにはローカル環境構築用のスクリプトがあって、それを順に実行していくとローカルでサービスを起動できる。ただしデータは作成されないので、各自で必要に応じてデータを作る必要がある。データは画面操作して作るだけ ... なのだが、人によってはデータ作成の難易度が高いらしく、サポートを必要とする場合がある。
そこで、ローカル環境構築用のスクリプトに初期データを投入する実装を追加して、環境構築とあわせてサービス実行に必要なデータも構築できるようにした[1]。この改善はデータ準備にかかる工数を削減するだけでなく、データ構造やデータの関連性を把握する助けにもなったと思っている。
本番環境のログ調査
本番環境のログを調査していると、ユーザーから問い合わせが来ていないけどエラーになっている ( または将来なり得る ) 問題を発見・対処できることもある。リリース後の稼働確認とあわせて実施することが多い。
バグの発見や対処までいかなくても「この辺はもう少しログが欲しいな」というレベルの改善点は見つかると思う。
さいごに
私自身はコード ( というか担当しているサービス ) を理解するためにそれなりに努力をしていると思っている。あなたの周りにいる優秀な人もきっと努力をしている。コードを見て「理解できない」となって、その理由を「ドキュメントがないから」とか「コードがひどいから」と簡単に結論付けず、理解できるようになるための努力を積み重ねると良いのかもしれない。
-
MySQL を Docker 構築した経験がある人であれば「
/docker-entrypoint-initdb.dに初期化スクリプトを配置した」と言えばイメージが湧くだろうか ↩︎
Discussion