El centro está lleno de previsiones y consejos sobre qué hacer el próximo año: qué idiomas aprender, en qué áreas centrarse, qué hacer con su salud. ¡Suena inspirador! Pero cada moneda tiene dos caras, y tropezamos no sólo con algo nuevo, sino sobre todo con lo que hacemos todos los días. “¿Por qué nadie me avisó?”, exclamamos irritados, normalmente volviéndonos hacia nosotros mismos. Invoquemos el fuego: hemos compilado para usted una lista de lo que NO debe hacer en 2020 (y tal vez siempre).
Pero no preguntaron sobre la gravedad.
Nos gustaría mucho ordenar las anti-recomendaciones, de las más importantes a las menos importantes. Pero son tan comunes, equivalentes y familiares para casi todo el mundo que los escribiremos al azar. Bueno, ¿revisemos la lista?
No es necesario acudir a TI si todo está bien.
No aprenda una nueva tecnología para cambiar de carrera o empezar de nuevo. Nuestro tiempo es maravilloso porque puedes estudiar, cambiar de trabajo, cambiar radicalmente de campo, etc., incluso hasta la jubilación. Es algo genial y seductor. Pero si tiene entre 28 y 30 años, no debe renunciar a todo para ingresar a TI o pasar a una nueva pila (por ejemplo, escribe sistemas altamente cargados en Java y de repente decide ingresar a las redes neuronales en Python). La razón es simple: no te resultará fácil. En primer lugar, existe una alta competencia por parte de los especialistas que han estado "sentados" en esta pila desde el comienzo de sus carreras, en segundo lugar, tendrás que volver a ser junior con un salario bajo y, en tercer lugar, te resultará moralmente difícil convertirse en un subordinado del nivel más bajo de la jerarquía. Por lo tanto, si desea avanzar en la otra dirección, intente hacerlo de acuerdo con su trabajo actual y sus tareas actuales, o desarrolle nuevos conocimientos como pasatiempo, comience un proyecto favorito para que cuando llegue a un nuevo trabajo pueda Ya no serás un junior.
Cambiar pila tras pila es solo una pérdida de tiempo
No se apresure entre pilas de tecnología para su desarrollo. Si está escribiendo un proyecto en un idioma, utilizando un determinado marco y bibliotecas, no debe tirar todo al infierno y reescribirlo en Dart solo porque lo encuentra interesante. Establezca como regla encontrar una justificación para cambiar la tecnología, no sólo en el nivel "lo quiero o no puedo", sino también en el nivel financiero y de ingeniería.
No hay necesidad de mantenerse firme y volverse bronce
Ceñirse a un idioma o tecnología y no aprender cosas nuevas es tan extremo como cambiar su pila con cada nueva tecnología. Asegúrese de estudiar nuevas bibliotecas y marcos, no sea terco sabiendo que es mejor que todo haya sido inventado antes que usted y completado exclusivamente por usted. Constantemente aparecen actualizaciones para casi todos los idiomas, lo que a veces puede mejorar enormemente su proyecto. ¡No seas perezoso para monitorear la dinámica de tu pila y, tan pronto como encuentres algo interesante y útil, siéntete libre de arrastrarlo al proyecto!
Tu propia cabeza es buena, siempre buena.
No pienses en la cabeza de los demás, la tuya es mejor. Desgraciadamente, algunos desarrolladores se sientan y esperan hasta recibir una tarea para codificar desde el error anterior hasta el final, sin intentar aportar algo propio al proyecto, desarrollar una nueva función, probarla y proponerla para producción. ¿Por qué molestarse cuando hay un líder de equipo o un gerente de empresa que decidirá todo por sí mismo? Si te reconoces, entonces tenemos malas noticias: una posición pasiva no te ayudará ni en tu carrera ni en tu desarrollo. Tienes la oportunidad de probar suerte como ingeniero de desarrollo, y no como codificador, en un proyecto de combate real y comprender adónde ir, qué falta, pero prefieres dedicar tu tiempo a otra cosa y hacerlo exactamente "desde aquí". para ahora." Estas personas sobreviven cada vez peor en las TI modernas, salen de la animación suspendida.
Los usuarios son personas terribles.
No sobreestime a los usuarios de su software: si no está escribiendo para programadores, espere que el programa encuentre malentendidos impenetrables. Los primeros días o semanas el usuario odiará su software porque "el anterior no era tan estúpido". Para evitar esto, cree excelente documentación y tutoriales. Al instalar o comprar, insinúan de manera muy intrusiva que se deben leer los manuales antes de comenzar a trabajar con el programa, y no después de que la base de datos falle, se pierda la contraseña y el autocontrol.
Tampoco debes subestimar a los usuarios: son más astutos, más inteligentes y más curiosos de lo que crees. Si cree que el error con el formato variable y la excepción al presionar Enter 138 a intervalos 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. Se aplica la regla del aficionado: él es quien mejor afronta las pruebas. Pero por alguna razón, a los usuarios no les gusta encontrar errores en producción: no hay solidaridad de TI en ellos. En general, cuanto más confianza tenga en su software, mejor. Después de todo, es mejor retrasar el lanzamiento de algunas funciones que agregarlas a una aplicación que funciona y de repente dejarla sin formato.
¡Deja de buscar en Google!
Deja de recurrir solo a Google. Ni siquiera discutiremos: en el campo del desarrollo se pueden encontrar muchas cosas con una consulta directa a un motor de búsqueda. Cuanto más profundices en busca de información, más datos “laterales” recibirás y más aprenderás, porque aprenderás algo nuevo que no está relacionado con tu solicitud, pero que probablemente será necesario en el futuro. Consulte materiales completos, libros, artículos, etc. Los lenguajes y las bibliotecas tienen especificaciones, comunidades, procedimientos y, por lo tanto, obtiene la forma más confiable de desarrollar habilidades de programador: simplemente lea la documentación y no busque soluciones locales ni fragmentos de código de otras personas. ¿Qué pasa si su solución es más óptima, más rápida y más fresca?
Confía, pero verifica
No utilice bibliotecas ni marcos creados por desarrolladores externos sin verificar el código y adaptarlo a sus propósitos. No tienes ninguna razón para confiar incondicionalmente en este autor del código a quien no conoces en absoluto. Sí, varios elementos maliciosos deliberados en el código de terceros no son tan comunes y no debería sufrir paranoia, pero copiar ciegamente partes de software ya preparadas en su proyecto puede tener consecuencias impredecibles. Por lo tanto, asegúrese de leer y analizar el código antes de usarlo y probarlo después de implementarlo.
¡Haz copias de seguridad!
Deja de hacer copias de seguridad ni de guardarlas en los mismos servidores de terceros donde está alojado tu proyecto. ¿Crees que este es un consejo ridículo e inútil? Pero más de 700 participantes del chat en Telegram, que recientemente se encontraron en una situación desagradable con el cierre de un conocido centro de datos, no lo creían así: allí había de todo: desde proyectos favoritos hasta grandes sitios web gubernamentales. autoridades y bases de datos corporativas 1C y facturación. Una parte importante está sin copias de seguridad o con copias de seguridad en el mismo lugar. Así que distribuya los riesgos y almacene la copia de seguridad al menos en el alojamiento principal, en algún VDS confiable y en su servidor local. Terminará siendo mucho más barato a largo plazo.
Deja de traer lo tuyo en detrimento del proyecto.
No hagas lo que quieras en un proyecto de trabajo, sino lo que los clientes necesitan. Sí, es increíblemente interesante y genial crear tu propia red neuronal, entrenarla e implementarla en tu software, pero si tus clientes necesitan un administrador de contactos simple, esto será excesivo. Vea cómo funciona el proyecto, lea la documentación, lea reseñas y solicitudes de los clientes e implemente lo que agregará valor comercial al proyecto. Si quieres crear algo científico o extremadamente complejo, 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 este truco: el desarrollador escribe código a su antojo, confundiéndolo un poco deliberadamente para que ninguno de sus colegas pueda entender lo que ha escrito; esto es una especie de venganza preventiva antes de que suceda algo. Sin embargo, estás poniendo en riesgo no sólo a la empresa (que te paga dinero por tu trabajo), sino también a ti mismo: es probable que tú mismo no recuerdes lo que querías decir con esta ofuscación involuntaria. Lo mismo ocurre con el código no documentado: dependiendo de su lógica de nomenclatura de funciones y variables y de su buena memoria, es posible que después de un par de años no recuerde por qué eligió ese bucle, método, patrón, etc. en particular. Documentar su código y su buena estructura es un gran servicio para sus colegas, su empleador y, sobre todo, para usted mismo.
Mantenlo simple, estúpido
Mantenga su código, soluciones y proyectos simples. No es necesario encerrar una estructura compleja y producir entidades sin significado especial. Cuanto más complejo sea su código, más rehén se convertirá en él; le resultará lo más difícil posible mantenerlo y desarrollarlo. Por supuesto, el famoso principio KISS ("Keep it simple, estúpido") no siempre es adecuado, pero fue creado por una razón: la simplicidad y elegancia del código son la clave para su aplicación y reutilización exitosas.
Protégete a ti mismo
No ignore la seguridad: en 2020 es literalmente criminal. Incluso si su empresa, su desarrollo y usted no son de interés para los atacantes, puede verse afectado por problemas relacionados con la derrota de algún segmento de red, proveedor de alojamiento, ataque al centro de datos, robo de contraseñas de correo electrónico y comportamiento inseguro de los empleados que pueden robar datos de la empresa, robar clientes o el código de programa de todo el proyecto. Si está en tu poder y dentro de tu área de especialización, intenta proteger los proyectos en los que estás trabajando. Bueno, observe usted mismo la seguridad de la información, nunca ha molestado a nadie.
No escupas en el pozo
No te metas con tu empleador. Hoy en día, la comunicación ha alcanzado tal nivel que, por ejemplo, todo el personal de RR.HH. de la ciudad se conoce en ausencia y puede intercambiar cualquier información en chats y grupos cerrados (tanto para ayudarles a encontrar trabajo como para escribir “Vasily Ivanov, arquitecto del sistema, eliminó todo antes de abandonar las cuentas, eliminó las copias de seguridad y apagó la red, la recuperación tomó 3 días. No lo contrate". Por lo tanto, su comportamiento jugará únicamente en su contra y, a veces, ni siquiera el traslado a otra ciudad o capital le ayudará. Incluso si te vas con rencor, no hay mejor venganza que convertirte en un empleado útil y genial de un competidor :) Y lo más importante, con total impunidad.
Tú tampoco deberías hacer eso. Pero, como demuestra la experiencia, no pararemos
En general, amigos, lean los consejos, pero hagan lo que crean mejor; después de todo, los verdaderos descubrimientos se hacen cuando dudamos de las verdades ya descubiertas. Feliz año nuevo, que sus proyectos tengan éxito, que su carrera sea placentera, que sus colegas y gerentes sean adecuados y que su vida en general sea un éxito. En general, ¡brindemos por el Año Nuevo y el nuevo código!
Con amor,
Equipo de estudio de desarrolladores de RegionSoft
En el nuevo año continuaremos trabajando para usted y desarrollando un potente sistema CRM de escritorio. y un servicio de asistencia y un sistema de tickets sencillo y práctico .
Fuente: habr.com