最終更新日：
Folkman氏によれば、データサイエンティストはコードを書く機会が多いものも、ソフトウェアエンジニアほどには高品質なコードを書けず、また上手にコードを書く努力を怠っています。しかし、AIモデルがさまざまな製品や環境に実装されるようになった今日、データサイエンティストであっても高品質なコードを書けるようになるべきなのです。
高品質なコードを書くためのヒントとして、Folkman氏は以下のような5項目を挙げています。
- 関数を簡潔に書く。具体的には1つのタスクだけを実行し、内容を反映した変数名を使う。
- Print文は不要になったら削除するか、ログを採取するコードに置き替える。
- スタイルガイドを採用し、それを遵守する。
- テストコードを作成し、保存する。
- コードレビューを実施する。
以上のようにヒントを挙げたうえで、コードを上手に書くこと自体は難しいことではないが、上手くなるまでに時間と努力が必要、とFolkman氏は述べています。
なお、以下の記事本文はTyler Folkman氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。また、翻訳記事の内容は同氏の見解であり、特定の国や地域ならびに組織や団体を代表するものではなく、翻訳者およびAINOW編集部の主義主張を表明したものでもありません。
画像出典：UnsplashのRoman Synkevych
ただコードを書くのではなく、良いコードを書く
（もしあなたがデータサイエンティストだとして、コーディングができるかと尋ねられたら）あなたが考えることはわかる。「もちろん、コードの書き方を知っているよ、そんなことを聞くなんて正気かい」
あなたは毎日、Jupyterノートブックに何百行もの大量のコードを書いている。明らかにコードを書ける。機械学習のモデルを手作業やExcelでトレーニングしているわけではないのだ（それも可能だが）。
では一体、私が言いたいこととは何か。
言いにくいことだが、データサイエンティストが行うコーディングのほとんどは、私がプログラミングと見なすものではない。データサイエンティストはデータを調査し、モデルを構築するためのツールとしてプログラミング言語を使っている。しかし、作成したプログラムは、仕事を遂行するためのものに過ぎず、あまり気にかけていない。
データサイエンティストのコードはたいてい散らかっていて、（ノートブックのおかげで）連続して実行されることもないかも知れない。また、ユニットテストを書いたことがなく、再利用可能な優れた関数の書き方についてもほとんど知らないだろう。
しかし、データサイエンスが実際の製品に組み込まれることが多くなると、そのようなコードでは対応できなくなる。悪いコードは信用できないし、信用できないコードを製品に組み込むと、膨大な技術的負債（※訳註1）と悪いユーザ体験を生み出してしまう。
「わかったわかった。しかし、私はデータサイエンティストであって、ソフトウェアエンジニアではない」とあなたは言うだろう。自分の仕事はモデルを構築することであって、コードをきれいにするのは他の人の問題だ。企業によってはそのようなやり方もあるかも知れないが、今のところ私が思うのは、データサイエンティストがよりよいコードの書き方を学ぶことのほうがはるかによい考え方である。エリートレベルのソフトウェアエンジニアにはなれないかも知れないが、データサイエンティストでも信頼できるコードを書け、そうしたコードを多少の労力で製品に投入できるのだ。
関数から始める
コードのレベルアップを図るには、まず関数の書き方から始めよう。ほとんどのコードは、関数（あるいは潜在的にはクラス）の集まりであり、優れた関数を書けるようになれば、コードの品質向上に大きく貢献する。
関数のコードは、以下のように必要最小限であるべきだ。
- 1つのこと（タスク）しかしない
- ドキュメントを作成する
- 良い変数名を使う
クリーンな関数の書き方については多数の本が書かれているほどだが、まずは以上の3項目から始めよう。
1つ以上のことをやろうとしているような関数は、絶対に避けなければならない。関数が多くのことをやりすぎている可能性がある兆候には、以下のようなものがある。
- 1画面分より長い、あるいは30行程度のコードよりも長い（私の経験上）。
- 多くのことを実行しようとしているために、関数名を明確に命名するのが難しくなっている。
- if/elseブロック内に多くのコードが含まれている。こうした場合は実際には別々の関数に分割する必要がある。
1つのことだけをする関数は、コードの理解、管理、テスト（テストについては後述）を容易にするために重要だ。
本番環境にリリースされる関数には、一連のドキュメントが必要である。そうしたドキュメント群にはその関数が何をするのか、入力パラメータに関する情報を記述されているべきであり、その関数の使い方に関する簡単な例が示されているかも知れない。文書化された関数があれば、後に自分自身に感謝することになるだろうし、他の人があなたのコードを理解するのが非常に簡単になるだろう。
最後に、わかりやすくて親切な変数名を使うようにしよう。多くのデータサイエンティストが「a」、「a1」、「a2 」などの変数名を使うことで悪循環に陥っている。短いが不親切な変数名は実験時には早く入力できるが、コードを本番環境に投入する際には他の人がコードを理解するのに役立つ変数名にしよう。
Print文の削除
データサイエンティストは起こっていることに関する情報を表示するために、しばしばprint文を使用する。しかし、本番環境では、これらのprint文は不要になったら削除するか、log文に変換する必要がある。
（ログを採取する）ロギングは、コードからの情報やエラーを伝達する方法であるべきだ。ロギングをよりシンプルにするために、PythonのライブラリとしてLoguruがある。Loguru は、ロギングに関する煩わしい部分のほとんどを自動的に処理し、単なる print 文を使用するのと同じように感じられる。
スタイルガイドの使用
プログラミングにおけるスタイルガイドは、多くの人が同じコードに取り組みながらも、そのコードのほとんどが一人で書かれたように見えるようにするために使用される。
なぜスタイルガイドが重要なのか。
一貫したスタイルを持つことで、コードのナビゲーションや理解が非常に容易になる。スタイルガイドを使用すると、バグの発見が驚くほど簡単になる。標準的なコードの書き方に準拠することで、他の人と同じように簡単にコードをナビゲートできるようにもなる。つまり、コードを理解するためにそれがどのようにフォーマットされているのかを解析するのに多くの時間を費やす必要はなく、代わりにコードが何をするのか、それが正しく動作するどうかに集中できるのだ。
PEP 8（※訳註2）は、おそらくPythonのスタイルガイドとして最も広く使われている。しかし、世の中には多くのスタイルガイドがある。スタイルガイドのもう1つの人気のあるソースはGoogleで、彼らは社内のスタイルガイドを公開している。
重要なのは、1つのスタイルを選び、それを遵守することだ。こうしたことを容易にする1つの方法は、IDE（※訳註3）にスタイルエラーをチェックする機能を持たせ、スタイルガイドに従わない場合にはコードがプッシュされないようにするスタイルチェックを設定することである。さらには、コードを自動的にフォーマットしてくれるオートフォーマッターも使える。これは、好きなようにコードを書いたとしても、実行すると標準に準拠するようにコードを自動フォーマットしてくれるものだ。Pythonで人気があるオートフォーマッターはBlack（※訳註4）である。
テストの作成
私が思うにほとんどのデータサイエンティストがテストを恐れるのは、テストの始め方がよくわからないからだ。
実のところ、多くのデータサイエンティストは、テンポラリーテスト（一時的なテスト）と私が呼んでいるものをすでに実行している。彼らのあいだでは、自分のノートブックで新しい関数に関するいくつかの「健全性チェック」を素早く実行するのが一般的なようだ。つまり、いくつかの簡単なテストケースを通過させて、その関数が期待通りに動作することを確認している。
ソフトウェアエンジニアはこのプロセスをユニットテストと呼んでいる。
データサイエンティストとソフトウェアエンジニアのテストにおける唯一の違いは、前者はテンポラリーテストを削除して次に進んでしまうことだ。テストを削除する代わりに、それを保存し、コードがプッシュされる前に必ずテストを実行して、何も壊れていないことを確認する必要がある。
Pythonを使ってテストを始めるにあたっては、私はpytestを使っている。pytestを使えば、簡単にテストを作成し、それらを一度に実行して合格を確認できる。簡単な方法は、「tests 」というディレクトリを作り、そのディレクトリ内に “test “で始まるPythonファイルを置くのだ。例えば、以下のような「test_addition.py 」を使える。
# content of test_addition.py
def add(x, y):
return x + ydef test_add():
assert add(3, 2) == 5
なお、assert文は任意の条件を満たさない場合にAssertionErrorを送出する。
一般的には、実際の関数を別のPythonファイルに記述し、それをテストモジュールにインポートするだろう。また、以上のようなPythonの追加コードをテストする必要はないだろうが、非常に単純な例を示したかった（ので例示した）。
これらのテストモジュールには、関数の「健全性チェック」をすべて保存できる。一般的には、通常なケースだけでなく、エッジケースや潜在的なエラーケースもテストするのが良い習慣とされている（※訳註6）。
コードレビューの実施
最後になるが、より良いコードを書くためにすべきことリストのトップは、コードレビューだ。
コードレビューとは、メインブランチにコードを提出する前に、自分が働いているドメインでコードを書くことに精通している別の人にコードをレビューしてもらうことである。このステップでは、ベストプラクティスが守られていることを確認し、うまくいけば悪いコードやバグを発見できる。
コードをレビューする人は、できればあなたと同じくらいコードを書ける人が望ましいのだが、あなたより経験が浅い人にコードをレビューしてもらうだけでも、非常に有益なことがある。
怠惰なのは人間の常で、コードにもその怠惰さが入り込んでしまうことがある。誰かが自分のコードをレビューしてくれると分かれば、良いコードを書くために時間をかける大きなきっかけにもなる。コードレビューは私が見つけた最善のコード改善方法でもある。経験豊富な同僚が自分のコードをレビューし、改善のためのヒントを与えてくれるのは、とても貴重なことなのだ。
あなたのコードをレビューする人が楽になるように、新しいコードの量を少なくするようにしよう。小規模で頻繁に行うコードレビューはうまく行く。時々しか行わない膨大な量のコードレビューは最悪だ。1,000行ものコードが送られてきてレビューさせられるのは、誰も望んでいない。このようなレビューでは、一度に多くのコードを理解するのに必要な時間を取れないため、フィードバックが悪くなる傾向がある。
10行のコード（レビュー） = 10の問題点（を指摘）
500行のコード（レビュー） = 「良いように見える」
以上のツイートの真意は、10行のコードレビューではコードを詳細に精査できるので細かな問題点を指摘できるが、500行のそれではレビュアーがあまりコードレビューに労力を費やさなくなるため、コードを精査せずに「何となく良い」という粗雑な結果が返ってくる、ということにある。
コーディングのレベルアップ
この記事が、より良いコードの書き方を学ぶのに時間をかけるようにあなたを触発することを願っている。コーディングが上手くなるのは難しいことでは決してないのだが、上達するには時間と努力が必要なのだ。
以上の5つの提案に従えば、コードの品質が大きく向上するに違いない。
コーディングが上手くなれば、将来の自分や同僚に感謝されることだろう。
・・・
機械学習モデルの実装方法に関する私が監修している無料講座についてもチェックしてみてください。
原文
『Data Scientists, You Need to Know How to Code』
著者
Tyler Folkman
翻訳
吉本幸記（フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得）
編集
おざけん
