Código

El software basura se produce cuando intentamos hacer todo a la vez.

Principios, pautas, mejores prácticas y reglas generales: todos te facilitan la vida. Sin ellos, las tareas de diez minutos pueden convertirse en tareas de diez horas.

Uno de los mejores consejos que se podría recibir al escribir un código se encuentra en este sencillo resumen:

“Hágalo funcionar, hágalo mejor, hágalo más rápido”.

Es una ligera alteración de la famosa cita de Kent Beck, y su simplicidad es habilitante y desconcertante.

“Haz que funcione” es bastante fácil de entender. Tienes un conjunto de requisitos y estás codificando para cumplirlos, cosas para niños.

“Hazlo mejor” es donde está ‘la carne’. “Mejor” es la parte jugosa en la que pasará la mayor parte del día logrando. Mejor código, mejor diseño, mejores enfoques. Pero, ¿qué significa “mejor”? Llegaremos a eso más tarde.

Bueno, seamos honestos: a menudo nunca se llega al aspecto de “hacerlo más rápido” de su código, al menos no para todas las partes del software. Desea que sus caminos calientes sean rápidos y eficientes, pero es probable que esté en buena forma, dejando caminos que rara vez se transitan. No vale la pena el esfuerzo. Simple como eso.

De manera ridícula, los desarrolladores tienden a centrarse en “hacerlo más rápido” cada vez que leen el código de otros. Es común leer comentarios como “¡Este código ineficiente es horrible!” Esto ignora por completo si el código resuelve el problema a tiempo.

No hay vergüenza en escribir código basura

El primer paso es hacerlo funcionar. Simple y llanamente.

Hacer que las cosas funcionen violando los principios del buen diseño de una manera rápida y engañosa está completamente bien.

Soñar con diseños preliminares prematuros y elaborados es completamente inútil. La exploración se realiza mejor utilizando algunas técnicas probadas en batalla, como la creación de prototipos, la prueba de concepto, el código simple y basura y el código desechable.

Todo está dispuesto frente a usted. No hay abstracciones, ni magia, ni “me pregunto cómo funciona”.

Sin embargo, lo importante es reconocer esto como un primer paso. Dejar basura es una forma segura de acumular una deuda técnica que volverá a atormentarlo. Experimente como científico loco, pero limpie antes de presionar el código.

Hagámoslo mejor

Es hora de ser real: ningún usuario final va a ser tipo: “Hombre, el código de Google está tan bien estructurado. ¡Por eso utilizo la búsqueda de Google!”. A los usuarios no les importa lo mejor que sea su código en comparación con el desastre que hizo anteriormente. Los usuarios se preocupan por las buenas experiencias y la facilidad de uso de su software, no por lo fácil que es modificarlo.

Aún así, mejorar su código es un aspecto importante de la calidad general de su producto. La calidad del software interno afecta su capacidad para pivotar, detectar y corregir defectos, y el tiempo de lanzamiento.

Antes de continuar con la mejora de su software, asegúrese de validar de alguna manera que su software siga funcionando correctamente después de las modificaciones. Ponga en práctica algún tipo de prueba de regresión. Las pruebas unitarias son útiles, pero la inspección del código es igualmente importante.

Mejorar su software no se trata solo de refactorizar. La refactorización es esencialmente el comportamiento que preserva los cambios en su base de código. Pero mejorar su software es una especie diferente, donde la refactorización es solo una parte.

Está rediseñando. Aplicar patrones de diseño donde corresponda. Evaluar si su código es SÓLIDO. Arreglando los olores del código y cuidando los casos extremos.

Un mejor código es:

• Legible
• Mantenible
• Flexible

Esfuércese por lograr estas características aplicando prácticas modernas, así como los famosos principios SOLID y DRY. No voy a predicar teoría aquí, ya que hay una abrumadora cantidad de artículos sobre estos temas. Solo busca en Google los acrónimos.

Si alguna vez lo hacemos, hágalo más rápido

No todos los aspectos de su aplicación o biblioteca son iguales. No todas las líneas de código se ejecutan con la misma frecuencia. No se apresure a ajustar el código en cada línea.

Lo que a menudo encuentra es que solo una pequeña parte de su aplicación está usando una parte desproporcionada del tiempo de ejecución. Averigüe qué parte es, mida su rendimiento, establezca objetivos de rendimiento, optimice y mida nuevamente.

Optimizar sin un rendimiento objetivo no va a terminar bien. Es posible que realice una sólida optimización del rendimiento, pero si le dedicó todo un día de trabajo, tal vez no valga la pena.

Una vez que alcanza un cierto punto de rendimiento, la apreciación de los usuarios por cada milisegundo recortado disminuye. En este punto, solo está obteniendo crédito callejero de otros desarrolladores, lo cual es completamente inútil.

Algunos desarrolladores predican que se debe optimizar sobre la marcha. La optimización prematura es tan mala como la aplicación prematura de un patrón de diseño.

En su lugar, escriba el código más simple posible para empezar. Luego, refactorice, rediseñe, etc. y optimice solo si hay un cuello de botella.