Atomic Spin

Vývojáři softwaru jsou skvělí v rozpoznávání vzorů. Možná je to vrozená schopnost, která nás k této profesi přitahuje. Nebo je to možná proces psaní softwaru, který tuto dovednost rozvíjí. Ať tak či onak, „neopakuj se“ (DRY) je přirozenou aplikací této dovednosti.

Naproti tomu opakování samo o sobě není takovým nepřítelem, za jakého ho tato zásada vydává.

Neopakuj se

Jakkoli může být „neopakuj se“ intuitivní, Pragmatický programátor ho shrnuje takto:

Každá znalost musí mít v systému jedinou, jednoznačnou a autoritativní reprezentaci.

Není těžké si představit výhody omezení nebo odstranění opakování.

• Méně duplikací znamená méně kódu k údržbě. A pokud nejlepší kód je žádný kód, zní to jako dobrá věc.
• Jediný zdroj pravdy eliminuje možnost, že se věci nebudou synchronizovat. Změnilo se nějaké obchodní pravidlo? Aktualizujte ho na jednom místě a hotovo.
• Kód je opakovaně použitelný. Máte proces, který je společný pro tři věci, a přidáváte čtvrtou? Většina práce už byla vykonána.

Někdy se opakujte

Příliš horlivá snaha o omezení zdánlivé duplicity může způsobit více problémů, než kolik jich vyřeší. Říkám „zdánlivá duplicita“, protože někdy věci, které vypadají podobně, ve skutečnosti nesouvisejí. Například dvě datové struktury s identickými vlastnostmi a typy mohou být strukturně stejné, ale ne sémanticky.

Běžnou strategií pro omezení duplicitního kódu je vyčlenit společné části a skrýt je za abstrakci. Nežádoucím vedlejším efektem tohoto postupu je však spárování všeho, co abstrakci používá. Jakákoli změna v abstrakci ovlivní všechny její konzumenty. A stejně tak může být nutné abstrakci ohnout, aby vyhovovala požadavkům jen jednoho spotřebitele.

Toto zvýšení provázanosti s sebou nese také snížení flexibility. Řekněme, že máte proces, který se používá na třech místech. Na všech třech místech je téměř stejný, jen s několika důležitými rozdíly. Implementujete tedy proces jako jediný modul, který přebírá několik parametrů, aby pokryl rozdíly.

Vyladění procesu pouze pro jeden z těchto případů použití je nyní nemožné: jakákoli změna jednoho z nich ovlivní všechny tři. Jistě, můžete přidat další parametry (nebo speciální případy!), protože případy užití se liší. Ale rychle se stane nemožné odlišit důležité části procesu od infrastruktury oddělující případy užití.

Otázky, které je třeba si položit

Při refaktorizaci stávajícího kódu nebo psaní nového kódu, který může být potenciálně duplicitní, se ptám sám sebe:

Jedná se o jednu duplicitní znalost, nebo je to jen infrastruktura, která náhodou vypadá podobně?“

Takže jste se prohrabali CSS a našli jste třídu, která má náhodou požadované styly. To asi není dostatečně dobrý důvod, abyste se vyhnuli definování další třídy.

Kolikrát se tato věc opakovala?

Pokud se skutečně redundantní věc neobjeví alespoň třikrát, byl bych velmi skeptický k jakémukoli opakování-redukci, která zvyšuje složitost.

Ztíží nyní redukce duplicity přizpůsobení jednotlivých případů v budoucnu?“

Je něco uspokojivého na tom, když refaktorizujete hromadu kódu typu „kopíruj a vlož“ do něčeho přehlednějšího a znovu použitelného. Ale uzamknout kód tak pevně, že by jakákoli změna zavedla zvláštní případy, není dobrý kompromis.

Pokud tuto duplicitu zmenším, jaký je poměr mezi velikostí abstrakce a počtem parametrů, které bude vyžadovat?

Knihovny a frameworky jsou skvělé, protože poskytují znovupoužitelný kód s relativně malým počtem parametrů pro přizpůsobení. Představte si však funkci specifickou pro aplikaci pro zobrazení dialogového okna, která se rozrostla a nyní přijímá 20 parametrů. Jakákoli výhoda pro snížení opakování, která existovala, když měla 2 parametry, už neexistuje.

Závěr

Stejně jako u mnoha jiných zásad vývoje softwaru je „neopakuj se“ spíše vodítkem než mantrou.