プロジェクトが大きくなるにつれて、元のコードに直接新しい機能を追加するのは本当にバグが増えるばかりだ。今日1日で似たようなバグを2つ発見してしまった。本当に腹立たしい！

kernel_size と stride が一対一に対応していない

以前のコードで定義されたモデルでは、nn.Conv2dの kernelsize と stride が一対一に対応していた。しかし拡張後のモデルでは、1層だけ以前の対応ルールに従っていなかったため、kernelsize に基づいて stride を設定するコードがそのまま壊れてしまった。

今日突然 assert を書いて形状をチェックしたからこそ気づけた。そうでなければ一生気づかなかったかもしれない。

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つのバグは、元のコードからちょっとだけ追加しただけで、判断条件のミスが原因だった。このような問題は避けられないように思える。もともと拡張性の高いアーキテクチャを設計しておけばいいのだろうが、最初から将来起きる問題を予測できるはずもない。研究は製品開発ではない。しばらくすると新しいアイデアが出てくる。それだけに、事前にすべてを考慮するのはさらに不可能だ。