Habr está lleno de predicciones y consejos sobre qué hacer el próximo año: qué idiomas aprender, en qué áreas restringir, cómo lidiar con su salud. Suena inspirador! Pero cualquier moneda tiene dos caras, y tropezamos no solo en algo nuevo, sino en su mayor parte en lo que hacemos todos los días. "Bueno, ¿por qué nadie me advirtió?", Exclamamos con irritación, generalmente volviéndonos hacia nosotros mismos. Nos provocamos incendios: hemos compilado para usted una lista de lo que NO vale la pena hacer en 2020 (y tal vez siempre).
Y no se le preguntó a la gravedad.Nos gustaría organizar las recomendaciones en orden, desde las más importantes hasta las más insignificantes. Pero están tan extendidos, equivalentes y familiares para casi todos que escribiremos por separado. Bueno, mira la lista?
No es necesario ir a TI si todo está bien
No aprenda nuevas tecnologías para cambiar su profesión o comenzar desde cero. Nuestro tiempo es maravilloso en el sentido de que puedes estudiar, cambiar de trabajo, cambiar fundamentalmente la esfera, e incluso hasta la jubilación. Esto es algo genial y seductor. Pero si tiene más de 28-30, no debe soltar todo para ingresar a TI o irse a una nueva pila (por ejemplo, escribe sistemas altamente cargados en Java y de repente decide abandonar una red neuronal en Python). La razón es simple: no será fácil para usted. En primer lugar, existe una alta competencia por parte de especialistas que han estado sentados en esta pila desde el comienzo de sus carreras, en segundo lugar, nuevamente tendrá que convertirse en un junior con un salario bajo y, en tercer lugar, será moralmente difícil para usted subordinarse al nivel más bajo de la jerarquía. Por lo tanto, si desea avanzar en la otra dirección, intente hacerlo en línea con el trabajo actual y las tareas actuales, o desarrolle nuevos conocimientos como pasatiempo, presente un proyecto favorito para llegar a un nuevo trabajo que ya no es un junior.
Cambiar pila a pila: solo tiempo para perder
No se apresure entre las pilas de tecnología para su desarrollo. Si escribe un proyecto en un idioma, usa un marco específico y bibliotecas, no debe tirar todo al infierno y reescribirlo a Dart, simplemente porque le pareció interesante. Establezca una regla para encontrar una razón para cambiar la tecnología, no solo en el nivel de que no puede, sino también en los niveles financiero y de ingeniería.
No es necesario pararse firme y bronce
Descansar en un idioma o tecnología y no aprender uno nuevo es el mismo extremo que cambiar la pila con cada nueva tecnología. Asegúrese de estudiar nuevas bibliotecas y marcos, no sea terco sabiendo que todo está mejor pensado para usted y dopado exclusivamente por usted. Para casi todos los idiomas, constantemente se publican actualizaciones, que a veces pueden mejorar enormemente su proyecto. ¡No seas perezoso para seguir la dinámica de tu stack y, tan pronto como encuentres algo genial y útil, no dudes en arrastrarte al proyecto!
Tu cabeza es buena, siempre buena
No pienses con las cabezas de otras personas, la tuya es mejor. Por desgracia, algunos desarrolladores están sentados y esperando que reciban la tarea de codificar desde el error anterior hasta el final, sin intentar introducir algo propio en el proyecto, desarrollar una nueva función, probarla y ofrecerla en producción. ¿Por qué molestarse cuando hay un jefe de equipo o una empresa que decidirá todo por sí mismo? Si te reconoces, entonces tenemos malas noticias: una posición pasiva no ayudará ni en una carrera ni en el desarrollo. Tienes la oportunidad de probar suerte con un ingeniero de desarrollo, no con un codificador, en un proyecto de combate real y entender dónde moverte, lo que falta, pero prefieres pasar tu tiempo en otra cosa y hacer exactamente "de ahora en adelante". Tal en TI moderna sobrevive peor y peor, sal de la animación suspendida.
Los usuarios son personas aterradoras
No sobreestime a los usuarios de su software: si no está escribiendo para programadores, espere que el programa encuentre un malentendido impenetrable. Los primeros días o semanas, el usuario odiará su software, porque "el anterior no era tan estúpido". Para evitar esto, haga documentación y materiales de capacitación interesantes. Al instalar o comprar, es muy intrusivo insinuar que los manuales deben leerse antes de comenzar a trabajar con el programa, y no después del bloqueo de la base de datos, la pérdida de contraseña y el autocontrol.
Tampoco subestimes a los usuarios: son más astutos, más inteligentes y más curiosos de lo que piensas. Si cree que ese error con el formato de la variable y ejecutado en la 138a pulsación de Enter con un intervalo de un segundo no aparecerá, está equivocado: aparecerán y afectarán el funcionamiento de su aplicación de la manera más extraña. La regla del aficionado funciona: es él quien se enfrenta mejor a las pruebas. Pero por alguna razón, a los usuarios no les gusta encontrar errores en la producción: no hay solidaridad en ellos. En general, cuanto más confiado esté en su software, mejor. Al final, es mejor retrasar el lanzamiento de algunas funciones que agregarlas a una aplicación en ejecución y hacer que se vuelvan crudas de repente.
¡Deja de buscar en Google!
Deja de acceder a Google solo. Ni siquiera discutiremos: en el campo del desarrollo, una solicitud directa al motor de búsqueda puede encontrar mucho. Cuanto más profundice en la búsqueda de información, más datos “secundarios” obtendrá y aprenderá más, porque aprenderá algo nuevo, no relacionado con su solicitud, pero que probablemente sea necesario en el futuro. Diríjase a materiales completos, libros, artículos, etc. Los idiomas y las bibliotecas tienen especificaciones, una comunidad, cómo hacerlo, por lo que obtienes la forma más confiable de desarrollar las habilidades de tu programador: solo lee la documentación y no busques soluciones locales y fragmentos de código de otras personas. ¿Qué pasa si su decisión será mejor, más rápida y más fresca?
Confía pero verifica
No use bibliotecas y marcos creados por desarrolladores externos sin verificar el código o adaptarlo para sus propios fines. No tiene ninguna razón para confiar incondicionalmente en este autor de código que no conoce en absoluto. Sí, varios elementos maliciosos intencionales en el código de terceros no son tan comunes y no vale la pena sufrir la paranoia, pero la copia oculta de partes terminadas del software en su proyecto puede tener consecuencias impredecibles. Por lo tanto, asegúrese de leer y analizar el código antes de usarlo y realizar pruebas después de la implementación del código.
¡Haz copias de seguridad!
Deje de no hacer copias de seguridad o mantenerlas en los mismos servidores de terceros donde se aloja su proyecto. ¿Piensa en consejos divertidos y vanos? Pero más de 700 participantes en el chat de Telegram que cayeron en una situación desagradable reciente con la parada de un centro de datos conocido no lo creían, lo que no estaba allí: desde proyectos favoritos hasta grandes sitios web estatales. organismos y bases corporativas 1C y facturación. Una parte importante: sin copias de seguridad o con copias de seguridad en el mismo lugar. Por lo tanto, distribuya los riesgos y almacene la copia de seguridad al menos en el alojamiento principal, en algunos VDS confiables y en su servidor local. Al final, saldrá mucho más barato.
Deja de traer el tuyo en detrimento del proyecto
No haga lo que quiere en un borrador de trabajo, sino lo que los clientes necesitan. Sí, es increíblemente interesante y genial crear su propia red neuronal, entrenarla e implementarla en su software, pero si sus clientes necesitan un administrador de contactos simple, será un exceso costoso. Vea cómo funciona el proyecto, lea la documentación, lea las revisiones y aplicaciones de los clientes e implemente lo que le dará valor comercial al proyecto. Si quieres crear algo científico o súper complicado, comienza con tu propio proyecto.
No es un código, sino un manojo de nervios.
No escriba código ilegible e indocumentado. Estamos familiarizados con esta característica: el desarrollador escribe el código cuando Dios se lo pone al alma, deliberadamente lo confunde un poco para que ninguno de los colegas pueda descifrar lo que está escrito, una venganza preventiva tan peculiar antes de que algo sucediera. Sin embargo, corre el riesgo no solo de la empresa (que le paga dinero por el trabajo), sino también de usted mismo: es probable que usted mismo no recuerde lo que quería decir con esta ofuscación involuntaria. Lo mismo con el código no documentado: confiando en su lógica para nombrar variables y funciones y buena memoria, después de un par de años puede que no recuerde por qué eligió este bucle, método, patrón, etc. particular. Documentar el código y su buena estructura es un servicio genial para colegas, el empleador y, sobre todo, para sí mismo.
Mantenlo simple, estúpido
No compliques el código, las decisiones y los proyectos. No es necesario cercar una estructura compleja y producir entidades sin un significado especial. Cuanto más complejo sea su código, más se convertirá en su rehén: será extremadamente difícil para usted mantenerlo y desarrollarlo. Por supuesto, el famoso principio KISS (“Mantenlo simple, estúpido”) no siempre es adecuado, pero fue creado no en vano: la simplicidad y elegancia del código es la clave para su aplicación y reutilización exitosas.
Cuidado
No ignore la seguridad: en 2020 es literalmente criminal. Incluso si su empresa, el desarrollo y usted no están interesados en intrusos, puede verse afectado por problemas asociados con la derrota de un segmento de red, un proveedor de alojamiento, un ataque a un centro de datos, el robo de contraseñas de correo y el comportamiento inseguro de los empleados que podrían robar datos de la empresa, retirar clientes o el código del programa de todo el proyecto. Si está dentro de su poder y pertenece al área de competencia, intente proteger los proyectos con los que trabaja. Bueno, observe la seguridad de la información usted mismo, esto no ha molestado a nadie.
No escupir en el pozo
No leas a tu empleador. Hasta la fecha, las comunicaciones han alcanzado un nivel tal que, por ejemplo, todos los recursos humanos de la ciudad están familiarizados entre sí en ausencia y pueden intercambiar cualquier información en salas de chat y grupos privados (cómo ayudar a encontrar un trabajo y escribir "Vasily Ivanov, un arquitecto de sistemas, mató todo antes de irse cuentas, copias de seguridad borradas y desconectado de la red, la recuperación tomó 3 días. No lo lleve a trabajar "). Por lo tanto, su comportamiento jugará exclusivamente en su contra, y a veces incluso la reubicación a otra ciudad o capital no ayudará. Incluso si te vas con resentimiento, no hay mejor venganza que convertirte en un empleado útil y genial de un competidor :-) Y lo más importante, completamente impune.
Tampoco vale la pena hacerlo. Pero, como lo demuestra la experiencia, no nos detendremosEn general, amigos, lean los consejos, pero hagan lo que mejor les parezca, porque se hacen descubrimientos reales cuando dudamos de las verdades que ya se han descubierto. Feliz año nuevo, deje que sus proyectos sean exitosos, una carrera no aburrida, colegas y gerentes adecuados, y la vida como un todo exitosa. En general, para el año nuevo y para el nuevo código!
Con amor
Equipo de RegionSoft Developer StudioEn el nuevo año, continuaremos trabajando para usted y desarrollaremos el poderoso sistema de CRM de escritorio RegionSoft CRM y el sencillo y conveniente servicio de ayuda y sistema de tickets ZEDLine Support .