új programozók, Üdvözöljük a szoftverfejlesztés iparában, anélkül, hogy egy évtizedes karriert kell befektetnie, hogy ezeket a tanulságokat nehéz módon megtanulja.
néhány dolgot csak tapasztalat útján lehet megtanulni. Elmondhatom, hogy ezek a dolgok fontosak, vagy hogy valóban megtörténnek az iparban, de lehet, hogy nem hisz nekem, amíg nem látja, hogy a saját karrierje során történnek. A döntés rajtad múlik, de itt vannak a tippek az Ön javára, ha úgy dönt, hogy megtanulja őket az egyszerű módon.
1. Az emberek készségei fontosak a programozók számára is
friss vagy az egyetemen. A fejed egy kert, ahol sok érdekes és kreatív dolgot ültetsz — elvégre életed végéig ott fogsz élni, miért ne? Vonakodsz beengedni az embereket, mert összetörhetik és tönkretehetik az összes kemény munkádat a saját különböző gondolkodásmódjukkal és dolgaikkal. Jó vagy az asszimilációban — új ötleteket keresel, lebontod és elemezed őket, majd beülteted őket a programozói agyad hatalmas adattárolójába. Ez nagyon jól jellemzi a legtöbb programozót,és engem is. Ha igen, akkor elég nagy kiigazítás vár rád.
az évtizedes számítógépes karrierem közel fele kellett ahhoz, hogy rájöjjek, hogy az emberekkel néha nehéz dolgozni, és hogy egy programozó munkája sokkal többet tartalmaz, mint pusztán a számítógépekkel való munka. Mielőtt számítógépekkel dolgozna, valakinek ki kell találnia, hogy valójában mire akarja költeni a pénzét — arra a pénzre, amellyel fizetnek. Amint rájönnek, sok időt töltenek a találkozókon, hogy megvitassanak bármit és mindent róla — mennyi ideig fog tartani, mi a helyes módja annak, hogy megtervezzék, és kit kell bevonni. Ezek a megbeszélések ritkán gyorsak vagy könnyűek, és ha már küzdesz a hatékony kommunikációval és meggyőzöd az embereket a meggyőződésedről, akkor nem lesz könnyebb, ha olyan technikai kifejezéseket kell használnod, amelyeket nem mindenki fog megérteni. Ha, mint a korábban leírt tipikus programozó, félénk vagy visszafogott, és nem szólal meg az értekezleteken, ez egy újabb akadály az utadban.
ezután dobja be a keverékbe azt a tényt, hogy nem mindenki könnyű kijönni, és van egy receptje a bajra. A legtöbb programozó már hiányzik az emberek készségeiből, ezért elképzelik azt az izgalmat, hogy csak számítógéppel dolgoznak, amit sokkal jobban megértenek, mint az emberek. Ahogy az előző bekezdés elmagyarázza, fordítva van. Tetszik vagy sem, sokkal több időt fog tölteni emberekkel, mint számítógépekkel. Mire végre felhúzza az ujját, és elkezdi “kódolni, mint a szél”, valószínűleg beteg lesz az üléseken, és fáradt lesz, hogy erőforrásként kezeljék, nem pedig a szakértelemért. Bár minden vállalat más, a barátságos, kényelmes vállalati kultúrával rendelkező vállalatokat nehéz megtalálni. Nem csak ez, de a dolgok napról napra változnak.
2. Szakértelem hatóság nélkül
nagyon gyakran az ötleteid arról, hogy mi lesz a hasznos szoftvermegoldás, drámaian ütköznek azoknak az embereknek az ötleteivel, akik ténylegesen meghozzák ezeket a döntéseket. Meg kell tudni élni, hogy a munka rettegett/unalmas projektek, és hogy a csomók, mint egy felnőtt. Fred Brooks a mitikus Emberhónapban ezt a szakértelmet tekintély nélkül hívta.
sokkal valószínűbb, hogy valaki másnak a 10 évvel ezelőtti rosszul megírt kódját tartja fenn, amelyet egy 3 órakor zümmögő személyhívó ébresztett fel a támogatási műszakban, mint hogy úgy döntött, hogy egy divatos új, teljes veremű webes alkalmazást ír az alapoktól kezdve, az összes lédús új eszközzel, amelyről olvasott és nyálas volt. Végül is az új eszközök drágák lehetnek, és általában nem te hozod a döntéseket.
persze, hülye ötlet egy egész gyepet kaszálni egy gyomnövénnyel. De amikor fűnyírót kér, és azt mondják ,hogy” nem”, akkor bedobhatja a törülközőt, vagy megteheti a gyomnövényt.
3. A kísérletezés természetes kíváncsisága elengedhetetlen
a szintaxis, a szemantika és a nyelv jó megértése — mint például az angol, a matematika vagy a mérnöki szakon — hosszú utat tesz ahhoz, hogy jó programozóvá váljon, de ez nem minden.
ennél nagyobb az, hogy nem fél kipróbálni dolgokat — gombokat nyomni — hibákat elkövetni — látni, mi történik. Kutakodj egy kicsit. Írj egy rossz kódot, és nézd, ahogy az arcára esik. Ez az elsődleges és legjobb módja annak, hogy megismerjük a számítógépeket. Ha másokra támaszkodik, hogy kitalálják az Ön számára, akkor csak korlátozza magát. Meg kell, hogy hajlandó kipróbálni magad, és tanulni az eredményekből, jó vagy rossz.
4. A fordító/számítógép abszolút tökéletességet igényel
Képzeld el, hogy nem tudsz e-mailt küldeni, amíg nem javít minden egyes nyelvtani hibát, hibásan írt szót és hiányzó vesszőt. Nevetségesen hangzik? A számítógép, mint a főnök, ez leírja minden e-mailt. Kivéve, hogy e-mail helyett egy számítógépes program írásáról beszélünk.
a tökéletesség elérése sok elkötelezettséget, motivációt és kitartást igényel — többet, mint sok ember. Lehet, hogy a leendő programozó nem elég motivált vagy kitartó ahhoz, hogy áttörje az akadályokat, hibákat, hibákat, 100 oldalas műszaki specifikációkat és hibakeresési kihívásokat, hogy végre elérje az abszolút tökéletesség utolsó lépését. Hosszú utat kell megtenni, különösen természetes kíváncsiság és nyelvi alkalmasság nélkül.
5. Az ötletek egyszerűek; a számítógépes programok összetettek
programozás közben arra utasítja a számítógépet, hogy tegyen valamit. A számítógép lehet tenni, hogy bármit lehet gondolni. Absztrakt gondolatokkal dolgozol-tiszta ötletekkel. Ez talán úgy hangzik, mint a mennyország, és minden bizonnyal vannak benne jó dolgok; de mint minden másnak, ennek is vannak hátrányai.
az ötletek gyakran nagyon egyszerűnek tűnnek. Egyetlen, az új ötlet elég egyszerűnek hangzik azoknak az embereknek, akik rendelkeznek a valós világ fogalmaival kapcsolatos intellektussal. A számítógépekből hiányzik ez a benne rejlő értelem, így még a legegyszerűbb ötlet is, amelyet számítógépes nyelvre fordítanak, gyorsan bonyolulttá válik. A megfelelő utasítások megtalálása még a szakértő, veterán programozók számára is nehéz feladat — különösen olyan dolgok esetében, amelyekre még nem került sor. És ha már megtörtént, miért nem vásárolja meg azt a programot, ahelyett, hogy újat írna? A programozó ideje drága-általában 30 dollár / óra vagy annál több. Ha EGY program felhasználónként 30 dollárba kerül, akkor ezt a programot általában véglegesen meg lehet vásárolni. Még akkor is, ha felhasználónként 300 dollárba kerül, ez még mindig sokkal olcsóbb, mint 30 dollár/óra.
6. Nem minden hiba hiba
sok új programozó megdöbbent, amikor először épít vagy fordít valamit, csak 50 piros jel, squiggly vonalak, vagy hibák és figyelmeztetések jelennek meg. Tovább ront a helyzeten, minden egyes hiba olyan rejtélyes ostobaság, mint például: “a nem statikus tag nem érhető el statikus kontextusból.”
tanácsom neked: pihenjen! Csak nyugodj meg egy pillanatra. Nem minden hiba hiba. Nem minden hiba a te hibád. Nem minden hibát kell azonnal kijavítani. Ezenkívül a hibák kijavíthatók.
a legtöbb modern kódszerkesztő annyira elfoglalt lesz a hibák megtalálásában, még mielőtt befejezné a kód beírását, hogy gyorsan lehetetlen feladatnak tűnhet a zárójelek megfelelő helyre helyezése. Ismét-csak nyugodj meg, lépj vissza, és rájössz, hogy nem olyan rossz, mint amilyennek látszik.
Több mint egy évtizede programozom, és nem hiszem, hogy egyszer írtam volna olyan programot, amely hibátlanul működött az első próbálkozáskor. Hibák lesznek a kódban! Szokja meg azt a gondolatot, hogy látja ezeket a bosszantó, piros, squiggly jeleket az egész helyen.
ezután a hiba nem feltétlenül hiba. Igen, a hibákat végül ki kell javítani, mielőtt futtathatja a programot. A hibák eltávolításának erőfeszítése azonban másodlagos a kódírás feladata mellett. Amint azt korábban említettük, a legtöbb szerkesztő ma már jóval a kód írása előtt megtalálja az összes lehetséges hibát. Ez nem teszi ezeket a hibákat fontosabbá, mint amit már csináltál. Ne hagyd, hogy elgáncsoljanak; meg fognak történni, ezért készülj fel, és tanuld meg tartani őket, amíg meg nem kapod a dolgokat. Ahogy megtanulsz úgy gondolkodni, mint egy számítógép, elkezded megérteni, hogy mely hibák fontosak, és amelyek csak hiányoznak a programodból, amelyeket még nem fejeztél be.
összefoglalva: piros, squiggly, és bosszantó (hiba) nem automatikusan lefordítani fontos.
7. Nincs hiba nem jelenti azt, hogy nincs hiba
képzelje el, hogy sok kemény munka után hátradől, elégedett azzal, hogy végre kijavította az összes bosszantó hibát. Most már mehetsz vidáman, igaz? Tévedés.
nem minden hiba hiba, és fordítva is igaz: a hibák hiánya nem feltétlenül a hibák hiánya. Csak azért, mert a kódnak nincs hibája, még nem jelenti azt, hogy megfelelően fog működni. Általában azt kell feltételeznie, hogy a kód nem fog megfelelően működni, még az összes hiba kijavítása után is.
a hibáknak két általános típusa van: fordítási hibák (piros, squiggly fajta), valamint futásidejű vagy logikai hibák. Ez utóbbi az, amiről most beszélünk.
mondjuk a kód ténylegesen fut. Ez azt jelenti, hogy a számítógép megérti és képes végrehajtani, de ez nem jelenti azt, hogy maguk az utasítások nem hibásak. Amit az agyad először kitalál, annak van értelme, de a számítógépnek általában több részletre van szüksége, mint az emberi agynak egy folyamat vagy algoritmus megértéséhez.
egy tökéletes példa a nullával való osztás. Ez a matematikai kifejezés nincs meghatározva, de a probléma nem nyilvánvaló, ha csak X-et osztunk y-vel. Csak akkor, ha a program fut, van Y valós értéke, amely lehet, hogy nem nulla.
8. Oldja meg a problémát, nem csak egy problémát
hibaelhárítás vagy hibakeresés során hihetetlenül könnyű összezavarodni abban, hogy mi is az igazi probléma valójában — a vezetékek keresztezése és órák produktív eltöltése, egy liba üldözése, amelynek semmi köze a tényleges problémához.
egyre jobb programozó sok köze van ahhoz, hogy képes gyorsan azonosítani a kiváltó oka a probléma—, majd kijavítani, hogy. Mint szeretném mondani, oldja meg a problémát.
a folyamat során gyakran találkozik kisebb, kapcsolódó problémákkal, amelyek szintén javításra szorulhatnak — probléma, de nem a probléma. Ne hátrálj csak azért, mert megoldottál valamit. Sok figyelmet igényel a probléma megoldása egészen a végéig.
a hibakeresést gyakran úgy gondolják, hogy 99% – ban megtörtént, a hibakereséshez szükséges idő nagy részében. Ez azért van, mert, amíg a kiváltó ok ténylegesen ismert, tudva, hogy mennyi ideig fog tartani, hogy rögzítse egy vitás vita. A kiváltó ok megtalálása önmagában gyakran sok időt vehet igénybe.
ezért ne feledje ezeket az egyszerű szabályokat a hibaelhárításhoz és a hibakereséshez:
a) mindig Teszteld a kódod
B) józanság ellenőrizze és érvényesítse mindent — különösen azokat a dolgokat, amelyekről úgy gondolja, hogy nincs rá szükség
C) próbálj meg nem “térd-bunkó” változtatásokat végrehajtani, véletlenszerű találgatás, hogy a hibát elhúzzák; ezek gyakran több problémát okoznak
D) Ezután ellenőrizze a
hibakeresés önmagában egyszerű bizonyíték arra, hogy a számítógépek vagy robotok soha nem fogják átvenni a világot. Mutass nekem egy számítógépet, amely képes hibakeresni magát, és megmutatom a világot, ahol nincs szükség programozókra.
9. A szoftverfejlesztés alapvető problémája
nem számít, milyen nagyszerű a program vagy a szoftver, valaki megtalálja a módját, hogy rosszul használja, mégis teljesen meg lesz győződve arról, hogy így kell működnie. Nem hiszel nekem? Fejlesszen ki néhány szoftvert, tegye közzé, és olvassa el a kapott megjegyzéseket és e-maileket. Hamarosan rájössz, hogy ez teljesen igaz.
mindenkinek megvan a maga módja. Egy méret soha nem fér el az összes, de sajnos az Ön számára, mint a programozó, Egy méret sokkal olcsóbb és hatékonyabb, mint három vagy négy méretben. Ritkán kap lehetőséget arra, hogy minden lehetséges funkciót megvalósítson — az összes harangot és sípot, amire gondolhat. Gyakran éppen az ellenkezője, amit a vezetés kér tőled. Azt akarják, hogy egy csupasz csontú, minimális életképes termék (MVP) tesztelje a koncepciót, és nézze meg, hogy tetszik-e az ügyfeleknek, és érdemes-e egyáltalán Megépíteni a teljes értékű verziót.
10. A technológia kiszámíthatatlan, mozgó célpont
időnként az emberek nem tudják eldönteni, mit akarnak – és meg kell birkózniuk a következményekkel, vagy akár fel kell takarítaniuk a rendetlenséget. Edward Berard így fogalmazott: “a vízen járás és a specifikációból származó szoftverek fejlesztése egyszerű, ha mindkettő fagyott.”Néha a követelmények megváltoznak a projekt közepén, és alkalmazkodnod kell, mintha egy autó motorján dolgoznál, miközben az autópályán vezetsz. Őrült, de igaz.
mire befejezte a projektet, előfordulhat, hogy elavulttá vagy feleslegessé válik. Lehet, hogy egy könyvtár vagy keretrendszer függ a frissített igényektől, és a vállalat nem akarja finanszírozni a frissítést. Lehet, hogy valóban eljuttatja az ügyfeleknek, és nem is akarják használni (láttam, hogy ez történik a saját projektemmel).
a technológia az emberek és más emberek, emberek és számítógépek, valamint a számítógépek és más számítógépek közötti sikeres interakciótól függ. Mind az emberek, mind a számítógépek kiszámíthatatlanok lehetnek, és ez a benne rejlő kiszámíthatatlanság nem fog eltűnni egyszerűen azért, mert azt akarja.
11. A becslés nehéz
a legérdekesebb és legértékesebb projektek általában azok, amelyek még soha nem készültek el. Mivel még soha nem tették meg, megbecsülni, hogy mennyi ideig fognak tartani, a frusztráció, a nehézség és a fájdalom sajátos pontja. A kiszámíthatatlanság (a fenti 10. pont) definíció szerint nehéz megjósolni!
az üzleti vezetők soha nem akarják hallani, mennyi ideig tart valami. Általában érdekli őket, hogyan lehet gyorsabban elvégezni, minimális költségvetéssel.
a programozók soha nem akarják hallani, hogy milyen kevés idő vagy kevés erőforrás lesz. Szabadidőre van szükségük az innovációra és a kutatásra. Drága új eszközökre van szükségük a gyorsabb és jobb kódoláshoz. A programozás egyenlő részben technikai és kreatív, és nem lehet siettetni anélkül, hogy elrontaná a végeredményt — de gyakran az. A futószalag csak olyan folyamattal működik, amely egyszerű, alig változik, és végtelenül megismételhető — ezek egyike sem vonatkozik a szoftverfejlesztésre. Úgy tűnik, hogy ez soha nem akadályozza meg a vezetőket abban, hogy megpróbálják futószalaggá tenni.
a becslési erőfeszítés az a soha véget nem érő csata, amelyre programozóként készülsz. Ennek a karrier-áttekintésnek a végén csak azt tudom mondani: ne felejts el nevetni és szórakozni. Lehet, hogy egyszer úgy találja,hogy a humor az, ami a végére jutott, ép elméjével.
P. S. A programozók most értékesebbek a vállalatok számára, mint a pénz. Ne légy túl kemény magaddal; a számítógép gondoskodik róla. Adj magadnak egy vállveregetést, amiért érdekel egy ilyen nehéz, mégis kifizetődő szakma.