Subscribed unsubscribe Subscribe Subscribe

SE Can't Code

A Tokyo based Software Engineer. Not System Engineer :(

検証コードのテストを書く.

僕が仕事で書くコードは主に検証コードとしてiPython-Notebookで書くことが多いためテストはあまり書かない。Notebookを使ったことがある人ならわかると思うが、基本的にセルにDataFrameなりが入った変数を投入してデータを目で確認するということが多い。データ解析の検証コードとして書くので性能や細かいチェックは二の次になる、というよりあまり意識しない。なぜならこのコードがそのままプロダクトに組み込まれることはないからだ。サンプルコードとして渡されて、開発側がそのコードを元に綺麗に整えていくイメージになる。

この検証コードも規模が小さければある程テストを書かなくてもそのまま突っ走ることが出来るが、ある程度規模が大きくなったり、複雑性を伴ってくるとちょっとしたテストを書く必要が出てくる。僕の場合、最近になって少し前に書いた1500行くらいのコードを再利用する必要が出てきたので、頭の整理の意味を込めて当時あまり書いていなかったテストを書き直したりした。

1500行くらいなら大した規模ではないが、自然言語処理機械学習モデリング計算などといろいろしていたので、中身の復習が多少必要だった。そうした、過去に書いたコードを理解しようとした時にファンクション単位でテストを書くのはとても有効だ。データ解析や機械学習の検証などの検証コードを理解しようとする時には特に。

まぁこのテストを書くという作業自体、なかなか時間がかかってしまうことがあるので、理解するためだけにどこまで時間かけるんだよ、という話はあるが、リファクタリングという意味でも割と価値があるためオススメである。僕はテストを書くことで、共通化できる処理を見つけてまとめることができたし、カプセル化も細かいレベルまで落とせたのでコードをかなり綺麗にすることができた。当時は時間がなくて出来なかった、外部からの再利用も意識して書き直すことができたので今後の役にも立つんじゃないかと思う。

僕の中ではデータ解析で書くコードはあまりテストが書かれない印象なんだけど、どうなんだろうか。もしテストが書かれていない検証コードがあれば、時間がある時にでも頭の整理や再利用の目的で一度テストを書いてみるといい。きっと頭の中が整理されると思う。

まぁデータ解析を営みにしている人は大抵頭が良いのでそんなものなくても整理されているかもしれないが、僕みたいな複雑なものを見ると頭がこんがらがってしまう人にはテスト書くという行為はかなり有効だと思う。

Remove all ads