Habr está lleno de pronósticos y consejos sobre qué hacer el próximo año: qué lenguajes aprender, en qué campos concentrarse, cómo cuidar de la salud. ¡Suena inspirador! Pero como cualquier moneda, tiene dos caras, y tropezamos no solo con algo nuevo, sino en su mayoría con lo que hacemos todos los días. "¡¿Por qué nadie me advirtió?!", exclamamos irritados, generalmente dirigiéndonos a nosotros mismos. Atraemos fuego sobre nosotros: hemos recopilado una lista de cosas que NO deberías hacer en 2020 (o tal vez siempre).
Y la gravedad no fue consultada.
Nos gustaría mucho ordenar las anti-recomendaciones de lo más importante a lo menos significativo. Pero son tan comunes, equivalentes y familiares que casi todos los conocen, que lo escribiremos de manera aleatoria. Entonces, ¿revisaremos la lista?
No debes entrar en IT si todo va bien.
No aprendas una nueva tecnología solo para cambiar de profesión o empezar desde cero. Nuestro tiempo es increíble porque puedes seguir aprendiendo, cambiar de trabajo, cambiar radicalmente de campo, y así hasta la jubilación. Es algo genial y tentador. Pero si tienes más de 28-30 años, no deberías dejar todo para entrar en IT o cambiar a un nuevo stack (por ejemplo, si programas sistemas altamente cargados en Java y de repente decides cambiarte a redes neuronales en Python). La razón es simple: te resultará difícil. En primer lugar, hay alta competencia de expertos que han estado en ese stack desde el inicio de su carrera; en segundo lugar, tendrás que convertirte nuevamente en junior con un salario bajo; y en tercer lugar, te será moralmente difícil ser subordinado en el nivel más bajo de la jerarquía. Por lo tanto, si deseas avanzar en otra dirección, intenta hacerlo ya sea en línea con tu trabajo actual y tareas actuales, o desarrolla nuevos conocimientos como un hobby, trabaja en un proyecto paralelo para llegar a un nuevo trabajo ya no como junior.
Cambiar de stack solo es perder tiempo.
No te saltes entre stacks de tecnologías para tu desarrollo. Si estás escribiendo un proyecto en un lenguaje, utilizando un framework y bibliotecas específicos, no deberías dejarlo todo y reescribirlo en Dart solo porque te pareció interesante. Tómalo como regla encontrar justificación para cambiar de tecnología, no solo a nivel de 'quiero-no puedo', sino también a nivel financiero y de ingeniería.
No es necesario quedarse en lo suyo y volverse rígido.
Aferrarse a un solo idioma o tecnología y no aprender cosas nuevas es tan extremo como cambiar de stack con cada nueva tecnología. Asegúrate de estudiar nuevas bibliotecas y frameworks, no seas terco al pensar que todo lo mejor ya fue creado antes que tú y perfeccionado exclusivamente por ti. Prácticamente para cada lenguaje hay actualizaciones constantes que a veces pueden mejorar significativamente tu proyecto. No te dejes llevar por la pereza de seguir la dinámica de tu stack y, en cuanto encuentres algo impresionante y útil, ¡incorpóralo con confianza a tu proyecto!
La propia cabeza es buena, siempre es buena.
No pienses con la cabeza de otros, la tuya es mejor. Lamentablemente, algunos desarrolladores se sientan y esperan recibir órdenes para codificar desde el error anterior hasta el final, sin intentar aportar algo propio al proyecto, desarrollar una nueva función, probar y ofrecer al producción. ¿Por qué esforzarse cuando hay cabezas de team leaders o jefes de empresa que decidirán todo por ti? Si te reconoces en esto, tenemos malas noticias: una posición pasiva no te ayudará ni en tu carrera ni en tu desarrollo. Tienes la oportunidad de probar tus habilidades como ingeniero desarrollador, no como simple codificador en un proyecto real y entender hacia dónde avanzar, qué te falta, pero prefieres gastar tu tiempo en otra cosa y hacer exactamente "de esto a esto". En la actualidad, quienes actúan de esta manera sobreviven cada vez peor, sal de tu letargo.
Los usuarios son personas temibles.
No sobreestimes a los usuarios de tu software: si no estás escribiendo para programadores, cuenta con que el programa enfrentará una incomprensión abrumadora. Los primeros días o semanas, el usuario odiará tu software porque "el antiguo no era tan tonto". Para evitar esto, crea buena documentación y materiales de formación. Al instalar o comprar, insinúa de forma muy insistente que los manuales deben leerse antes de comenzar a trabajar con el programa, y no después del colapso de la base de datos, pérdida de contraseña y autocontrol.
No subestimes a los usuarios: son más astutos, inteligentes y curiosos de lo que piensas. Si crees que ese error con el formato de la variable y la excepción en el 138º intento de presionar Enter cada segundo no saldrá a la luz, estás equivocado: sí saldrá y afectará el funcionamiento de tu aplicación de maneras muy peculiares. Funciona la regla del aficionado: él es quien mejor se encarga de las pruebas. Pero a los usuarios no les gusta encontrar errores en producción, no hay ninguna solidaridad IT en ello. En resumen, cuanto más seguro estés de tu software, mejor. Al final, es mejor retrasar el lanzamiento de algunas funciones que añadirlas a una aplicación en funcionamiento y hacer que de repente esté cruda.
¡Basta de buscar en Google!
Deja de depender únicamente de Google. No vamos a discutirlo, en el campo del desarrollo, una búsqueda directa puede arrojar muchos resultados. Cuanto más profundices en tu búsqueda de información, más datos ‘laterales’ obtendrás y aprenderás más, porque estarás descubriendo cosas nuevas que no están relacionadas con tu consulta, pero que probablemente serán útiles en el futuro. Consulta materiales completos, libros, artículos, etc. Los lenguajes y bibliotecas tienen especificaciones, comunidades, guías, y así obtienes la manera más fiable de desarrollar las habilidades de un programador: simplemente leyendo la documentación, en lugar de buscar soluciones locales de otros y fragmentos de código. ¿Y si tu solución resulta ser más óptima, más rápida y mejor?
Confía, pero verifica
No utilices bibliotecas y frameworks creados por desarrolladores externos sin verificar el código y adaptarlo a tus objetivos. No tienes ninguna razón para confiar incondicionalmente en este autor de código que no conoces. Sí, varios elementos maliciosos intencionados en el código externo no son tan comunes y no hay que preocuparse en exceso, pero copiar sin pensar fragmentos listos de software para tu proyecto puede llevar a consecuencias imprevisibles. Así que asegúrate de leer y analizar el código antes de usarlo y realiza pruebas después de implementar el código.
¡Haz copias de seguridad!
Deja de no hacer copias de seguridad o de mantenerlas en los mismos servidores externos donde está alojado tu proyecto. ¿Crees que es un consejo ridículo y sin sentido? Más de 700 participantes en un chat de Telegram que se encontraron en una desagradable situación con la parada de un conocido centro de datos no lo pensaron así: hubo de todo, desde proyectos personales hasta grandes sitios de organismos gubernamentales y bases corporativas de 1C y de facturación. Una parte significativa, sin copias de seguridad o con copias de seguridad guardadas allí mismo. Así que distribuye los riesgos y guarda una copia de seguridad al menos en el alojamiento principal, en algún VDS confiable y en tu propio servidor local. Al final, esto resultará mucho más económico.
Deja de poner tus intereses en detrimento del proyecto.
No hagas en un proyecto en funcionamiento lo que a ti te gustaría, sino lo que necesitan los clientes. Sí, es increíblemente interesante y genial crear tu propia red neuronal, entrenarla e integrarla en tu software, pero si tus clientes necesitan un simple gestor de contactos, eso será un lujo costoso. Observa cómo funciona el proyecto, lee la documentación, revisa los comentarios y solicitudes de los clientes y ejecuta lo que aporte valor comercial al proyecto. Si deseas crear algo científico o extremadamente complejo, comienza con tu propio proyecto.
No es código, es un buen lío de nervios.
No escribas código ilegible y sin documentación. Conocemos este truco: el desarrollador escribe código como Dios le da a entender, lo enreda un poco para que ninguno de sus colegas pueda entenderlo, como una especie de venganza preventiva antes de que algo ocurra. Sin embargo, pones en riesgo no solo a la empresa (que te paga por tu trabajo), sino también a ti mismo: es muy probable que tú mismo no recuerdes qué querías decir con esa ofuscación no intencionada. Lo mismo ocurre con el código no documentado: al confiar en tu propia lógica de nombramiento de variables y funciones y en tu buena memoria, después de un par de años puedes no recordar por qué elegiste ese ciclo, método, patrón, etc. Documentar el código y tener una buena estructura es un gran servicio para los colegas, el empleador y, sobre todo, para uno mismo.
Mantenlo simple, estúpido.
No compliquen el código, las soluciones y los proyectos. No es necesario construir una estructura complicada y crear entidades sin relevancia. Cuanto más complicado sea su código, más se convertirá en su prisionero: le será muy difícil mantenerlo y desarrollarlo. Por supuesto, el famoso principio KISS («Keep it simple, stupid») no siempre es aplicable, pero no fue creado sin razón: la simplicidad y la elegancia del código son la clave para su aplicación y reutilización exitosa.
Protéjanse
No ignoren la seguridad: en 2020 esto es literalmente un crimen. Incluso si su empresa, desarrollo o ustedes no son de interés para los atacantes, pueden verse afectados por problemas relacionados con un segmento de la red, un proveedor de hosting, un ataque a un centro de datos, el robo de contraseñas de correo y el comportamiento inseguro de los empleados, quienes pueden robar datos de la empresa, clientes o el código de todo el proyecto. Si está en sus manos y corresponde a su área de competencia, intente proteger los proyectos con los que trabaja. Y, por supuesto, cumpla con la seguridad de la información, eso no ha perjudicado a nadie.
No escupas en el pozo
No perjudique a su empleador. Hoy en día, las comunicaciones han alcanzado un nivel en el que, por ejemplo, todos los recursos humanos de la ciudad se conocen entre ellos y pueden intercambiar cualquier información en chats y grupos cerrados (ya sea para ayudar en la búsqueda de empleo o para decir: «Vasili Ivanov, arquitecto de sistemas, al irse borró todas las cuentas, eliminó las copias de seguridad y desconectó la red, la recuperación tardó 3 días. No lo contraten»). Así, su comportamiento será en su contra, y a veces cambiar de ciudad o de capital no ayudará. Incluso si se va enojado, no hay mejor venganza que ser un empleado útil y genial del competidor 🙂 Y lo más importante, completamente sin consecuencias.
Tampoco es correcto hacer eso. Pero, como muestra la experiencia, no dejaremos de hacerlo
En general, amigos, lean los consejos, pero hagan lo que consideren mejor, ya que los verdaderos descubrimientos ocurren cuando dudamos de las verdades ya establecidas. Les deseamos un Feliz Año Nuevo, que sus proyectos sean exitosos, su carrera no aburrida, colegas y jefes razonables, y que la vida en general les salga bien. ¡Por el Nuevo Año y por un nuevo código!
Con cariño,
el equipo de RegionSoft Developer Studio
En el nuevo año, seguiremos trabajando para usted y desarrollando un potente sistema CRM de escritorio. y un helpdesk simple y conveniente, así como un sistema de tickets. .
Fuente: habr.com
