En The Clean Coder: un código de conducta para programadores profesionales, Martin presenta las disciplinas, técnicas, herramientas y prácticas de verdadera destreza en software.
Este libro está repleto de consejos prácticos sobre todo, desde la estimación y la codificación hasta la refactorización y la prueba. Cubre mucho más que técnica: se trata de la actitud.
Martin muestra cómo abordar el desarrollo de software con honor, amor propio y orgullo; trabaja bien y trabaja limpio; comunicar y estimar fielmente; enfrentar decisiones difíciles con claridad y honestidad; y entiendo que el conocimiento profundo viene con la responsabilidad de actuar. Vamos, que ser desarrollador de software es ser como un samurai, tenemos nuestros códigos morales que deberían impedirnos escribir código sucio.
Martin coloca en este libro varias lecciones:
- Lo que significa comportarse como un verdadero artesano del software
- Cómo lidiar con conflictos, horarios ajustados y gerentes poco razonables (¡que abundan!)
- Cómo entrar en el flujo de codificación y superar el bloqueo del escritor
- Cómo manejar una presión implacable y evitar el agotamiento (ya saben, el famoso "trabajo bajo presión", es decir fechas límite poco razonables)
- Cómo combinar actitudes duraderas con nuevos paradigmas de desarrollo (combinar actitud con aptitud)
- Cómo administrar su tiempo y evitar callejones sin salida, marismas, pantanos y cagaderos (¡no te escandalices!)
- Cómo fomentar entornos donde los programadores y equipos pueden prosperar
- Cuándo decir "No" y cómo decirlo
- Cuándo decir "Sí", y lo que sí realmente significa.
El gran software es algo para maravillarse: potente, elegante, funcional, un placer para trabajar como desarrollador y como usuario.
El gran software no está escrito por máquinas. Está escrito por profesionales (personas) con un compromiso inquebrantable con el arte. Escribir código limpio te ayudará a convertirte en uno de ellos y ganarte el orgullo y la satisfacción que solo ellos poseen.
Eso es el resumen "oficial". Ampliemos las lecciones:
Lección: No hacer daño
El software es demasiado complejo para crearlo sin errores. Un software que no tenga errores no existe o no hace prácticamente nada.
Sin embargo, un programador debe ser responsable de los errores, aunque los errores sean prácticamente inocuos. Las disculpas son necesarias, pero insuficientes. No puedes seguir cometiendo los mismos errores una y otra vez. A medida que madures en tu profesión, tu tasa de error debería disminuir rápidamente hacia cero. Es tu responsabilidad acercarte lo más posible.
Lo que significa que QA no debe encontrar nada.
Algunas personas usan al área de QA como los atrapamoscas. Les envían un código que no han revisado minuciosamente (es horrible pero sucede). Este comportamiento es simplemente perezoso e irresponsable ("otros deberían probarlo porque yo no sé"). Libera código que sabes que no funciona correctamente no es profesional.
Debes saber que funciona.
Pruébalo. Pruébalo de nuevo. Y una vez más.
Cada vez que el control de calidad (QA) encuentra algo, el equipo de desarrollo debe reaccionar con horror. Deben preguntarse cómo sucedió y tomar medidas para prevenirlo en el futuro.
Lección: Ética de trabajo
No es responsabilidad de tu empleador asegurarse de que seas comercializable, que seas valorado en el mercado. No es responsabilidad de tu empleador entrenarte (lamentablemente, pero así es), enviarte a conferencias o comprarte libros. Estas cosas son tu responsabilidad.
Debes planear trabajar 60 horas a la semana. Los primeros 40 son para tu empleador. Los 20 restantes son para ti. Durante las 20 horas restantes, debes leer, practicar, aprender y, lo que sea que contribuya a mejorar tu carrera.
Lección: Tutoría
La mejor manera de aprender es enseñar (y yo la verdad que no sé enseñar, me falta aprender a enseñar). Nada generará hechos y valores en tu cabeza más rápido y más difícil que tener que comunicarlos a las personas por las que eres responsable. Es decir, si puedes llegar a explicarle un tema a alguien, y ese alguien te entiende, significa que tú entiendes, ¿entiendes?.
Lección: Buen código
Primero, tu código debe funcionar. Debes comprender qué problema estás resolviendo y comprender cómo resolver ese problema. Debes asegurarte de que el código que escribes sea una representación fiel de esa solución. Debes administrar cada detalle de esa solución sin dejar de ser coherente dentro del lenguaje, la plataforma, la arquitectura actual y todas las verrugas (o callos) del sistema actual.
Tu código debe resolver el problema establecido por el cliente (que el cliente tiene la razón en un 90 por ciento). A menudo, los requisitos del cliente en realidad no resuelven los problemas del cliente. Depende de ti ver esto y asegurarte de que se cumplan las verdaderas necesidades del cliente.
Tu código debe encajar bien en el sistema existente. No debe aumentar la rigidez, fragilidad u opacidad de ese sistema. En resumen, tu código debe seguir sólidos principios de ingeniería.
Tu código debe ser legible por otros programadores. Requiere que escribas el código de tal manera que revele su intención. Esto puede ser lo más difícil que un programador puede llegar a dominar.
Lección: Codifica a las 3 AM
No es cierto, pero si cuando y donde puedas hacerlo sin distracciones. Cuando no puedes concentrare y enfocarte lo suficiente, el código que escribas será incorrecto. Tendrá errores. Tendrá una estructura incorrecta. Será opaco y complicado. No resolverá los problemas reales de los clientes. En resumen, tendrá que volverse a trabajar o volver a hacer. Trabajar distraído crea desperdicios.
Lección: Falsa entrega
Lo peor que puede hacer como programador es decir que ha terminado cuando sabe que no lo está.
Lección: Pedir ayuda
Aprende cómo pedir ayuda. Cuando estás atrapado, confundido o simplemente no puedes resolver tu problema, pídele ayuda a alguien. Esta es una cuestión de ética profesional.
No es profesional quedarse estancado cuando hay ayuda disponible. No temas preguntar. A veces se deben vencer barreras culturales pero preguntar no hace daño a nadie.
La colaboración es fundamental para una programación efectiva.
Lección: Esfuerzo de equipo
Como profesional, es tu trabajo ayudar a tu equipo a crear el mejor software que se pueda. Todos deben estar atentos a errores y deslices, y trabajar juntos para corregirlos.
Lección: Reuniones
Usa tu tiempo sabiamente.
Cuando recibas una invitación a una reunión, no la aceptes a menos que sea una reunión para la cual tu participación es inmediata y significativamente necesaria para el trabajo que estás realizando ahora (esto es lo ideal, ya sabemos que a veces las reuniones se convoca a gente que luego no pudo participar en ningun tema).
Cuando la reunión se vuelva aburrida, salte de ella. Tienes la obligación de administrar bien tu tiempo (tu vida).
Lección: Reuniones Stand-up
- ¿Qué hice ayer?
- ¿Qué voy a hacer hoy?
- ¿Qué hay en mi camino?
Cada pregunta no debería tomar más de veinte segundos. Si no es posible reunirte con alguien, reunete contigo mismo y preguntate lo mismo.
Lección: Prioridades
Los profesionales evalúan la prioridad de cada tarea, haciendo caso omiso de sus miedos y deseos personales, y ejecutan esas tareas en orden de prioridad.
Lección: Pantanos
Los profesionales temen mucho más los desarreglos que los callejones sin salida. Siempre están atentos a los líos que comienzan a crecer sin ataduras y gastarán todos los esfuerzos necesarios para escapar de ellos lo más pronto y lo más rápido posible.
Mantén tus sistemas, tu código y tu diseño lo más limpios posible.
Lección: Compromisos
Los desarrolladores de software profesional no hacen promesas que no pueden cumplir, y no hacen compromisos que no están seguros de que puedan cumplir (no temas decir no).
Lección: Arte
Un artesano es alguien que trabaja rápido, pero sin prisa, que proporciona estimaciones razonables y cumple los compromisos. Un artesano sabe cuándo decir que no, pero se esfuerza por decir que sí.
0 Comentarios