De qué hablo cuando hablo de programar (volumen 2)

Por Rafael Gómez Blanes

No es lo mismo programar que desarrollar una carrera profesional como programador.

En este segundo volumen de "De Qué Hablo Cuando Hablo de Programar", Rafael Gómez Blanes recopila una selección de los artículos más visitados y vinculados en su web (www.rafablanes.com).

Corregidos, revisados y hasta elaborados de nuevo, y enriquecidos con su experiencia de los últimos años, cada capítulo aborda un aspecto diferente del desarrollo de software.

Al igual que el primer volumen, el contenido de este libro es imprescindible para cualquier desarrollador amateur, júnior o sénior: desde por qué se produce la deuda técnica, cómo documentar correctamente un proyecto software, cómo reconocer a un mal gestor y por qué es útil realizar paradas técnicas y retrospectivas hasta cómo trabajar con mejor orden y con ciertas habilidades de desarrollo personal, aspectos que te ayudarán, sin duda, a ser mejor profesional y avanzar más rápido en tu carrera.

En palabras del mismo autor: "Este es uno de esos libros que me hubiese gustado leer tan pronto como terminé mi etapa académica, habría cometido menos errores, progresado mucho más rápido y con menos dificultades".

Por el autor de El Libro Negro del Programador, El Libro Práctico del Programador Ágil, Legacy Code, The Coder Habits, El Arte del Emprendedor Digital y otros.

Lista de capítulos:

INTRODUCCIÓN
1. DECÁLOGO DE UNA APLICACIÓN NO PROFESIONAL
2. NO DEJES QUE SER UN BUEN TÉCNICO TE ARRUINE
3. LA CALIDAD Y LA GESTIÓN DE PROYECTOS SOFTWARE
4. IDEAS CONTRAINTUITIVAS EN EL DESARROLLO DE SOFTWARE
5. LA TIRANÍA DEL SIEMPRE-DISPONIBLE
6. PRODUCTOS VS PROYECTOS
7. LA TEORÍA DE LA ÚLTIMA MILLA
8. POR QUÉ EL SOFTWARE SE CORROMPE
9. 15 AÑOS DE EXPERIENCIA... REPETIDA
10. REFINAMIENTO CONTINUO
11. SOBRE LA ADMINISTRACIÓN Y EL MANTENIMIENTO
12. ACUMULA LECCIONES APRENDIDAS
13. EL PODER DE LAS PEQUEÑAS TAREAS
14. REFACTORIZAR PARA GANAR VELOCIDAD
15. ESCUCHA ACTIVAMENTE A TUS CLIENTES
16. SÓLO LOS PRINCIPIOS PERMANECEN
17. EMPRENDIENDO PROYECTOS DE SOFTWARE
18. DESARROLLANDO PARA EL CORTO O EL LARGO PLAZO
19. PRIMERO EL "QUÉ", DESPUÉS EL "CÓMO"
20. CUÁNDO DESPLEGAR UNA NUEVA SOLUCIÓN
21. UNA GESTIÓN DE TAREAS SENCILLA Y EFICAZ
22. EXCEL, MAILS, TARES Y FLUJOS DE TRABAJO
23. SOBRE EL RENDIMIENTO
24. LA SEGURIDAD FORMA PARTE DEL DISEÑO
25. COMO UNA NOVELA
26. CUIDADO CON LO QUE LEES
27. UN PROYECTO COMIENZA POR SUS REQUISITOS
28. PRINCIPIOS SÓLIDOS
29. EL HÁBITO DE PROCEDIMENTAR
30. CÓMO USAR REPOSITORIOS DE DATOS
31. FRAMEWORKS CORPORATIVOS
32. DE QUÉ HABLO CUANDO HABLO DE PROGRAMAR

• Idioma: Español
• Editorial: Rafael Gómez Blanes
• Fecha de lanzamiento: 3 nov 2021
• ISBN: 9781005312947

Rafael Gómez Blanes

Rafael Gómez Blanes es Ingeniero Informático por la Universidad de Sevilla (España). Infoemprendedor, ha trabajado en proyectos software internacionales relacionados con el sector eléctrico. Desarrollador profesional desde el año 1998, es experto en clean code y todas aquellas prácticas metodológicas que incrementan la productividad, mejorando la calidad del software generado. Evangelista de software ágil, dirige actualmente un equipo de desarrollo en una compañía de ingeniería realizando productos para la gestión de smart meters y su despliegue en la nube en modo SaaS (software as a service).

Vista previa del libro

De qué hablo cuando hablo de programar

Volumen 2

Cómo avanzar mejor y más rápido en tu carrera como desarrollador

Rafael Gómez Blanes

Primera edición - Noviembre de 2021 - #01#

De qué Hablo cuando Hablo de Programar. Volumen 2 - Copyright © 2021

Todos los derechos reservados

Rafael Gómez Blanes

www.rafablanes.com

ISBN: 9798758133118

Hub de Libros: Plataforma de Publicación Abierta

www.hubdelibros.com

A mis padres, hermana y mis hijas, Luna y Beatriz

A mi pareja Mercedes

Introducción

No es lo mismo programar que desarrollar una carrera profesional como programador.

Este es el segundo y último volumen de «De qué hablo cuando hablo de programar». Al igual que el primero, recoge una serie de artículos que he ido publicando regularmente en mi web (www.rafablanes.com) y que ahora presento revisados totalmente, mejorados y enriquecidos con varios años más de experiencia a mis espaldas. Todos forman un conjunto compacto, al igual que los del primer volumen.

El tiempo que ha pasado desde que escribí esos artículos, algunos hace bastantes años, y las experiencias que he tenido desde entonces, me ha demostrado una y otra vez la validez de los mismos, y también me ha dado la oportunidad de profundizar aún más en todos los conceptos de los que hablo en este trabajo.

Además, durante estos dos últimos años he dedicado bastante tiempo a formación de equipos de desarrollo para diversas compañías sobre «arquitectura» y «calidad de software». Entre otras responsabilidades, también he realizado varias mentorías personales muy satisfactorias para mí.

Compruebo, por tanto, una y otra vez, que hay ciertos aspectos de esta profesión en sus diferentes ámbitos que no están bien descritos en la literatura técnica y en aquellos trabajos bien conocidos en nuestro sector, la mayoría más enfocados a «lo técnico».

También compruebo cómo errores y deficiencias similares se repiten de un equipo a otro.

Me encuentro con CTOs que aún creen que el testing es un lujo y no una necesidad, desarrolladores con muchos años de experiencia (pero repetida) incapaces de cambiar de paradigma de trabajo, líderes de equipos que contratan a júniors esperando que aprendan en meses lo que en realidad se tarda años en aprender (si es que existe la voluntad suficiente para ello, claro está), y organizaciones que aún creen que la organización prusiana del trabajo funciona para todo tipo de actividades.

El desarrollo de software va mucho más allá de comprender bien un lenguaje de programación particular.

Ciertos aspectos del software son extraordinariamente sutiles y, sus consecuencias, difíciles de comprender con facilidad.

Detalles, detalles y más detalles, aunque parezcan insignificantes.

En software, la acumulación de pequeños defectos, por pequeños que sean, en la calidad del código, en el diseño y hasta en la organización y en la planificación, termina generando un producto o proyecto de mala calidad y con una deuda técnica que lo hará más costoso o difícil de mantener y de evolucionar.

Sobre todos estos aspectos trata directa e indirectamente este segundo volumen de «De qué hablo cuando hablo de programar» que espero que te guste tanto como yo he disfrutado durante todo el tiempo que he dedicado a este nuevo libro.

Rafael Gómez Blanes

Sevilla, noviembre de 2021

1

Decálogo de una aplicación no profesional

Escribir un buen proyecto software siguiendo aceptablemente las buenas prácticas, no es para nada ninguna ciencia oculta lejos de nuestro alcance. Y mucho menos, suponen un coste extra. El peor coste proviene de la falta de profesionalidad, que no te quepa la menor duda. Lamentablemente, me temo que me he encontrado con más proyectos comerciales mal hechos (y hasta tremendamente mal desarrollados) que lo contrario.

En una ocasión, hace bastantes años, me pidieron que evaluara una sencilla tienda online para estimar el coste y esfuerzo necesarios para añadirle nuevas características (y de paso corregir algunos detalles que no funcionaban bien) y, para mi sorpresa, me encontré con algo que es habitual en nuestro sector: aplicaciones que están mal planteadas, mal hechas, escritas de cualquier forma, a pesar de que con ella el cliente final había facturado en el último año más de veinte mil euros en pedidos. Con esto quiere decir que aunque el proyecto fuese discreto, para el cliente era importante puesto que parte de sus ingresos venían de él.

En nuestra profesión, termina por ser recurrente el siguiente ejemplo: cuando compramos un coche, nos interesamos por muchos de sus acabados, prestaciones y, cómo no, detalles de su mecánica interna (fabricante del motor, etc); del mismo modo, para la construcción de una casa se necesita la firma de un arquitecto colegiado (al menos en España) cuya función se supone que es la de supervisar todos los aspectos técnicos de la construcción (más el trabajo del aparejador, las licencias de obra, etc).

Me pregunto entonces por qué para un proyecto software a casi ningún cliente se le ocurre preguntar o preocuparse por la calidad del proyecto que se le entrega o qué tipo de profesionales lo realizan, sin saber en realidad que, según esa calidad, el coste de evolucionar o mejorar en el futuro la aplicación será asequible y razonable o por el contrario totalmente desorbitado (cuando no se termina por tirar el sistema a la basura y realizar otro de nuevo desde cero).

Y créeme, he visto tirar a la basura bastantes proyectos por su mala calidad que hacía que fuesen inasumibles, con repercusiones económicas importantes.

Así las cosas, en muchísimos casos en nuestra profesión, para clientes de pequeño tamaño, medianos y, por supuesto, también en grandes corporaciones, se entregan aplicaciones que en realidad son una manzana envenenada que explotará más adelante en cuanto el cliente necesite modificaciones o cambios, que es lo normal para casi cualquier tipo de software.

¿Compraríamos un coche que no se puede reparar o mantener o cuyo coste de reparación fuese exorbitante?

Absurdo.

Me planteo varias preguntas en relación a esto. ¿Cómo demostrarle a un cliente la calidad del software que se le entrega? ¿Cómo destacarnos de los competidores garantizando al cliente que nuestra solución va a ser más mantenible ante cambios? Este es un tema que da para mucho y es uno de esos asuntos recurrentes con los que nos encontramos día sí, día no.

Quizá tendríamos que hacer más pedagogía y explicar a los clientes en algún momento, como valor añadido de nuestras propuestas, que el proyecto realizado por nosotros será muy mantenible y que no habrá problemas para añadirle más características en el futuro o modificar las existentes.

¿Estaría el cliente dispuesto a un mayor coste si se le garantiza mejor calidad interna en lo que se le ofrece? ¿Tendrían sentido auditorías externas de calidad para poder dar un producto por terminado con su correcto certificado acreditado de calidad software? Vale, sí, sé que existen auditorías así y que se suelen usar en grandes proyectos para grandes compañías, pero eso es una gota en el océano.

En el caso que comentaba al principio, un simple vistazo a la estructura de la aplicación me hacía temer lo peor, algo que comprobé al poco tiempo.

A continuación describo brevemente lo que más me llamó la atención:

Nada de documentación. Cuando digo nada, es que ni un sencillo comentario en ningún fichero de código, muchísimo menos algún documento sobre las pautas de diseño seguidas, guía de despliegue, etc.

De este modo, lo único que nos queda hacer es bucear entre la aplicación e ir viendo o suponiendo cómo está todo organizado, haciendo una especie de ingeniería inversa y con miedo de tocar algo sin saber si generaría algún error colateral.

Esto es, toda la documentación de ese proyecto estaba en la cabeza de quien lo desarrolló, algo bastante común.

Por supuesto, ni rastro de ningún tipo de pruebas. Yo diría que esto es lo peor, ya que, de este modo el tiempo que se tarda en probar manualmente todo es extraordinariamente mayor y cuando tocas algo no tienes ninguna garantía de que no estás rompiendo nada.

Así es, seguro que lo sabes, pero continuamente tengo que explicar esto, una y otra vez, en pequeños grupos de trabajo y en grandes, a CEOs (e incluso CTOs).

La base de datos no tenía diseño. Lo único que existía era un script larguísimo exportado desde phpMyAdmin... Cuando digo que no tenía diseño, quiero decir que simplemente se utilizaba como forma de almacenar datos, sin estructura y sin relaciones entre las entidades de datos.

Ausencia de evidencias del uso control de versiones. Esto, en sí mismo y para retomar una aplicación, no es del todo imprescindible, pero ya el hecho de que no se usara una herramienta de control de versiones te da una idea de cómo se hizo la aplicación en su día.

Múltiples sitios donde configurar las mismas contraseñas. Esta dispersión de contraseñas hard-coded es una práctica característica de alguien con muy pocas experiencia que no sabe (aún) las consecuencias de este tipo de detalles.

¿Hay que indicar que si tienes las mismas contraseñas o configuraciones en distintos sitios dispersos entre el código, cuando las cambies (que cambiarán), vas a tener que perder mucho tiempo en modificarlas en todos y cada uno de esos sitios (si es que no se te olvida alguno y después tendrás que perder aún más tiempo depurando?

Mala estructura de la solución. Cuando digo mala quiero decir que no se distinguía dónde estaba la parte de la interfaz de usuario, dónde el backend y tampoco se intuía dónde podía estar la lógica de negocio. Esto es, no había un diseño claro y una separación de responsabilidades en el código. Todo estaba mezclado y disperso por aquí y por allá. Si es la primera vez que usamos esas tecnologías, entonces es normal que andemos un poco perdidos sobre la mejor forma de organizar las cosas; no obstante, basta buscar en GitHub por boilerplate o un starter kit para encontrar propuestas de esqueletos para cualquier tipo de proyecto.

El layout de la interfaz de usuario tenía errores y estaba hecho desde cero. Esto no es que esté mal, pero en un mundo multi-navegador con multitud de versiones por cada tipo de navegador, el hacer tú mismo este tipo de cosas puede llevar muchísimo tiempo en garantizar que al menos el layout funcione bien para los navegadores que más se usan. ¿No es mejor usar algo así como bootstrap o 960 Grid System o multitud de propuestas maduras para este problema?

Extensos ficheros css y js sin minificar ni concatenar. Esto tampoco es que sea imprescindible, pero existiendo herramientas que te permiten reducir todos los ficheros CSS y de javascript a un único fichero .css y .js (este último además ofuscado), ¿por qué no usarlo?, así la aplicación gana algo más de velocidad en cada request, entre otras ventajas. Este detalle revelaba que no había un flujo claro de generación de versiones para producción.

Agujeros de seguridad como claves sin encriptar en base de datos y campos de texto cuyos contenidos no son filtrados para evitar ataques XSS. Sin comentarios.

Partes de la aplicación en completo desuso y mucho <>. Tampoco es que esto esté del todo mal, pero si lo mantenemos junto con partes que no se usan, nuestra aplicación será más difícil de organizar, mantener y leer: sólo debe existir aquello que la aplicación usa. Si tenemos miedo de perderlo, ¿para qué entonces tenemos la herramienta de control de versiones?

Esto tan solo era la punta del iceberg, ya que podría añadir que la aplicación no estaba en absoluto modularizada y ordenada (las clases de acceso a datos diseminadas, el frontend mezclado con el backend), ausencia total de estilos a la hora de escribir el código (variables privadas escritas de distinta forma, por poner un ejemplo) y un largo etcétera.

Nada más lejos de mi intención criticar, en absoluto (paso de acumular karma negativo...), pero me pregunto hasta qué punto degrada nuestra profesión entregar trabajos así que después van a entrar en explotación para un cliente para el que parte de su facturación dependerá de este sistema.

No sé si es un consejo que vale para todo el mundo, pero cuando entrego un nuevo trabajo o gestiono el equipo que lo realiza, intento garantizarle al cliente que se ha hecho mucho esfuerzo para que la calidad de lo que se le entrega sea alta (además de cumplir correctamente con todos los requerimientos funcionales); otra cosa es que esa calidad interna sea valorada o no por el mismo cliente.

2

No dejes que ser un buen técnico te arruine

Es difícil prosperar económicamente significativamente realizando un trabajo como desarrollador de software. Sin embargo, como tal, se tienen las habilidades de la economía digital y apenas lo aprovechamos para mejorar nuestros ingresos.

Hace muchos años creí que siendo un buen técnico me aseguraría un salario con el que pagar las facturas cómodamente. Y así fue, y me he considerado muy afortunado por ello y no lo puedo negar: en mi anterior compañía para la que trabajaba tuve muchas oportunidades de participar en proyectos muy diferentes, ganando con el tiempo experiencia no solo técnica sino también de contacto con el cliente final.

Fui aprendiendo que las dinámicas de trabajo y de grupo, el ambiente, la mala gestión del tiempo y de productividad, entre otros factores, afectaban a veces de forma dramática al desarrollo de un software «de calidad».

También pasé muchísimo tiempo escribiendo código, qué duda cabe, algo que sigo haciendo muchos años después a diario; esto es, acumulé mucha experiencia y muy variada, por lo que me siento muy afortunado, fruto de lo cual, como sabes porque estás leyendo esto, hasta me he atrevido a publicar, con éste, nueve libros relacionados con el sector.

Pero también fueron pasando los años, y el trabajo seguía igual de exigente con sus momentos de estrés muy duros y asfixiantes, y a medida que transcurría el tiempo en el que sacaba los proyectos con éxito junto con mis compañeros, mi consideración en la empresa era creo que buena, o sea, que estaba bien considerado y me gané de algún modo la confianza de mis colegas y jefes, al menos de casi todos.

Cuando me quise dar cuenta, puesto que me etiquetaron en la categoría de «un tipo que saca las cosas adelante», fui encontrando barreras ya no solo para cambiar de proyecto o departamento, también para «ascender» por la escalera corporativa, porque, lamentablemente, esa era la única forma de pasar al siguiente nivel económico, al menos en la cultura empresarial predominante en mi país.

De algún modo, me encasillaron como imprescindible en algunas áreas y de ahí no me querían sacar. Es decir, la gente no me quería quitar de donde estaba porque era suficientemente bueno en ello y, paradójicamente, esto me bloqueaba para desarrollar más mi carrera profesional, participar en otros proyecto e incluso asumir más responsabilidades.

No estoy hablando de relucientes compañías de Sillicon Valley financiadas con capital riesgo tirando