Habr è pieno di previsioni e consigli su cosa fare l'anno prossimo: quali lingue studiare, in quali settori orientarsi, come prendersi cura della propria salute. Suona ispiratore! Ma ogni medaglia ha il suo rovescio, e inciampiamo non solo in qualcosa di nuovo, ma soprattutto in ciò che facciamo ogni giorno. "Perché nessuno mi ha avvertito!" esclamiamo irritati, di solito parlando con noi stessi. Ci mettiamo nei guai — abbiamo raccolto per voi un elenco di ciò che NON dovreste fare nel 2020 (o forse sempre).
E la gravità non è stata interpellata.
Ci piacerebbe molto ordinare le anti-raccomandazioni, dalla più importante alla meno significativa. Ma sono così diffuse, equivalenti e familiari a quasi tutti, che scriveremo in modo disordinato. Beh, controlliamo l'elenco?
Non dovete andare nell'IT se va tutto bene.
Non studiate una nuova tecnologia per cambiare professione o ricominciare da zero. Il nostro tempo è meraviglioso perché permette di apprendere, cambiare lavoro, cambiare settore radicalmente — e così fino alla pensione. È una cosa fantastica e allettante. Ma se avete più di 28-30 anni, non dovete abbandonare tutto per entrare nell'IT o passare a un nuovo stack (ad esempio, scrivete sistemi ad alta capacità con Java e improvvisamente decidete di passare alle reti neurali con Python). La ragione è semplice: sarà difficile. In primo luogo, c'è una forte concorrenza da parte di specialisti che "si sono seduti" su quello stack dall'inizio della loro carriera; in secondo luogo, dovrete tornare a essere junior con uno stipendio basso; in terzo luogo, sarà moralmente difficile diventare un sottoposto del livello più basso nella gerarchia. Quindi, se volete muovervi in un'altra direzione, cercate di farlo sia nel contesto del lavoro attuale e delle attuali attività, sia sviluppando nuove conoscenze come hobby, realizzando un progetto personale, così da arrivare a un nuovo lavoro già non da junior.
Cambiare stack per stack è solo una perdita di tempo.
Non saltate tra gli stack tecnologici per il vostro sviluppo. Se state scrivendo un progetto in un certo linguaggio, utilizzando un determinato framework e librerie, non vale la pena abbandonare tutto e riscrivere in Dart, solo perché vi è sembrato interessante. Fatevi una regola di trovare una giustificazione per cambiare tecnologia — non solo a livello di "voglio-non posso", ma anche a livello finanziario ed ingegneristico.
Non dovete rimanere fermi sulle vostre posizioni e irrigidirvi.
Concentrarsi su un'unica lingua o tecnologia senza esplorare nuove opportunità è un'estremità, tanto quanto cambiare stack con ogni nuova tecnologia. Assicurati di studiare nuove librerie e framework, non essere testardo pensando che tutto il meglio sia già stato inventato da te e perfezionato esclusivamente da te. Praticamente ogni linguaggio riceve continuamente aggiornamenti che possono notevolmente migliorare il tuo progetto. Non essere pigro nel monitorare la dinamica del tuo stack e, non appena trovi qualcosa di interessante e utile, portalo senza paura nel progetto!
La propria testa è buona, è sempre buona
Non pensare con la testa degli altri; la tua è migliore. Purtroppo, alcuni sviluppatori si siedono e aspettano che arrivi un compito per programmare dall'errore precedente fino alla fine, senza cercare di portare nel progetto qualcosa di proprio, sviluppare una nuova funzione, testare e proporre per la produzione. Perché affaticarsi, quando c'è la testa del team leader o del direttore dell'azienda, che risolverà tutto? Se ti riconosci in questo, abbiamo brutte notizie: una posizione passiva non aiuterà nella carriera né nello sviluppo. Hai l'opportunità di testare le tue capacità come ingegnere sviluppatore, e non come programmatore in un vero progetto, e capire in quale direzione muoverti, cosa manca, ma preferisci spendere il tuo tempo in qualcos'altro e fare solo il minimo indispensabile. In un'IT moderna, chi agisce così ha sempre meno possibilità di sopravvivere, esci dall'ibernazione.
Gli utenti sono persone temibili
Non sopravvalutare gli utenti del tuo software: se scrivi per chi non è programmatore, preparati a che il programma si trovi di fronte a una comprensione inesorabile. Nei primi giorni o settimane, l'utente odierà il tuo software, perché "il vecchio non era così stupido". Per evitare questo, crea una documentazione e materiali didattici eccellenti. Durante l’installazione o l’acquisto, sottolinea in modo molto insistente che i manuali andrebbero letti prima di iniziare a lavorare con il programma, e non dopo il fallimento del database, la perdita della password e il controllo di sé.
Non bisogna sottovalutare gli utenti: sono più astuti, intelligenti e curiosi di quanto pensiate. Se pensate che quel bug relativo al formato della variabile e l'eccezione al 138° colpo di Enter con un intervallo di un secondo non emergeranno, vi sbagliate: emergeranno e influenzeranno il funzionamento della vostra applicazione in modo bizzarro. Funziona la regola del dilettante: è proprio lui a occuparsi dei test meglio di tutti. Tuttavia, agli utenti non piace scoprire bug in produzione — non c'è solidarietà tra professionisti dell'IT. In generale, più siete sicuri del vostro software, meglio è. Dopotutto, è meglio ritardare il rilascio di alcune funzionalità, piuttosto che aggiungerle in un'applicazione funzionante e renderla improvvisamente incompleta.
Smettila di googlare!
Smettetela di affidarvi solo a Google. Non ne discuteremo nemmeno: nel campo dello sviluppo, con una ricerca diretta su un motore di ricerca si può trovare davvero molto. Più in profondità scaverete nella ricerca di informazioni, più dati 'laterali' otterrete e più imparerete, perché scoprirete cose nuove non collegate alla vostra ricerca, ma probabilmente utili in futuro. Rivolgetevi a materiali completi, libri, articoli, ecc. I linguaggi e le librerie hanno specifiche, comunità, guide, e in questo modo ottenete il modo più affidabile per sviluppare le competenze di programmatore: semplicemente leggendo la documentazione, e non cercando soluzioni locali e frammenti di codice altrui. E se la vostra soluzione fosse più ottimale, veloce e migliore?
Fidati, ma verifica
Non utilizzate librerie e framework creati da sviluppatori esterni senza controllare il codice e adattandolo ai vostri obiettivi. Non avete alcuna ragione per fidarvi incondizionatamente di questo autore di codice, che non conoscete affatto. Sì, vari elementi malevoli intenzionali in codice esterno non si incontrano così frequentemente e non è il caso di soffrire di paranoia, ma copiare alla cieca parti di software pronte nel vostro progetto può portare a conseguenze imprevedibili. Quindi assicuratevi di leggere e analizzare il codice prima di utilizzarlo e di eseguire test dopo l'implementazione del codice.
Fate i backup!
Smettila di non fare backup o di tenerli sugli stessi server esterni dove è ospitato il tuo progetto. Pensi che sia un consiglio ridicolo e superfluo? Eppure oltre 700 membri di un chat su Telegram che sono recentemente incappati in una spiacevole situazione a causa dell'interruzione di uno noto data center, non la pensano così: c'erano di tutto, dai progetti minori a grandi siti di enti governativi e basi aziendali 1C e di fatturazione. Una parte significativa è senza backup o con backup sullo stesso server. Quindi distribuisci i rischi e conserva il backup almeno sull'hosting principale, su qualche VDS affidabile e su un tuo server locale. Alla fine, ti costerà molto meno.
Smettila di compromettere il progetto per il tuo tornaconto personale
Non fare nel progetto di lavoro ciò che è più comodo per te, ma fai ciò che serve ai clienti. Sì, è estremamente interessante e stimolante creare la propria rete neurale, addestrarla e integrarla nel proprio software, ma se ai tuoi clienti serve un semplice gestore di contatti, sarebbe un'esagerazione costosa. Guarda come funziona il progetto, leggi la documentazione, dai un'occhiata alle recensioni e alle richieste dei clienti e realizza ciò che darà valore commerciale al progetto. Se vuoi realizzare qualcosa di scientifico o di estremamente complesso, comincia con un tuo progetto.
Non codice, ma un groviglio di nervi
Non scrivere codice illeggibile e non documentato. Sappiamo quali siano queste abitudini: lo sviluppatore scrive codice come meglio crede, complicandolo un po' per impedire ai colleghi di capirlo — una sorta di vendetta preventiva prima che succeda qualcosa. Tuttavia, stai mettendo a rischio non solo l'azienda (che ti paga per il lavoro), ma anche te stesso: è molto probabile che nemmeno tu ricordi cosa volevi dire con questa offuscazione non intenzionale. Lo stesso vale per il codice non documentato: facendo affidamento sulla tua logica di denominazione delle variabili e delle funzioni e sulla buona memoria, dopo un paio d'anni potresti non ricordare perché hai scelto proprio quel ciclo, metodo, pattern, ecc. Documentare il codice e strutturarlo bene è un ottimo servizio ai colleghi, al datore di lavoro e, soprattutto, a te stesso.
Keep it simple, stupid
Non complicate il codice, le soluzioni e i progetti. Non è necessario costruire strutture complesse e creare entità senza particolare significato. Più complesso è il vostro codice, maggiore sarà la vostra schiavitù nei suoi confronti: sarà molto difficile mantenerlo e svilupparlo. Certamente, il famoso principio KISS («Keep it simple, stupid») non si applica sempre, ma non è stato creato per caso: la semplicità e l'eleganza del codice sono la chiave per il suo successo e riutilizzo.
Proteggetevi
Non ignorate la sicurezza: nel 2020 è letteralmente un crimine. Anche se la vostra azienda, il vostro sviluppo e voi non interessano ai malintenzionati, potreste essere colpiti da problemi legati all'infezione di un segmento di rete, di un provider di hosting, da un attacco a un data center, dal furto delle password e da comportamenti non sicuri dei dipendenti, che possono rubare dati dall'azienda, portare via clienti o il codice sorgente dell'intero progetto. Se è nelle vostre possibilità e rientra nella vostra area di competenza, cercate di proteggere i progetti con cui lavorate. E seguite anche voi la sicurezza informatica; non ha mai fatto male a nessuno.
Non sputare nel pozzo
Non danneggiare il tuo datore di lavoro. Al giorno d'oggi, le comunicazioni hanno raggiunto un livello tale che, ad esempio, tutti gli HR della città si conoscono a distanza e possono scambiarsi qualsiasi informazione in chat e gruppi chiusi (sia per aiutare a trovare lavoro, sia per dire «Vasiliy Ivanov, architetto sistemico, prima di andare via ha cancellato tutti gli account, ha cancellato i backup e ha disattivato la rete, il ripristino ha impiegato 3 giorni. Non assumerlo»). Pertanto, il tuo comportamento giocherà esclusivamente contro di te — e a volte non aiuterà nemmeno il trasferimento in un'altra città o capitale. Anche se te ne vai con risentimento, non c'è vendetta migliore che diventare un dipendente utile e fantastico della concorrenza 🙂 E soprattutto, completamente impunito.
Non vale nemmeno la pena fare così. Ma, come dimostra l'esperienza, non ci fermeremo
E in generale, amici, leggete i consigli, ma fate come vi sembra migliore — perché le vere scoperte avvengono quando dubitiamo delle verità già scoperte. Vi auguriamo un Buon Anno, che i vostri progetti siano di successo, la vostra carriera non noiosa, i colleghi e i dirigenti ragionevoli e la vita in generale vi riesca. Insomma, per il Nuovo Anno e per il nuovo codice!
Con affetto,
il team di RegionSoft Developer Studio
Nel nuovo anno continueremo a lavorare per voi e a sviluppare un potente sistema CRM desktop. e un helpdesk semplice e comodo e un sistema di ticket. .
Fonte: habr.com
