人の作ったWebアプリケーションのコードを見るときに注目しているところ

普段見ているものをなんとなく書き出してみた。

インターフェイス

あえてやってないとか、レイヤ的にやる必要がないというケースもある。しかし、ある程度の規模のソフトウェアには大抵インターフェイスが現れる。インターフェイスがないコードはユニットテストもないことが多い。したがって、インターフェイスが現れないコードは責務分離が行われてない可能性を感じたりする。

言語機能上インターフェイスがない動的型付け言語の場合には、ダックタイピングを意識したコードが書かれているかをチェックする。ダックタイピングでなくとも、例えばRubyだったら抽象クラスと実装クラスの分離が行われているかを見たりする。

バリデーションロジック

すべてのバリデーションが、フレームワークの機能で実装されてたりしないかをチェックする。MVCとかクリーンアーキテクチャ的な実装であれば、それぞれのレイヤでどういうバリデーションをしているのかを覗いてみる。コントローラで全部のバリデーションが行われているときもある。

また、バリデーションエラーをどうハンドリングしているかも確認する。DBエラーをそのままプレゼンター層に返していたり、ドメイン層に外部レイヤの言葉とかデータが出てくると「オッ」となったりする。

トランザクション

トランザクションをどの範囲で貼っているのかをチェックする。そもそもトランザクションが貼られていないときは、なんらかの理由があるかを調べてみる。トランザクションの実装がドメインからどれくらい分離できているかを見てみる。

トランザクションが貼られている部分に対するリクエストのトラフィックを見てみる。なぜそのトランザクションが結果整合じゃないのかを考えてみる。

Userクラス

大体、どんなアプリケーションでもUserみたいな名前のクラスが存在する。とりあえずおもむろにそれを覗いてみる。1000行とかあったりすることもあるので、そのときはまず深呼吸する。もしかしたら本当にそれだけ長くなる理由があるのかもしれない。

Userが薄い場合にはUserを継承してそうなクラスを探してみる。薄すぎるな〜と思ったときには、Userの実装をもとに値オブジェクト的なものを探してみる。あったら実装を読んでみる。どういうクラス設計になっているか覗いてみる。

POXO

これは極めて強引な意見だが、できのいいソフトウェアは大体POXO*1がちゃんと作られている。RubyならPOROだし、JavaならPOJOになる。特に、ドメインにあたるレイヤのコードがPOXOじゃないときは、その理由を探ってみる。

すべてのクラスが何かを継承していたり、なにかに依存している場合には「なんでだろう？」を考えてみたりする。

〇〇サービス

ディレクトリ構造を全部展開してHogeServiceみたいなのがないか探してみる。するとだいたい見つかるので、ゆっくりその中身を読んでみる。

ステートフルなのか、ステートレスなのか。ドメインサービスなのか、アプリケーションサービスなのか判断を試みる。どっちでもなさそうな場合には、なんらかのドメインに所属させれないか考えてみたりする。

〇〇リポジトリ

とりあえずDDDのリポジトリを期待して中身を覗いてみる。インターフェイスであることを期待しているところ、いきなりSQL文が現れたりすることもある。

インターフェイスになっている場合には、どこまで永続化装置を抽象化できているか見てみる。追加と削除のインターフェイスだけになっていたらかなり驚く。満足したらどこでDIしているのかを探してみる。フレームワークの機構を使っているのか、シンプルなコンストラクタDIなのかをチェックする。

レイヤごとの実装

MVCであればそれぞれにどういうコードが書かれているのかを見てみる。Mの中に永続化装置やプレゼンター実装の具体的な単語が出てくると「オッ」となる。クリーンアーキテクチャであればFlow of Controlをどう作っているか、アダプタ実装ごとのプラガビリティがインターフェイスでどれだけ抽象化できているか、をじっくり眺めてみる。

静的型付言語であれば、型を使ってドメインをどれくらい守れているかを見てみる。