Centrul este plin de previziuni și sfaturi despre ce să faci anul viitor - ce limbi să înveți, ce domenii să te concentrezi, ce să faci cu sănătatea ta. Sună inspirator! Dar fiecare monedă are două fețe și ne împiedicăm nu numai în ceva nou, ci mai ales în ceea ce facem în fiecare zi. „De ce nu m-a avertizat nimeni!” exclamăm iritați, de obicei întorcându-ne către noi înșine. Să punem focul asupra noastră - am întocmit pentru voi o listă cu ceea ce NU trebuie să faceți în 2020 (și poate întotdeauna).
Dar nu au întrebat despre gravitație
Ne-am dori foarte mult să punem în ordine antirecomandările, de la cele mai importante la cele mai puțin importante. Dar sunt atât de comune, echivalente și familiare pentru aproape toată lumea, încât vom scrie la întâmplare. Ei bine, să verificăm lista?
Nu este nevoie să mergi la IT dacă totul este bine
Nu învăța o nouă tehnologie pentru a schimba cariera sau a începe de la capăt. Timpul nostru este minunat pentru că poți să studiezi, să schimbi locul de muncă, să-ți schimbi radical domeniul – și așa mai departe, chiar și până la pensie. Este un lucru misto, seducător. Dar dacă ai peste 28-30 de ani, nu ar trebui să renunți la tot pentru a intra în IT sau pentru a trece la o stivă nouă (de exemplu, scrii sisteme foarte încărcate în Java și decizi brusc să intri în rețelele neuronale în Python). Motivul este simplu: nu îți va fi ușor. În primul rând, există o concurență mare din partea specialiștilor care „stă” pe această stivă încă de la începutul carierei, în al doilea rând, va trebui să devii din nou junior cu un salariu mic și, în al treilea rând, îți va fi greu din punct de vedere moral să deveni un subordonat al celui mai jos nivel al ierarhiei. Prin urmare, dacă doriți să vă mutați în cealaltă direcție, încercați să o faceți fie în conformitate cu munca dvs. curentă și sarcinile curente, fie să dezvoltați noi cunoștințe ca hobby, începeți un proiect pentru animale de companie, astfel încât atunci când veți ajunge la un nou loc de muncă nu mai fi junior.
Schimbarea stivă după stivă este doar o pierdere de timp
Nu vă grăbiți între stivele de tehnologie pentru dezvoltarea dvs. Dacă scrieți un proiect într-o singură limbă, folosind un anumit cadru și biblioteci, nu ar trebui să aruncați totul la naiba și să-l rescrieți în Dart doar pentru că vi se pare interesant. Faceți o regulă pentru a găsi o justificare pentru schimbarea tehnologiei - nu numai la nivelul „Vreau sau nu pot”, ci și la nivel financiar și de inginerie.
Nu este nevoie să rămâi în picioare și să te transformi în bronz
Respectarea unei limbi sau tehnologie și a nu învăța lucruri noi este la fel de extrem ca schimbarea stack-ului cu fiecare tehnologie nouă. Asigurați-vă că studiați biblioteci și cadre noi, nu vă încăpățânați știind că totul a fost mai bine inventat înaintea dvs. și completat exclusiv de dvs. Actualizări apar în mod constant pentru aproape fiecare limbă, ceea ce uneori vă poate îmbunătăți foarte mult proiectul. Nu fi leneș să monitorizezi dinamica stivei tale și, de îndată ce găsești ceva cool și util, nu ezitați să-l trageți în proiect!
Capul tău este bun, mereu bun
Nu te gândi în capul altora, al tău este mai bun. Din păcate, unii dezvoltatori stau și așteaptă până primesc o sarcină pentru a codifica de la eroarea anterioară până la final, fără a încerca să contribuie cu ceva al lor la proiect, să dezvolte o nouă funcție, să o testeze și să o propună pentru producție. De ce să vă deranjați când există un lider de echipă sau un manager de companie care va decide singur totul? Dacă te recunoști, atunci avem o veste proastă: o poziție pasivă nu te va ajuta nici în carieră, nici în dezvoltare. Ai șansa să-ți încerci mâna ca inginer de dezvoltare, și nu programator, într-un adevărat proiect de luptă și să înțelegi unde să mergi, ce lipsește, dar preferi să-ți petreci timpul la altceva și să faci exact „de aici până la acum." Astfel de oameni supraviețuiesc din ce în ce mai rău în IT-ul modern, ies din animația suspendată.
Utilizatorii sunt oameni groaznici
Nu supraestimați utilizatorii software-ului dvs.: dacă nu scrieți pentru programatori, așteptați-vă ca programul să întâmpine neînțelegeri impenetrabile. În primele zile sau săptămâni, utilizatorul vă va urî software-ul pentru că „cel vechi nu era atât de prost”. Pentru a evita acest lucru, faceți documentație și tutoriale grozave. Când instalați sau cumpărați, sugerați foarte intruziv că manualele trebuie citite înainte de a începe să lucrați cu programul și nu după ce baza de date se blochează, pierderea parolei și autocontrolul.
Nici utilizatorii nu ar trebui să subestimezi: sunt mai vicleni, mai inteligenți și mai curioși decât crezi. Dacă credeți că bug-ul cu formatul variabil și excepția de la a 138-a apăsare a Enter la intervale de o secundă nu vor apărea, vă înșelați - vor apărea și vor afecta funcționarea aplicației dvs. în cel mai bizar mod. Se aplică regula amatorului: el este cel care face față cel mai bine testării. Dar din anumite motive, utilizatorilor nu le place să găsească erori în producție - nu există solidaritate IT în ei. În general, cu cât sunteți mai încrezător în software-ul dvs., cu atât mai bine. La urma urmei, este mai bine să întârzii lansarea unor caracteristici decât să le adaugi la o aplicație de lucru și să o faci brusc brută.
Nu mai căutați pe Google!
Nu mai apela la Google singur. Nici măcar nu ne vom certa - în domeniul dezvoltării, puteți găsi multe cu o solicitare directă către un motor de căutare. Cu cât sapi mai adânc în căutarea informațiilor, cu atât vei primi mai multe date „laterale” și vei învăța mai multe, pentru că vei afla ceva nou care nu are legătură cu solicitarea ta, dar probabil că va fi nevoie în viitor. Consultați materiale cu drepturi depline, cărți, articole etc. Limbile și bibliotecile au specificații, comunități, modalități și astfel obțineți cea mai fiabilă modalitate de a dezvolta abilitățile de programator - doar citiți documentația și nu căutați soluțiile locale și fragmentele de cod ale altora. Ce se întâmplă dacă soluția ta este mai optimă, mai rapidă și mai rece?
Crede, dar verifică
Nu utilizați biblioteci și cadre create de dezvoltatori terți fără a verifica codul și a-l adapta pentru a se potrivi scopurilor dvs. Nu aveți niciun motiv să aveți încredere necondiționată în acest autor de cod pe care nu-l cunoașteți deloc. Da, diverse elemente rău intenționate din codurile terțelor părți nu sunt atât de comune și nu ar trebui să suferi de paranoia, dar copierea orbește a unor părți gata făcute ale software-ului în proiectul tău poate duce la consecințe imprevizibile. Prin urmare, asigurați-vă că citiți și analizați codul înainte de utilizare și testați după implementarea codului.
Faceți copii de rezervă!
Nu mai faceți copii de rezervă sau nu le păstrați pe aceleași servere terțe pe care este găzduit proiectul dvs. Crezi că acesta este un sfat ridicol și inutil? Dar peste 700 de participanți la chat de pe Telegram, care s-au trezit într-o situație neplăcută recentă cu închiderea unui centru de date binecunoscut, nu au crezut așa - acolo era totul: de la proiecte pentru animale de companie până la site-uri web mari ale guvernului. autorități și baze de date corporative 1C și de facturare. O parte semnificativă este fără copii de rezervă sau cu copii de rezervă în același loc. Așa că distribuiți riscurile și stocați backup-ul cel puțin pe găzduirea principală, pe niște VDS de încredere și pe serverul dvs. local. Va ajunge să fie mult mai ieftin pe termen lung.
Nu mai aduceți ai dvs. în detrimentul proiectului
Nu faceți ceea ce doriți într-un proiect de lucru, ci faceți ceea ce au nevoie clienții. Da, este incredibil de interesant și grozav să-ți creezi propria rețea neuronală, să o antrenezi și să o implementezi în software-ul tău, dar dacă clienții tăi au nevoie de un simplu manager de contact, acesta va fi exagerat. Vedeți cum funcționează proiectul, citiți documentația, citiți recenziile și solicitările clienților și implementați ceea ce va adăuga valoare de afaceri proiectului. Dacă vrei să creezi ceva științific sau extrem de complex, începe cu propriul tău proiect.
Nu un cod, ci un mănunchi de nervi
Nu scrie cod necitit și nedocumentat. Suntem familiarizați cu acest truc: dezvoltatorul scrie cod după pofta inimii, confundându-l puțin, astfel încât niciunul dintre colegii săi să nu poată înțelege ce a scris - acesta este un fel de răzbunare preventivă înainte să se întâmple ceva. Cu toate acestea, pui în pericol nu doar compania (care te plătește bani pentru munca ta), ci și pe tine însuți: este posibil ca tu însuți să nu-ți amintești ce ai vrut să spui cu această ofuscare neintenționată. La fel este și cu codul nedocumentat: bazându-te pe logica ta de denumire a variabilelor și funcțiilor și a memoriei bune, după câțiva ani s-ar putea să nu-ți amintești de ce ai ales acea buclă, metodă, model etc. Documentarea codului și a structurii sale bune este un serviciu grozav pentru colegii tăi, angajatorul și, mai ales, pentru tine.
Păstrează-te simplu, prost
Păstrați codul, soluțiile și proiectele simple. Nu este nevoie să îngrădiți într-o structură complexă și să produceți entități fără semnificație specială. Cu cât codul tău este mai complex, cu atât devii mai mult ostatic al acestuia - îți va fi cât mai dificil să-l menții și să-l dezvolți. Desigur, celebrul principiu KISS („Keep it simple, stupid”) nu este întotdeauna potrivit, dar a fost creat dintr-un motiv: simplitatea și eleganța codului sunt cheia aplicării și reutilizării sale cu succes.
Protejeaza-te
Nu ignora siguranța - în 2020 este literalmente criminală. Chiar dacă compania dvs., dezvoltarea și dvs. nu sunteți de interes pentru atacatori, puteți fi afectat de probleme legate de înfrângerea unui segment de rețea, furnizor de găzduire, atac asupra centrului de date, furtul parolelor de e-mail și comportamentul nesigur al angajaților care pot fura date de la companie, furt de clienti sau codul de program al intregului proiect. Dacă este în puterea ta și în aria ta de expertiză, încearcă să protejezi proiectele la care lucrezi. Ei bine, observați singur securitatea informațiilor, nu a deranjat niciodată pe nimeni.
Nu scuipa în fântână
Nu te încurca cu angajatorul tău. Astăzi, comunicațiile au atins un astfel de nivel încât, de exemplu, toți oamenii de HR din oraș se cunosc în lipsă și pot face schimb de informații în chat-uri și grupuri închise (atât pentru a ajuta la găsirea unui loc de muncă, cât și pentru a scrie „Vasili Ivanov, arhitect de sistem, a ucis totul înainte de a părăsi conturile, a șters copiile de rezervă și a oprit rețeaua, recuperarea a durat 3 zile. Nu-l angaja." Astfel, comportamentul tău va juca numai împotriva ta - și uneori nici mutarea în alt oraș sau capitală nu va ajuta. Chiar dacă pleci cu ranchiună, nu există răzbunare mai bună decât să devii un angajat util și cool al unui concurent :) Și, cel mai important, cu deplină impunitate.
Nici tu nu ar trebui să faci asta. Dar, după cum arată experiența, nu ne vom opri
În general, prieteni, citiți sfaturile, dar faceți ceea ce credeți că este mai bine - la urma urmei, descoperirile reale se fac atunci când ne îndoim de adevăruri deja descoperite. La mulți ani, fie ca proiectele tale să aibă succes, fie ca cariera să fie plăcută, fie ca colegii și managerii să fie adecvati și viața ta în general să aibă succes. În general, iată la Anul Nou și noul cod!
Cu dragoste,
Echipa RegionSoft Developer Studio
În noul an, vom continua să lucrăm pentru tine și să dezvoltăm un sistem CRM desktop puternic și un birou de asistență și un sistem de bilete simplu și convenabil .
Sursa: www.habr.com