皆様の考えをコメントなどで聞かせていただけるとありがたいです｡
注意
- 自分用のまとめ
- 文章力皆無
slackでの履歴が消えてしまうまえにまとめておこうと思った｡
ことの始まり
自分でコードを書いている時に以下のようなことを経験した
- 共通化したら複雑化させてしまった｡
- 共通化しよう-> やっぱりやめよう -> やっぱり共通化しようと繰り返した｡
共通化するしないはどうすればよいのかと思い調べ以下のサイトにたどりついた
そして､所属しているコミュニティでも同じ質問をしてみた｡
参考サイトの軽いまとめ
コミュニティでの回答の前に参考サイトのいくつかのサイトを軽くまとめる
回答者1
共通化することで得られるメリットと、共通化によって生ずるデメリットを予想を含めて比較し、得すると思われる方を選ぶ。
メリットの量は呼び出し箇所に比例して増大する｡
仕様変更やバグによるコード修正の可能性がなければ縮小される｡
共通化切り出しをしやすいように、メリットが引き出せデメリットが顕在化しにくいように、普段から設計なりコーディングなり技術選択の工夫をしておくことが重要｡
メリット
- バグや仕様変更があったときの修正の一元化
- 似て非なるコードが複数あることで、なにかにつけ目を皿のように比較しなければならなくなることを避ける
- コード削減
デメリット
- 将来の状況変化、未知の事実の発見により、本当は共通ではないことが判明したとき分岐が複雑化する。もしくは手戻り。
- パラメータ化による複雑さの増加。テストバリエーション組み合わせ的増加、カバレッジ低下
- 汎用性が高く、機能が多ければ、インターフェースの複雑さは増す。この3つはトリレンマの関係にある。
- 複数のモジュールから使われるなにかの配置場所は自明ではない。util,common?方針を決めておかないと乱雑になる。
- 名前の付け方に迷う。
- 依存性の複雑化。
- 修正の影響が読みきれなくなる可能性。
- いろいろな箇所から呼べるように汎用性を高めたくなるが、それに引っ張られすぎると無駄な工数になる。
回答者2
経験と勘で共通化するかどうかを決める
どんなものでも再利用にはコストがかかる｡
適用できるかどうかはどうやって判断するのか
個人でも沢山あると戸惑うのにグループだとさらに困難になる､そして管理を他人にも合わせる必要がある｡
プログラムは文章であり､ただでさえ個人の属性が大きいのに他人にあわせるとさらにストレスが貯まる。
他人の思想を理解するにはその人と沢山話す必要があり｡
アジャイルのみえない効率の良さはここら辺も発揮される。
トップダウンで大上段にやるより
- 個人や対面できるグループ程度でフォルダ分け
- コメントをひっかっける
- プロセスくらいはわかるタグをつける
それくらいで共通化へのリソースはあきらめ、拾えたらラッキー程度に留めとくのが吉
回答者3
テストドリブンで進めるのであれば同じ処理が複数現れるかどうかで決める
ただし､システムの規模やメンバー､費用､言語､将来改修していくのか作り直す可能性などいろいろ考慮する点が多い。
やり過ぎるとシステムを複雑にして新メンバーが理解するのに時間がかかりトラブルシューティングするのに時間がかかる。
共通化するということは汎用性もしいられるので、通常よりも考慮する部分が多くなる。
拡張性も考えておかないと､似たような共通モジュールが沢山できてしまうので事前に検討して方針を決めておく必要はある。
コミュニティでの回答
3名の方に回答していただけた
miさん
共通化＝設計の成果物のルールの作りのキモかなと思っているので、共通化の基礎は大事にしている。
inさん
基準としては仕様変更の多さとか再利用性の高さの必要さ（利用パターンが増えそうか）や想定される利用頻度とかがある｡
一般的にはテストやCSSのスタイルなどについては共通化しすぎないほうが良いというのは言われている
初めての機能でまだ再利用するかも怪しい段階や共通化して作るか迷った場合は、変にDRYを意識しすぎずにYAGNIとしてできるだけシンプルに（単一責任は厳守して）作ってしまい、2~3個似たような要件が出来てからはじめて共通化を『リファクタリング』として後から考えたほうが良いケースが多い
ikさん
単一責任の原則を守る
達人プログラマーに以下のようなことが書かれている。
DRY原則は「知識」や「意図」の二重化についての原則です。つまり、異なった場所(おそらくはまったく異なった場所)に同じことを表現するという問題を避けるための原則です。
※この方は別サイトで解説しているので以下のサイトをみた方がわかりやすい
駄文(おまけ)
自分自身の考え
私も結局､なれや経験からしか判断ができないと思う｡