保守しやすいコードの反面教師
（アンチパターン） その1
2021/11/30 須藤

自己紹介
 ID：suusanex（ connpass・Twitter・GitHub共通）
 名前：須藤圭太
 サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属
 4年ほど受託開発で、上流から下流まで全部を回す
 ここ6年ほどは、自社製品開発を担当
 Windowsアプリ開発のネタが多い

概要
 改修を請け負ったソースコードで、「ここに気を遣ってくれていたら、何倍も
改修が楽だったのに」と思った点がある
 当然、改修後にはそれを避けるように減らすように注意した
 そういうアンチパターンをいくつか紹介して、これ以上無駄な苦労を再生産し
ないようにしていきたい

目次
 必要ないところで結合度を下げない
 エラー処理方針は最初に統一する
 広すぎる名前を付けない
 その他小さいものをいくつか

必要ないところで結合度を下げない
 何を見たか
 クライアント内C#コード間のデータ受け渡しで、key-valueの文字列Dictionaryやobjectに
変換して、C#の型に依存しないようにしていた
 何が問題だったか
 コンパイラでエラー検出が出来なくなり、問題の発覚が実行時になった
 せっかくのC#の型安全メリットが死んだ
 クライアント・サーバー間やマイクロサービス型なら意味のある結合度低下だが、同時に
ビルドする同一言語のコード間の場合はデメリットしか無い
 どう改善したか
 同一プロセス内の呼び出しは、名前と型を明示したメンバを持つクラスへ変更
 同一ビルド内で定義を共有しているので、値を追加・削除などしても問題ない
 プロセス間の呼び出しは、WCFを使って型の制約のあるパイプ通信に変更

エラー処理方針は最初に統一する
 何を見たか
 コードの場所によって、「戻り値にエラーコードを返す」「戻り値のクラス内にエ
ラー情報がある」「例外を投げる」「エラーを返さない」などエラーの方針がバラ
バラ
 何が問題だったか
 作っている人も混乱しているのか、エラーをチェックせずにスルーするコードが多
数→エラー発生時に何の情報も出ず、要デバッガ
 エラーコードと実際に発生したエラーの紐付けが分からず、解析も改修もキツい
 どう改善したか
 .NETの出した例外を捨てずに上位へ渡し、判断できる処理階層でだけcatchする
 このルールを明確にし、メンバーにも周知

広すぎる名前を付けない
 何を見たか
 Commonというクラスに、ビジネスロジック固有の処理も含めた大量のメソッドが
集まっていた
 改修対象の機能やデータに影響するものを、コード全部読まないと見つけられない
 何が問題だったか
 広すぎる名前を付けると、人によって範囲の解釈が変わるので、起きがち
 Common,Utility,Settings,Defineなどが危険
 どう改善したか
 ProcessUtilityなど、用途別に名前を付けてCommonを分割
 ビジネスロジックやデータに依存するものは、その責務を持つ場所に移してカプセ
ル化

その他小さいものをいくつか
 独自用語なのか規格の用語なのかを曖昧にしない
 「string deviceId; //< デバイスID」 独自に振ったID？何かの規格で取得したID？
 データ型（特に文字列）をバラバラに使わない
 Char*,std::string,CString。BYTE*,std::vector。malloc,new。混在は辛い

まとめ
 改修時に苦労する点を知っておけば、新規開発時の問題作り込みを避けられる
 問題を先送りすると、工数不足でまた問題のあるコードを新規に作り込む
 最初からアンチパターンを避けて、悪循環を断ち切ろう