Software Potter

Bas Smells in code

Arturo Elias Antón — Sun, 23 May 2010 22:55:33 +0000

La otra vez estaba mirando el código de un proyecto y me acorde del capítulo “Bad Smells in Code” del libro de Martin Fowler “Refactoring Improving the Design Of Existing Code”

El concepto de “Smells(olores)” me gusto mucho. “Smells” se da cuando uno mira el código y dice “algo me huele mal”. Digamos que esos olores son esos “Smells”

Dejare una lista de los supuestos “Smells” que podemos encontrar en nuestro código según Martin Fowler y con el correr de los días explicaremos uno a uno. Si bien la lista la dejare en ingles en general es fácil entender su concepto.

Duplicated Code
Long Method
Large Class
Long Parameter List
Divergent Change
Shotgun Surgery
Feature Envy
Data Clumps
Primitive Obsession
Switch Statements
Parallel Inheritance Hierarchies
Lazy Class
Speculative Generality
Temporary Field
Message Chains
Middle Man
Inappropriate Intimacy
Alternative Classes with Different Interfaces
Incomplete Library Class
Data Class
Refused Bequest
Comments

¿MVC y Tres capas es lo mismo?

Arturo Elias Antón — Wed, 12 May 2010 15:15:01 +0000

Hoy en el trabajo tuve una pregunta de mi coordinador que me pareció copada, ya que es una duda generalizada en el ámbito de desarrollo.

¿MVC y Tres capas es lo mismo?

Empecemos por el principio

¿A qué apuntamos con el modelo de tres capas?
Cuando hacemos un modelo de tres capas apuntamos a la separación de la lógica de diseño y de negocio, con la esperanza de que posteriormente se puedan realizar modificaciones en una capa sin que la otra se vea afectada.
¿A qué apuntamos con el patrón MVC?
Con MVC apuntamos a definir la secuencia de ejecución que seguirá la aplicación para resolver las peticiones realizadas por los usuarios.

En otras palabras cuando hablamos de MVC no hablamos de Tres Capas y cuando hablamos de Tres Capas no hablamos de MVC.

Bien entonces como ¿Cómo conviven?

Una distribución posible podría ser esta…

Vista : Corresponde con las UI. Esto corresponde claramente con la capa de presentación de la arquitectura en 3 capas.
Modelo: Es el sitio donde se almacena el código que obtiene la información de la base de datos. Se encarga de llevar a cabo los eventos dictados por el controlador. Tendría correspondencia con la capa de acceso a datos y una parte de la capa de negocio.
Controlador: El controlador es el que recibe la petición del usuario, decidiendo que página (vista) deberá ser mostrada. Esto implica invocar la lógica de negocio, obtener los datos (modelo) e inyectar la información en la vista para que la solicitud sea servida al usuario (o dejarla preparada para que sea la propia vista la que acceda al modelo). Corresponde con una parte de la capa de negocio.

Como siempre espero sus comentarios…..

Over-Engineering

Arturo Elias Antón — Tue, 11 May 2010 17:04:27 +0000

Tal vez el motivo más grande de que se provoque la overengineering (sobre-ingenieria), es el temor que tenemos nosotros mismos a quedar atados a un mal diseño. Sabiendo que un mal diseño es el monstruo, que luego no podremos dominar ni a nivel código, ni a nivel diseño. Por este motivo empezamos a pensar en que nuestro diseño, debe soportar las mejoras del mañana y ser flexible al cambio. Ahora bien como dice Kerievsky en su primer capítulo de “Refactoring to Patterns” eso suena bien si somos psíquicos.

El problema viene aparejado de cuando nos equivocamos en nuestra predicciones, primero diseñamos y escribimos un montón de código que no sirve, y encima ese código no se purga mas, haciendo más difícil a al equipo de desarrollo de interactuar con ese código, para realizar mejoras o corrigiendo bugs.

Para empezar a manejar este monstruo gigante que creamos con un diseño overengineering. La gente decide atacarlo por partes, por ende, al ver solo una parte del sistema, duplican código y no purgan el código ya que puede llegar a tocar un modulo que no le corresponda. Nunca ven el total del monstruo.

Uno de los principales problemas de la overengineering es que suele pasar en silencio en las etapas tempranas de los proyectos, ya que ni los arquitectos, ni los programadores suelen darse cuenta de que están haciendo overengineering hasta después de la primer o segunda implementación.

Si usted está por modelar un sistema y quiere dormir tranquilo piense en esto… si usted ya es padre de un monstruo como me pasa a mí y a casi todos, úselo de experiencia para los nuevos proyectos y no se enamore de sus diseños complejos que solo usted lo entiende por su nivel de seniority. Recuerde que su nivel es más alto cuando más personas pueden entenderlo.

Como siempre, espero que les guste… :p

¿Por que escribo este Blog?

Arturo Elias Antón — Tue, 11 May 2010 01:55:51 +0000

En parte es por que siento que PythonR2 concluyo su ciclo y en otra parte es un blog muy Python, de tal manera que no da lugar a escribir algo fuera de Python.

En estos últimos tiempos he tenido muchas ganas de escribir sobre Java, .Net y simplemente POO. Ojo con esto no quiero decir que se me fue las ganas de escribir sobre Python. Pero la verdad es que, no solo de Python esta hecho el mundo ¿no?…

Bueno como siempre espero que en esta nueva etapa les guste y podamos intercambiar muchas ideas y conocimientos.