プロジェクトが大きくなるにつれて、既存のコードに直接新機能を追加すると、本当にバグが増えていく。今日一日で2つの似たようなバグを見つけて、本当に腹立たしい！

kernel_size と stride は一対一で対応していない

以前のコードで定義されたモデルでは、nn.Conv2dの kernelsize と stride が一対一で対応していた。しかし、拡張後のモデルには以前書いた対応ルールに合わない層があり、kernelsize に基づいて stride に値を代入するコードが直接問題を引き起こした。

今日突然assertで shape を判定するコードを書かなかったら、一生気づかなかっただろう。

if kernel_size == 3:
    padding = 1
    stride = 1
elif kernel_size == 5:
    padding = 2
    stride = 2
else:
    raise ValueError()

すべての畳み込み層の後にReLUがあるわけではない

以前のモデルでは、各畳み込み層の後にnn.ReLUが続いていた。しかし、新しい解像度要件に適応させるために変換層を設計し、その後にはnn.ReLUがない。その名前のルールは以前の畳み込みと同じだ。その一方で、シミュレーション計算時に、以前書いた判定ルールが直接エラーになった。o(￣┰￣*)ゞ

-if quant.startswith('classifier_conv'):
+if quant.startswith('classifier_conv') and quant != 'classifier_conv_transfer':
    x[x < 0] = 0

とにかく、今日見つかった2つのバグはどちらも、既存のコードから移行して少し追加した結果、判定条件のミスが生じたものだ。これらの問題は、最初から拡張性の良いアーキテクチャを設計しない限り、避けようがないように思える。でも、最初から将来起こりうる問題にどうやって気づけばいいのだろう？研究は製品開発ではないし、しばらくすると新しいアイデアが浮かぶので、それほど多くを考慮することは不可能に感じる。