データサイエンスレガシーコード

Repro Tech Meetup #7 にて、「データサイエンスレガシーコードに立ち向かう」というタイトルで講演しました。

データサイエンティスト全てというわけではありませんが、データサイエンスのコードは試行錯誤の連続であり、様々な手法を連続して試すことを考えると、最初からきちんとテストを書いた保守性の高いコードを書く、というのはそう簡単ではありません。

しかし、そうした試行錯誤を経て出来上がったデータサイエンスのコードを、「動いているから」という理由でそのまま実戦投入していくケースを目にしたことある人はいるのではないでしょうか。

このような状況に直面したとき、私が思い出したのは、10年前の、あるプロジェクトのことでした。

当時の私はある社内システムの開発に携わったのですが、既存コードには一切テストがなく、かなりの分量の改修が必要で、そして期日が迫っている、という状況でした。

このとき私のバイブルとして助けになったのが、「レガシーコード改善ガイド」でした。

レガシーコード改善ガイド (Object Oriented SELECTION)

まさか10年経ってからこの本を再び開くことになるとは思いませんでした。しかし、そこに書かれている内容は、まさに今の私にとって役に立つ内容ばかりでした。

この本の冒頭には、以下の一文が記されています。

レガシーコードとは、単にテストのないコードです

この一文を読んで、私は「データサイエンスレガシーコード」という言葉を思いつきました。

データサイエンティストの考えたモデルがもし本当に有用であれば、コードはきちんと整備され、あるいは書き直されることになるでしょう。しかし、そうなる前の段階、つまり、データサイエンティストの頭の中から一歩踏み出した状態は、保守性の低い、レガシーコード同様となっていることが多いでしょう。このようなときに、この古い書籍は大変役に立ちます。

とはいえ、この本で取り上げている例やツールは現代から見ればかなり古く、また、コードもJavaやC/C++で書かれているため、私が使うPythonの世界にはそのままでは適用できません。

Pythonでテストを書くための本として、テスト駆動Pythonがあります。この本は2018年に出たばかりの新しい本であり、内容もわかりやすく、Pythonでテストを書くのに慣れていない人にとってはかなり有益な本でしょう。

テスト駆動Python

ソフトウェアエンジニアと違い、短期間のうちに様々な小さいコードを実装しなければいけないソリューリョンアーキテクト(あるいは、プリ・ポスト含む全てのフィールドエンジニア)がよく口にするのは、「テストなんて書いている時間がない」というものですが、テストを書けば、バグ探しや確認作業のための工数が減り、改修作業のときの手戻りを減らし、同僚や他プロジェクトで自分が書いたコードが再利用されるときに発生する質問や支援依頼もぐっと減り、その結果、自分の時間を大きく節約することができます。なので、私は小さなコードであってもなるべくテストは書くべきと考えています。

テストを忌避する理由として考えられるのは、推測ですが、「テストが品質向上のためのものであり、テストを書くには分岐網羅などを全て行った、カバレッジの高いものにしなければいけない」という考えがあるからでは、と思っています。私は、特にソリューションアーキテクトのような立場でコードを書く場合のテストは、単に確認作業の自動化くらいの意味合いで考えれば問題ないと考えています。普段自分が実行しているコマンドや作業を自動化するというくらいの軽い気持ちでテストを書くだけで、必要最低限のテストでの保護は可能となります。そしてそのためのテストコードは数行で書くことができます。

新しいアイデア、素晴らしい機械学習モデル、こうしたものを作ることそのものは確かに誰にもできないことであり、その業績は褒められるべきものです。しかし、せっかくのその傑作を素早く広めていくには、保守性の向上は常に考える必要があります。そのためにも、テストがないコードにテストをかぶせていく手法を学ぶのはとても有益と考えています。

テストの話とは外れますが、こうした発想がソリューションアーキテクトという仕事において有益である、という話を、4/24(水) 開催の SA Night #1 で少しだけ触れますので、興味がある人は是非ご参加ください。