Sigo teniendo la vieja edición original de Octubre de 1999. Y, a pesar de existir una edición más nueva por el vigésimo aniversario, es, definitivamente, un libro que se lleva fantástico con el paso del tiempo.

Leí por ahí que tal vez no sea el libro ideal para aquellos que se inician en la programación, ¿o sí? Aquellos que estén dando sus primeros pasos en el mundo de la programación tal vez se encuentren con tópicos algo crípticos, pasajes muy técnicos o avanzados, pero el mensaje seguro que llega. Para aquel que tiene algo de experiencia, es ideal, porque complementa la formación. Y debería ser obligatoria su relectura para todo programador avanzado. 

Personalmente lamento no haberlo releído antes…

Si te interesa la programación, estás aprendiendo a programar o ya sabés programar, deberías tenerlo. Y leerlo. Y releerlo. 

Pueden encontrarlo acá, junto con muchas otras cosas muy interesantes: pragprog.com

Algo particular de esta relectura fueron las numerosas retrospectivas y flashbacks que me surgieron. Situaciones muy puntuales olvidadas en un rincón remoto de la memoria de hace 10, 15 o hasta 20 años atrás. Discusiones. Festejos. Reproches. Proyectos. Empresas. Jefes. Amigos… 

Pero lo que más me sorprendió es el enfoque ÁGIL de los tips, del libro, de las argumentaciones en general. 

Hoy, la “agilidad” está absolutamente instalada a nivel de prácticas de desarrollo y gestión de proyectos y personas en la industria del software. El paradigma ágil domina y ofrece un enfoque superador a las metodologías tradicionales, predictivas. Y esto está presente a lo largo de todo el libro. Un libro publicado un año y medio ANTES de la firma del Manifiesto Ágil (agilemanifesto.org/iso/es/manifesto.html). ESE es un valor en sí mismo. Porque es fácil de ver ahora, con 20 años de historia transcurridos. Pero es lo que refuerza la idea del valor, por la visión de Hunt y Thomas (ambos firmantes originales del Manifiesto). Una visión que marca la actual época, el state of the art de la programación. Visionarios es poco. Gurúes les quedaría mejor. 

Dividí las ideas extraídas en estas categorías:

• Forma de pensar del programador: el funcionamiento de la cabeza del programador no es algo que podamos definir como “normal”. El programador analiza, estructura, agrupa, optimiza su trabajo, pero también su día a día. Desde la forma en se prepara el desayuno hasta cómo hace las compras en el súper
• Gestión de proyectos: todo programador (salvo aquel que está haciendo un desarrollo propio para sí mismo) trabaja en el contexto de un proyecto, equipo u organización que requiere mantener ciertos parámetros de orden y procesos, sean más o menos ágiles, más o menos formales, más o menos cumplidos… 🙂
• Herramientas: se usa software para desarrollar software. Se usan herramientas para crear otras herramientas. Pero también “útiles”, procesos, metodologías y prácticas, automatizaciones… 
• Calidad de código: es el objetivo final, poder crear un software de calidad que cumpla con las expectativas del usuario, satisfaga una necesidad del cliente e implique un beneficio para el desarrollador de ese software. 

Aquí vamos, con una traducción libre (con el perdón del Colegio de Traductores 😐 ) desde el original en inglés:

1) Forma de pensar del programador

“(…) depende de ti (programador) proporcionar soluciones, no excusas”

“En lugar de excusas, brinda opciones. No digas que no se puede hacer; explicar qué se puede hacer para salvar la situación.”

“Nuestro objetivo es pensar de manera declarativa (especificando qué se debe hacer, no cómo) y crear programas altamente dinámicos y adaptables. Hacemos esto adoptando una regla general: programa para el caso general, y colocamos los detalles en otro lugar, fuera de la base del código compilado.”

“Realmente no importa si el error es culpa tuya o de otra persona. Sigue siendo tu problema.”

“Si le das a tus usuarios algo con lo que jugar en forma temprana, sus comentarios a menudo te llevarán a una mejor solución eventual”

“CADA PIEZA DE CONOCIMIENTO DEBE TENER UNA REPRESENTACIÓN INDIVIDUAL, SIN AMBIGÜEDADES Y AUTOMÁTICA EN UN SISTEMA.”

“Una técnica muy simple pero particularmente útil para encontrar la causa de un problema es simplemente explicárselo a otra persona.”

“La metáfora de la jardinería está mucho más cerca de las realidades del desarrollo de software (en comparación con la arquitectura o construcción). Quizás una determinada rutina ha crecido demasiado o está tratando de lograr demasiado: debe dividirse en dos. Las cosas que no funcionan según lo planeado deben ser desmalezadas o podadas.”

“Hay una técnica simple para cumplir con los requisitos de los usuarios que no se usa con la suficiente frecuencia: convertirse en usuario. ¿Estás escribiendo un sistema para la mesa de ayuda? Pasa un par de días monitoreando los teléfonos con una persona de soporte con experiencia. ¿Estás automatizando un sistema de control de stock manual? Trabaja en el almacén durante una semana.”

“Cuando sientas una duda persistente, o experimentes cierta reticencia al enfrentar una tarea, presta atención. Es posible que no puedas identificar exactamente qué está mal, pero dale tiempo y tus dudas probablemente se cristalizarán en algo más sólido, en algo que puedas abordar”

“El desarrollo de software todavía no es una ciencia. Deja que tus instintos contribuyan a tu trabajo.”

“Un diseño que deja al codificador sin espacio para la interpretación roba el esfuerzo de programación de cualquier habilidad y arte.”

“A menudo, es sólo durante la codificación que ciertas opciones se vuelven aparentes.”

“Los buenos desarrolladores tienden a ser apasionados por su trabajo.”

2) Gestión de proyectos

“Los proyectos de forma lenta e inexorable se salen completamente de control. La mayoría de los desastres de software comienzan siendo demasiado pequeños para darse cuenta, y la mayoría de los desbordes en los proyectos ocurren día a día. Los sistemas se desvían de sus especificaciones característica por característica, mientras que parche tras parche se agrega a un código hasta que no queda nada del original.”

“Con el soporte adecuado, puedes programar mucho más cerca del dominio de la aplicación. No estamos sugiriendo que tus usuarios finales realmente programen en estos (meta) lenguajes. En cambio, te estás dando (“regalando”) una herramienta que te permite trabajar más cerca de su dominio.”

“Debes considerar formas de acercar tu proyecto al dominio del problema. Al codificar en un nivel superior de abstracción, puedes concentrarte en resolver problemas del dominio y puedes ignorar los pequeños detalles de implementación.”

“Esto puede no ser popular entre los gerentes, que generalmente quieren un número puro y duro (y rápido) antes de que el proyecto incluso comience. Deberás ayudarlos a comprender que el equipo, su productividad y el entorno determinarán el cronograma. Al formalizar esto y refinar la programación como parte de cada iteración, les darás las estimaciones de programación más precisas que puedas.”

“Qué decir cuando se le pide un presupuesto? Dices ‘me pondré en contacto contigo’.”

“Nadie en la breve historia de la informática ha escrito una pieza de software perfecta.”

“Cuando el sistema falle, ¿fallará con ‘elegancia’?”

3) Herramientas

“Elige un editor (de textos), conócelo a fondo y úsalo para todas las tareas de edición. Si usas un solo editor (o conjunto de teclas) en todas las actividades de edición de texto, no tienes que detenerse a pensar cómo manipular el texto: las pulsaciones de teclas necesarias serán un reflejo”

“Siempre. Incluso si eres un equipo de una sola persona en un proyecto de una semana. Incluso si es un prototipo “desechable”. Incluso si las cosas en las que estás trabajando no son código fuente. Asegúrese de que todo esté bajo control del código fuente”

“Nunca subestimes el costo de adoptar nuevas herramientas y métodos. Debes estar preparado para afrontar los primeros proyectos utilizando lo nuevo como una experiencia de aprendizaje.”

“¿Deberíamos usar métodos formales? Absolutamente. Pero recuerda siempre que los métodos formales de desarrollo son solo una herramienta más en la caja de herramientas.”

“Los programadores pragmáticos analizan las metodologías de manera crítica, luego extraen lo mejor de cada una y las combinan en un conjunto de prácticas de trabajo que mejora cada mes. Esto es crucial”

 4) Calidad de código

“No dejes “ventanas rotas” (malos diseños, decisiones incorrectas o código deficiente) sin reparar. Arregla cada una tan pronto como sea descubierta.”

“Debes tender a ver el relevamiento de requisitos, el diseño y la programación como diferentes facetas del mismo proceso: la entrega de un sistema de calidad”

“Dos o más cosas son ortogonales si los cambios en una no afectan a ninguna de las otras. En un sistema bien diseñado, el código de la base de datos será ortogonal a la interfaz de usuario: puede cambiar la interfaz sin afectar la base de datos e intercambiar bases de datos sin cambiar la interfaz.”

“Una de las ventajas de detectar problemas lo antes posible es que puedes ´romperlo´ en forma temprana. Y muchas veces, ‘romper’ tu programa es lo mejor que puedes hacer.”

“Debido a que los programadores pragmáticos no confían en nadie, incluidos sí mismos, creemos que siempre es una buena idea construir código que realmente verifique que los recursos se hayan liberado adecuadamente.”

“Organiza tu código en celdas (módulos) y limita la interacción entre ellas. Si un módulo se ve comprometido y tiene que ser reemplazado, los otros módulos deberían poder continuar.”

“No solo prueba tu código, sino también prueba sus suposiciones. No adivines; en realidad inténtalo. Escribe una afirmación para probar tus suposiciones. Si tu afirmación es correcta, ha mejorado la documentación en tu código. Si descubres que tu suposición es errónea, considérate afortunado.”

“En esencia, la refactorización es el rediseño. Todo lo que tu u otros miembros de tu equipo diseñaron se puede rediseñar a la luz de nuevos hechos, entendimientos más profundos, requisitos cambiantes, etc.”

“No hay mejor manera de corregir errores que evitándolos en primer lugar. De hecho, al construir los casos de pruebas antes de implementar el código, puedes probar la interfaz antes de comprometerte con ella.”

“Todo el software que escriba será probado, si no es por ti y tu equipo, lo será por los usuarios finales”

“Las pruebas (testing) son más culturales que técnicas; podemos inculcar esta cultura de prueba en un proyecto independientemente del lenguaje (de programación) que se utilice.”

“La mayoría de los desarrolladores odian las pruebas (testing). Tienden a probar levemente, sabiendo inconscientemente dónde se romperá el código y evitando los puntos débiles (el “camino feliz”). Los programadores pragmáticos son diferentes. Estamos obligados a encontrar nuestros errores ahora, por lo que no tendremos que soportar la vergüenza de que otros encuentren nuestros errores más tarde.”

“En primer lugar, el código nunca está ‘terminado’ realmente. Más importante aún, no puedes afirmar que puede ser utilizado por nadie hasta que pase todas las pruebas disponibles.”

“Una vez que un ‘tester humano’ encuentra un error, debería ser la última vez que un ‘tester humano’ encuentra ESE error. Las pruebas automáticas deberán modificarse para asegurar que ese error en particular, a partir de ese momento, nunca más ocurra.”

“Comentar el código fuente le brinda la oportunidad perfecta para documentar esos escurridizos fragmentos de un proyecto que no se pueden documentar en ningún otro lugar: discusiones de ingeniería, por qué se tomaron decisiones, qué otras alternativas se descartaron, etc.”

“Tu firma debe ser reconocida como un indicador de calidad.”

Es, en esencia, la descripción del “trabajador pragmático”.

Autor: Emilio Rasic (Emilio es egresado de los Posgrados PBA y Management Estratégico)

Fuente: emiliorasic.com https://www.emiliorasic.com/de-pragmaticos-y-programadores-depende-de-ti-proporcionar-soluciones-no-excusas/