卒論のアーキテクチャ設計で失敗した話
はじめに
本記事は、私が卒業論文制作の過程で行った
アーキテクチャ設計の失敗体験について振り返るものです。
卒論では「とりあえず動けばいい」「後で直せばいい」と考えがちですが、
アーキテクチャ設計を軽視した結果、
実験直前・データ取得段階で大きな手戻りが発生しました。
これから卒論や研究用システムを作る人が
同じ落とし穴に落ちないための記録として書いています。
使用した技術スタック
- Unity
- （必要に応じて：C# / VRデバイス / センサ系など）
卒論では主に Unity を用いて実験用アプリケーションを開発しました。
当初設計したアーキテクチャ
全体構成
開発初期は、以下のような非常に単純な構成で実装を進めました。
├── src/
│ ├── core
│ │
│ ├── 機能ごとに/
│ │ └── script①
│ │ └── script②
設計時の判断基準
- 卒論なので「そこまで綺麗にしなくていい」と考えていた
- アーキテクチャ設計の経験がほぼなかった
- 一年間動けばなんでも良いのお気持ちでスタートした
結果として、
明確な設計方針を持たないまま実装を開始していました。
何がうまくいかなかったのか
具体的な失敗ポイント
- ゼミ発表に間に合わせることを優先し、リファクタリングを後回しにした.
- 実験条件や仕様変更に対応できない構造になっていた
特に「後で直せばいい」という判断が、
後半で大きな負債として返ってきました。
問題が顕在化したタイミング
- 実験直前
- 要らないスクリプトを消去したらアプリが動かなくなったとき
なぜその失敗をしてしまったのか
- ある意味ゼミの進捗を生み出すわけではないリファクタリング作業をめんどくさがった
- 将来の仕様変更や実験条件の追加を想定していなかった
- 他の人からもらったコードを、自分のプロジェクト全体のアーキテクチャに合わせて整理しなかった
結果、以下のように「設計思想の異なるコードが混在する構成」になっていた。
├── src/
│ ├── core
│ │
│ ├── 機能ごとに/
│ │ └── script①
│ │ └── script②
| |──他の人のコード（何も整理されていない状態）
│ │ └── script1
特に
「研究用コードだから雑でもいい」という思い込みが大きな原因でした。
実際に起きた被害
- 修正に想定以上の時間がかかり、精神的にかなり消耗した
- 修論のシステムを作るときは全て作り直したいと思っています（猛省）
今後に向けて
卒論でシステムを作る人へのアドバイス
-
定期的にリファクタリングはしましょう
-
研究室内の先輩・後輩からコードをもらったら自分のコードとして適切になるようにコードの場所を変更しましょう！
-
大学院に行く人や、後輩に引継ぎが確定している人はとにかく丁寧にリファクタリングを常にしましょう
おわりに
- ゼミだけしのげればいいと思ってシステムを作成していましたが、それでシステムが耐えるのは一年が限界なので、2.3年開発するシステムはちゃんとリファクタリングを行いながら作成しましょう