非エンジニアの Kaggler がエンジニア指南を受けて気づいた、たった1つのこと

この記事は GiXo アドベントカレンダー の 10 日目の記事です。
昨日は、「Apache Superset の可視化例紹介」 でした。

MLOps Div. の濱田です。
皆さん、Kaggle をご存知でしょうか？ざっくりいうと、企業やラボから与えられたデータに対してモデリングを行い、その精度を競うコンペティションプラットフォームです。そして Kaggle に取り組んでいる人々を世間では Kaggler と呼び、私もその一人です。（Kaggle アカウントはこちら）

そんな私が、GiXo 入社時にエンジニア指南を受けて気づいた1つのことを、ご紹介させていただきます。

お前のソースコードは汚い

これに尽きます。完。

…と終わるわけには行かないので、しばしお付き合いくださいませ。

なぜ汚いのか

Kaggle というのは、いかに実験を回して最適な予測に近づけるかを競うゲームです（諸説あり）。そのため、追い求めるのは試行錯誤するためのスピードと精度です。そうすると下記のような行動をとることになります。

• 自分が読めれば良いので、コードをキレイにしようという意識が生まれない
• 処理の結果にしか興味がないので、逐次処理を羅列する
• とりあえずグローバル変数で書き進める
• テストコードを書かない
• 極論、精度の上昇に寄与しない行為を放棄する

この過程で生まれたのが私です。

コードが汚いとはどういう状態か

コードが汚いというのは大きく2つのことが関係しているかと思います。

1. 自分以外が解読できない
2. ルールが守られていない

以降、詳しく見ていきます。

1. 自分以外が解読できない

これは、まさに非エンジニア Kaggler^※ に典型的なことではないでしょうか 。自分以外に見せる必要がない状態でコードを書き続けた、なれの果てです。具体的には、下記のようなことが起こります。

• Python
  • 引数や戻り値が多すぎる関数を書く
  • 変数を容赦なく上書きする。「いい加減に終わったかな？」と思った後にまた上書きする
  • インデックス参照の書き方を多用する
  • 適切ではない状況で map や filter などの高階関数を使っている自分がかっこいいと思っている
  • 他人の理解を助ける目的でのコメントを書かない（ただの自分用メモ）

• Git
  • コミットを意味のある単位で分けず、後から見ても理解できない
  • 他人の理解を助ける目的でのコミットメッセージを書かない（ただの自分用メモ）

そうなるといわゆる「オレオレコード」が増えていき、パッと見て何をやっているのかわからない状態になります。何がキレイで何が汚いのか、自分の中に基準がないのです。

2. ルールが守られていない

Pythonには、PEP8 というコーディング規約があります。非エンジニア Kaggler は、これを意識していません。教科書ともいえるようなドキュメントを読んでいないのにいきなり応用問題を解こうとしても、やはり解けないので赤点だらけになってしまうのです。これはコード上で下記のような形で表れます。

• dataclass のような標準で提供されている簡潔な書き方を使用していない、または知らない
• 関数に独創的な名前をつける
• クラスを必要な場面で使わず、逆に使うべきでないところで使う
• Linter や Formatter を適用せず歪んだコードを書く
• 型アノテーションをつけない

エンジニアの世界での一般常識が欠落したままコードを書いていると、コーディングにおける認知の歪みともいうべき事象が発生し、その後も苦しみ続けることになるので注意が必要です。

どのように解決するか

1. 「自分以外が解読できない」に対する解決策

「可読性の高いコードの基準」を、自分の中で醸成できると良いのではないかと思います。

• OSS の GitHub リポジトリにあたって、自分の書いたコードとの違いを確認する
  例えば scikit-learn のリポジトリを見ると、下記のような理由で可読性が高いことがわかります。
  • コメントや docstring がしっかりと書かれている
  • fit() 、transform() のように、各インスタンスで共通の関数を利用するように方針が整っている
  • CircleCI で linting を行っている
• コードレビューで忌憚のない意見をもらう
  自分に無い視点が得られるのは、とても重要なことです。どんどんツッコミを入れてもらいましょう。

2. 「ルールが守られていない」に対する解決策

何事も、公式のドキュメントにあたることが肝要です。量が多いので完璧に目を通せるかというと難しいかもしれませんが、書き方に迷うことなどあれば、本家を見るのが一番です。何か問題があって Stack Overflow を探しても出てこないなー、というときにも、公式ドキュメントや GitHub リポジトリの Issue に目を通すと、普通に書いてあったりします。

おわりに

自分のコードがキレイになっていくと、まるで心まで洗われていくような感覚になりますね。同じ間違いを二度は犯さないようににしていけば理論的にはいつか間違えることがなくなるというポジティブな思考で、今後も精進していきたいと思います。

そんな成長を日々感じられる弊チームの紹介記事はこちらです。興味を持っていただけた方は、是非目を通してみてください。
さらに、私達と一緒に働きたい！と思っていただけた方がいらっしゃれば、ぜひこちらからご応募ください。まずはカジュアル面談で話だけ聞いてみたい、という方も歓迎です。

明日は Technology Div. の緒方より「pandas でヘッダーが複数ある POS データを縦持ち横持ち変換する（前編）」を公開予定です。

※ コードがキレイな 非エンジニア Kaggler の方々を巻き込んでしまい、誠に申し訳ございません

Shota Hamada (濱田 翔大)
MLOps Div. 所属
Kaggle 、将棋、コーヒー。React + TypeScript によるフロントエンドの開発を担当しています。