研究室で過ごす【実装編】
島田研では手を動かすことで研究を進めることがほとんどであり、それはプログラムを実装することに他ならない。
実装は独特の注意点を持っていると思うのでこの項でまとめる。
順番を間違えるだけで手間が無茶苦茶増える場合がある
プログラムは今まで作ってきたものを引きずりながら動作する
基準
クリティカルな実装は先に行う
データセットは小さく動かす
小さく作って正しく動くことを確認してから次に進む = 分割統治
GPTに聞く時も順番に気を付ける
複雑な条件を最初に指定してしまうと、その後の変更要求も複雑な条件を引きずってしまう
質問の順番によっては妥当な回答が得られる可能性が減ってしまう
例：深層学習の実装手順
特殊な損失関数やモデル構造を作る
小さい次元やデータセットで動くようにする
小さくて簡単なモデルで動くようにする
作ったモデルを使って推論できる機構を作る
モデルのサイズとデータを増やす
過学習を確認したら正則化手法を試す
パイパラ探索
プログラムの設計に時間をかけない
正直、プログラムをどう作れば”美しく”なるか設計するのは楽しい
しかし研究では一旦置いておく
研究のコードは多少見にくくても構わない。
研究は上手くいく可能性が低いことを行っている。
厳密な設計は実験的に開発する研究やプロトタイプでは効果を発揮しにくい
設計は初期コストを上げ、ランニングコストを下げる
仕様変更を続けながらも動かし続けることに意義のあるソフトウェアには大事
上手くいったらそこで初めてリファクタリングすればよい
今後付き合っていくコードになるから
GitHubを使う
手戻りが多い研究コードとGitは相性が良い
バックアップ目的だと人間一生動かないので、手戻りしやすくなるのをモチベにしたほうが良い。
研究室のメンバーに見られるのが恥ずかしいなら最初は個人のリポジトリでよい。
後からでも研究室所有のリポジトリに変更できる
最初はadd→commit→pushコマンドが使えればいい。使い方を網羅しなくても使える。
開発環境はテキストから再現可能にする
手段は問わない。pyproject.tomlでもdockerfileでも、コマンドを記録した手順書でもいい。
テキストファイルはGit管理対象にする。
これにより開発環境がPCの環境に依存しなくなる。
自分がいまどんな環境なのか見返せるだけでなく、GPT等に情報提供しやすくなる。
概念と実装は表裏一体
基本的にはまず概念があり、それがコードとして具体化される
よって概念を理解することは非常に大事
理解しないで実装しても、結局はデバッグなどで時間が掛かるもの
デバッグの際に低レイヤ（概念や理論）に降りる必要がある
実装スピードをデバッグまで含めて考えるなら、どこかではしっかり理解しておく必要がある
自分の理解の浅いところにバグは現れる
ツールは「開発を便利にする」「楽になる」ために使う
なんでもかんでも導入すればいいものではない
例：タスク管理ツールを使いこなせというわけではなく、タスク管理をしろと言っている
ツールは直接的に課題を解決してくれるものではない
ツールが操作できても研究課題は解決しない
ツールは開発を進みやすくするために導入するもの
開発の進行に問題が出るほど難解なツールは、見送ることも視野に入れる
それでもやはりこの機能が必要だとなったときに初めて導入を考えればよい
Git, Docker, DB等はただ難しいのに学ばないといけない、面倒なツールではないよと言いたい
欲しくなったときに導入すればよろしい
後戻りの簡単さや共有の楽さ、環境構築の楽さ、データ抽出とトランザクションの楽さを得るために導入する