こんにちは。最近めっきり寒くなってきましたね。寒さに起因して頭痛もひどくなってきましたが、柚子しょうが紅茶が結構効くのでなんとかやってこれています。
今日のお題はスパゲティコードの治療です。
Contents
なぜ急にスパゲティコードを治そうと思ったのか
先日、Ryuの自己管理室さんの公開している【完全版】”超ハードワーク”を実現する３つの脳ハック術を観ました。かなり自己啓発な内容で個人的には結構アレルギーが出る内容でしたが、一方で「最初のハードルを下げる」というのは結構使えそうだなと感じました。特にメンタルをやってからは何もせずに生きているだけの日も多かったので、それならばコードくらい触っていよう。そうして行き着いたのが、過去の自分のコードを治療することでした。
自分のスパゲティコードの特徴
まずは自己分析から。自分のコードの特徴は、とにかく機能が多くて整理されていないこと。傾向としては以下があげられます。
- とにかく機能の実装を最優先にして、ドキュメントを書かない
- 古い機能も勉強の役に立つかもと思って残しがち
- コードの書き方やディレクトリでの配置方法にルールが無い
この状態では半年も経てば無事にレガシーになります。逆にいえば問題点は明確なので、今回はドキュメントを書きながらいらないところを消し、コードのルールを作って次につなげていきましょう。
実際の事例
いらなすぎる勉強用プログラムたち
どうやらこのプログラムを作った頃、コンテナやMySQLなどのDBMSにハマっていたこともあってそういった技術の勉強用にプログラムを作っていたようです。プログラム実行環境はAWS上のコンテナを想定し、専用のDockerfileとビルドスクリプトまで用意している始末。もちろん、これらはプログラム本体とは切り分けて管理したほうが良いですね。他にも、tensorflowに初めて触った関係から、これらの試験的なコードも保存してありました。これは個別にGithubに上げて、このブログで解説するのが良いでしょう。ともかく、勉強用プログラムや環境構築スクリプトと本番プログラムは混ぜないように！
環境構築部分や勉強用プログラムとメイン部分は別プロジェクトにしましょう。
足りない説明
いらなすぎる勉強用プログラムたちに付随する形になりますが、あたらしいことを実践した際はメモくらい残しておいてくれ、過去の自分！！全然何をするためのものか分からないプログラムばっかり残っているではないか。なんか面白いプログラムを作ったらこまめに日記としてブログに上げて、いつでも振り返られるようにしましょう。そして、どうしても本番プログラムに入れる際はブログへのリンクでも良いから説明を入れておきましょう。しかしプログラミングって奥が深いというか、ちゃんとドキュメントを残しておかないと、ほぼすべての作業がパアになってしまう気がしますね。
どっちがmainかわからないプログラム
プログラムの主であるメインプログラムと、それを用いた応用を行うプログラム、そしてテストを行うプログラムと、いくつかのプログラムから構成されるプロジェクトがある場合は、ちゃんとフォルダわけしましょう。今回はメインとなるのはデータを計算するプログラム、応用部分はデータをもとに図を作成するプログラム、テストはメインプログラムの動作チェック用でした。なので、応用とテストはそれぞれvisualization, testと分けて管理したほうが良かったですね。データはdataフォルダを作って管理していただけに、惜しかったというかなんというか。
どうやって入れたか不明のライブラリ
環境設定済みであれば問題なく動くけれど、そもそもこのライブラリどうやって入れたの問題が発生しました。いやーoptunaのことなんですけどね。多分conda経由で入れたと思うんだけど、環境構築でバグらないようにするためにも、ちゃんとどうやって入れたかは残しておくべきでした。メインプログラムに影響するようなライブラリはブログへのリンクをREADMEに貼るなどして対策することが必要ですね。
いったんのまとめ
ここまで書いてきて感じたのは、スパゲティコードになる落とし穴は結構あって一記事ではまとめきれないということです。なのでこれを#001として、不定期連載という感じでやっていこうとおもいます。昨日図書館へ行ってリーダブルコードを借りてきましたので、次回はリーダブルコードと比較しながら改善して行こうと思います。それとは別に勉強用コードの供養もやっていきます。どっちが先に記事化されるかはわかりませんが、【完全版】”超ハードワーク”を実現する３つの脳ハック術でも毎日の進歩を確認することが大切といっていた気がしますので、少しペースを速めて頑張ろうと思います。それでは！また次回！