Hay muchos procesos que deben completarse y problemas técnicos que deben abordarse para hacer una aplicación completamente funcional. Una de las cosas que podemos hacer para que nuestras aplicaciones funcionen correctamente y sean más rápidas es implementar los principios de codificación.
¿Qué está mal y cómo identificar esas aplicaciones como «apenas mantenibles»? Si estamos acostumbrados a implementar principios de codificación en nuestra aplicación, lo más probable es que podamos identificar si una aplicación es mala o buena desde la perspectiva de la base de código.
Estos son los principios de codificación que suelen usar muchos desarrolladores profesionales.
Haz que funcione
La primera regla antes de implementar cualquier principio es que debemos asegurarnos de que nuestra aplicación funcione primero como aplicaciones completamente funcionales. ¿Cuál es el punto de tener una base de código totalmente mantenible si los usuarios no pueden usar la aplicación en sí?
Porque al final, al usuario no le importa si la aplicación se basa en un super servidor superior y se desarrolla utilizando los mejores principios de codificación. Al usuario solo le importa si la aplicación funciona o no para satisfacer sus necesidades.
Una vez que la aplicación funciona este como este, podemos comenzar a trabajar en la implementación de cualquier principio de codificación que se adapte a nuestras aplicaciones.
No lo vas a necesitar
Muchos desarrolladores, suelen guardar el código, los componentes, los comentarios, etc. sin usar solo porque piensan que lo necesitaría más tarde, pero la realidad es que casi nunca se llega a utilizar ese código.
En primer lugar, debemos excluir cualquier código no utilizado de nuestra base de código principal, y si insiste en mantenerlo porque «lo necesitará más adelante», entonces solo controle la versión del sistema correctamente.
Si eliminamos un código de nuestra base de código, habrá un historial en el VCS y podemos revertir o copiar y pegar fácilmente el código anterior sin mantener ese código para siempre en nuestra base de código.
Al final, cuanto mayor sea la base de código, mayor será el esfuerzo necesario para mantener.
Mantenlo simple estúpido
Sí, lo leíste bien. No hagas nada más complicado como es.
Si podemos hacer que un proceso sea más sencillo, ¿por qué nos molestaríamos en hacerlo más complicado?
El punto de referencia más fácil es que nuestros cambios en el código aligeren la carga del servidor o la agobien y si nuestros códigos pueden ser mantenidos por otros o no.
Si nuestro código no pasó esos puntos de referencia, significa que nuestra base de código es demasiado complicada y necesita una refactorización. Podemos refactorizar fácilmente el código utilizando un crítico de código abierto o bibliotecas de colores de código para hacer automáticamente una sugerencia de cambios de código para nosotros.
Recuerde que cuanto más simple sea el código base, más fácil será mantenerlo y cuanto más simple sea el proceso, menos recursos del servidor se utilizarán para manejar el proceso.
No te repitas
¿Alguna vez has necesitado una acción o un proceso que debe realizarse antes de cada acción, por ejemplo, debemos asegurarnos de que el usuario ya haya iniciado sesión antes de que pueda acceder a cualquier página de usuario?
class HomeController
def index
is_user_login?
end
def profile
is_user_login?
end
private
def is_user_login?
redirect back if user.login == false
end
end
Como puedes ver en el código anterior, se intenta llamar a is_user_login? en cada acción del controlador, y debe optimizarse, porque si necesitamos cambiar el nombre del método o cambiar la lógica, etc. Este tipo de método será ineficiente, pero podemos solucionarlo.
Podemos crear un constructor/middleware/ antes de la acción que llamará a is_user_login? que función cada vez que se active una de las funciones.
class HomeController
before_action :is_user_login?
def index; end
def profile; end
private
def is_user_login?
redirect back if user.login == false
end
end
Puedea ver la diferencia después de que refactorizamos el código, el código será más mantenible y legible.
Pero ten en cuenta que existen diferentes enfoques en cada lenguaje de programación o marco para manejar este caso, así que tienes que ser inteligente y flexible.
Código limpio
Apuesto a que ya escuchaste muchas veces sobre el principio del código limpio, y quiero decirte que el código limpio es más un principio general.
La primera regla del código limpio es siempre crear un código claro y conciso con una intención clara, por ejemplo, cada vez que creamos una función, método, módulo o nombre de variable.
El nombre debe representar su valor o su lógica como un todo y no olvides seguir las convenciones de código existentes porque cada lenguaje de programación tiene un enfoque diferente.
No puedo escribirlos todos en este artículo, pero si estás interesado en explorar más sobre este tema, le recomiendo que lea este libro Clean Code: A Handbook of Agile Software Craftsmanship.
De pie sobre el hombro de los gigantes
Utilizar estándares de la industria y tecnologías maduras en lugar de crear nuestros propios estándares.
Hay muchos recursos que ya analizan cómo crear un código repetitivo con algunas herramientas, cómo codificar con las mejores prácticas con una herramienta específica, etc.
Te recomiendo que siga las convenciones, las mejores prácticas y la estandarización existentes porque no debemos construir ninguna solución sobre dichos estándares a menos que nos brinde una ventaja competitiva.
Regla de los Boy Scouts
¿Cuál es una de las principales causas de la disminución de la productividad de los programadores?
Sí, tiene usted razón. La razón principal de nuestra productividad decreciente a medida que pasa el tiempo es cuando tenemos que mantener o continuar el desarrollo de un proyecto que está construido con un código desordenado.
Seguramente nos ralentizará cuando tengamos que lidiar con el código desordenado de otra persona o incluso con nuestro código desordenado (lástima de nosotros).
Entonces, ¿cómo lidiar con eso? Podemos usar “La Regla de los Boy Scouts” como decía el tío Bob en su libro “Deje siempre el campamento más limpio de lo que lo encontraste”.
Entonces, siempre que tengamos que desarrollar nuevas funciones o mantener las funciones existentes, siempre debemos agregar alguna mejora a nuestra base de código. No tiene que ser una solución importante, también podemos hacer una solución menor. Por ejemplo, cambiar el nombre de las variables, eliminar los espacios en blanco, hacer que el código tenga la misma sangría, etc.
Hazlo rápido
Después de abordar el desafío de hacer que nuestro código sea más mantenible, optimizado y legible, podemos centrarnos en hacer que nuestra aplicación sea más rápida.
Ya sea que optimice la indexación de la base de datos, modifique la arquitectura, agregue una estrategia de caché, etc.
Por último, la marca de un gran artesano es comprender que la refactorización cuesta tiempo y es mejor equilibrar todos los principios al mismo tiempo. No hagas YAGNI solo para la fase 1.
Lo que significa usar estos principios al mismo tiempo dentro de cada iteración/hito, pero asignando el menor tiempo/cuidado a los elementos en la parte inferior de la pirámide.
De lo contrario, terminará con una montaña de deuda técnica incluso antes de darse cuenta.
Medium
