Našel jsem svůj podíl krásně napsaného, nadměrně inženýrského kódu... Jednou jsem si myslel „To je zajímavý způsob, jak to udělat“ a v další minutě se divíte „co se tady děje!“ Také jsem trpěl psaním nadměrně inženýrského kódu, kde přemýšlíte tak daleko do budoucnosti, že kompromitujete. • The Princip (You Are Not Gonna Need It) je dobrým způsobem, jak bojovat proti nadměrnému inženýrství: funkce by měly být implementovány pouze tehdy, když je potřebujete, ne na možnosti, že je budete potřebovat. Nyní YAGNI Nyní Velmi jednoduše řečeno, nadměrné inženýrství dělá design softwaru/systému složitějším, než je nezbytné; to se obvykle děje proto, že chcete přidat další funkčnost do své součásti, abyste zjednodušili implementaci A, pouze abyste později přidali funkčnost pro B. Máme tuto kódovou základnu pro správu pozvánek; je to zděděná, zděděná kódová základna s technickým dluhem, která zvyšuje úroky. Čím více se snažíte pracovat na zděděném kódu, tím více se něco někde jinde rozbije. Musíte se ve většině případů obrátit a začít všude. Práce kolem zděděného kódu končí nahromaděním zájmu o technický dluh; Na začátku se to zdálo jako Hail Mary. Konečně můžeme pracovat na této mangled kódové základně s minimálními vedlejšími účinky. Třetí řešení, které jsme přišli s, bylo abstrakce. Museli jsme najít způsoby, jak modulovat nové funkce nebo vylepšení aplikace a vystavit a sdí Při spolupráci s více lidmi na bázi kódu (což je téměř vždy případ), a pro korporace, které se více zajímají o přepravní funkce než o kvalitu kódu, vždy trpí recenze kódu. Pro problémy, jako je nadměrné inženýrství a nadměrná abstrakce, tradiční recenze kódu řádek za řádkem často chybí tyto systematické problémy. Zkontrolujete komponent vytvořený před několika týdny, aby podpořil integraci funkce, podle principu DRY, a uvědomíte si, že nyní existuje 10 vzájemně propojených / podobných funkcí, které závisí na komponentu. Recenze kódu budou muset být zvýšeny, aby zachytily tyto architektonické problémy a zajistily, že jsou splněny požadavky na závislost Špagety Dry Code Žijeme podle evangelia DRY (Don’t Repeat Yourself), protože zjednodušuje práci a vývojáři jsou v podstatě leniví (dobrým způsobem). . Systémy by se měly skládat ze souboru spolupracujících modulů, z nichž každý implementuje funkčnost nezávisle na sobě. Alıntılar - Pragmatický programátor: Od cestovatele po mistra Kitap.Guru. Měl by být kladen větší důraz na ortogonální systémy a na kód DRY; je snazší kombinovat funkce pro opakované použití, které vytváříte navzájem a rozšiřovat je, když úložiště postupuje, když nejsou nafouklé a nadměrně abstraktní, v tomto bodě skončíte s tuhým systémem tak vzájemně propojeným, že bude obtížné propojit, které aspekty kódu, které nesplňují přesné pravidlo, zjistíte, že duplikujete kód, protože jeho fungování pro nové připojení narušuje starý systém. Komplexní složka Vaše komponenty by se neměly soustředit pouze na vyhýbání se opakování, ale také na to, že jsou malými abstrakcemi celkového systému; jinak skončíte s komponenty tak složitými, že mohou snadno přerušit jedinou změnu na připojenou komponentu. Při vytváření opakovatelného kódu by měl být přístup psaní kódu, který nezávisí na žádném jiném bloku kódu, aby fungoval určitým způsobem. Opětovné použití by mělo být používáno jako nástroj a ne cíl; když máte opakovatelné komponenty rozhraní uživatele s obchodní nebo API logikou ve stejné komponentu, jste na silnici k nadměrné abstrakci. Začíná malý a předtím, než si uvědomíte, co se děje, onemocnění se roz Způsoby, jak se vyhnout nadměrné abstrakci a nadměrnému inženýrství Modularita Modularita Modularita Modularita Modularita zahrnuje rozdělení vašeho systému na menší, nezávislé kódy/komponenty zvané moduly. Prosím, věnujte pozornost slovu „menší“; je možné mít nafouklý modul s více kódem, než je nutné, což vytváří nadměrnou abstrakci a mělo by být zabráněno. Nadměrná abstrakce je opravdu jen neúspěšným pokusem o modularitu. Vaše moduly by měly být schopny fungovat nezávisle na jiných modulech, pouze vystavovat požadované údaje. Změny v dobrém, modulárním, strukturovaném kódu by měly ovlivnit pouze moduly, bez jakýchkoliv kaskádových účinků. První funkce A good approach to building orthogonal systems and easily avoiding over-abstraction is to build with functionality first, then features; this aligns well with Component-Based architecture(separating UI components from stateful components). The functionality stage will focus on the smallest reusable units of code that are assembled to implement the feature. A Login feature will consist of the following functions: collect username and password (UI), validate user data, redirect to the user profile/reject collected user data. Each functionality should operate independently, relying only on necessary data. Žádné medaile za přehnaně sofistikovaný kód Po psaní každé implementace kódu se zeptejte sami sebe, zda existuje jednodušší nebo jednodušší způsob, jak dosáhnout stejného výsledku.Většina z nás slyšela příběhy o kódu, který může být upraven nebo zpracován pouze jednou osobou ve společnosti, což není úspěch, na který byste měli být hrdí.Psaní kódu, který může být udržován pouze vámi, pravděpodobně znamená, že je příliš sofistikovaný nebo používá neortodoxní postupy. Bývalý zaměstnanec společnosti je známý tím, že nekontroluje kód a že má programy a části kódu na svém pevném disku (představte si, že je nutné tento produkt udržovat!). “We ran out of columns” - The best, worst codebase by Jimmy Miller Zjistil jsem, že píšu příliš sofistikovaný kód, protože chci použít novou technologii / balíček / knihovnu, o které jsem se právě dozvěděl, aniž bych přemýšlel o tom, zda je to nejjednodušší nástroj pro práci. finále V hledání psaní dokonalých kódů, které odrážejí všechny možné případy budoucnosti a cestování časem, skončíte s nadměrně inženýrskou kódovou základnou. Měli byste to vzdát, protože není možné psát dokonalý kód, zaměřit se na dost dobré, které splňuje všechny vaše bezprostřední požadavky. Princip DRY je zásadní; opakování je stále hříchem ve vývoji softwaru. Princip DRY by měl být aplikován na ortogonální systém, aby se vytvořila kódová základna, která je odpojena, s každým modulem nezávisle a výměnou dat na samostatném místě setkání (funkční modul). Tyto vám pomohou vytvořit systémy, které jsou snadno udržitelné a vyřešitelné. Nezapomeňte, že jednoduché je
