Habr este plin de prognoze și sfaturi despre ce să faci în anul următor — ce limbi să înveți, în ce domenii să te orientezi, cum să ai grijă de sănătatea ta. Sună inspirator! Dar orice monedă are două fețe, iar noi ne împiedicăm nu doar în lucruri noi, ci, în majoritatea cazurilor, în cele pe care le facem în fiecare zi. „De ce nu m-a avertizat nimeni!”, exclamăm iritat, de obicei către noi înșine. Ne asumăm riscuri — am compilat pentru voi o listă cu ceea ce NU ar trebui să faceți în 2020 (sau poate și întotdeauna).
Dar gravitația nu a fost întrebată
Ne-ar plăcea foarte mult să ordonăm aceste anti-recomandări de la cele mai importante la cele mai puțin semnificative. Dar ele sunt atât de răspândite, echivalente și familiarizate încât vom scrie haotic. Ei bine, să vedem lista?
Nu trebuie să intri în IT dacă totul este bine
Nu învățați o nouă tehnologie doar pentru a vă schimba profesia sau a începe de la zero. Timpul nostru este minunat deoarece permite învățarea, schimbarea locului de muncă, schimbarea radicală a domeniului — și asta chiar până la pensie. Este o chestie faină și tentantă. Dar dacă aveți mai mult de 28-30 de ani, nu ar trebui să renunțați la tot doar pentru a intra în IT sau a schimba tehnologia (de exemplu, scrieți sisteme cu încărcare mare în Java și brusc decideți să treceți la rețele neuronale în Python). Motivul este simplu: vă va fi greu. În primul rând, concurența este mare din partea specialiștilor care „sunt” pe această tehnologie încă de la începutul carierei lor, în al doilea rând, va trebui să deveniți din nou junior cu un salariu mic, iar în al treilea rând, va fi moral greu să deveniți subalternul celui mai de jos nivel din ierarhie. Prin urmare, dacă doriți să mergeți într-o altă direcție, încercați să faceți acest lucru fie în cadrul muncii actuale și al sarcinilor actuale, fie dezvoltați noi cunoștințe ca un hobby, dezvoltați un proiect personal pentru a veni la un nou loc de muncă deja nu ca junior.
Schimbarea tehnologiilor cu alte tehnologii — doar pierdere de timp
Nu oscilati între tehnologiile pentru dezvoltarea voastră. Dacă scrieți un proiect într-o limbă, folosiți un anumit framework și biblioteci, nu ar trebui să renunțați la tot și să rescrieți pe Dart, doar pentru că vi s-a părut interesant. Faceți un obicei din a găsi o justificare pentru schimbarea tehnologiei — nu doar la nivelul „vreau-nu pot”, ci și la nivel financiar și ingineresc.
Nu trebuie să insiști și să te împotmolești.
A te împotrivi unui singur limbaj sau tehnologie și a nu învăța lucruri noi este o extremă, la fel ca și schimbarea stivei cu fiecare nouă tehnologie. Asigură-te că studiezi noi biblioteci și cadre, nu fi încăpățânat în convingerea că tot ceea ce este mai bun a fost inventat înaintea ta și rafinat exclusiv de tine. Practic, pentru fiecare limbaj ies constant actualizări, care pot îmbunătăți semnificativ proiectul tău. Nu te lenevi să urmărești dinamica stivei tale și, de îndată ce găsești ceva grozav și util, încorporează-l în proiect!
Capul tău este bun, mereu este bine.
Nu gândi cu capul altora, al tău este mai bun. Din păcate, unii dezvoltatori stau și așteaptă să le vină o sarcină de codare de la eroarea precedentă până la final, fără a încerca să aducă ceva de-al lor în proiect, să dezvolte o nouă funcție, să testeze și să propună în producție. De ce să te obosești, când există capul team leader-ului sau al managerului care decid totul? Dacă te-ai recunoscut, avem vești proaste: o poziție pasivă nu te va ajuta nici în carieră, nici în dezvoltare. Ai șansa să îți încerci forțele ca inginer-dezvoltator, nu ca programator într-un proiect real și să înțelegi încotro să te îndrepți, ce îți lipsește, dar preferi să îți petreci timpul cu altceva și să faci exact „de la x la y”. Cei care sunt așa în IT-ul actual supraviețuiesc din ce în ce mai greu, ieși din anabiotic.
Utilizatorii sunt oameni înfricoșători.
Nu supraestima utilizatorii software-ului tău: dacă nu scrii pentru programatori, așteaptă-te ca programul să întâmpine o neînțelegere insurmontabilă. În primele câteva zile sau săptămâni, utilizatorul va urî software-ul tău, pentru că „vechiul nu era atât de prost”. Pentru a evita acest lucru, fă o documentație grozavă și materiale de instruire. La instalare sau achiziție, subliniază foarte insistent că manualele ar trebui citite înainte de a începe să lucreze cu programul, nu după prăbușirea bazei de date, pierderea parolei și autoreglementarea.
Nu subestima utilizatorii: sunt mai inteligenți, mai ingenioși și mai curioși decât credeți. Dacă credeți că acel bug legat de formatul variabilei și excepția de la apăsarea a 138-a pe Enter cu un interval de o secundă nu va apărea, vă înșelați — va apărea și va afecta funcționarea aplicației dumneavoastră în cele mai ciudate moduri. Se aplică regula începătorului: tocmai el se descurcă cel mai bine la testare. Dar utilizatorilor nu le place, dintr-un motiv sau altul, să descopere bug-uri în producție — nu există nici o solidaritate IT în asta. În general, cu cât ești mai sigur de software-ul tău — cu atât mai bine. În cele din urmă, e mai bine să întârzii lansarea unor funcții decât să le adaugi într-o aplicație în funcțiune și să o faci brusc nefuncțională.
Încetați să căutați pe Google!
Nu te limita doar la Google. Nici nu o să mai discutăm — în domeniul dezvoltării, căutând direct pe motorul de căutare poți găsi foarte multe informații. Cu cât te scufunzi mai adânc în căutarea informațiilor, cu atât mai multe date „laterale” vei obține și vei învăța mai multe, deoarece vei descoperi ceva nou nelegate de cererea ta, dar probabil necesar în viitor. Consultă materiale complete, cărți, articole etc. Limbajele și bibliotecile au specificații, comunități, ghiduri, astfel obții cea mai fiabilă modalitate de a-ți dezvolta abilitățile de programator — citind documentația, nu căutând soluții locale și fragmente de cod de la alții. Și poate soluția ta va fi mai optimizată, mai rapidă și mai bună?
Încrede-te, dar verifică
Nu utiliza biblioteci și cadre realizate de dezvoltatori terți fără să verifici codul și să-l adaptezi pentru obiectivele tale. Nu ai motive să ai încredere necondiționată în acel autor de cod, pe care nu-l cunoști deloc. Da, elementele dăunătoare intenționate în codul terț nu apar foarte des și nu trebuie să suferi de paranoia, dar copierea oarbă a părților de software gata făcute în proiectul tău poate duce la consecințe imprevizibile. Prin urmare, asigură-te că citești și analizezi codul înainte de utilizare și efectuezi teste după implementarea codului.
Realizați backup-uri!
Opriți-vă din a nu face backup-uri sau a le stoca pe aceleași servere externe pe care se găsește proiectul dumneavoastră. Credeți că este un sfat amuzant și inutil? Dar mai mult de 700 de participanți dintr-un grup de Telegram care s-au confruntat cu o situație neplăcută recent, legată de oprirea unui cunoscut data center, nu au fost de aceeași părere — a fost tot felul: de la proiecte mici la site-uri mari ale agențiilor guvernamentale și baze de date corporative 1C și de billing. O parte semnificativă — fără backup-uri sau cu backup-uri acolo. Așa că dispersați riscurile și păstrați un backup cel puțin pe principalul hosting, pe un VDS de încredere și pe serverul dumneavoastră local. În cele din urmă, va fi mult mai ieftin.
Basta cu a vă sacrifica proiectul.
Nu faceți în proiectul de lucru ceea ce doriți, ci faceți ceea ce au nevoie clienții. Da, este extrem de interesant și grozav să creați propriul model de rețea neuronală, să-l antrenați și să-l implementați în software-ul dumneavoastră, dar dacă clienții dumneavoastră au nevoie de un simplu manager de contacte, atunci va fi un lux costisitor. Uitați-vă cum funcționează proiectul, citiți documentația, citiți recenziile și cererile clienților și implementați ceea ce va adăuga valoare de afaceri proiectului. Dacă doriți să creați ceva științific sau deosebit de complex, începeți cu propriul proiect.
Nu cod, ci un ghem de nervi.
Nu scrieți cod ilizibil și nedocumentat. Ne este cunoscută această metodă: dezvoltatorul scrie codul cum îi vine la suflet, o complică puțin intenționat, astfel încât nimeni din colegi să nu se poată descurca în scris — o formă de răzbunare preventivă înainte de a se întâmpla ceva. Totuși, puneți în pericol nu doar compania (care vă plătește pentru această muncă), ci și pe dumneavoastră: este foarte probabil că nu veți mai ține minte ce ați vrut să exprimați cu această obfuscatie neintenționată. Aceeași situație este și cu codul nedocumentat: bazându-vă pe propria logică de denumire a variabilelor și funcțiilor și pe o memorie bună, după câțiva ani este posibil să nu vă amintiți de ce ați ales exact acest ciclu, metodă, pattern etc. Documentarea codului și o bună structură a acestuia reprezintă un serviciu excelent pentru colegi, angajator și în primul rând pentru dumneavoastră.
Păstrează-l simplu, prostule.
Nu complicați codul, soluțiile și proiectele. Nu este nevoie să construiți o structură complicată și să generați entități fără o semnificație specială. Cu cât codul dumneavoastră este mai complicat, cu atât mai mult deveniți prizonierul său - vă va fi extrem de dificil să-l întrețineți și să-l dezvoltați. Desigur, celebrul principiu KISS („Keep it simple, stupid”) nu se potrivește întotdeauna, dar nu a fost creat fără un motiv: simplitatea și eleganța codului sunt cheia aplicării și reutilizării sale de succes.
Protejați-vă
Nu ignorați securitatea — în 2020 a fost literalmente un mare risc. Chiar dacă compania dumneavoastră, dezvoltarea și dumneavoastră nu sunt de interes pentru infractori, problemele legate de un segment al rețelei, de un furnizor de hosting, de un atac asupra centrului de date sau de furtul parolelor de e-mail pot să vă afecteze. De asemenea, comportamentul nesigur al angajaților, care pot fura date din companie, clienți sau codul sursă al întregului proiect, poate crea probleme. Dacă este în puterea dumneavoastră și face parte din competența dumneavoastră, încercați să protejați proiectele cu care lucrați. De asemenea, respectați securitatea informațională, acest lucru nu a afectat niciodată pe nimeni.
Nu scuipați în fântână
Nu vă sabotați angajatorul. În ziua de azi, comunicarea a ajuns la un nivel în care, de exemplu, toți HR-ii din oraș se cunosc între ei și pot schimba orice informație în grupuri de chat și grupuri închise (fie că este vorba despre ajutor în angajare, fie despre a scrie „Vasilii Ivanov, arhitect de sisteme, înainte de a pleca a șters toate conturile, a estompat backup-urile și a deconectat rețeaua, recuperarea a durat 3 zile. Nu-l angajați”). Astfel, comportamentul dumneavoastră va juca exclusiv împotriva dumneavoastră — și uneori, relocarea într-un alt oraș sau capitală nu ajută. Chiar dacă plecați supărat, nu există o răzbunare mai bună decât să deveniți un angajat valoros și excelent al competitorului 🙂 Și, cel mai important, total impunit.
Așa ceva nu ar trebui să faceți niciodată. Dar, după cum arată experiența, nu ne vom opri
În general, prieteni, citiți sfaturile, dar faceți așa cum credeți că este cel mai bine — pentru că adevăratele descoperiri sunt făcute atunci când ne îndoim de adevărurile deja acceptate. Vă felicităm cu ocazia Anului Nou, să aveți proiecte de succes, o carieră interesantă, colegi și conducători raționali, iar viața, în general, să meargă bine. Așadar, pentru Anul Nou și pentru un nou cod!
Cu dragoste,
echipa RegionSoft Developer Studio
În noul an, vom continua să lucrăm pentru voi și să dezvoltăm un sistem CRM desktop puternic și un helpdesk simplu și convenabil și sistem de ticketing .
Sursa: habr.com
