A fordító előszava: A cikk elolvasása után meglepődhet, vagy akár dühös is lehet. Igen, mi is meglepődtünk: a szerző állítólag soha nem hallott a csapatban fellépő hierarchiáról, a „gyorsan és okoskodás nélkül” státuszú feladatok felállításáról. Igen, ez így van, ez egy kicsit furcsa szöveg. Valóban, a szerző azt javasolja, hogy a programozó vegye fel a rendszertervező szerepét – akkor miért van szükség építészre? Mindezek az ellenvetések azonban nem vakíthatják el Önt a fő dolog előtt - miért vettük át és fordítottuk le ezt a szöveget. Nem a szerepekről beszél. Ez a szöveg a szakmai megközelítésről és tudatosságról szól. Az igazság az, hogy amíg csak „azt csinálod, amit mondanak” anélkül, hogy átgondolnád a tetteid értelmét, soha nem leszel nagy programozó.
Mondj nemet a felesleges kódra. Nincs más dolgod, mint összerakni három betűt, és kimondani a szót. Próbáljuk meg ezt együtt: "Neeeee!"
De várj. Miért csináljuk ezt? Hiszen a programozó fő feladata a kód írása. De meg kell írnod bármilyen kódot, amit kérnek tőled? Nem! „Egy programozó számára valószínűleg a legfontosabb készség annak megértése, hogy mikor nem szabad kódot írni.” .
Emlékeztetünk: a "Habr" minden olvasója számára - 10 000 rubel kedvezmény, ha a "Habr" promóciós kóddal bármely Skillbox tanfolyamra jelentkezik.
A Skillbox a következőket ajánlja: Gyakorlati tanfolyam .
A programozás a problémamegoldás művészete. És ti vagytok ennek a művészetnek a mesterei.
Néha, hogy a lehető leggyorsabban elkezdhessük a munkát, nem gondolunk másra, mint az adott feladat elvégzésére. Ez pedig még komolyabb problémákat okozhat.
Mire hunynak szemet a programozók?
Minden írt kódnak érthetőnek kell lennie más fejlesztők számára, és tesztelni és hibakeresést kell végezni.
De van egy probléma: bármit is írsz, az bonyolítja a szoftveredet, és valószínűleg hibákat fog bevezetni a jövőben.
Rich Skrent szerint . Íme, amit ír:
„A kód rossz, mert rothadni kezd, és folyamatos karbantartást igényel. Új funkciók hozzáadásához gyakran szükséges a régi kód módosítása. Minél nagyobb, annál nagyobb a valószínűsége a hiba előfordulásának, és annál több időt vesz igénybe a fordítás. Egy másik fejlesztőnek több időbe telik, hogy kitalálja. Ha pedig refaktorálásra van szükség, akkor biztosan lesznek olyan töredékek, amin érdemes változtatni. A nagy kód gyakran csökkenti a projekt rugalmasságát és funkcionalitását. Egy egyszerű és elegáns megoldás gyorsabb, mint az összetett kód.”
Honnan tudod, hogy mikor ne írj kódot?
A probléma az, hogy a programozók gyakran eltúlozzák az alkalmazásuknak szükséges funkciók számát. Ennek eredményeként a kód számos része befejezetlen marad, vagy senki sem használja őket, de bonyolítják az alkalmazást.
Világosan meg kell értenie, mire van szüksége a projektjének, és mire nem.
Példa erre egy olyan alkalmazás, amely egyetlen feladatot – az e-mailek kezelését – old meg. Ebből a célból két funkció került bevezetésre - levelek küldése és fogadása. Nem szabad elvárnia, hogy a levélkezelő egyúttal feladatkezelő is legyen.
Határozottan „nem”-et kell mondania az olyan funkciók hozzáadására vonatkozó javaslatokra, amelyek nem kapcsolódnak az alkalmazás fő feladatához. Pontosan ez az a pillanat, amikor világossá válik, hogy nincs szükség további kódra.
Soha ne veszítse el az alkalmazás fókuszát.
Mindig kérdezd meg magadtól:
— Milyen funkciót kellene most megvalósítani?
- Milyen kódot írjak?
Kérdezze meg az eszébe jutó ötleteket, és értékelje a kívülről érkező javaslatokat. Ellenkező esetben az extra kód egyszerűen megölheti a projektet.
Ha tudja, mikor ne adjon hozzá felesleges dolgokat, az segít a kódbázis szilárd ellenőrzése alatt tartani.
Az útvonal legelején a programozónak csak két vagy három forrásfájlja van. Ez egyszerű. Az alkalmazás összeállítása és elindítása minimális időt vesz igénybe; Mindig világos, hogy hol és mit kell keresni.
Az alkalmazás bővülésével egyre több kódfájl jelenik meg. Megtöltik a katalógust, mindegyik több száz sorral. Mindezek helyes megszervezéséhez további könyvtárakat kell létrehoznia. Ugyanakkor egyre nehezebb emlékezni arra, hogy mely funkciók miért felelősek, és mely cselekvések okozzák ezeket; a hibák elkapása is több időt vesz igénybe. A projektmenedzsment is egyre bonyolultabb, nem egy, hanem több fejlesztőnek kell mindent nyomon követnie. Ennek megfelelően a költségek – mind pénzben, mind időben – nőnek, a fejlesztési folyamat pedig lelassul.
A projekt végül hatalmassá válik, és minden új funkció hozzáadása egyre több erőfeszítést igényel. Még valami nagyon jelentéktelen dologra is több órát kell töltenie. A meglévő hibák kijavítása új hibák megjelenéséhez vezet, és a pályázatok megjelenési határideje elmarad.
Most meg kell küzdenünk a projekt életéért. Miért?
A helyzet az, hogy egyszerűen nem értette, mikor nem szabad extra kódot hozzáadni, és minden javaslatra és ötletre igennel válaszolt. Vak voltál, az új dolgok létrehozásának vágya arra késztetett, hogy figyelmen kívül hagyd a fontos tényeket.
Úgy hangzik, mint egy horrorfilm forgatókönyve, igaz?
Pontosan ez fog történni, ha továbbra is igent mondasz. Próbáld megérteni, mikor nem szabad kódot hozzáadni. Távolítsa el a felesleges dolgokat a projektből – ez nagyban megkönnyíti az életét, és meghosszabbítja az alkalmazás élettartamát.
„Az egyik legproduktívabb napom az volt, amikor 1000 kódsort töröltem.”
– Ken Thompson.
Nehéz megtanulni, mikor ne írjunk kódot. De szükséges.
Igen, tudom, hogy most lépett a fejlesztő útjára, és szeretne kódot írni. Jó, ne veszítsd el az első benyomást, de a lelkesedés miatt se veszítsd szem elől a fontos tényezőket. Mindenre rájöttünk próbálgatással. Ön is követ el hibákat, és tanul belőlük. De ha tudsz tanulni a fentiekből, akkor tudatosabb lesz a munkád.
Folytasd az alkotást, de tudd, mikor mondj nemet.
A Skillbox a következőket ajánlja:
- Jelentkezett online tanfolyam .
- Online tanfolyam .
- Gyakorlati évfolyam .
Forrás: will.com