L'hub è pieno di previsioni e consigli su cosa fare il prossimo anno: quali lingue imparare, su quali aree concentrarsi, cosa fare con la propria salute. Sembra stimolante! Ma ogni medaglia ha due facce 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 rivolgendoci a noi stessi. Chiamiamo il fuoco su noi stessi: abbiamo compilato per te un elenco di cosa NON fare nel 2020 (e forse sempre).
Ma non hanno chiesto informazioni sulla gravità
Vorremmo davvero mettere in ordine le anti-raccomandazioni, dalla più importante alla meno importante. Ma sono così comuni, equivalenti e familiari a quasi tutti che li scriveremo a caso. Bene, controlliamo l'elenco?
Non c'è bisogno di andare all'IT se tutto va bene
Non imparare una nuova tecnologia per cambiare carriera o ricominciare da capo. Il nostro tempo è meraviglioso perché puoi studiare, cambiare lavoro, cambiare radicalmente campo - e così via, anche fino alla pensione. È una cosa bella e seducente. Ma se hai più di 28-30 anni, non dovresti rinunciare a tutto per entrare nell'IT o passare a un nuovo stack (ad esempio, scrivi sistemi altamente caricati in Java e all'improvviso decidi di entrare nelle reti neurali in Python). Il motivo è semplice: per te non sarà facile. In primo luogo, c'è una forte concorrenza da parte di specialisti che sono "seduti" su questo stack dall'inizio della loro carriera, in secondo luogo, dovrai diventare di nuovo junior con uno stipendio basso e, in terzo luogo, sarà moralmente difficile per te diventare un subordinato del livello più basso della gerarchia. Pertanto, se vuoi muoverti nella direzione opposta, prova a farlo in linea con il tuo lavoro attuale e i tuoi compiti attuali, o sviluppa nuove conoscenze come hobby, avvia un progetto preferito in modo che quando arrivi a un nuovo lavoro lo farai non essere più un junior.
Cambiare stack dopo stack è solo una perdita di tempo
Non correre tra gli stack tecnologici per il tuo sviluppo. Se stai scrivendo un progetto in una lingua, utilizzando un determinato framework e librerie, non dovresti buttare tutto al diavolo e riscriverlo in Dart solo perché lo trovi interessante. Stabilisci come regola la ricerca di una giustificazione per il cambiamento tecnologico, non solo a livello del “lo voglio o non posso”, ma anche a livello finanziario e ingegneristico.
Non c'è bisogno di mantenere la tua posizione e diventare bronzo
Attenersi a una lingua o a una tecnologia e non imparare cose nuove è estremo quanto cambiare il proprio stack con ogni nuova tecnologia. Assicurati di studiare nuove librerie e framework, non essere testardo nella consapevolezza che tutto è stato inventato meglio prima di te e completato esclusivamente da te. Vengono costantemente pubblicati aggiornamenti per quasi tutte le lingue, il che a volte può migliorare notevolmente il tuo progetto. Non essere pigro nel monitorare le dinamiche del tuo stack e, non appena trovi qualcosa di interessante e utile, sentiti libero di trascinarlo nel progetto!
La tua testa è buona, sempre buona
Non pensare nella testa degli altri, la tua è migliore. Purtroppo, alcuni sviluppatori si siedono e aspettano finché non ricevono un compito da codificare dall'errore precedente fino alla fine, senza cercare di contribuire con qualcosa di proprio al progetto, sviluppare una nuova funzione, testarla e proporla per la produzione. Perché preoccuparsi quando c'è un responsabile del team o un manager dell'azienda che decide tutto da solo? Se ti riconosci, allora abbiamo cattive notizie: una posizione passiva non ti aiuterà né nella tua carriera né nello sviluppo. Hai la possibilità di cimentarti come ingegnere di sviluppo, e non come programmatore, in un vero progetto di combattimento e capire dove andare, cosa manca, ma preferisci dedicare il tuo tempo a qualcos'altro e fare esattamente "da qui a Ora." Queste persone sopravvivono sempre peggio nell'IT moderno, escono dall'animazione sospesa.
Gli utenti sono persone terribili
Non sopravvalutare gli utenti del tuo software: se non scrivi per programmatori, aspettati che il programma incontri incomprensioni impenetrabili. I primi giorni o settimane l’utente odierà il tuo software perché “quello vecchio non era così stupido”. Per evitare ciò, crea ottima documentazione e tutorial. Durante l'installazione o l'acquisto, suggerire in modo molto intrusivo che i manuali dovrebbero essere letti prima di iniziare a lavorare con il programma e non dopo il crash del database, la perdita della password e l'autocontrollo.
Non dovresti sottovalutare nemmeno gli utenti: sono più furbi, più intelligenti e più curiosi di quanto pensi. Se pensi che il bug con il formato variabile e l'eccezione alla 138a pressione di Invio a intervalli di un secondo non compariranno, ti sbagli: appariranno e influenzeranno il funzionamento della tua applicazione nel modo più bizzarro. Vale la regola del dilettante: è lui che affronta meglio le prove. Ma per qualche motivo, agli utenti non piace trovare bug nella produzione: non c'è solidarietà IT in loro. In generale, più sei sicuro del tuo software, meglio è. Dopotutto, è meglio ritardare il rilascio di alcune funzionalità piuttosto che aggiungerle a un'applicazione funzionante e renderla improvvisamente grezza.
Smettila di cercare su Google!
Smetti di rivolgerti solo a Google. Non discuteremo nemmeno: nel campo dello sviluppo puoi trovare molto con una richiesta diretta al motore di ricerca. Più scaverai alla ricerca di informazioni, più dati “laterali” riceverai e più imparerai, perché imparerai qualcosa di nuovo che non è legato alla tua richiesta, ma che probabilmente ti servirà in futuro. Fare riferimento a materiali completi, libri, articoli, ecc. I linguaggi e le librerie hanno specifiche, comunità, procedure e quindi ottieni il modo più affidabile per sviluppare le capacità di un programmatore: basta leggere la documentazione e non cercare soluzioni locali e frammenti di codice di altre persone. E se la tua soluzione fosse più ottimale, più veloce e più interessante?
Fidati, ma verifica
Non utilizzare librerie e framework creati da sviluppatori di terze parti senza controllare il codice e adattarlo ai propri scopi. Non hai motivo di fidarti incondizionatamente di questo autore di codice che non conosci affatto. Sì, vari elementi dannosi intenzionali nel codice di terze parti non sono così comuni e non dovresti soffrire di paranoia, ma copiare ciecamente parti di software già pronte nel tuo progetto può portare a conseguenze imprevedibili. Pertanto, assicurati di leggere e analizzare il codice prima dell'uso e di testarlo dopo aver implementato il codice.
Effettua backup!
Smetti di fare backup e di non tenerli sugli stessi server di terze parti su cui è ospitato il tuo progetto. Pensi che sia un consiglio ridicolo e inutile? Ma più di 700 partecipanti alla chat di Telegram, che si sono trovati di recente in una situazione spiacevole con la chiusura di un noto data center, non la pensavano così: c'era di tutto: dai progetti per animali domestici ai grandi siti web governativi. autorità e database aziendali 1C e di fatturazione. Una parte significativa è senza backup o con backup nello stesso posto. Quindi distribuisci i rischi e archivia il backup almeno sull'hosting principale, su alcuni VDS affidabili e sul tuo server locale. Alla fine finirà per essere molto più economico.
Smetti di portare il tuo a scapito del progetto
Non fare quello che vuoi in un progetto di lavoro, ma fai ciò di cui i clienti hanno bisogno. Sì, è incredibilmente interessante e fantastico creare la propria rete neurale, addestrarla e implementarla nel proprio software, ma se i tuoi clienti hanno bisogno di un semplice gestore di contatti, questo sarà eccessivo. Scopri come funziona il progetto, leggi la documentazione, leggi le recensioni e le richieste dei clienti e implementa ciò che aggiungerà valore aziendale al progetto. Se vuoi creare qualcosa di scientifico o estremamente complesso, inizia con il tuo progetto.
Non un codice, ma un fascio di nervi
Non scrivere codice illeggibile e non documentato. Conosciamo questo trucco: lo sviluppatore scrive il codice a suo piacimento, confondendolo deliberatamente un po' in modo che nessuno dei suoi colleghi possa capire cosa ha scritto: questa è una sorta di vendetta preventiva prima che accada qualcosa. Stai però mettendo a rischio non solo l’azienda (che ti paga per il tuo lavoro), ma anche te stesso: è probabile che tu stesso non ricorderai cosa volevi dire con questo offuscamento involontario. È lo stesso con il codice non documentato: facendo affidamento sulla logica di denominazione delle variabili e delle funzioni e sulla buona memoria, dopo un paio d'anni potresti non ricordare perché hai scelto quel particolare ciclo, metodo, modello, ecc. Documentare il tuo codice e la sua buona struttura è un ottimo servizio per i tuoi colleghi, il tuo datore di lavoro e soprattutto per te stesso.
Rendilo semplice, stupido
Mantieni il codice, le soluzioni e i progetti semplici. Non è necessario recintare una struttura complessa e produrre entità senza significato speciale. Più complesso è il tuo codice, più ne diventi ostaggio: sarà il più difficile possibile per te mantenerlo e svilupparlo. Naturalmente, il famoso principio KISS (“Keep it simple, stupid”) non è sempre adatto, ma è stato creato per un motivo: la semplicità e l’eleganza del codice sono la chiave per la sua applicazione e riutilizzo di successo.
Proteggiti
Non ignorare la sicurezza: nel 2020 è letteralmente criminale. Anche se la tua azienda, il tuo sviluppo e te non interessano agli aggressori, potresti essere interessato da problemi legati alla distruzione di alcuni segmenti di rete, provider di hosting, attacchi al data center, furto di password di posta elettronica e comportamenti non sicuri dei dipendenti che possono rubare dati dall'azienda, rubare clienti o il codice di programma dell'intero progetto. Se è in tuo potere e rientra nella tua area di competenza, cerca di proteggere i progetti su cui stai lavorando. Bene, osserva tu stesso la sicurezza delle informazioni, non ha mai disturbato nessuno.
Non sputare nel pozzo
Non scherzare con il tuo datore di lavoro. Oggi le comunicazioni hanno raggiunto un livello tale che, ad esempio, tutti gli addetti alle risorse umane della città si conoscono in contumacia e possono scambiarsi qualsiasi informazione in chat e gruppi chiusi (sia per aiutare a trovare un lavoro che per scrivere “Vasily Ivanov, architetto di sistema, ha ucciso tutto prima di lasciare gli account, ha cancellato i backup e ha spento la rete, il ripristino ha richiesto 3 giorni. Non assumerlo." Pertanto, il tuo comportamento giocherà esclusivamente contro di te e, a volte, anche il trasferimento in un'altra città o capitale non aiuterà. Anche se te ne vai con rancore, non c'è vendetta migliore che diventare un dipendente utile e simpatico di un concorrente :) E, soprattutto, con completa impunità.
Non dovresti farlo neanche tu. Ma, come dimostra l’esperienza, non ci fermeremo
In generale, amici, leggete i consigli, ma fate quello che pensate sia meglio: dopo tutto, le vere scoperte vengono fatte quando dubitiamo delle verità già scoperte. Buon anno, che i tuoi progetti abbiano successo, che la tua carriera sia piacevole, che i tuoi colleghi e manager siano adeguati e che la tua vita in generale abbia successo. In generale, brindiamo al nuovo anno e al nuovo codice!
Con amore
Il team di RegionSoft Developer Studio
Nel nuovo anno continueremo a lavorare per te e a sviluppare un potente sistema CRM desktop e un help desk e un sistema di ticket semplici e convenienti .
Fonte: habr.com