A központ tele van előrejelzésekkel és tanácsokkal, hogy mit tegyél a következő évben – milyen nyelveket tanulj, milyen területekre koncentrálj, mit kezdj az egészségeddel. Inspirálóan hangzik! De minden éremnek két oldala van, és nem csak valami újdonságba botlunk, hanem leginkább abban, amit nap mint nap csinálunk. „Miért nem figyelmeztetett senki!” – kiáltunk fel ingerülten, általában magunk felé fordulva. Szívjuk magunkra a tüzet – összeállítottunk egy listát arról, hogy 2020-ban (és talán mindig) mit NE tegyünk.
De nem kérdeztek a gravitációról
Nagyon szeretnénk rendbe tenni az ellenjavaslatokat, a legfontosabbtól a legkevésbé fontosig. De annyira gyakoriak, egyenértékűek és szinte mindenki számára ismerősek, hogy véletlenszerűen írjuk le. Nos, nézzük a listát?
Nem kell informatikára menni, ha minden rendben van
Ne tanulj meg új technológiát a karrierváltáshoz vagy az újrakezdéshez. A mi időnk csodálatos, mert lehet tanulni, munkahelyet váltani, gyökeresen szakterületet váltani – és így tovább, akár nyugdíjba vonulásig. Klassz, csábító dolog. De ha elmúltál 28-30, akkor ne adj fel mindent, hogy belépj az informatikába, vagy új verembe lépj (például erősen terhelt rendszereket írsz Java nyelven, és hirtelen úgy döntesz, hogy Pythonban neurális hálózatokba lépsz). Az ok egyszerű: nem lesz könnyű neked. Először is, nagy a verseny a szakemberek között, akik pályafutásuk kezdete óta „ülnek” ezen a veremön, másodszor, alacsony fizetéssel újra juniornak kell lenni, harmadszor pedig morálisan nehéz lesz a hierarchia legalsó szintjének alárendeltjévé váljon. Ezért ha más irányba szeretnél elmozdulni, akkor vagy a jelenlegi munkádhoz és jelenlegi feladataidhoz igazodva próbáld megtenni, vagy hobbiként új ismereteket szerezni, indíts egy kisállat projektet, hogy amikor új munkahelyre kerülsz ne legyen többé junior.
A verem egymás után cseréje csak időpocsékolás
Ne rohanjon a technológiai halmok között a fejlesztés érdekében. Ha egy nyelven írunk egy projektet, egy bizonyos keretrendszer és könyvtárak használatával, akkor ne dobjunk mindent a pokolba, és írjuk át Dartban csak azért, mert érdekesnek találjuk. Legyen szabály, hogy indoklást kell találni a technológia megváltoztatására – nem csak a „akarom vagy nem tudom” szinten, hanem pénzügyi és mérnöki szinten is.
Nincs szükség arra, hogy megállja a helyét és bronzé váljon
Ragaszkodni egy nyelvhez vagy technológiához, és nem tanulni új dolgokat, ugyanolyan szélsőséges, mint minden új technológiával megváltoztatni a halmot. Ügyeljen arra, hogy tanulmányozza az új könyvtárakat és keretrendszereket, ne makacskodjon abban a tudatban, hogy mindent jobb, ha Ön előtt talált ki, és kizárólag Ön fejezte be. Szinte minden nyelvhez folyamatosan jelennek meg frissítések, amelyek néha nagymértékben javíthatják a projektet. Ne légy lusta figyelni a stacked dinamikáját, és amint találsz valami klassz és hasznos dolgot, nyugodtan húzd be a projektbe!
A saját fejed jó, mindig jó
Ne gondolkodj mások fejében, a sajátod jobb. Sajnos egyes fejlesztők ülnek és várnak, amíg nem kapnak egy feladatot az előző hiba kódolásához, anélkül, hogy megpróbálnának saját magukkal hozzájárulni a projekthez, új funkciót fejleszteni, tesztelni és élesre ajánlani. Miért baj, ha van egy csapatvezető vagy cégvezető, aki mindenről maga dönt? Ha felismered magad, akkor rossz hírünk van: a passzív pozíció nem segít sem a karrieredben, sem a fejlődésedben. Lehetőséged van kipróbálni magad fejlesztőmérnökként és nem kódolóként egy igazi harci projektben, és megérted, merre indulj el, mi hiányzik, de szívesebben töltöd az idődet valami mással, és pontosan "innentől" Most." Az ilyen emberek egyre rosszabbul élnek túl a modern informatikában, kijönnek a felfüggesztett animációból.
A felhasználók szörnyű emberek
Ne becsülje túl szoftvere felhasználóit: ha nem programozóknak ír, számítson arra, hogy a program áthatolhatatlan félreértésbe ütközik. Az első napokban vagy hetekben a felhasználó utálni fogja a szoftverét, mert „a régi nem volt olyan hülye”. Ennek elkerülése érdekében készítsen nagyszerű dokumentációkat és oktatóanyagokat. Telepítéskor vagy vásárláskor nagyon tolakodóan utaljon arra, hogy a kézikönyveket a programmal való munka megkezdése előtt érdemes elolvasni, és nem az adatbázis összeomlása, a jelszó elvesztése és az önkontroll után.
Nem szabad alábecsülni a felhasználókat sem: ravaszabb, okosabb és kíváncsibb, mint gondolná. Ha úgy gondolja, hogy a változó formátumú hiba és az Enter 138. másodpercenkénti lenyomására vonatkozó kivétel nem jelenik meg, akkor téved – felbukkannak, és a legfurcsább módon befolyásolják az alkalmazás működését. Az amatőr szabály érvényes: ő bírja a legjobban a tesztelést. De valamiért a felhasználók nem szeretnek hibákat találni a termelésben – nincs bennük IT szolidaritás. Általánosságban elmondható, hogy minél magabiztosabb a szoftverében, annál jobb. Végül is jobb késleltetni egyes funkciók kiadását, mint hozzáadni őket egy működő alkalmazáshoz, és hirtelen nyersvé tenni.
Hagyd abba a guglizást!
Ne fordulj egyedül a Google-hoz. Nem is vitatkozunk - a fejlesztés területén sok mindent megtalálhat egy keresőmotorhoz intézett közvetlen kéréssel. Minél mélyebbre ás az információkeresésben, annál több „oldalsó” adatot kap, és annál többet fog megtudni, mert valami újat fog megtudni, ami nem kapcsolódik a kéréséhez, de valószínűleg a jövőben szükség lesz rá. Hivatkozzon a teljes értékű anyagokra, könyvekre, cikkekre stb. A nyelveknek és a könyvtáraknak vannak specifikációi, közösségei, módjai, így Ön a legmegbízhatóbb módot kapja a programozói készségek fejlesztésére – csak olvassa el a dokumentációt, és ne keresse mások helyi megoldásait és kódrészleteit. Mi van, ha az Ön megoldása optimálisabb, gyorsabb és menőbb?
Bízz, de ellenőrizze,
Ne használjon külső fejlesztők által létrehozott könyvtárakat és keretrendszereket anélkül, hogy ellenőrizné a kódot, és nem igazította volna a céljainak megfelelően. Nincs okod feltétel nélkül megbízni ebben a kódszerzőben, akit egyáltalán nem ismersz. Igen, a harmadik féltől származó kódok különböző szándékos rosszindulatú elemei nem olyan gyakoriak, és nem kell paranoiában szenvednie, de a szoftver kész részeinek vak másolása a projektbe beláthatatlan következményekkel járhat. Ezért használat előtt feltétlenül olvassa el és elemezze a kódot, majd a kód implementálása után tesztelje.
Készítsen biztonsági másolatot!
Ne készítsen biztonsági másolatot, és ne tartsa azokat ugyanazokon a harmadik féltől származó szervereken, ahol a projektet tárolják. Szerinted ez nevetséges és haszontalan tanács? De a Telegram több mint 700 csevegő résztvevője, akik a közelmúltban kellemetlen helyzetbe kerültek egy jól ismert adatközpont leállásával, nem így gondolta – volt ott minden: a kisállat-projektektől a nagy kormányzati webhelyekig. hatóságok és vállalati 1C és számlázási adatbázisok. Jelentős része mentés nélkül, vagy ugyanott található. Tehát oszd meg a kockázatokat, és tárold a biztonsági másolatot legalább a fő tárhelyen, néhány megbízható VDS-en és a helyi szerveren. Hosszú távon sokkal olcsóbb lesz.
Ne hozd a sajátodat a projekt rovására
Egy munkaprojektben ne azt csináld, amit szeretnél, hanem azt, amire az ügyfeleknek szüksége van. Igen, hihetetlenül érdekes és nagyszerű saját neurális hálózatot létrehozni, betanítani és beépíteni a szoftverébe, de ha ügyfeleinek egyszerű kapcsolatkezelőre van szükségük, ez túlzás. Tekintse meg, hogyan működik a projekt, olvassa el a dokumentációt, olvassa el az ügyfelektől érkező véleményeket és kéréseket, és valósítsa meg azt, ami üzleti értéket fog hozzáadni a projekthez. Ha valami tudományos vagy rendkívül összetettet szeretne létrehozni, kezdje el saját projektjével.
Nem egy kód, hanem egy köteg ideg
Ne írjon olvashatatlan és nem dokumentált kódot. Ismerjük ezt a trükköt: a fejlesztő tetszés szerint ír kódot, szándékosan kicsit összekeverve, hogy egyik kollégája se értse, amit írt – ez egyfajta megelőző bosszú, mielőtt valami történik. Ezzel azonban nemcsak a céget (amely pénzt fizet a munkájáért), hanem saját magát is kockáztatja: valószínű, hogy maga sem fog emlékezni arra, hogy mit akart ezzel a nem szándékos elhomályosítással mondani. Ugyanez a helyzet a nem dokumentált kóddal: a változó és függvény elnevezési logikájára és a jó memóriájára hagyatkozva pár év után nem biztos, hogy eszébe jut, hogy miért választotta az adott ciklust, metódust, mintát stb. A kód dokumentálása és jó felépítése nagy szolgálatot tesz kollégáinak, munkáltatójának, de legfőképpen önmagadnak.
Legyen egyszerű, hülye
Legyen egyszerű kódja, megoldásai és projektjei. Nincs szükség bonyolult szerkezetbe kerítésre és különösebb jelentősége nélküli entitások előállítására. Minél összetettebb a kódja, annál inkább lesz a túsza – a lehető legnehezebb lesz fenntartani és fejleszteni. Természetesen a híres KISS-elv („Keep it simple, stupid”) nem mindig megfelelő, de okkal jött létre: a kód egyszerűsége és eleganciája a kulcs a sikeres alkalmazáshoz és újrafelhasználáshoz.
Védd magad
Ne hagyja figyelmen kívül a biztonságot – 2020-ban ez a szó szoros értelmében bűncselekmény. Még ha cége, fejlesztése és Ön nem is érdekli a támadókat, akkor is érinthetik Önt bizonyos hálózati szegmensek, tárhelyszolgáltatók legyőzésével, az adatközpont elleni támadásokkal, az e-mail jelszavak ellopásával és az alkalmazottak nem biztonságos viselkedésével kapcsolatos problémák. ellopni az adatokat a cégtől, ellopni az ügyfeleket vagy a teljes projekt programkódját. Ha ez az Ön hatáskörében és szakterületén belül van, próbálja meg védeni azokat a projekteket, amelyeken dolgozik. Nos, figyeljen maga az információbiztonságra, ez soha senkit nem zavart.
Ne köpj a kútba
Ne szórakozzon a munkáltatójával. Mára a kommunikáció elérte azt a szintet, hogy például a városban a HR-esek távollétében ismerik egymást, és chaten és zárt csoportokban bármilyen információt kicserélhetnek (mind az álláskeresést segítik, mind a „Vaszilij Ivanov, rendszerépítész, mindent megölt, mielőtt elhagyta a fiókokat, törölte a biztonsági másolatokat és kikapcsolta a hálózatot, a helyreállítás 3 napig tartott. Ne alkalmazza őt." Így viselkedése kizárólag Ön ellen fog hatni – és néha még az sem segít, ha átköltözik egy másik városba vagy fővárosba. Még ha haraggal távozol is, nincs jobb bosszú, mint egy versenytárs hasznos és menő alkalmazottjává válni :) És ami a legfontosabb, teljes büntetlenül.
Ezt sem szabadna tenned. De a tapasztalatok szerint nem állunk meg
Általában véve, barátaim, olvassátok el a tanácsokat, de tegyétek azt, amit a legjobbnak gondoltok – elvégre igazi felfedezések születnek, amikor kételkedünk a már felfedezett igazságokban. Boldog új évet, legyen sikeres a projektje, legyen kellemes a karrierje, legyen megfelelő kollégái és vezetői, és általában sikeres legyen az élete. Általánosságban elmondható, hogy itt az új év és az új kód!
Szeretettel,
RegionSoft Developer Studio csapata
Az új évben továbbra is az Ön számára dolgozunk, és egy hatékony asztali CRM rendszert fejlesztünk valamint egy egyszerű és kényelmes help desk és jegyrendszer .
Forrás: will.com