Habr è pieno di previsioni e consigli su cosa fare nel prossimo anno: quali lingue studiare, in quali settori investire, come prendersi cura della propria salute. Suona ispiratore! Ma ogni medaglia ha il suo rovescio, e ci imbattiamo non solo in cose nuove, ma soprattutto in ciò che facciamo ogni giorno. "Perché nessuno mi ha avvertito!", esclamano irritati, solitamente parlando a se stessi. Attiriamo l'attenzione su di noi: abbiamo raccolto per voi un elenco di ciò che NON dovreste fare nel 2020 (e forse sempre).
E la gravità non è stata consultata
Ci piacerebbe molto ordinare le anti-raccomandazioni per importanza, dalla più significativa alla meno rilevante. Ma sono così diffuse, equivalenti e familiari a praticamente tutti, che scriveremo in modo casuale. Bene, controlliamo la lista?
Non dovete entrare nel settore IT se tutto va bene
Non ti limitare a studiare una nuova tecnologia per cambiare carriera o ricominciare da zero. Il nostro tempo è fantastico poiché è possibile apprendere, cambiare lavoro e persino settore — fino alla pensione. È una cosa affascinante e seducente. Tuttavia, se hai più di 28-30 anni, non è saggio lasciare tutto per entrare nel settore IT o per passare a un nuovo stack (ad esempio, se sviluppi sistemi ad alto carico in Java e decidi improvvisamente di passare alle reti neurali in Python). La ragione è semplice: non sarà facile per te. In primo luogo, la concorrenza è alta, con specialisti che usano questo stack fin dall'inizio della loro carriera; in secondo luogo, dovrai ricominciare come junior con uno stipendio basso; in terzo luogo, sarà moralmente difficile per te diventare subordinato al livello più basso della gerarchia. Pertanto, se desideri muoverti in un'altra direzione, cerca di farlo all'interno del tuo attuale lavoro e delle tue attuali responsabilità, oppure sviluppa nuove competenze come hobby, lavora a progetti personali, in modo da arrivare al tuo nuovo lavoro non come junior.
Cambiarsi stack a stack significa solo perdere tempo
Non lasciatevi travolgere tra le tecnologie per il vostro sviluppo. Se state scrivendo un progetto in un linguaggio specifico, utilizzando un determinato framework e librerie, non è necessario abbandonare tutto e ricominciare da capo con Dart solo perché vi sembra interessante. Prendete l'abitudine di trovare una giustificazione per cambiare tecnologia — non solo a livello di "voglio-non posso", ma anche a livello finanziario e ingegneristico.
Non è necessario essere testardi e restare fissi
Fermarsi su un solo linguaggio o tecnologia e non esplorare il nuovo è un'estremità così come cambiare stack con ogni nuova tecnologia. Dovete sempre studiare nuove librerie e framework, non siate testardi nel pensare che tutto sia già stato inventato e perfezionato da voi. Praticamente ogni linguaggio riceve costantemente aggiornamenti che possono davvero migliorare il vostro progetto. Non siate pigri nel seguire le dinamiche del vostro stack e, non appena trovate qualcosa di interessante e utile, integratelo nel progetto con sicurezza!
La propria testa è buona, è sempre buona
Non pensate con la testa degli altri, la vostra è migliore. Purtroppo, alcuni sviluppatori si siedono e aspettano che arrivi un compito da codificare, dal precedente errore fino alla fine, senza cercare di portare qualcosa di proprio nel progetto, sviluppare una nuova funzione, testarla e proporla in produzione. Perché affaticarsi, quando c'è la testa del team leader o del responsabile dell'azienda che decide tutto? Se vi riconoscete in questo, abbiamo brutte notizie: una posizione passiva non aiuta né nella carriera né nello sviluppo. Avete l'opportunità di mettere alla prova le vostre capacità come ingegnere sviluppatore, non come codificatore in un vero progetto lavorativo e capire quale direzione prendere, cosa vi manca, ma preferite spendere il vostro tempo in qualcos'altro e fare esattamente "da qui a lì". In questo moderno ambiente IT, chi ha questo atteggiamento sopravvive sempre peggio, uscite dall'anabiosi.
Gli utenti sono persone terribili
Non sottovalutate gli utenti del vostro software: se non scrivete per programmatori, aspettatevi che il programma incontri incomprensioni insormontabili. Nei primi giorni o settimane, l'utente odierà il vostro software perché "quello vecchio non era così stupido". Per evitarlo, create una documentazione efficace e materiali di formazione. Durante l'installazione o l'acquisto, suggerite in modo insistente che i manuali dovrebbero essere letti prima di iniziare a usare il programma, e non dopo un crash del database, la perdita della password e una crisi di autocontrollo.
Non bisogna sottovalutare gli utenti: sono più astuti, intelligenti e curiosi di quanto pensiate. Se credete che quel bug con il formato della variabile e l'eccezione al 138° colpo di Enter con un intervallo di un secondo non emergerà, vi sbagliate: emergerà e influenzerà il funzionamento della vostra applicazione in modi bizzarri. Funziona la regola dell'apprendista: è proprio lui a fare il lavoro di test migliore. Ma agli utenti non piace scoprire bug in produzione — non c'è alcuna solidarietà IT in questo. Insomma, più siete sicuri del vostro software, meglio è. In fin dei conti, è meglio ritardare il rilascio di alcune funzionalità piuttosto che aggiungerle in un'applicazione funzionante e renderla improvvisamente incompleta.
Smettila di googlare!
Smetti di rivolgerti solo a Google. Non stiamo nemmeno discutendo: nel campo dello sviluppo, una semplice ricerca nel motore può rivelare molto. Più a fondo scaverai nella ricerca di informazioni, più dati "laterali" otterrai e più imparerai, perché scoprirai cose nuove non correlate alla tua richiesta, ma probabilmente utili in futuro. Rivolgiti a materiali completi, libri, articoli, ecc. I linguaggi e le librerie hanno specifiche, comunità e guide pratiche, e così facendo ottieni il modo più affidabile per sviluppare le tue abilità di programmatore: leggere la documentazione piuttosto che cercare soluzioni locali e frammenti di codice di qualcun altro. E chissà, forse la tua soluzione sarà più ottimale, veloce e migliore?
Fidati, ma verifica
Non utilizzare librerie e framework creati da sviluppatori esterni senza verificare il codice e adattarlo ai tuoi scopi. Non hai alcun motivo per fidarti ciecamente di un autore di codice che non conosci affatto. Sì, elementi malevoli intenzionali nel codice di terze parti non si incontrano così spesso e non è necessario soffrire di paranoia, ma copiare a occhi chiusi parti di software pronte per il tuo progetto può portare a conseguenze imprevedibili. Quindi assicurati di leggere e analizzare il codice prima dell'uso e di effettuare test dopo l'implementazione del codice.
Fai dei backup!
Smettila di non fare backup o di tenerli sugli stessi server di terze parti dove è ospitato il tuo progetto. Pensi che sia un consiglio ridicolo e inutile? Eppure, più di 700 partecipanti a un chat su Telegram, che si sono trovati in una recente situazione scomoda a causa della chiusura di un noto data center, non lo pensavano affatto — ci sono stati di tutto: dai progetti personali a siti web importanti di enti statali e basi aziendali di 1C e billing. Una parte significativa — senza backup o con backup tenuti lì. Quindi distribuisci i rischi e conserva il backup almeno sul principale hosting, su un VDS affidabile e sul tuo server locale. Alla fine, ti costerà molto meno.
Basta portare il tuo a scapito del progetto
Non fate nel progetto di lavoro ciò che desiderate, ma ciò che serve ai clienti. Sì, è estremamente interessante e stimolante creare la propria rete neurale, addestrarla e integrarla nel proprio software, ma se ai vostri clienti serve un semplice gestore di contatti, questo sarebbe un eccesso costoso. Osservate come funziona il progetto, leggete la documentazione, esaminatela e leggete le recensioni e le richieste dei clienti, poi implementate ciò che porterà valore commerciale al progetto. Se volete realizzare qualcosa di scientifico o di estremamente complesso, iniziate con un progetto personale.
Non codice, ma un groviglio di nervi
Non scrivere codice illeggibile e non documentato. Questa pratica ci è familiare: un sviluppatore scrive codice come meglio crede, complicandolo volutamente per rendere difficile la comprensione da parte dei colleghi — una sorta di vendetta preventiva prima che accada qualcosa. Tuttavia, stai rischiando non solo per l'azienda (che ti paga per il lavoro), ma anche per te stesso: è molto probabile che tu stesso non ricordi cosa volevi comunicare con questa offuscamento involontario. Lo stesso vale per il codice non documentato: basandoti sulla tua logica di denominazione delle variabili e delle funzioni e su una buona memoria, dopo un paio d'anni potresti non ricordare perché hai scelto proprio quel ciclo, metodo, pattern, ecc. Documentare il codice e avere una buona struttura è un grande servizio per i colleghi, per il datore di lavoro e, soprattutto, per te stesso.
Keep it simple, stupid
Non complicate il codice, le soluzioni e i progetti. Non serve creare una struttura complessa e generare entità senza un significato particolare. Più il vostro codice è complesso, più diventate suoi prigionieri: sarà estremamente difficile mantenerlo e svilupparlo. Certo, il famoso principio KISS («Keep it simple, stupid») non si applica sempre, ma non è stato creato per niente: la semplicità e l'eleganza del codice sono la chiave per un suo utilizzo e riutilizzo di successo.
Proteggiti
Non ignorare la sicurezza: nel 2020 è praticamente un crimine. Anche se la tua azienda, il tuo sviluppo e tu stesso non siete interessanti per i malintenzionati, potreste essere colpiti da problemi legati a un segmento di rete, a un provider di hosting, ad attacchi contro un data center, al furto delle password di posta elettronica e ai comportamenti non sicuri dei dipendenti che potrebbero rubare dati dall'azienda, portare via clienti o il codice sorgente dell'intero progetto. Se è possibile e rientra nelle vostre competenze, cercate di proteggere i progetti con cui lavorate. E rispettate sempre la sicurezza informatica, questo non ha mai fatto male a nessuno.
Non sputare nel pozzo
Non danneggiate la vostra reputazione presso il datore di lavoro. Oggi le comunicazioni hanno raggiunto un livello tale che, ad esempio, tutti gli HR della città sono in contatto tra loro e possono condividere qualsiasi informazione in chat e gruppi chiusi (sia per aiutare qualcuno a trovare lavoro, sia per inviare messaggi tipo «Vasiliy Ivanov, architetto di sistemi, prima di andarsene ha cancellato tutti i conti, ha distrutto i backup e ha disattivato la rete, il ripristino ha richiesto 3 giorni. Non assumerlo»). Pertanto, il vostro comportamento giocherà esclusivamente contro di voi — e a volte non aiuta nemmeno trasferirsi in un'altra città o nella capitale. Anche se ve ne andate con risentimento, non c'è vendetta migliore che diventare un collaboratore utile e fantastico per un concorrente 🙂 E soprattutto, senza alcuna punizione.
Non è una buona idea nemmeno questo. Ma, come dimostra l'esperienza, non smetteremo di farlo.
In effetti, amici, leggete i consigli, ma seguite ciò che ritenete migliore — poiché le vere scoperte si fanno quando dubitiamo delle verità già accettate. Vi auguriamo un felice anno nuovo, che i vostri progetti siano di successo, la vostra carriera — stimolante, i colleghi e i superiori — ragionevoli, e la vita in generale vi sorrida. In sintesi, brindiamo al nuovo anno e al nuovo codice!
Con affetto,
il team di RegionSoft Developer Studio
Nel nuovo anno continueremo a lavorare per voi e a sviluppare una potente CRM desktop e un help desk semplice e intuitivo, insieme a un sistema di ticketing .
Fonte: habr.com
