💕 🏇🏿 👂🏾 Ocho hábitos importantes del programador 👼🏾 ♻️ 🤞🏾

“Una persona puede convertirse en una persona solo a través de la educación. Él es lo que la educación hace de él ".
I. Kant

En mi opinión, esta cita es muy adecuada para programadores. De hecho, un programador no es solo un especialista bien versado en cuestiones técnicas. Un programador es, antes que nada, un artesano que crea código todos los días utilizando su conocimiento. Crear un buen código es imposible sin el uso disciplinado de ciertas habilidades. Y este uso regular es lo que son los hábitos.

Dio la casualidad de que los malos hábitos nos impiden vivir y trabajar, y los buenos aumentan la productividad, y en general una persona disfruta más de la vida. Si hace esfuerzos y comienza a adquirir y bombear buenos hábitos, muy pronto comenzará a notar cómo se convierte en un especialista de un nivel superior. Pero eso no es todo, sus colegas también notarán rápidamente los cambios para mejor, y esto los obligará a aprender y adoptar técnicas útiles. Cuando trabajas con código en un equipo, puedes leer la actitud de la persona para trabajar en cada commit.

Entonces, repasemos los ocho hábitos útiles de un programador que lo convertirán en el mejor profesional.

1. No repitas (SECO - No te repitas)

Probablemente se encontró con el hecho de que, mirando la siguiente sección de código, piensa: "Hmm, aquí ya hice algo similar, pero con diferentes argumentos, y en general había una matriz de datos diferente".

Esto debería ser una llamada para que este código se repita en el futuro, nuevamente con pequeños cambios en las condiciones y los datos. Pero si no presta atención a esta señal o tiene prisa, lo más probable es que vuelva a escribir el algoritmo desde cero cuando se necesite una solución similar en el futuro. Gradualmente, dichos algoritmos se acumularán, el código crecerá y, al final, perderá por completo la motivación para realizar ediciones y mejoras en tales fideos.

Por lo tanto, desarrolle un buen hábito de seguir el principio SECO (No repetir). Siempre que se encuentre escribiendo un algoritmo similar, tómese el tiempo para pensar en varias opciones posibles con diferentes entidades. Organice una pequeña función genérica o incluso una clase si el algoritmo es complejo. Esto llevará un poco más de tiempo que escribir una solución rápida para una tarea específica, pero ahorrará una cantidad increíble de horas en el futuro para la depuración y prueba.

Gradualmente, se acumulará en usted una biblioteca completa de tales espacios en blanco, y puede usarlos fácilmente en cualquier proyecto.

La programación en su conjunto consiste en esfuerzos tan pequeños que se realizan en el proceso. Apriete un poco más de lo que se requiere actualmente. Entonces comenzarás a crecer.

Hay una lista completa de principios similares que son muy útiles para cumplir. Pero, en mi opinión, DRY es fundamental para todo lo demás en el trabajo de un programador.

2. Una vez que haya decidido que todo está hecho, refactorice

La mayoría de los programadores, especialmente los principiantes, creen que su trabajo se realiza tan pronto como el código comienza a realizar la tarea según lo previsto. Solo que ahora la palabra "hecho" incluye un concepto más amplio que la escritura trivial de código.

¿El código funciona correctamente? ¡Si! Entonces, ¿cuál es el trato?

Si eso es correcto. Justo antes de pasar a la siguiente tarea, revise lo que escribió. Desde el principio hasta el final. Lo más probable es que observe que algunas variables se declaran en un lugar inconveniente y no está claro por qué son necesarias. También puede haber una línea demasiado larga que no cabe en la pantalla, lo que significa que aquí debe pensar en cómo hacerla más bella. O la función resultó ser demasiado voluminosa y puede dividirse en un par de partes.
Piensa en las personas que leerán tu código en el futuro. Si les gusta este código o no la cerveza no lo pueden entender.

Tome una decisión hermosa, no solo una que funcione. Al igual que los buenos escritores después de escribir un borrador: leen su trabajo varias veces y tiran partes innecesarias para que al lector le guste y capte el punto sin tener que entrar en demasiados detalles.

Recomiendo leer a Robert Martin sobre este tema . Un libro esclarecedor que debería estar en la biblioteca de cada programador.

3. Centrarse en las tareas empresariales.

Muchos programadores tienden a centrarse en estudiar el aspecto técnico de su trabajo y creen que los negocios no tienen nada que ver con ellos. Lo principal es dar buenas especificaciones técnicas, y luego haré todo de la mejor manera posible. Solo para convertirse en un verdadero maestro de su oficio, debe comprender por qué lo que está haciendo se ha llevado el negocio.

Si es muy grosero imaginar un programador que trabaje exclusivamente en TK sin comprender la esencia, entonces se puede dar un ejemplo. El conductor del autobús, al lado del cual se sientan los pasajeros y le dice: "Gire a la izquierda, gire a la derecha, ahora a la derecha". Y así los pasajeros "conducen" el autobús. Pero si el conductor toma la iniciativa y pregunta: "¿A dónde debo ir?", Entonces el pasajero puede simplemente decir: "Vamos a la ciudad N", y todo se vuelve mucho más fácil. El conductor conoce el destino final y puede, utilizando su experiencia, construir independientemente una ruta y decirse a sí mismo dónde y cómo girar.

Curiosamente, pero muchos programadores no se molestan en comprender el propósito del proyecto. Y, por un lado, puedes entender este punto de vista, porque programar es un trabajo mental muy difícil. A veces, el conocimiento de su instrumento ocupa una parte tan grande en la mente que simplemente no hay suficientes recursos para todo lo demás. Resulta que los programadores, como los conductores en un tanque sin una ventana de visualización, solo pueden girar las perillas cuando el comandante de la tripulación los golpea.

Además, comprender el problema comercial no le permitirá sumergirse en el desarrollo de algo completamente innecesario en un momento dado. Por ejemplo, si la tarea es hacer una función que ayude a compilar estadísticas al pasar las pruebas, entonces, sabiendo que esta no es una tarea crítica para el rendimiento, ya no necesita perder tiempo en la optimización innecesaria y acelerar el algoritmo. De todos modos, esto no afectará el resultado final. Las pruebas solo serán ejecutadas por desarrolladores, y solo una vez por semana.

Otro ejemplo, si el programa tiene una función que todos los usuarios ejecutan varias veces al día, tiene sentido gastar más esfuerzo en encontrar la versión ideal de esta función y su accesibilidad ideal en la interfaz. Aquí ya no puede perder tiempo.

Pero, como puede ver, desde el punto de vista de un programador que no está familiarizado con las tareas comerciales, ambas tareas parecerán equivalentes.

Para una mejor comprensión, le aconsejo que lea el libro "Comience con por qué" de Simon Sinek .

4. Pequeñas confirmaciones

El hecho de que un programador necesita usar un sistema de seguimiento de versiones, creo, es obvio. Quiero hablar sobre otro hábito muy útil: hacer compromisos tan a menudo como sea posible y en las porciones más pequeñas posibles. Al mismo tiempo, agregue comentarios significativos y útiles a cada confirmación.

A menudo, los programadores principiantes e incluso los más experimentados al final del día hacen un esfuerzo con todos los archivos modificados y algún tipo de comentario inútil como "solucionar problema29". O "solucionó un error en la solicitud". Nadie de tal descripción entenderá lo que se hizo específicamente. Y cuando llega el momento de fusionar un compromiso tan grande en una rama común, el propietario del repositorio, en primer lugar, oculta mentalmente al desarrollador perezoso. En segundo lugar, si se produce un conflicto durante la fusión, es probable que el propietario simplemente revierta este compromiso y no lo acepte. ¿Quién quiere obtener una parte de los errores por el hecho de que no entendió qué condición resultó ser superflua al resolver conflictos manualmente?

Por otro lado, si presiona regularmente sus cambios una vez por hora y proporciona a cada confirmación una descripción más detallada, para que en el futuro sea fácil, sin mirar el código, comprender qué cambió y qué consideraciones tuvo sobre estos cambios, entonces alcanzará un nuevo nivel de comprensión de la filosofía general de escribir código. Ahora no solo "reparará el primus", ahora se convertirá en parte del equipo creativo y se comunicará con sus colegas a través de sus compromisos, como en un chat. Este será un diálogo significativo.

Como literatura, recomiendo leer al menos el primer capítulo del libro "Git for a Professional Programmer" de Scott Chacon y Straub Ben. Cuando descubres qué funciones maravillosas hay en Git y de lo que es capaz, entonces solo queda comprometerse con más frecuencia, y el resto se puede resolver con las herramientas necesarias.

5. Cuenta el tiempo

Cualquier trabajo tiene un principio y un final. La efectividad de un programador se mide en el número de horas necesarias para resolver ciertos problemas. Cuanto más rápido se resuelvan las tareas, mejor. Esto es bastante obvio y no requiere ninguna explicación.

Pero hay otro lado de esta evidencia, que a menudo elude a los programadores: debe calcular con precisión el tiempo dedicado a la solución. No es lo que siente cuando se sienta en el trabajo de nueve a cinco, entremezclado con sellos y reuniones. Y el presente es tu trabajo.
Al principio, desarrollé el hábito de contar el tiempo simplemente escribiendo informes sobre lo que hice durante el día y calculando un tiempo aproximado. Incluso entonces, calculé aproximadamente que solo obtengo 4 horas de 8 para trabajar de manera efectiva.

Y luego instaló programas especiales que contaban el tiempo automáticamente. Al principio usé www.rescuetime.com . Gracias a este programa, vi que las redes sociales, aunque me parecieron un desperdicio menor, realmente arruinaron mi imagen de rendimiento. Al final, decidí deshabilitar el acceso a algunos sitios por completo durante las horas de trabajo. Para esto, también hay complementos especiales en el navegador.

Se requirió el siguiente paso en el seguimiento del tiempo cuando decidí arreglar el tiempo exacto de trabajo con el código del programa. Para esto, primero probé hubstaff.com . Resultó que es una solución bastante costosa si la usas cuando trabajas en equipo.

Luego probé wakatime.com. Y resultó ser esa bala de plata. Este servicio tiene la capacidad de integrarse en todos los IDE populares, así como la integración con github. Como resultado, puede determinar con precisión hasta un minuto cuántos minutos útiles dedicó a programar. Además, hay un enlace a commits. Es maravilloso cuando puede ver no solo los compromisos en sí, sino también descubrir el tiempo dedicado a este compromiso.
Una sorprendente colección de recetas para la correcta organización del tiempo y el trabajo en los proyectos se encuentra en el libro "Técnicas Jedi" de Maxim Dorofeev .

6. La estabilidad es un signo de dominio.

Como probablemente ya haya entendido, puede desarrollar sin cesar sus habilidades y capacidades. Lo que hiciste hace un año puede parecer ridículo y sin pretensiones en términos de tu nueva experiencia. Usted, por supuesto, tendrá formas mejoradas de escribir expresiones complejas.
Pero entre todo esto, debe desarrollar el hábito de apegarse a ciertas reglas. Incluso si no te parecen completamente resueltos, utiliza estos métodos de trabajo en todas partes.

Usando el ejemplo de código: si decide usar un esquema específico para nombrar variables o usar espacios en lugar de pestañas, entonces siga este principio constantemente. No necesita probar un nuevo estilo cada semana e intentar aplicar nuevas prácticas avanzadas. Entonces solo pierdes tu enfoque.

El problema con la inconstancia es que el tiempo destruye cualquier producto de software. Cuanto más tiempo trabajen unas pocas personas en el programa, más cambios se realizarán en el proceso, lo que finalmente creará caos. Si cada uno de los miembros del equipo no cumple con un acuerdo específico.

Entonces, ¿qué hay que hacer para cumplir con el principio de constancia?

Lo primero que debe adoptar es adherirse a un estilo definitivamente en el código. En los editores de JetBrains , me gusta mucho la herramienta que indica la calidad de su código. Solía tener miedo de tantas advertencias, pero cuando comienzas a seguir el consejo de un linter de manera disciplinada, entonces el código se vuelve claro y estéticamente agradable.

También estudie la literatura sobre cómo nombrar clases, métodos y variables. Recomiendo el libro "Código perfecto" de Steve McConnell.

En un momento, leí este libro durante media hora por la noche, cuando todos los demás ya se iban de casa. El libro estaba en la biblioteca de la oficina. Solo un par de meses después, vi todo el horror que había codificado antes de ese momento. Tuve que introducir gradualmente nuevas técnicas y realizar refactorizaciones.

7. Hazlo una vez

"Lo arreglaré un poco más tarde". Cada uno de nosotros se pronunció esto cuando encontramos un error en nuestro código o una condición insuficientemente correcta para procesar en un bucle. Y cada uno de nosotros sabe que este "arreglo más tarde" y luego permanece en el código en forma de comentariosque hacer. Y cuando tú mismo ves comentarios de código en el estiloque hacer, solo significa que alguien no sigue el principio de "hacer aquí y ahora". En el momento en que se escribió este comentario, lo más probable es que el programador entienda muy bien cuál es el problema y cómo solucionarlo. Porque está en el contexto de la tarea actual. Pero si vuelve a esta sección del código más adelante, será más difícil entender por qué se requirió tal reserva.
Por lo tanto, crea un hábito muy importante para ti mismo: resolver la solución desde cero hasta que la tarea se complete por completo. La más completa, porque no es realista cubrir todas las opciones con un cien por ciento. Pero al menos no dejes espacio para estosque hacer-comentarios. Después de todo, si se le ocurrió y se tomó el tiempo para comentar, significa que para el siguiente paso, la implementación, queda muy poco.

Una buena manera de entender que realmente ha terminado este código es crear una prueba para verificar varias condiciones entrantes.

8. Nunca dejes de aprender

Al parecer, esta es una habilidad obvia que necesita cualquier especialista, no solo un programador. Pero, desafortunadamente, muchos se olvidan de él. A veces, le pregunto a mis amigos que participan en la programación, qué libros han leído recientemente. A menudo, muchos comienzan a recordar con dificultad lo que leyeron hace uno o dos años. Al mismo tiempo, dominaron un par de trucos en la universidad o en algunos cursos y lo usan todo el tiempo.

Sin embargo, si en una esfera de desarrollo tan rápido se detiene al menos una vez al mes para familiarizarse con una nueva herramienta, tecnología o un concepto interesante, entonces, después de un tiempo, es posible que literalmente no entienda lo que está sucediendo en el presente.

Esto me pasó una vez. Desarrollé un producto exitoso y lo vendí por un tiempo. Por supuesto, escuché historias sobre nuevos marcos, pero no les presté mucha atención. Estaba profundamente inmerso en el desarrollo y el apoyo de su solución.

Solo cuando disminuyó el flujo de clientes me di cuenta de que mi producto necesitaba ser modernizado. Y luego me encontré con una gran barrera. Solía usar solo PHP y muy raramente funciones AJAX. Y para comprender los marcos modernos React, Angular, Vue JS, necesitaba pasar urgentemente alrededor de un año para estudiarlos a través de los libros. Lo más interesante es que si hubiera dedicado suficiente tiempo a la capacitación antes, entonces mi producto no perdería competitividad. Era solo que, en lugar de admitir funciones antiguas, era necesario aprender nuevas e introducir tecnologías gradualmente, y no en un modo de emergencia.

Conclusión

Incluso si tiene un cien por ciento de confianza en sus habilidades, recuerde que no hay límite para la perfección. No dejes de hacerte preguntas provocativas. Admita que en algunas áreas no tiene suficiente capacitación o no conoce los puntos sutiles en los marcos familiares, pero le gustaría conocerlos. Pasar un par de horas y ejecutar la versión de prueba directamente desde github en el servidor local ahora es muy fácil.

En experimentos tan pequeños, entrenarás tus habilidades y desarrollarás todos los hábitos importantes.

Ocho hábitos importantes del programador