Aš susidūriau su savo dalimi gražiai parašyto, pernelyg inžinerinio kodo ... vieną akimirką aš galvoju „Tai įdomus būdas tai padaryti“, o kitą minutę jūs klausiate „ką čia velniškai vyksta!“ Aš taip pat kenčia nuo pernelyg inžinerinio kodo rašymo, kur jūs galvojate taip toli į ateitį, kad jūs kompromituojate. • The (Jums to nereikės) principas yra geras būdas kovoti su pertekline inžinerija: funkcijos turėtų būti įgyvendinamos tik tada, kai jums jų reikia, o ne dėl galimybės, kad jums jų reikės. Dabar YAGNI Dabar Labai paprastais žodžiais tariant, pernelyg inžinerija daro programinės įrangos / sistemos dizainą sudėtingesnį nei būtina; tai paprastai atsitinka todėl, kad norite pridėti papildomų funkcijų į savo komponentą, kad supaprastintumėte A įgyvendinimą, tik pridėti B funkcionalumą vėliau. Mes turime šią kodo bazę kvietimams valdyti; tai yra paveldima, paveldima kodo bazė su techninėmis skolomis, kurios didina palūkanas. Kuo daugiau jūs bandote dirbti su paveldėtu kodu, tuo daugiau kažkas kitur sulaužoma. Daugeliu atvejų turite grįžti ir pradėti viską. Darbas aplink paveldėtą kodą baigiasi susidomėjimu techninės skolos duomenimis; iš pradžių tai atrodė kaip „Hail Mary“. Galiausiai, mes galime dirbti su šiomis funkcijomis visoje programoje arba pridėti daugiau techninės skolos prie kodo bazės. Trečiasis sprendimas, su kuriuo mes susidūrėme, buvo abstrakcija. Turėjome išsiaiškinti būdus, kaip moduliuoti naujas funkcijas ar tobulinti program Kai bendradarbiaujama su keliais žmonėmis kodų pagrindu (tai beveik visada būna), o korporacijoms, kurios labiau domisi funkcijų pristatymu nei kodo kokybe, kodo peržiūros visada kenčia. Dėl problemų, tokių kaip pernelyg inžinerija ir pernelyg abstrakcija, Tradicinės eilutės po eilutės kodo peržiūros dažnai praleidžia šias sistemingas problemas. Jūs tikrinate komponentą, sukurtą prieš porą savaičių, kad palaikytų funkcijos integraciją, laikydamiesi DRY principo, ir suprantate, kad dabar yra 10 tarpusavyje susijusių / panašių funkcijų, kurios priklauso nuo komponento. Špinatai Dry Code Mes gyvename pagal DRY (nepakartoti savęs) evangeliją, nes ji supaprastina darbą, o kūrėjai iš esmės yra tingūs (geru būdu). DRY principas gerai veikia su ortogoninėmis sistemomis: maži, savarankiški komponentai sujungiami, kad sudarytų sistemą. . Sistemas turėtų sudaryti bendradarbiaujančių modulių rinkinys, kurių kiekvienas įgyvendina funkcionalumą nepriklausomai vienas nuo kito Alıntılar - Pragmatinis programuotojas: nuo keliautojo iki meistro. Reikėtų daugiau dėmesio skirti ortogonalioms sistemoms ir DRY kodui; lengviau sujungti pakartotinai naudojamas funkcijas, kurias sukuriate tarpusavyje, ir juos išplėsti, kai saugykla progresuoja, kai jos nėra išsipūsusios ir pernelyg abstrakčios, taigi jūs galų gale susiduriate su kieta sistema, susipynusia tiek tarpusavyje, kad bus sunku susieti, kurie kodo aspektai neatitinka tikslios taisyklės, jūs atsidursite dubliuojant kodą, nes tai, kad jis veikia naujam ryšiui, sulaužys seną sistemą. Sudėtingas komponentas Jūsų komponentai turėtų sutelkti dėmesį ne tik į pasikartojimo išvengimą, bet ir į tai, kad jie yra nedideli visos sistemos abstrakcijos; kitaip jūs galų gale turėsite komponentų, kurie yra tokie sudėtingi, kad jie gali lengvai nutraukti vieną pakeitimą į susietą komponentą. Kurdami pakartotinai naudojamą kodą, požiūris turėtų būti kodo rašymas, kuris nepriklauso nuo bet kokio kito kodo bloko, kad veiktų tam tikru būdu. Pakartotinis naudojimas turėtų būti naudojamas kaip įrankis, o ne tikslas; kai turite pakartotinai naudojamų UI komponentų su verslo ar API logika tame pačiame komponente, esate kelyje į pernelyg didelę abstrakciją. Jis prasideda mažai, ir kol jūs suprantate, Šablonai, kad būtų išvengta pernelyg abstrakcijos ir pernelyg inžinerijos Moduliavimas Moduliavimas Moduliavimas Moduliavimas Moduliavimas Modularumas apima jūsų sistemos suskaidymą į mažesnius, nepriklausomus kodus / komponentus, vadinamus moduliais. Prašome atkreipti dėmesį į žodį „mažesnis“; galima turėti išsipūsusį modulį su daugiau kodo nei būtina, o tai sukuria pernelyg abstrakciją ir turėtų būti vengiama. Pernelyg abstrakcija iš tikrųjų yra tik nesėkmingas bandymas moduliarumo. Jūsų moduliai turėtų galėti veikti nepriklausomai nuo kitų modulių, atskleidžiant tik reikiamus duomenis. Pirmiausia funkcionalumas Geras būdas kurti stačiakampes sistemas ir lengvai išvengti pernelyg abstrakcijos yra kurti su funkcionalumu pirmiausia, tada funkcijomis; tai gerai atitinka komponentų pagrindu pagrįstą architektūrą (atskiriant UI komponentus nuo valstybinių komponentų). funkcionalumo etapas bus sutelktas į mažiausius pakartotinai naudojamus kodo vienetus, surinktus funkcijai įgyvendinti. Prisijungimo funkcija susidės iš šių funkcijų: rinkti naudotojo vardą ir slaptažodį (UI), patvirtinti naudotojo duomenis, nukreipti į naudotojo profilį / atmesti surinktus naudotojo duomenis. Nėra medalių už pernelyg sudėtingą kodą Po kiekvieno kodo įgyvendinimo rašymo paklauskite savęs, ar yra lengvesnis ar paprastesnis būdas pasiekti tą patį rezultatą.Dauguma iš mūsų girdėjo istorijas apie kodą, kurį gali redaguoti ar dirbti tik vienas asmuo įmonėje, o tai nėra pasididžiavimas.Rašyti kodą, kurį galite išlaikyti tik jūs, greičiausiai reiškia, kad jis yra pernelyg sudėtingas arba naudoja netradicines procedūras. Buvęs įmonės darbuotojas yra žinomas dėl to, kad nekontroliuoja kodo ir turi programų ir kodo bazės dalių savo kietajame diske (įsivaizduokite, kad šis produktas išlaikomas!). „Mes išbėgo iš stulpelių“ - Jimmy Miller geriausia, blogiausia kodo bazė Aš atsidūriau rašydamas pernelyg sudėtingą kodą, nes noriu naudoti naują technologiją / paketą / biblioteką, apie kurią ką tik sužinojau, nesvarstydamas, ar tai yra paprasčiausias įrankis darbui. Galutinis Siekdami parašyti tobulą kodą, kuris atspindi visus galimus ateities ir laiko kelionių atvejus, jūs galiausiai susiduriate su pernelyg inžinerine kodo baze. Turėtumėte atsisakyti, nes neįmanoma parašyti tobulo kodo, siekti pakankamai gero, kad atitiktų visus jūsų tiesioginius reikalavimus. DRY principas yra esminis; kartojimas vis dar yra programinės įrangos kūrimo nuodėmė. DRY principas turėtų būti taikomas stačiakampėje sistemoje, kad būtų sukurta kodo bazė, kuri yra atskirta, o kiekvienas modulis yra nepriklausomas ir keičiasi duomenimis atskirame susitikimo taške (funkcijos modulis). Tai padės jums sukurti sistemas, kurias lengva prižiūrėti ir ištaisyti. Atminkite
