Download to read offline
保守しやすいコードの反面教師 （アンチパターン） その1
- 1.
- 2. 自己紹介 ID：suusanex（ connpass・Twitter・GitHub共通） 名前：須藤圭太 サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属 4年ほど受託開発で、上流から下流まで全部を回す ここ6年ほどは、自社製品開発を担当 Windowsアプリ開発のネタが多い
- 3. 概要 改修を請け負ったソースコードで、「ここに気を遣ってくれていたら、何倍も 改修が楽だったのに」と思った点がある 当然、改修後にはそれを避けるように減らすように注意した そういうアンチパターンをいくつか紹介して、これ以上無駄な苦労を再生産し ないようにしていきたい
- 4. 目次 必要ないところで結合度を下げない エラー処理方針は最初に統一する 広すぎる名前を付けない その他小さいものをいくつか
- 5. 必要ないところで結合度を下げない 何を見たか クライアント内C#コード間のデータ受け渡しで、key-valueの文字列Dictionaryやobjectに 変換して、C#の型に依存しないようにしていた 何が問題だったか コンパイラでエラー検出が出来なくなり、問題の発覚が実行時になった せっかくのC#の型安全メリットが死んだ クライアント・サーバー間やマイクロサービス型なら意味のある結合度低下だが、同時に ビルドする同一言語のコード間の場合はデメリットしか無い どう改善したか 同一プロセス内の呼び出しは、名前と型を明示したメンバを持つクラスへ変更 同一ビルド内で定義を共有しているので、値を追加・削除などしても問題ない プロセス間の呼び出しは、WCFを使って型の制約のあるパイプ通信に変更
- 6. エラー処理方針は最初に統一する 何を見たか コードの場所によって、「戻り値にエラーコードを返す」「戻り値のクラス内にエ ラー情報がある」「例外を投げる」「エラーを返さない」などエラーの方針がバラ バラ 何が問題だったか 作っている人も混乱しているのか、エラーをチェックせずにスルーするコードが多 数→エラー発生時に何の情報も出ず、要デバッガ エラーコードと実際に発生したエラーの紐付けが分からず、解析も改修もキツい どう改善したか .NETの出した例外を捨てずに上位へ渡し、判断できる処理階層でだけcatchする このルールを明確にし、メンバーにも周知
- 7. 広すぎる名前を付けない 何を見たか Commonというクラスに、ビジネスロジック固有の処理も含めた大量のメソッドが 集まっていた 改修対象の機能やデータに影響するものを、コード全部読まないと見つけられない 何が問題だったか 広すぎる名前を付けると、人によって範囲の解釈が変わるので、起きがち Common,Utility,Settings,Defineなどが危険 どう改善したか ProcessUtilityなど、用途別に名前を付けてCommonを分割 ビジネスロジックやデータに依存するものは、その責務を持つ場所に移してカプセ ル化
- 8. その他小さいものをいくつか 独自用語なのか規格の用語なのかを曖昧にしない 「stringdeviceId; //< デバイスID」 独自に振ったID？何かの規格で取得したID？ データ型（特に文字列）をバラバラに使わない Char*,std::string,CString。BYTE*,std::vector。malloc,new。混在は辛い
- 9. まとめ 改修時に苦労する点を知っておけば、新規開発時の問題作り込みを避けられる 問題を先送りすると、工数不足でまた問題のあるコードを新規に作り込む 最初からアンチパターンを避けて、悪循環を断ち切ろう