Tip 11: DRY – No te repitas (Don’t Repeat Yourself<\/em>)<\/h3>\n![\"DRY\"](\"http:\/\/img.printfection.com\/1\/2683\/1732811\/I15YW.jpg\")
<\/p>\n
\u00bfAlgo da m\u00e1s rabia para un desarrollador que hacer lo mismo dos veces? Pues aunque parezca que no, al final siempre nos acaba sucediendo. Es m\u00e1s, al tener partes de la aplicaci\u00f3n duplicada (reglas de negocio, m\u00e9todos, men\u00fas, etc…), con cada cambio, nos toca retocar cada parte por duplicado\/triplicado\/…<\/p>\n
\u00bfY por qu\u00e9 aparecen los duplicados? porque (1) no podemos evitarlos, o (2) no nos damos cuenta, (3) por pereza o al compartir c\u00f3digo, (4) por duplicaci\u00f3n del mismo trabajo por diferentes desarrolladores.<\/p>\n
\u00bfY como evitar la duplicaci\u00f3n? \u00bfEs posible? En el primer caso, cuando no podemos evitarla, por temas de diferente representaci\u00f3n de la informaci\u00f3n, los generadores de c\u00f3digo pueden ayudarnos. Cuando documentamos el c\u00f3digo, estamos duplicando. Y los comentarios,en ocasiones son imprescindibles. \u00bfSoluci\u00f3n? Simplifica el c\u00f3digo. \u00bfY si el c\u00f3digo se basa en un documento de especificaci\u00f3n? \u00bfY qu\u00e9 pasa con los lenguajes de programaci\u00f3n que nos hacen repetir mucho c\u00f3digo (no hay que ir m\u00e1s lejos que la separaci\u00f3n interfaz\/implementaci\u00f3n)? Aqu\u00ed la refactorizaci\u00f3n y los IDEs juegan un papel muy importante. Cuando los duplicados aparecen por nuestra negligencia (suena mejor descuido), solo nos queda aprender de los errores. Respecto a la pereza (o las prisas), os dejo dos refranes. No dejes para ma\u00f1ana lo que puedes hacer hoy<\/em> y V\u00edsteme despacio que tengo prisa<\/em>. \ud83d\ude42 Y finalmente, para la debida al trabajo en equipo, lo mejor es la comunicaci\u00f3n, abierta, activa, bidireccional y entre todos los miembros del equipo.<\/p>\nTip 12: Facilita la Reutilizaci\u00f3n (Make It Easy to Reuse<\/em>)<\/h3>\nPara evitar duplicados, si nuestro c\u00f3digo es reusable y est\u00e1 localizable en un lugar adecuado, nuestro equipo no va a reimplementar algo que ya est\u00e1 hecho. Si el c\u00f3digo no es reusable, o su uso no es facil\/amigable, nadie lo usar\u00e1, e inevitablemente, aparecer\u00e1n duplicados \ud83d\ude41<\/p>\n
En el segundo apartado, titulado Ortogonalidad<\/strong>, se trata la cohesi\u00f3n <\/em>y el acoplamiento <\/em>(2 de los conceptos m\u00e1s importantes dentro de la ingenieria del software). 2 lineas son ortogonales si forman un angulo recto. 2 vectores son ortogonales si son independientes. 2 componentes son ortogonales si al modificar uno, el otro no se ve afectado. La base de datos es ortogonal del interfaz de usuario, si al modificar la base de datos, no tenemos que modificar ninguna pantalla\u00a0 \u00bfesto es posible?<\/em><\/p>\nTip 13: Elimina los Efectos entre las Cosas que No Est\u00e1n Relacionadas (Eliminate Effect Between Unrelated Things<\/em>)<\/h3>\nAl dise\u00f1ar componentes cohesionados y con bajo acoplamiento, un cambio en un componentes evita tener que cambiar otros. Con esto, ganaremos productividad, ya que aquello que es modificable est\u00e1 localizado, y por tanto, los cambios se hacen estimable, las pruebas viables, y adem\u00e1s, se reduce el riesgo.<\/p>\n
Respecto a como eliminar los efectos, con una buena organizaci\u00f3n del equipo de desarrollo, un dise\u00f1o basado en capas, con un buen uso (y no abuso) de los patrones de dise\u00f1o, con ayuda de la AOP, etc…<\/p>\n
El tercer apartado, Reversible<\/strong>, trata sobre la inestabilidad de las decisiones. Lo que hoy es blanco, ma\u00f1ana es negro y la semana siguiente es gris. El problema viene cuando estas decisiones son cr\u00edticas, como elegir un proveedor de base de dastos o un patr\u00f3n arquitect\u00f3nico, ya que el coste de deshacer esta decisi\u00f3n suele rechazar de antemano la posibilidad del cambio.<\/p>\nDentro del marco de las metodolog\u00edas \u00e1giles, donde se abrazan los cambios y el dise\u00f1o se minimiza para favorecer la producci\u00f3n temprana de c\u00f3digo, el cual va mejorando d\u00eda a d\u00eda mediante refactorizaciones, nuestra aplicaci\u00f3n va a cambiar siempre. Lo que hoy nos vale como soluci\u00f3n, puede que dentro de un mes no. Hoy hacemos un prototipo, y la semana que viene lo tiramos a la basura.<\/p>\n
Tip 14: No Hay Decisiones Finales (There Are No Final Decisions<\/em>)<\/h3>\nPor esto, necesitamos que nuestra arquitectura sea flexible, que vea los cambios como algo bueno (al fin y al cabo, una petici\u00f3n de cambio por parte del cliente supone m\u00e1s trabajo, y m\u00e1s trabajo debe suponer m\u00e1s ingresos). \u00bfComo conseguimos una arquitectura flexible? Una arquitectura en capas (l\u00f3gicas, m\u00e1s que f\u00edsicas) es imprescindible, as\u00ed como un buen uso (y no abuso – me repito) de los patrones de dise\u00f1o.<\/p>\n
Bueno, hasta aqu\u00ed medio cap\u00edtulo m\u00e1s … espero que os haya gustado. La segunda mitad, si no pasa nada raro, estar\u00e1 para despu\u00e9s de vacaciones. A disfrutar del merecido descanso, y que la fuerza os acompa\u00f1e \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
Buenas, ya estamos de vuelta. \u00a1 Han pasado las Navidades, y casi la Pascua ! Para que no se haga eterno y pueda publicarse antes de que cambiemos de milenio, he dividido este articulo en dos. Aqu\u00ed va la primera … Continue reading
<\/p>\nTip 12: Facilita la Reutilizaci\u00f3n (Make It Easy to Reuse<\/em>)<\/h3>\nPara evitar duplicados, si nuestro c\u00f3digo es reusable y est\u00e1 localizable en un lugar adecuado, nuestro equipo no va a reimplementar algo que ya est\u00e1 hecho. Si el c\u00f3digo no es reusable, o su uso no es facil\/amigable, nadie lo usar\u00e1, e inevitablemente, aparecer\u00e1n duplicados \ud83d\ude41<\/p>\n
En el segundo apartado, titulado Ortogonalidad<\/strong>, se trata la cohesi\u00f3n <\/em>y el acoplamiento <\/em>(2 de los conceptos m\u00e1s importantes dentro de la ingenieria del software). 2 lineas son ortogonales si forman un angulo recto. 2 vectores son ortogonales si son independientes. 2 componentes son ortogonales si al modificar uno, el otro no se ve afectado. La base de datos es ortogonal del interfaz de usuario, si al modificar la base de datos, no tenemos que modificar ninguna pantalla\u00a0 \u00bfesto es posible?<\/em><\/p>\nTip 13: Elimina los Efectos entre las Cosas que No Est\u00e1n Relacionadas (Eliminate Effect Between Unrelated Things<\/em>)<\/h3>\nAl dise\u00f1ar componentes cohesionados y con bajo acoplamiento, un cambio en un componentes evita tener que cambiar otros. Con esto, ganaremos productividad, ya que aquello que es modificable est\u00e1 localizado, y por tanto, los cambios se hacen estimable, las pruebas viables, y adem\u00e1s, se reduce el riesgo.<\/p>\n
Respecto a como eliminar los efectos, con una buena organizaci\u00f3n del equipo de desarrollo, un dise\u00f1o basado en capas, con un buen uso (y no abuso) de los patrones de dise\u00f1o, con ayuda de la AOP, etc…<\/p>\n
El tercer apartado, Reversible<\/strong>, trata sobre la inestabilidad de las decisiones. Lo que hoy es blanco, ma\u00f1ana es negro y la semana siguiente es gris. El problema viene cuando estas decisiones son cr\u00edticas, como elegir un proveedor de base de dastos o un patr\u00f3n arquitect\u00f3nico, ya que el coste de deshacer esta decisi\u00f3n suele rechazar de antemano la posibilidad del cambio.<\/p>\nDentro del marco de las metodolog\u00edas \u00e1giles, donde se abrazan los cambios y el dise\u00f1o se minimiza para favorecer la producci\u00f3n temprana de c\u00f3digo, el cual va mejorando d\u00eda a d\u00eda mediante refactorizaciones, nuestra aplicaci\u00f3n va a cambiar siempre. Lo que hoy nos vale como soluci\u00f3n, puede que dentro de un mes no. Hoy hacemos un prototipo, y la semana que viene lo tiramos a la basura.<\/p>\n
Tip 14: No Hay Decisiones Finales (There Are No Final Decisions<\/em>)<\/h3>\nPor esto, necesitamos que nuestra arquitectura sea flexible, que vea los cambios como algo bueno (al fin y al cabo, una petici\u00f3n de cambio por parte del cliente supone m\u00e1s trabajo, y m\u00e1s trabajo debe suponer m\u00e1s ingresos). \u00bfComo conseguimos una arquitectura flexible? Una arquitectura en capas (l\u00f3gicas, m\u00e1s que f\u00edsicas) es imprescindible, as\u00ed como un buen uso (y no abuso – me repito) de los patrones de dise\u00f1o.<\/p>\n
Bueno, hasta aqu\u00ed medio cap\u00edtulo m\u00e1s … espero que os haya gustado. La segunda mitad, si no pasa nada raro, estar\u00e1 para despu\u00e9s de vacaciones. A disfrutar del merecido descanso, y que la fuerza os acompa\u00f1e \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
Buenas, ya estamos de vuelta. \u00a1 Han pasado las Navidades, y casi la Pascua ! Para que no se haga eterno y pueda publicarse antes de que cambiemos de milenio, he dividido este articulo en dos. Aqu\u00ed va la primera … Continue reading
Tip 13: Elimina los Efectos entre las Cosas que No Est\u00e1n Relacionadas (Eliminate Effect Between Unrelated Things<\/em>)<\/h3>\nAl dise\u00f1ar componentes cohesionados y con bajo acoplamiento, un cambio en un componentes evita tener que cambiar otros. Con esto, ganaremos productividad, ya que aquello que es modificable est\u00e1 localizado, y por tanto, los cambios se hacen estimable, las pruebas viables, y adem\u00e1s, se reduce el riesgo.<\/p>\n
Respecto a como eliminar los efectos, con una buena organizaci\u00f3n del equipo de desarrollo, un dise\u00f1o basado en capas, con un buen uso (y no abuso) de los patrones de dise\u00f1o, con ayuda de la AOP, etc…<\/p>\n
El tercer apartado, Reversible<\/strong>, trata sobre la inestabilidad de las decisiones. Lo que hoy es blanco, ma\u00f1ana es negro y la semana siguiente es gris. El problema viene cuando estas decisiones son cr\u00edticas, como elegir un proveedor de base de dastos o un patr\u00f3n arquitect\u00f3nico, ya que el coste de deshacer esta decisi\u00f3n suele rechazar de antemano la posibilidad del cambio.<\/p>\nDentro del marco de las metodolog\u00edas \u00e1giles, donde se abrazan los cambios y el dise\u00f1o se minimiza para favorecer la producci\u00f3n temprana de c\u00f3digo, el cual va mejorando d\u00eda a d\u00eda mediante refactorizaciones, nuestra aplicaci\u00f3n va a cambiar siempre. Lo que hoy nos vale como soluci\u00f3n, puede que dentro de un mes no. Hoy hacemos un prototipo, y la semana que viene lo tiramos a la basura.<\/p>\n
Tip 14: No Hay Decisiones Finales (There Are No Final Decisions<\/em>)<\/h3>\nPor esto, necesitamos que nuestra arquitectura sea flexible, que vea los cambios como algo bueno (al fin y al cabo, una petici\u00f3n de cambio por parte del cliente supone m\u00e1s trabajo, y m\u00e1s trabajo debe suponer m\u00e1s ingresos). \u00bfComo conseguimos una arquitectura flexible? Una arquitectura en capas (l\u00f3gicas, m\u00e1s que f\u00edsicas) es imprescindible, as\u00ed como un buen uso (y no abuso – me repito) de los patrones de dise\u00f1o.<\/p>\n
Bueno, hasta aqu\u00ed medio cap\u00edtulo m\u00e1s … espero que os haya gustado. La segunda mitad, si no pasa nada raro, estar\u00e1 para despu\u00e9s de vacaciones. A disfrutar del merecido descanso, y que la fuerza os acompa\u00f1e \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
Buenas, ya estamos de vuelta. \u00a1 Han pasado las Navidades, y casi la Pascua ! Para que no se haga eterno y pueda publicarse antes de que cambiemos de milenio, he dividido este articulo en dos. Aqu\u00ed va la primera … Continue reading
Dentro del marco de las metodolog\u00edas \u00e1giles, donde se abrazan los cambios y el dise\u00f1o se minimiza para favorecer la producci\u00f3n temprana de c\u00f3digo, el cual va mejorando d\u00eda a d\u00eda mediante refactorizaciones, nuestra aplicaci\u00f3n va a cambiar siempre. Lo que hoy nos vale como soluci\u00f3n, puede que dentro de un mes no. Hoy hacemos un prototipo, y la semana que viene lo tiramos a la basura.<\/p>\n