Cuando comencé este blog, lo hice con la intención de facilitar el trabajo de las personas que se dedican al desarrollo de software, de forma profesional. Creo que existen muchos blogs y libros tecnológicos que hablan desde el desarrollo de software desde un punto de vista académico y teórico, pero muy pocos que lo atacan desde un punto de vista laboral (sobre todo en español).
Desde hace bastantes años, tengo ciertas labores de “tutelaje”, intentando ayudar a nuevos profesionales, a que vean el panorama completo desarrollo de software empresarial. Con base a eso, comencé a elaborar una serie de “Reglas de la Ingeniería de Software”, puntos cuya lectura nos ayudarían a hacer software de calidad en un tiempo razonable. Se analizaba todo los que nos llevaba al éxito y los que nos llevaba al fracaso (y creedme he estado en ambos tipos de proyectos), y se intentaba sintetizar en un punto fácil de recordar.
Las reglas son de diversa índole, por que abarcan el desarrollo empresarial de software en general. Así que se puede encontrar reglas que hagan referencia a aspectos técnicos de los mismos lenguajes de programación, pero también a aspectos como la gestión del tiempo, la responsabilidad, o la relación entre los integrantes de un equipo de desarrollo.
Algunas reglas pueden parece que están repetidas, esto porque hay una constante que se da en el desarrollo empresarial, que es el cambio rápido y constante en el negocio que abarcan los sistemas, los que provoca cambios en los mismos sistemas, a sus capacidades y sus necesidades, forzándonos a que sea simple y fácil de mantener. Muchas reglas girar en torno a esas ideas, aunque enfocadas cada una desde un punto de vista diferente, aunque parecido.
Por otro lado este es un proyecto vivo, en el que se agregaran, corregirán (y quitaran si es necesario), las reglas que sean necesarias, para mantenerlas coherente y útiles para la vida laboral del desarrollador de software.
Las reglas actuales son las siguientes:
-
Regla N°1: Va a cambiar
31 de agosto de 2014
Todo cambia muy rápido en el proceso de desarrollo de un software, el mismo software construido, genera nuevos requisitos, la satisfacción de las necesidades de un proyecto, genera a su vez nuevas necesidades.
Explicado de otra forma la resolución de un problema, genera un entendimiento más claro de dicho problema, y en esta situación, se abren nuevas posibilidades sobre las capacidades del software y el negocio que sustenta.
-
Regla N°2: Va a fallar
6 de septiembre de 2014
Es imposible determinar si cierto software continuara funcionando en un futuro, porque las condiciones en las que se verá envuelto son impredecibles (actualizaciones de software con el que convive, actualizaciones de hardware… incluso la fecha y hora del ordenador).
Hay que evitar actitudes optimistas con respecto a la posibilidad que ocurran fallos, puesto que es muy probable que estos ocurran, por otro lado considerar que el usuario del sistema hará un uso “lógico” o coherente de este, es un desatino, generalmente nos sorprenderá descubriendo errores, que nunca se nos hubieran pasado por la cabeza.
-
Regla N°3: Se va a mantener
15 de septiembre de 2014
El tiempo que vas a estar creando software nuevo, es incomparablemente menor al tiempo que vas a estar manteniéndolo.
Gran parte nuestros esfuerzos de desarrollo van a estar enfocados en el mantenimiento de código que bien puede ser código ajeno o código de otras personas.
-
Regla N°4: Todo sistema tiene un propósito
21 de septiembre de 2014
Es común que olvidemos que lo que estamos creando no es un conjunto de variables, y líneas de código, sino que tiene que un significado y relevancia especial fuera del lenguaje de programación en el que los estamos creando. Por ejemplo, una trasferencia bancaria de un millón de dólares errónea no es una posición de memoria mal inicializada, sino que puede ser una pérdida real, o un sistema médico de monitores mal construido puede poner en juego vidas humanas. Hay que pensar en nuestros sistemas por lo que van a poner aportar en un negocio o los problemas que van a poder resolver y no como simples entes tecnológicos.
-
Regla N°5: No te repitas
28 de septiembre de 2014
La regla "No te repitas", hace referencia a que no se deben repetir porciones de código, con funcionalidades iguales, "casi iguales", o parecidas a los largo del código. Aunque técnicamente funcione y de el resultado correcto, aumenta el grado de "degeneración del software" (el tiempo en que se echa a perder un software, hasta que ya no es útil su funcionalidad).
-
Regla N° 6: Lo importante es el "Que hace" y no el "Como lo hace"
16 de octubre de 2014
En la programación orientada a objetos, se diseñan elementos, donde prima la representación de "Que es lo que hace" y "Que son", principalmente, a través de sus atributos y sus métodos. también se establece como se relacionan con otros tipos de elementos (o clases), ya sea mediante técnicas como la composición, la herencia, o el envió y recepción de mensajes.
De esta forma centrándonos en "Que hace" obtenemos una comprensión mas clara del sistema, y de sus requisitos, además construiremos un sistemas más escalable (debido a que no nos estamos centrando en "Como lo hace"). Inclusive tendremos muchas más posibilidades de conectarnos a otros sistemas, puesto que queda mas claramente establecidos los limites y conectores de estos.
-
Regla N°7: Primero los objetos, después las base de datos
2 de enero de 2015
El enfoque más idóneo para comenzar un sistema, es el diseño de los objetos o las clases de los que se va a constituir nuestros sistemas. Generalmente al comienzo del diseño, tenemos una idea de cómo queremos hacer las cosas, dicha idea no tiene que estar completa, y cuanto más avancemos en ella, mas compresión tendremos sobre la misma. Podemos ir reduciendo el nivel de abstracción según los necesitemos. Igualmente podemos usar relaciones de objetos, ya sea de jerarquía (herencia) o de contención (un objeto contiene a otro, o a varios). Y lo más importante, se comprende que los datos, van de la mano de las operaciones (funcionalidad), y se diseña el sistema de dicha forma.
-
Regla N°8: El entusiasmo da el conocimiento, el conocimiento sin entusiasmo no sirve de nada
19 de julio de 2015
El conocimiento sin entusiasmo es, en el mejor de los casos, fortuito, y casi nunca podrá convertirse en algo útil para el negocio, en sistemas y herramientas funcionalidades que creen una diferencia significativa. En la mayoría de los casos lo único que podrá realizarse sin entusiasmo es lo que yo llamo “tareas de escuela”, programas técnicamente correctos, hechos según un enunciado claro como una receta, pero que no sirve en la práctica de absolutamente nada, que son imposibles de encajar en un ambiente laboral real. En última instancia los conocimientos, y más en esta profesión, son caducos.
-
Regla N°9: Los warnings de hoy son los errores de mañana (programa sin warning)
8 de agosto de 2015
Cuando me enfrento al mantenimiento de código realizado por diversos equipos de trabajo (y he de reconocer que no con menos frecuencia al creado por mi), me encuentro con que al compilar, existe un excesivo número de advertencias (excesivo son más de 200 o incluso mas). Advertencias que se han ido creando a lo largo del tiempo y que nadie se ha molestado en revisar jamás, acumulándose más y más cuanto más codificadores mueven el sistema. Generalmente nadie toca dichos warning debido al temor que entraña "mover" algo cuyo sentido desconocemos (el hecho que lo desconozcamos ya debiera hacer saltar la alarma). Bueno, si existe el warning, seguramente no tenga ningún significado oculto y simplemente es una omisión no intencional que deba ser corregida.
Los warnings se acumulan a lo largo de los años y el número dificulta entender claramente lo que nos están indicando, cuanto más warnings haya, menos casos les haremos, hasta que uno de esos warnings realmente representen un potencial problema en producción que se nos pase completamente desapercibido, convirtiéndose en un dolor de cabeza (con suerte) o en algo más grave, porque "los warnings de ahora son los errores de mañana".
-
Regla N°10: Si no es sencillo está mal hecho
1 de diciembre de 2015
El desarrollo de un software tiende a complicarse… a complicarse mucho. Se complica sacar el proyecto a tiempo, se complica las relaciones con el equipo de trabajo, con los proveedores o con los recursos. Debemos mantener esa complejidad bajo control, teniendo en la mente que todo lo que hagamos cumplir la regla "Si no es sencillo, está mal hecho".
La sencillez muchas veces se confunde. Sencillez no quiere decir fácil, es casi siempre lo contrario. Es difícil hacer las cosas sencillas. Casi siempre invertir en sencillez es un proceso costoso al principio y ventajoso al final del proyecto. El objetivo de esta regla es conseguir sistemas que estén guiados por la sencillez.
-
Regla N°11: El primer código es para entender el problema, los restantes para hacerlo bien
5 de febrero de 2017
Como defensor del las metodologías agiles, creo que la mejor forma de comprender un problema es descomponiéndolo en problemas más sencillos y solucionándolos uno a uno.
Esto implica que hasta que no tengamos algo de código listo, no comprenderemos exactamente la necesidad que estamos intentando suplir. Es más, el ver la necesidad resulta, pueda cambiar los requisitos y la percepción sobre el problema real a tratar.
Los motivos anteriores hacen que el primer código no sea el más optimo, porque su objetivo está más orientado al análisis que a la implementación. La situación en este punto es tenemos un código que nos muestra una solución, pero es una solución temporal y estática (Si hubiera un cambio en los requisitos sería muy difícil de ajustar estar código para atenderlo).
Es por lo cual necesitamos realizar una segunda revisión del código, en estas caso ya no para resolver el problema de negocio, sino para asegurarnos que nuestro código sea de calidad, cumpliendo los siguientes requisitos:
-
Regla N°12: “Hay que prepararse para la lluvia cuando hace sol” (olvídate de “Si funciona no lo toques”)
16 de agosto de 2017
Si funciona no lo toques”, es un refrán bastante popular y además es horrible, promueve una filosofía de conformismo e incluso de cobardía ante el cambio. Me imagino que funcionaria en algún momento, donde tu zona de confort sea enorme. En la actualidad, y particularmente en nuestro negocio, las zonas de confort tienen a hacerse muy pequeñas muy rápidamente.
¿Cuándo es el momento de “tocar” algo que funciona?, si crees que es “cuando no funcione”, estas en un error, ese es el peor momento para plantearte cambios. Por la misma circunstancia que “no funciona”, el objetivo, o la prioridad ya no es crear ningún tipo de mejora, si no conseguir que el sistema siga funcionando.
-
Regla N°13: Simplifica las cosas
10 de noviembre de 2017
Cuanto te enfrentes a un problema grande, simplifícalo en problemas más pequeños. Si estos problemas siguen siendo demasiado grandes repite el proceso hasta que tengas un problema lo suficientemente pequeño para poderlo resolver.
Para simplificar partimos siempre de un problema grande que es irresoluble en su tamaño actual, e identificamos las partes que lo componen. Lo dividimos en pequeños problemas que son más fáciles de resolver, repitiendo el proceso hasta que podémonos identificar dichos problemas con una solución clara y sencilla, y además que solo sirva para resolver exclusivamente una necesidad.
-
Regla N°14: Evita la ceguera voluntaria
16 de diciembre de 2017
La ceguera voluntaria es ignorar de forma deliberada situaciones que si bien son perjudiciales, no suponen un daño inmediato, con lo que no se hace nada para corregirlas, convirtiéndose en una posible situación catastrófica a futuro.
Cuando aparecen problemas en mitad de un desarrollo y no son atacados y mitigados cuando son pequeños, aumentaran de forma progresiva hasta ser de tal tamaño que afecte al tiempo, calidad o costo del proyecto.
-
Regla N°15: Haz que las cosas sucedan
11 de enero de 2018
Una de las cosas que más afectan al éxito del desarrollo de un sistema es la pasividad y falta de proactividad. Esto es, principalmente, quedarse esperando a que las cosas pasen por si solas.
Muchas veces existen escenarios de incertidumbre en que no queda claro que es lo tenemos que hacer en cuanto al sistema que se está construyendo, esto puede ser por muchos motivos, puede ser una falta de visibilidad del objetivo real o que no se nos ha comunicado apropiadamente.
Pero es necesario comprender que mientras el sistema no esté finalizado (satisfaga las necesidades del cliente), hay tareas pendientes que hay que resolver y es responsabilidad de cada integrante del equipo conocer cuáles son y conseguir se lleve a cabo. Es responsabilidad de cada uno hacer que las cosas sucedan.
-
Regla N°16: Por defecto todo es privado (principio de ocultación)
25 de enero de 2018
He observado un problema muy común de muchos programadores noveles, escriben la palabra "public" por inercia al momento de crear una nueva funcionalidad, sin pararse realmente a pensar que están haciendo, y solo cuando lo meditan bien escriben "privado". A veces no se dan cuenta de esta circunstancia, otra veces piensan que es más sencillo, si todo es público, a veces incluso piensan que le dan cierto sentido de "libertad", cuando lo que se hace abrir puerta al desastre (la “libertad” la da en todo caso, compartir el código fuente, no habilitar métodos privados como públicos).
-
Regla N°17: Primero el camino principal luego las excepciones
23 de diciembre de 2018
Si es bien es cierto que uno se tiene que prepara para los fallos (para que el software falle) la ruta principal (de ejecución) debe ser un camino limpio y fácilmente trazable. Incluso desde el momento del diseño, no podemos dejarnos abrumar con todas las excepciones y giros posibles de la lógica de negocio, debemos diseñar el camino feliz, y asumir que habrá excepciones en algún momento. Esto es porque si bien el camino principal suele ser sencillo, los recovecos, bifurcaciones y excepciones suelen ser muchas, muy variadas y a veces difíciles de ver, si el cambio principal y los secundarios están entrelazados obtendremos un código sumamente difícil de comprender.
-
Regla N°18: Mejor herencia que sentencias condicionales (evita el código espagueti)
4 de febrero de 2019
El código Espagueti es aquel que tiene un control de flujo demasiado complicado para entenderlo claramente, además de que son prácticamente imposibles de modificar por miedo a que mientras cambiamos algo se estropee otra cosa. El código esta enredado tal como un plato de espagueti, se llega a esta situación (en la actualidad), a base de agregar sentencias if encadenas, grandes y complejas. Ya de por sí, tener dos if encadenados aumenta la complejidad del código y la dificultad de mantenerlo.
Para evitar que nuestro programa contenga código espagueti debemos evitar usar instrucciones condicionales, cuando estas pueden evitarse usando mecanismos de herencia, "Mejor herencia que condicionales".
-
Regla N°19: Enfoque en el mantenimiento y la escalabilidad antes que en la optimización
22 de agosto de 2020
Primero haga que funcione, después hágalo rápido. Esto es cierto incluso si se está seguro de que una trozo de código es realmente importante y se sabe que será un cuello de botella es el sistema. No lo haga. Primero, consiga que el sistema tenga un diseño lo más simple posible. Entonces, si no es suficientemente rápido, optimícelo. Casi siempre descubrirá que «su» cuello de botella no es elproblema. Guarde su tiempo para lo verdaderamente importante. Bruce Eckel, Thinking in C++
La mantenibilidad son las modificaciones que hacemos a un sistema para que siga funcionando con el propósito para el cual fue diseñado (para resolver la necesidad de el negocio para que fue creado). La escalabilidad es la facilidad con la que podemos agregar nueva funcionalidad a un software para que se adapte a las nuevas necesidades de un mercado y para que nuestro negocio no se quede estancando y obsoleto.
-
Regla Nº20: No depender del llamador, ni de la implementación (evitar acoplamientos)
13 de marzo de 2021
Una clase no debe cambiar su comportamiento según quien la consume, igualmente el consumidor de una clase no debiera saber cómo esta implementada internamente dicha clase, para poder consumirla de forma adecuada.
Idealmente una clase solo se debiera relacionar con otras a través de la definición de los métodos, el cómo hagan esos métodos sus funciones con cosas que nos deben preocupar. Lo anterior se ve claramente cuando podemos sustituir la referencia de una clase, por la referencia a una interface, y cambiar la clase que lo implementan sin mucho (o ningún) impacto.
Si te ha gustado el artículo, compártelo en tus redes sociales ;-)
