レイヤードアーキテクチャでコードを書き直した
レイヤードアーキテクチャでコードを書き直した感想。
という記事をふんわり参考にして、今作りかけている物のソースコードを書き換えてみた。
テストは書いてない。
正直なところ個人開発でスケールが小さい場合にはコード量がもりもり増えていくデメリットが大きいと思う。
参考記事内ではメリットとして
責務毎にグループ分けされているため、追加修正の際にどこを変更したらいいか分かりやすい 依存関係が１方向なので追加修正の際の影響範囲を特定しやすい
と書いてあるが、実際のところ自分で書いたからどこを変更したらいいかわかるのであって、他人が書いたものの場合は理解に時間がかかる。
初心者向けのチュートリアルでは全部のコードが 1 ファイル内に書いてあったりするのはそういうことだと思っている。
基本的に、色んなファイルに散らばっているよりも 1 ファイルにまとまっているほうがわかりやすいのである。
更に下位層をちょっと変更すると修正量が鬼のように増えることがある。
「これを変えるとここも変えなきゃいけなくて、更にここも……あとテストも全部変えて……」という風に変更の大連鎖が発生してしまうわけである。
これは実際に実務でそういうような経験をした。
自分の体感としては
下位レイヤーをモック化できるので責務毎の単体テストがしやすい
これだけが確かなメリットであり、逆に言えばテストコードなんて一切書かずに手動でテストするぜ！ というゆるふわ個人開発の場合には本当にメリットが無い。
＊ ＊ ＊
まあ、とはいえ良かったと思う点はある。
たとえば今までは DB からデータを取ってくるロジックを共通化していた。
読み取り（Fetch）の場合は読み取った結果を json の形にまで加工して返すようにしていたのだが、正直なところ Go の database/sql パッケージの関数はそういう使い方には向いていない。
通常は読み取った結果を構造体に格納し、その構造体を json にするのが普通だと思われるのだが、アプリケーション全体で「読み取り」というロジックを共通化しようと思うとそれはちょっと難しいのである。
なぜなら格納すべき構造体が定まっていないので。
結果として読み取った結果からカラム情報を取得して json のキーとするようにしていた。
が、これでは DB に定義したカラム名以外に json のキーを変えることができない。
今回はこのような実装はしなくなった。
DB からデータを読み取ったら構造体に入れ、その扱いは上位層に任せるのが適切なので。
その結果、json のキー名は好きに決められるようになった。
もちろんレイヤードアーキテクチャにしなくてもこのような実装はできるが、他の言語のフレームワークで OR マッパーに慣れすぎたせいか、無理に共通化しないほうがいいという気づきに至っていなかったのである。
（ちなみに Go では OR マッパーは以前から使っていない。OR マッパーを使わされるたびに思うが生の SQL を書くほうがわかりやすい……）
＊ ＊ ＊
そういうわけでテストを書いていない現時点ではソースコードが複雑で面倒だなあという気持ちだが、いずれテストをきちんと書いて「こうしてよかった」と思えるようにしたい。
おわり