fejlesztőként gyakran hallunk közhelyes kifejezéseket, amelyeket úgy dobálnak, mint “ne ismételje meg magát”. Ilyen ötleteket veszünk, és futunk velük, néha egy kicsit túl messzire.

a visszalépés és annak értékelése, hogy miért tesszük ezeket a dolgokat, hasznos. Tehát ma nézzük meg a száraz programozás alternatív ideológiáját.

A DRY meghatározása (a Wikipedia szerint) a következő:

minden tudásnak egyetlen, egyértelmű, hiteles ábrázolással kell rendelkeznie egy rendszeren belül.

néhány ez lehet, hogy egy kicsit pedáns, de ez hasznos lehet, ha figyelembe vesszük valami ilyesmi. Bontsuk le a megfogalmazás részeit.

minden darab

mi az a “minden darab”? Soha nem ismételhetjük meg a változó nevét? HTML entitás?

Ok, ok. Tehát megismételhetjük <div>‘s-t sok probléma nélkül, és nem hiszem, hogy bárki megsértené. De ez felveti a kérdést-mikor döntjük el, hogy valami “tudásdarab”lett? A Reactben jó példa lehet egy komponens-de ez a PrimaryButton és a SecondaryButton vagy általánosított Button osztály? A választ általában úgy tekintik, hogy” bármit is választ a szervezete”, de ez még mindig jó kétértelműséget hagyhat az elvont mellett.

tudás

Ez egy másik kétértelmű pont – mit határozunk meg tudásként? Vegyünk egy stílusú gombelemet néhány atomosztály használatával, és reagáljunk. Ha egy idősebb fejlesztőnek 10 másodpercbe telik a létrehozása, akkor nem biztos, hogy ezt a tudást érdemes elvonatkoztatni. De egy fiatalabb fejlesztőnek, aki nem ismeri jól a rendszert, ez a tudás jó absztrakció lehet. Ellenkező esetben le kell vadászniuk az osztályokat, emlékeztetniük kell magukat a gombok működésére, és ki kell találniuk a onClickszintaxisát. A tudás relatív, és a definícióban való használata kétértelműséget ad.

frissítés: Xander a következő megjegyzést hagyta alább. Úgy gondolom, hogy ez a cikk nagyszerű munkát végez annak elmagyarázásában, hogy mit jelent a “tudás”.

csak azt akartam, hogy hagyja ezt itt az emberek, akik érdeklődnek.

“a száraz a tudásról szól, a kódmásolás nem a kérdés.”
verraes.net/2014/08/dry-is-about-k…

egyetlen, egyértelmű, hiteles ábrázolás

az “egyetlen” ábrázolás sok kívánnivalót hagy maga után. A devops mérnökének véleménye szerint egyetlen reprezentáció lehet egy teljes alkalmazás, amelyet telepíteni kell. Egy frontend dev számára ez lehet egy összetevő. Egy backend dev számára ez lehet egy osztály vagy egy API végpont metódusa. Hol húzódik a vonal?

megvan az “egyértelmű” szó is – de amint az imént rámutattam, a mondat többi része több kétértelműséget határoz meg. A” mérvadó ” – nak van értelme-a száraz kódnak pontosan meg kell határoznia, hogy mit csinál, és hűnek kell lennie ehhez a definícióhoz. Ez azonban nem korlátozódik kifejezetten a száraz kódra.

rendszer

végül megvan a világ “rendszere” – ez visszatér az” egyetlen ” állításhoz, amelyet egy másodperccel ezelőtt tárgyaltunk. Mi az a”rendszer”? A React, lehet, hogy egy komponens vagy Redux akció / komponens / szűkítő. A konténeres szoftverekben egy egész pod-ról vagy csak egyetlen példányról beszélhetünk.

a nap végén a DRY all to gyakran elősegíti az előzetes optimalizálást, ami szükségtelen, és néha valóban károsítja a kódírás képességét. Néha nehezebb módosítani egy elvont összetevőt, hogy illeszkedjen egy adott felhasználási esethez. Sok bonyolultságot ad hozzá, vagy az összetevőt valami újra bontja – ami nem szuper száraz. Az első napon nem ismerheti az alkatrész minden Használati esetét.

alternatív-írj mindent kétszer (nedves) programozás

ehelyett nedves programozást javasolok. Számomra a meghatározás a következő lenne:

felteheti magának a kérdést: “nem írtam ezt korábban?”kétszer, de soha háromszor.

ezzel a meghatározással a fókusz eltávolodik a korai optimalizálástól, és lehetővé teszi a hasonló kód néhányszor történő megismétlését. Ez a fókuszt egy bélreakcióra is áthelyezi. Ez lehetővé teszi, hogy a pontos felhasználási eset alapján döntéseket hozzon. Ha webes alkalmazást épít, akkor valószínűleg el akarja vonni a gombokat egy összetevőbe, mert sokat fog használni. De ha van egy oldal, amely valamilyen speciális stílussal rendelkezik (talán egy árképzési oldal?), akkor nem kell túl sokat aggódnia az adott oldal összetevőinek kivonása miatt. Valójában ebben a rendszerben, ha szüksége van egy új oldalra, amely hasonló volt az adott speciális oldalhoz, egyszerűen másolhatja/beillesztheti és megváltoztathatja a szükséges kódot. Abban a pillanatban azonban, amikor ez harmadszor történik, ideje eltölteni egy kis időt az elvonatkoztatható részek kivonásával.

ezt a kikötést is hozzáadnám (mind a nedves, mind a száraz programozáshoz):