El centre està ple de previsions i consells sobre què fer l'any que ve: quins idiomes aprendre, en quines àrees centrar-se, què fer amb la vostra salut. Sona inspirador! Però cada moneda té dues cares, i ensopeguem no només amb alguna cosa nova, sinó sobretot amb el que fem cada dia. "Per què ningú em va avisar?", exclamem irritats, normalment girant-nos cap a nosaltres mateixos. Cridem-nos a nosaltres mateixos: hem compilat per a vosaltres una llista del que NO heu de fer el 2020 (i potser sempre).
Però no van preguntar per la gravetat
Ens agradaria molt posar en ordre les anti-recomanacions, de les més importants a les menys importants. Però són tan comuns, equivalents i familiars a gairebé tothom que escriurem a l'atzar. Bé, revisem la llista?
No cal anar a TI si tot està bé
No apreneu una nova tecnologia per canviar de carrera o començar de nou. El nostre temps és meravellós perquè pots estudiar, canviar de feina, canviar radicalment el teu camp... i així successivament, fins i tot fins a la jubilació. És una cosa fresca i seductora. Però si teniu entre 28 i 30 anys, no hauríeu de renunciar a tot per entrar a TI o passar a una pila nova (per exemple, escriviu sistemes molt carregats en Java i de sobte decideix entrar a les xarxes neuronals a Python). El motiu és senzill: no us serà fàcil. En primer lloc, hi ha una gran competència d'especialistes que han estat "asseguts" en aquesta pila des del començament de la seva carrera, en segon lloc, haureu de tornar a ser un júnior amb un sou baix i, en tercer lloc, us serà difícil moralment convertir-se en un subordinat del nivell més baix de la jerarquia. Per tant, si vols avançar en l'altra direcció, intenta fer-ho d'acord amb el teu treball actual i les tasques actuals, o desenvolupar nous coneixements com a afició, inicia un projecte per a mascotes perquè quan arribis a una nova feina ja no serà un júnior.
Canviar de pila rere pila és només una pèrdua de temps
No us precipiteu entre les piles de tecnologia per al vostre desenvolupament. Si esteu escrivint un projecte en un idioma, utilitzant un marc i biblioteques determinats, no hauríeu de tirar-ho tot a l'infern i reescriure-lo a Dart només perquè us resulti interessant. Feu que sigui una regla trobar una justificació per canviar la tecnologia, no només a nivell "Ho vull o no puc", sinó també a nivell financer i d'enginyeria.
No cal mantenir-se ferm i convertir-se en bronze
Adherir-se a un idioma o tecnologia i no aprendre coses noves és tan extrem com canviar la pila amb cada tecnologia nova. Assegureu-vos d'estudiar noves biblioteques i marcs, no us tossudeu en saber que tot va ser millor inventat abans que vosaltres i completat exclusivament per vosaltres. Contínuament surten actualitzacions per a gairebé tots els idiomes, cosa que de vegades pot millorar molt el vostre projecte. No tingueu mandra controlar la dinàmica de la vostra pila i, tan bon punt trobeu alguna cosa interessant i útil, no dubteu a arrossegar-la al projecte!
El teu propi cap és bo, sempre bo
No pensis en el cap dels altres, el teu és millor. Per desgràcia, alguns desenvolupadors s'asseuen i esperen fins que rebin una tasca per codificar des de l'error anterior fins al final, sense intentar aportar alguna cosa pròpia al projecte, desenvolupar una nova funció, provar-la i proposar-la per a la producció. Per què molestar-se quan hi ha un cap d'equip o un responsable de l'empresa que ho decidirà tot ells mateixos? Si et reconeixes, tenim una mala notícia: una posició passiva no t'ajudarà ni en la teva carrera ni en el teu desenvolupament. Tens l'oportunitat de provar la teva mà com a enginyer de desenvolupament, i no com a programador, en un projecte de combat real i entendre a on anar, què falta, però prefereixes dedicar el teu temps a una altra cosa i fer exactament "d'aquí a ara.” Aquestes persones sobreviuen cada cop pitjor a la informàtica moderna, surten de l'animació suspesa.
Els usuaris són persones terribles
No sobreestimeu els usuaris del vostre programari: si no esteu escrivint per a programadors, espereu que el programa trobi un malentès impenetrable. Els primers dies o setmanes l'usuari odiarà el vostre programari perquè "l'antic no era tan estúpid". Per evitar-ho, feu una bona documentació i tutorials. Quan instal·leu o compreu, insinueu de manera molt intrusiva que els manuals s'han de llegir abans de començar a treballar amb el programa, i no després que la base de dades es bloquegi, la pèrdua de la contrasenya i l'autocontrol.
Tampoc hauríeu de subestimar els usuaris: són més astuts, intel·ligents i curiosos del que penseu. Si creieu que l'error amb el format variable i l'excepció a la 138a premsa d'Enter a intervals d'un segon no apareixerà, us equivoqueu: apareixeran i afectaran el funcionament de la vostra aplicació de la manera més estranya. S'aplica la regla de l'aficionat: ell és el que millor s'enfronta a les proves. Però per alguna raó, als usuaris no els agrada trobar errors a la producció: no hi ha solidaritat informàtica. En general, com més confiat tinguis en el teu programari, millor. Al cap i a la fi, és millor retardar el llançament d'algunes característiques que afegir-les a una aplicació que funcioni i, de sobte, convertir-les en brut.
Deixa de Google!
Deixa de recórrer només a Google. Ni tan sols discutirem: en el camp del desenvolupament, podeu trobar moltes coses amb una sol·licitud directa a un motor de cerca. Com més aprofundis a la recerca d'informació, més dades "laterals" rebràs i més n'aprendràs, perquè aprendràs alguna cosa nova que no està relacionada amb la teva sol·licitud, però que probablement serà necessària en el futur. Consulteu materials, llibres, articles complets, etc. Els idiomes i les biblioteques tenen especificacions, comunitats, com fer-ho i, per tant, obteniu la manera més fiable de desenvolupar habilitats de programador: només cal que llegiu la documentació i no busqueu solucions locals ni fragments de codi d'altres persones. Què passa si la vostra solució és més òptima, més ràpida i més fresca?
Confia però verifica
No utilitzeu biblioteques i marcs creats per desenvolupadors de tercers sense comprovar el codi i adaptar-lo als vostres propòsits. No teniu cap motiu per confiar incondicionalment en aquest autor de codi que no coneixeu en absolut. Sí, diversos elements maliciosos deliberats en codi de tercers no són tan comuns i no hauríeu de patir paranoia, però copiar cegament parts del programari ja fetes al vostre projecte pot tenir conseqüències imprevisibles. Per tant, assegureu-vos de llegir i analitzar el codi abans d'utilitzar-lo i provar-lo després d'implementar el codi.
Feu còpies de seguretat!
Deixeu de no fer còpies de seguretat ni mantenir-les als mateixos servidors de tercers on està allotjat el vostre projecte. Creus que aquest és un consell ridícul i inútil? Però més de 700 participants de xat a Telegram, que es van trobar en una situació desagradable recentment amb l'aturada d'un centre de dades conegut, no ho van pensar: hi havia de tot: des de projectes per a mascotes fins a grans llocs web del govern. autoritats i bases de dades corporatives 1C i de facturació. Una part important és sense còpies de seguretat o amb còpies de seguretat al mateix lloc. Així que distribuïu els riscos i emmagatzemeu la còpia de seguretat almenys a l'allotjament principal, en alguns VDS fiables i al vostre servidor local. A la llarga acabarà sent molt més barat.
Deixeu de portar el vostre en detriment del projecte
No facis el que vulguis en un projecte de treball, sinó el que necessiten els clients. Sí, és increïblement interessant i fantàstic crear la vostra pròpia xarxa neuronal, entrenar-la i implementar-la al vostre programari, però si els vostres clients necessiten un simple gestor de contactes, això serà un excés. Vegeu com funciona el projecte, llegiu la documentació, llegiu ressenyes i sol·licituds dels clients i implementeu el que afegirà valor comercial al projecte. Si vols crear quelcom científic o extremadament complex, comença amb el teu propi projecte.
No és un codi, sinó un paquet de nervis
No escriviu codi il·legible i no documentat. Estem familiaritzats amb aquest truc: el desenvolupador escriu codi al seu gust, confonent-lo deliberadament una mica perquè cap dels seus col·legues pugui entendre el que ha escrit: aquesta és una mena de venjança preventiva abans que passi alguna cosa. No obstant això, estàs posant en risc no només l'empresa (que et paga diners per la teva feina), sinó també a tu mateix: és probable que tu mateix no recordis el que volies dir amb aquesta ofuscació involuntària. Passa el mateix amb el codi no documentat: basant-vos en la vostra lògica de denominació de variables i funcions i una bona memòria, al cap d'un parell d'anys potser no recordeu per què vau triar aquest bucle, mètode, patró, etc. Documentar el vostre codi i la seva bona estructura és un gran servei per als vostres companys, el vostre empresari i, sobretot, per a vosaltres mateixos.
Sigues-ho senzill, estúpid
Manteniu el vostre codi, solucions i projectes senzills. No cal tancar en una estructura complexa i produir entitats sense una importància especial. Com més complex sigui el vostre codi, més us convertireu en el seu ostatge; us serà el més difícil possible mantenir-lo i desenvolupar-lo. Per descomptat, el famós principi KISS ("Keep it simple, stupid") no sempre és adequat, però es va crear per una raó: la senzillesa i l'elegància del codi són la clau per a la seva aplicació i reutilització amb èxit.
Protegiu-vos
No ignoreu la seguretat: el 2020 és literalment criminal. Fins i tot si la teva empresa, desenvolupament i tu no són d'interès per als atacants, pots veure't afectats per problemes relacionats amb la derrota d'algun segment de la xarxa, proveïdor d'allotjament, atac al centre de dades, robatori de contrasenyes de correu electrònic i comportament insegur dels empleats que poden robar dades de l'empresa, robar clients o el codi del programa de tot el projecte. Si està a les vostres mans i dins de la vostra àrea d'expertesa, intenteu protegir els projectes en què esteu treballant. Bé, observeu vosaltres mateixos la seguretat de la informació, mai no ha molestat a ningú.
No escopis al pou
No et fiquis amb el teu empresari. Avui dia, les comunicacions han arribat a tal nivell que, per exemple, totes les persones de RRHH de la ciutat es coneixen en absència i poden intercanviar qualsevol informació en xats i grups tancats (tant per ajudar a trobar feina com per escriure “Vasily Ivanov, arquitecte de sistemes, va matar-ho tot abans de deixar els comptes, va suprimir còpies de seguretat i va apagar la xarxa, la recuperació va trigar 3 dies. No el contractis." Per tant, el vostre comportament només jugarà en contra vostre, i de vegades fins i tot el trasllat a una altra ciutat o capital no ajudarà. Fins i tot si marxes amb rancúnia, no hi ha millor venjança que convertir-te en un empleat útil i genial d'un competidor :) I el més important, amb total impunitat.
Això tampoc ho hauries de fer. Però, com demostra l'experiència, no ens aturarem
En general, amics, llegiu els consells, però feu el que creieu millor; després de tot, es fan descobriments reals quan dubtem de veritats ja descobertes. Feliç Any Nou, que els vostres projectes tinguin èxit, que la vostra carrera sigui agradable, que els vostres companys i directius siguin adequats i que la vostra vida en general tingui èxit. En general, aquí teniu l'Any Nou i el nou codi!
Amb amor,
Equip de RegionSoft Developer Studio
El nou any continuarem treballant per a vosaltres i desenvoluparem un potent sistema CRM d'escriptori i un taulell d'ajuda i un sistema de bitllets senzills i còmodes .
Font: www.habr.com