Desarrolla código reutilizable y de calidad
Escribir código reutilizable es probablemente una de las cosas más importantes a tener en cuenta a la hora de programar. Ya hemos hablado en Geeky Theory sobre reinventar la rueda y, en este caso hay que aplicarlo al código que escribimos.
Soluciones genéricas
Implementar soluciones genéricas es el primer punto a seguir para desarrollar código reutilizable, pero a veces podemos tener problemas con esto. Escribir código demasiado genérico puede incurrir en una falta de usabilidad.
Cuando un proyecto crece y se hace muy grande suele ser complicado mantenerlo y seguir desarrollándolo. Si tenemos una pieza de software que soluciona muchos problemas, posiblemente estemos implementando bien el código, pero no podamos reutilizarlo en un futuro. Al final, estaremos desarrollando algo que en un futuro no podremos reusarlo en otros proyectos.
Escribir código reutilizable
La solución que creo correcta para desarrollar código reutilizable es: no escribir funciones enormes que implementen toda la lógica de la aplicación, sino programar funciones pequeñas que se centren en problemas concretos.
Según el principio de responsabilidad individual, cada clase debe tener un objetivo individual, el cual debe estar encapsulado completamente en dicha clase. Podríamos tener, por ejemplo, una clase que implemente la lógica de una aplicación, además del diseño de la interfaz de usuario. ¿Qué pasaría si el programador necesita cambiar algo de la lógica? ¿Y si hay que cambiar el diseño? El principio de responsabilidad individual afirma que ambas funciones deben estar separadas en clases distintas, ya que sería un error implementar ambas cosas en el mismo sitio cuando pueden cambiar cada una por diferentes razones y en cualquier momento.
Hacer que una clase o método se centre en resolver un problema concreto hace nuestro código más robusto y reutilizable.
Tenemos muchas más posibilidades y opciones en las que reutilizar el código desarrollado si cada método es fácil de utilizar y comprender. Puede que parte del código pase a estar desactualizada en un determinado momento y tengamos que modificarla. ¿Qué pensáis que es más fácil? ¿Modificar un método de 1000 líneas o varios de 20? Es un ejemplo un poco exagerado, pero puede pasar. No digo que un método de 1000 líneas esté mal escrito, pero si se puede simplificar y separar en otros más fáciles de comprender, mejor que todo en un bloque.
Es complicado encontrar el punto en el que separar o unir piezas de código, pero al final la experiencia hace que escribamos soluciones de mayor calidad. No hay que tener miedo de reorganizar los componentes del proyecto. De hecho, es lo que se suele hacer cuando crece y se vuelve incontrolable.