A Habr tele van előrejelzésekkel és tanácsokkal arról, hogy mit tegyünk a következő évben — mely nyelveket tanuljuk, milyen területekre térjünk át, hogyan bánjunk az egészségünkkel. Inspirálóan hangzik! De bármilyen érmének két oldala van, és nemcsak az új dolgokkal botlunk meg, hanem leginkább abban, amit minden nap csinálunk. "Hogyhogy senki nem figyelmeztetett rám!" — mondjuk dühösen, általában magunknak. Kihívjuk a tüzet magunkra — összegyűjtöttük nektek azt a listát, amit 2020-ban NEM szabad megtenni (vagy talán soha).
De a gravitációt nem kérdezték meg.
Nagyon szeretnénk rangsorolni az ellenjavaslatokat a legfontosabbtól a legkevésbé jelentősig. De annyira elterjedtek, egyenrangúak és szinte mindenki számára ismertek, hogy zavaros sorrendben fogunk írni. Na, nézzük meg a listát?
Ne menj IT-be, ha minden rendben van.
Ne tanulj új technológiát, hogy szakmát változtass, vagy újrakezdd. Az időnk csodálatos abban, hogy tanulhatunk, váltogathatunk munkát, gyökeresen megváltoztathatjuk a területet — ezt csinálhatjuk egészen nyugdíjig. Ez egy klassz, csábító dolog. De ha több mint 28-30 éves vagy, nem érdemes mindent feladni azért, hogy IT-be lépj, vagy átállj egy új technológiára (például, ha magas terhelésű rendszereket írsz Java-ban, és hirtelen úgy döntesz, hogy átváltasz Python-ra a neurális hálózatokon). Az ok egyszerű: nehéz lesz. Először is, nagy a verseny a szakemberek között, akik már a karrierjük kezdetén ebben a stackben dolgoznak, másodszor, újra junior leszel alacsony bérért, harmadszor, lelkileg nehéz lesz alacsonyabb szintű főnök lenned. Tehát, ha másik irányba akarsz haladni, próbálj meg ezt a jelenlegi munkád és feladataid keretein belül tenni, vagy fejleszd az új ismereteket mint hobbi, építs pet-projektet, hogy ne junior legyél, amikor új munkát keresel.
A technológiai stacket váltogatni — csak időpazarlás.
Ne ingadozz a technológiai stackek között a fejlesztésed során. Ha egy nyelven írsz egy projektet, egy bizonyos keretrendszert és könyvtárakat használsz, akkor nem érdemes mindent az ördögbe dobni és Dart-ra átírni, csak mert érdekesnek tűnik. Tedd szokásoddá, hogy indokolás nélkül nem váltogatsz technológiát — nemcsak a "szeretném-nem tudom" szinten, hanem pénzügyi és mérnöki szempontból is.
Nem szükséges ragaszkodni a saját álláspontodhoz és megbékélni.
Ragaszkodni egy nyelvhez vagy technológiához, és nem tanulni újakat, éppolyan szélsőség, mint minden új technológia megjelenésére váltani. Mindig tanulj meg új könyvtárakat és keretrendszereket, ne legyél makacs azzal a gondolattal, hogy mindent már régen kitaláltak előtted, és csak te tökéletesítetted. Gyakorlatilag minden nyelvhez folyamatosan érkeznek frissítések, amelyek néha jelentősen javíthatják a projektedet. Ne légy lusta figyelemmel kísérni a technológiai könyvtárad fejlődését, és amikor találsz valami menőt és hasznosat, bátran vedd be a projektbe!
A saját fejed jó, mindig jó.
Ne mások fejével gondolkodj, a saját jobb. Sajnos, vannak fejlesztők, akik ülnek, és várják, hogy megkapják a jelentést a kódolásra az előző hibától a végéig, anélkül hogy megpróbálnának valami sajátot hozni a projektbe, új funkciót fejleszteni, tesztelni és ajánlani a gyártásba. Miért fáradnál, amikor van a csapatvezető vagy a cég vezetőjének gondolkodása, aki mindent eldönt helyetted? Ha magadra ismertél, akkor rossz híreim vannak: a passzív hozzáállás sem a karrierednek, sem a fejlődésednek nem fog jót tenni. Van lehetőséged kipróbálni magad fejlesztőmérnökként, nem csak kóderként egy igazi projektben, és megérteni, hová kellene haladnod, mi hiányzik, de inkább az idődet valami másra költenéd, és pontosan „ettől eddig” dolgozol. Az ilyenek a mai informatikában egyre rosszabbul élnek, lépj ki az anabiózisból.
A felhasználók ijesztő emberek.
Ne túlbecsüld a szoftvered felhasználóit: ha nem programozók számára írsz, számíts arra, hogy a program megbízhatatlan félreértésekkel fog szembesülni. Az első néhány napban vagy hétben a felhasználó utálni fogja a szoftvered, mert „a régi nem volt ennyire buta”. Ennek elkerülése érdekében készíts nagyszerű dokumentációt és oktatási anyagokat. Telepítés vagy vásárlás során nagyon nyomatékosan utalj rá, hogy a kézikönyveket érdemes elolvasni a program használata előtt, nem pedig a hibák, a jelszó elvesztése és az önkontroll után.
A felhasználókat sem érdemes lebecsülni: okosabbak, ügyesebbek és kíváncsibbak, mint gondolnád. Ha azt hiszed, hogy az a hiba a változó formátumával és az Enter 138. megnyomásakor fellépő kivétel nem fog megjelenni, tévedsz – meg fog jelenni, és a legfurcsább módon befolyásolja az alkalmazásod működését. A dilettánsok szabálya működik: ők a legjobb tesztelők. De a felhasználóknak valamilyen oknál fogva nem tetszik, ha hibákat találnak a termelési környezetben – semmi IT-s szolidaritás. Általában minél biztosabb vagy a szoftveredben, annál jobb. Végül is jobb késleltetni néhány funkció kiadását, mint bekerülni a működő alkalmazásba, és hirtelen nyersebbé tenni azt.
Elég a guglizásból!
Ne csak a Google-hoz fordulj. Még csak vitatkozni sem fogunk arról, hogy a fejlesztés terén sok mindent megtalálhatsz közvetlen kereséssel. Minél mélyebbre ásol az információkeresésben, annál több „oldalsó” adatot kapsz és annál többet tanulsz, mert új dolgokat fedezel fel, amelyek nem kapcsolódnak a kérdésedhez, de valószínűleg hasznosak lesznek a jövőben. Használj teljes körű anyagokat, könyveket, cikkeket stb. A nyelveknek és a könyvtáraknak vannak specifikációik, közösségek, útmutatók, és így a legmegbízhatóbb módon fejlesztheted programozói készségeidet – egyszerűen olvasd a dokumentációt, és ne máshol keress helyi megoldásokat vagy kódrészleteket. Mi van, ha a te megoldásod hatékonyabb, gyorsabb és jobb?
Bízz, de ellenőrizz!
Ne használj harmadik féltől származó könyvtárakat és keretrendszereket anélkül, hogy ellenőriznéd a kódot, és ne igazítsd azokat a saját céljaidhoz. Nincs okuk vakon megbízni egy olyan kód szerzőjében, akit egyáltalán nem ismersz. Igen, a különböző szándékos rosszindulatú elemek a külső kódban nem túl gyakoriak, és nem érdemes paranoidnak lenni, de a kész szoftverdarabok vak másolás a projektedbe előre nem látható következményekhez vezethet. Ezért mindenképpen olvasd el és elemezd a kódot a használat előtt, és végezz tesztelést a kód implementálása után.
Hogy elkerüljük az olyan helyzeteket, amikor szükség lesz rá:
Ne hagyja abba a mentéseket, vagy ne tárolja őket ugyanazon harmadik félnél, ahol a projektje hosztolva van. Viccesnek és feleslegesnek tartja ezt a tanácsot? Pedig több mint 700 résztvevő a Telegram csoportban, akik nemrégiben egy ismert adatközpont leállásával kapcsolatos kellemetlen helyzetbe kerültek, nem így gondolták – ott mindenféle dolog akadt: a pet projektektől kezdve a nagy állami weboldalakig és a vállalati 1C és billing adatbázisokig. Jelentős része – backup nélkül vagy a backupok ott. Tehát osztozzon a kockázatokon, és tárolja a backupot legalább az alap hosztoláson, egy megbízható VDS-en és a saját helyi szerverén. Végül sokkal olcsóbb lesz.
Elég a saját érdekei miatt kínozni a projektet
Ne azt csinálja a munkahelyi projektben, amit Ön szeret, hanem azt, amire a klienseknek szükségük van. Igen, őrülten érdekes és nagyszerű saját neurális hálózatot létrehozni, betanítani és beépíteni a szoftverébe, de ha az ügyfelei egy egyszerű kapcsolattartó menedzserre vágynak, az csak fölösleges költséget jelent. Nézze meg, hogyan működik a projekt, olvassa el a dokumentációt, tekintse át az ügyfél visszajelzéseit és kéréseit, és valósítsa meg azt, ami üzleti értéket ad a projektnek. Ha valami tudományos vagy rendkívül bonyolultat szeretne létrehozni, kezdje a saját projektjével.
Nem kód, hanem idegcsomó
Ne írjon olvashatatlan és dokumentálatlan kódot. Ismerjük ezt a trükköt: a fejlesztő úgy írja a kódot, ahogy csak a lelke kívánja, szándékosan kicsit összezavarja, hogy senki kollégája ne tudja megérteni, amit írt – ez egyfajta megelőző bosszú légyott előtt. Azonban nemcsak a céget (amely pénzt fizet Önnek a munkáért), hanem saját magát is kockázatnak teszi ki: valószínű, hogy Ön sem fog emlékezni arra, mit akart mondani ezzel a nem szándékos obfuszkálással. Ugyanez a helyzet a dokumentálatlan kóddal: ha a változók és funkciók elnevezése logikájára és a jó memóriájára hagyatkozik, pár év múlva nem emlékezhet rá, miért választotta ezt a ciklust, metódust, mintát stb. A kód dokumentálása és jó struktúrája nagyszerű szolgáltatás a kollégák, a munkaadó és elsősorban saját magunk számára.
Tartsd egyszerűen, hülye
Ne bonyolítsd a kódot, a megoldásokat és a projekteket. Nincs szükség bonyolult struktúrák létrehozására és jelentéktelen entitások szaporítására. Minél bonyolultabb a kódod, annál inkább a rabjává válsz — nagyon nehéz lesz karbantartani és továbbfejleszteni. Természetesen a híres KISS-elv („Keep it simple, stupid”) nem mindig alkalmazható, de nem véletlenül létezik: a kód egyszerűsége és eleganciája a sikeres alkalmazás és újrahasználás kulcsa.
Védje magát
Ne hagyja figyelmen kívül a biztonságot — 2020-ban ez szó szerint bűncselekmény. Akkor is, ha a vállalata, a fejlesztése és Ön nem érdekes a rossz szándékúak számára, akkor is érintheti Önöket például egy hálózati szegmens meghibásodásával, egy hosting szolgáltató támadásával, egy adatközpont elleni támadással, e-mail jelszavak ellopásával és a munkavállalók biztonságtalan viselkedésével, akik adatokat lophatnak a cégtől, ügyfeleket vihetnek el vagy ellophatják a projekt forráskódját. Ha ezt a hatáskörébe tartozik, próbálja meg megvédeni azokat a projekteket, amelyekkel dolgozik. Továbbá, tartsa be az információbiztonságot is, ez még senkinek sem ártott.
Ne köpj a kútba
Ne rombold le a munkáltatódat. Napjainkban a kommunikáció olyan szinten áll, hogy például az összes HR-es városias módon ismerheti egymást, és bármilyen információt megoszthatnak chatcsoportokban és zárt csoportokban (mint például segítséget nyújtani az elhelyezkedéshez, vagy megírni, hogy „Vasiliy Ivanov, rendszermérnök, távozása előtt megölte az összes fiókot, törölte a biztonsági másolatokat, és lekapcsolta a hálózatot, a helyreállítás 3 napig tartott. Ne vegyétek fel!”). Így a viselkedésed kifejezetten ellened fog játszani — és néha még a másik városba vagy fővárosba költözés sem segít. Még ha dühösen távozol is, nincs jobb bosszú, mint hasznos és nagyszerű munkavállalóvá válni a versenytársaknál 🙂 A legfontosabb pedig, hogy mindez teljesen következmények nélküli.
Ezt sem érdemes csinálni. De a tapasztalat azt mutatja, hogy nem hagyunk fel vele
De egyébként, barátok, olvassátok a tanácsokat, de úgy tegyetek, ahogyan a legjobbnak látjátok — hiszen a valódi felfedezések akkor történnek, amikor kételkedünk a már felfedezett igazságokban. Boldog új évet kívánunk, legyenek sikeresek a projektjeitek, izgalmas a karrieretek, normálisak a kollégák és a vezetők, és az élet általában sikeres. Szóval, egy új évre és egy új kódra!
Szeretettel,
a RegionSoft Developer Studio csapata
Az új évben továbbra is önökért fogunk dolgozni és egy erőteljes asztali CRM rendszert fejleszteni. és egy egyszerű és kényelmes helpdesk és jegykezelő rendszert. .
Forrás: habr.com
