Kam hasur në pjesën time të kodit të shkruar bukur, të mbinxhiruar ... një moment unë jam duke menduar “Kjo është një mënyrë interesante për ta bërë atë” dhe minuta tjetër ju jeni duke menduar “Çfarë dreqin po ndodh këtu!”. të Parimi (You Are Not Gonna Need It) është një mënyrë e mirë për të kundërshtuar over-engineering: funksionalitetet duhet të zbatohen vetëm kur ju keni nevojë për to, jo mbi mundësinë që ju do të keni nevojë për to. Tani YAGNI Tani Në terma shumë të thjeshtë, inxhinieria e tepërt është duke e bërë dizajnin e softuerit / sistemit më kompleks se sa është e nevojshme; kjo zakonisht ndodh sepse ju doni të shtoni funksionalitet shtesë në komponentin tuaj për të thjeshtuar zbatimin e A, vetëm për të shtuar funksionalitetin për B më vonë. Ne kemi këtë bazë kodash për menaxhimin e ftesave; është një bazë kodash e trashëguar, e trashëguar me borxhe teknike që rrit interesin. Sa më shumë që përpiqeni të punoni në kodin e trashëguar, aq më shumë diçka diku tjetër thyhet. Ju duhet të ktheheni në shumicën e rasteve dhe të filloni të gjithë. Punimi rreth kodit të trashëguar përfundon duke grumbulluar interes në borxhin teknik; Në fillim, kjo dukej si një Hail Mary. Më në fund, ne mund të punonim në këtë bazë kodesh të thyera me efekte anësore minimale. Zgjidhja e tretë që erdhëm me ishte abstraktimi. Ne duhej të gjejmë mënyra për të moduluar karakteristika të reja ose përmirësime në aplikacion Kur bashkëpunoni me shumë njerëz në një bazë kodi (që është pothuajse gjithmonë rasti), dhe për korporatat që janë më të interesuar në veçoritë e transportit sesa në cilësinë e kodit, rishikimet e kodit gjithmonë vuajnë. Për probleme si over-engineering dhe overabstraction, Rishikimet tradicionale të kodit linjë pas linje shpesh humbasin këto probleme sistematike. Ju kontrolloni një komponent të krijuar disa javë më parë për të mbështetur integrimin e një veçori, duke ndjekur parimin DRY, dhe kuptoni se tani ka 10 veçori të ndërlidhura / të ngjashme që varen nga komponenti. Rishikimet e kodit do të duhet të ngrihen për të kapur këto çështje arkitektonike dhe për të siguruar që kërkesat e varësisë midis komponentëve janë përmbushur. Spaghetti me kod të thatë Ne jetojmë me ungjillin DRY (Mos përsëris veten) sepse thjeshton punën, dhe zhvilluesit janë në thelb dembelë (në një mënyrë të mirë). parimi DRY punon mirë me sistemet orthogonal: komponentët e vegjël, të vetë-mbajtur të kombinuar për të formuar një sistem. . Sistemet duhet të përbëhen nga një grup modulesh bashkëpunimi, secila prej të cilave zbaton funksionalitetin e pavarur nga njëra-tjetra. Alıntılar - Programi pragmatik: nga udhëtari në mjeshtër Kitap.Guru. Duhet të ketë më shumë theks në sistemet ortogonale dhe në kodin DRY; është më e lehtë të kombinoni funksionet e ripërdorshme që krijoni me njëri-tjetrin dhe t'i shkallëzoni ato ndërsa depoja përparon kur ato nuk janë të fryrë dhe të abstraktuara, në këtë pikë ju përfundoni me një sistem të ngurtë të ndërthurur aq shumë me njëri-tjetrin që do të jetë e komplikuar të lidhni cilat aspekte të kodit që nuk plotësojnë një rregull të saktë, ju do të gjeni veten duke kopjuar kodin sepse duke e bërë atë të punojë për një lidhje të re thyen një sistem të vjetër. Komponente komplekse Komponentët tuaj nuk duhet të përqëndrohen vetëm në shmangien e përsëritjes, por edhe në të qenë abstrakcione të vogla të sistemit të përgjithshëm; përndryshe, ju do të përfundoni me komponente aq komplekse që ata mund të thyejnë lehtësisht me një ndryshim të vetëm në një komponent të lidhur. Kur krijoni kod të ripërdorshëm, qasja duhet të jetë të shkruani kodin që nuk varet nga asnjë bllok tjetër i kodit për të funksionuar në një mënyrë të caktuar. Reusability duhet të përdoret si një mjet dhe jo qëllimi; kur keni komponentë të ripërdorshëm të UI me logjikën e biznesit ose API në të njëjtën komponentë, ju jeni në një autostradë për mbivlerësim. Fillon pak, dhe para se të kuptoni se çfarë po Modelet për të shmangur abstraksionin e tepërt dhe inxhinierinë e tepërt Modularizëm Modularizëm Modularizëm Modulariteti përfshin thyerjen e sistemit tuaj në kodet më të vogla, të pavarura/komponente të quajtura module. Ju lutemi të kushtoni vëmendje për fjalën ‘më të vogla’; është e mundur të keni një modul të fryrë me më shumë kod se sa është e nevojshme, e cila krijon abstraksion të tepërt dhe duhet të shmanget. Abstraksioni i tepërt është me të vërtetë vetëm një përpjekje e pasuksesshme për modularitet. Modulet tuaja duhet të jenë në gjendje të funksionojnë pavarësisht nga modulet e tjera, duke ekspozuar vetëm të dhënat e kërkuara. Ndryshimet në kodin e mirë, modular, të strukturuar duhet të ndikojnë vetëm në modulet, pa ndonjë efekt kaskad. Funksionaliteti i parë Një qasje e mirë për të ndërtuar sisteme ortogonale dhe për të shmangur lehtë abstraksionin e tepërt është të ndërtohet me funksionalitetin e parë, pastaj me karakteristikat; kjo përputhet mirë me Arkitekturën e Bazuar në Komponente (ndarja e komponentëve të UI nga komponentët shtetërorë). Faza e funksionalitetit do të përqendrohet në njësitë më të vogla të ripërdorshme të kodit që janë mbledhur për të zbatuar funksionalitetin. Asnjë medalje për kodin e sofistikuar Pas shkrimit të çdo zbatimi të kodit, pyesni veten nëse ekziston një mënyrë më e lehtë ose më e thjeshtë për të arritur të njëjtin rezultat. Shumica prej nesh kanë dëgjuar histori për kodin që mund të redaktohet ose punohet nga vetëm një person në kompani, gjë që nuk është një arritje për të qenë krenar. Një ish-punonjës i një kompanie është i njohur për të mos kontrolluar kodin dhe për të pasur programe dhe pjesë të bazës së kodit në hard drive e tij (imagjinoni mbi kokën për mirëmbajtjen e atij produkti!). “Ne u larguam nga kolonat” - Baza më e mirë, më e keqe e kodit nga Jimmy Miller Kam gjetur veten duke shkruar kod tepër të sofistikuar sepse dua të përdor një teknologji të re / paketë / bibliotekë që sapo kam mësuar për, pa marrë parasysh nëse është mjeti më i thjeshtë për punën. Finale Në kërkimin për të shkruar kodet e përsosura që përcaktojnë të gjitha rastet e mundshme të së ardhmes dhe të udhëtimit në kohë, ju përfundoni me një bazë të kodit të mbingarkesuar. Ju duhet të hiqni dorë nga kjo sepse nuk është e mundur të shkruani kodin e përsosur, qëllimi për të mirë të mjaftueshme që i plotëson të gjitha kërkesat tuaja të menjëhershme. Parimi DRY është themelor; përsëritja është ende një mëkat në zhvillimin e softuerit. Parimi DRY duhet të aplikohet në një sistem ortogonal për të krijuar një bazë kodesh që është e ndarë, me çdo modul të pavarur dhe shkëmbimin e të dhënave në një pikë të veçantë takimi (moduli i karakteristikës). Këto do t'ju ndihmojnë të
