¿Cómo empezar a programar? Te cuento mi experiencia
En este artículo, te contaré mi experiencia sobre cómo empecé a programar y compartiré algunos consejos para aquellos que quieren comenzar en esta industria.
—- consejos
- destacado
Hace poco tomé la iniciativa de refactorizar la forma en la que se cargaban las variables de entorno en un sitio web en el que estoy trabajando. Acabé iterando varias veces hasta encontrar una solución centralizada y limpia para mitigar errores a la hora de desplegar el sitio web, pero pasé toda la jornada investigando y probando alternativas. Eventualmente, mi pulcra solución comenzó a volverse incómoda, y más temprano que tarde supuso una piedra en el zapato de cada despliegue.
¿Era esto necesario? La verdad es que no. Procrastiné las tareas importantes a cambio de un código limpio, organizado y técnicamente funcional, pero no aportaba ningún valor. Bastaba con documentar, pero preferí complicarme.
Es normal que, como desarrolladores, nos preocupemos por la calidad del código que producimos a diario durante nuestra labor. Sin embargo, un código de alta calidad no siempre se traduce en un producto de alta calidad desde la perspectiva del usuario. Por eso, en este artículo quisiera reflexionar sobre cómo nuestra obsesión con la limpieza del código nos puede desviar del verdadero objetivo: entregar un producto que satisfaga las necesidades del cliente.
En su esencia, el "código limpio" se refiere a un código que es fácil de entender, modificar y mantener. Es un código que ha sido cuidadosamente diseñado y escrito, con atención a los detalles y un enfoque en la simplicidad y la claridad. En consecuencia, todo código limpio debe atender a patrones que prometan, a largo plazo, escalabilidad, inteligibilidad y flexibilidad.
El código limpio siempre parece escrito por alguien que se preocupa. No hay nada obvio que puedas hacer para empeorarlo.
— Robert C. Martin, en su libro Clean Code: A Handbook of Agile Software Craftsmanship
Descrito así, parece que nuestra meta como desarrolladores es alcanzar ese pináculo, convertirnos en una mejor versión de nosotros mismos capaces de producir arte programático. A final de cuentas, es probable que nuestro código acabe en manos de un colega, otro ingeniero o nuestro superior más inmediato en el trabajo, y puede resultar crucial que lo que escribimos comunique de forma sencilla dos conceptos entre líneas: funcionalidad e intención.
Debemos tener en cuenta que el problema del código limpio no es el resultado, ni su concepto. El problema atiende a la imposibilidad natural de alcanzar ambos polos del equilibrio entre velocidad y limpieza. No puedes tener un código pulcro y escalable sin sacrificar tiempos de desarrollo, e igualmente no puedes ir demasiado rápido sin que tu código parezca, en alguna medida, espaguetti, y aunque normalmente esta decisión no depende de ti como desarrollador sino de los stakeholders, es relativamente fácil perderse en el camino y acabar priorizando la calidad de lo que escribimos.
Las razones por las que podemos llegar a obsesionarnos con el código limpio son diversas, pero podría enumerar algunas que, personalmente, he detectado a lo largo de mi carrera.
Cuando buscamos mejorar y aumentar nuestra producción de código, es natural querer que nuestras habilidades sean reconocidas, especialmente si hay más personas viendo nuestro trabajo. Esta necesidad de validación es particularmente notable en los desarrolladores autodidactas, ya que su validación no proviene de una certificación académica, sino de lo que pueden producir con lo que han aprendido.
Empezar un proyecto nuevo nunca es fácil. Nos toca tomar decisiones que pueden afectar, a largo plazo, la sostenibilidad y mantenibilidad del mismo, por lo que resulta bastante sencillo acabar ahogándonos en soluciones muy complejas, quizás pensando en que serán capaces de tolerar tantos cambios como sea posible sin afectar su desarrollo. Esto es especialmente frecuente en entornos ágiles, en donde la flexibilidad es prioritaria.
A veces la presión para entregar resultados rápidos puede llevarnos a tomar atajos en nuestro código. Sin embargo, en un intento de evitar estos errores a corto plazo, podemos llegar a obsesionarnos con la limpieza del código, a expensas de la eficiencia y la entrega puntual. En este punto, es habitual decir que nos sentimos "sucios", y queremos hacer todo lo posible por limpiar nuestro "desastre".
Muy ligado al ego y a la ansiedad por la escalabilidad, el perfeccionismo es una trampa en la que es fácil caer. Queremos que nuestro código sea perfecto, que no tenga fallos y que esté listo para cualquier cambio o adaptación futura. Sin embargo, este perfeccionismo puede llevar a la parálisis por análisis y a la procrastinación. ¿Cuántas veces no hemos perdido días enteros en Google buscando cuál es la mejor manera de organizar nuestros proyectos?
Como desarrolladores, a menudo nos preocupamos por producir código impecable, siguiendo al pie de la letra los principios de "código limpio". Sin embargo, es crucial recordar que la principal meta es entregar un producto que funcione y resuelva un problema real para el usuario. Un código funcional, aunque no sea perfecto desde el principio, aporta valor inmediato. Este valor permite obtener feedback temprano, validar hipótesis y realizar iteraciones que conduzcan a un producto final más robusto y adaptado a las necesidades del cliente. En contraposición, obsesionarnos con la limpieza prematura del código puede llevarnos a la "parálisis por análisis", consumiendo tiempo valioso que podría dedicarse a la implementación de funcionalidades clave. Es preferible un código que funcione hoy y se refactorice mañana, a un código "perfecto" que nunca vea la luz.
La eficiencia en el desarrollo de software reside en encontrar el punto óptimo entre la calidad del código y la velocidad de entrega. No se trata de elegir un extremo u otro, sino de adoptar un enfoque pragmático que considere las restricciones del proyecto y las prioridades del cliente. La comunicación abierta y la colaboración entre los miembros del equipo son fundamentales para tomar decisiones informadas sobre la limpieza del código. Por ejemplo, ¿es más importante refactorizar una sección del código para mejorar su mantenibilidad, o implementar una nueva funcionalidad que impacte directamente en la satisfacción del cliente? Herramientas como la automatización de pruebas y la refactorización continua pueden contribuir a mejorar la eficiencia sin sacrificar la calidad. Las pruebas automatizadas aseguran que los cambios no introduzcan errores, mientras que la refactorización continua permite mantener el código limpio y organizado a medida que evoluciona el proyecto.
Al final del día, el éxito de un proyecto de software se mide por la satisfacción del cliente. Un código elegante y bien estructurado es valioso, pero no tiene sentido si no se traduce en un producto que cumpla con las expectativas del usuario. Entregar un producto funcional y a tiempo genera confianza y permite establecer una relación duradera con el cliente. La retroalimentación del cliente es invaluable para guiar el desarrollo y asegurar que el producto final satisfaga sus necesidades reales. Escuchar atentamente sus comentarios, comprender sus desafíos y responder a sus inquietudes es esencial para crear un producto que realmente marque la diferencia. Recordemos siempre que el "código limpio" es un medio para lograr un fin, no un fin en sí mismo. El verdadero objetivo es la satisfacción del cliente.
En este artículo, te contaré mi experiencia sobre cómo empecé a programar y compartiré algunos consejos para aquellos que quieren comenzar en esta industria.
—Cuantos más cuadraditos verdes en GitHub, más seniors... ¿o no?
—