Bas Smells in code

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.

  1. Duplicated Code
  2. Long Method
  3. Large Class
  4. Long Parameter List
  5. Divergent Change
  6. Shotgun Surgery
  7. Feature Envy
  8. Data Clumps
  9. Primitive Obsession
  10. Switch Statements
  11. Parallel Inheritance Hierarchies
  12. Lazy Class
  13. Speculative Generality
  14. Temporary Field
  15. Message Chains
  16. Middle Man
  17. Inappropriate Intimacy
  18. Alternative Classes with Different Interfaces
  19. Incomplete Library Class
  20. Data Class
  21. Refused Bequest
  22. Comments
2010
05/23
CATEGORY
DOO
TAGS



Write comment

¿MVC y Tres capas es lo mismo?

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…..

2010
05/12
CATEGORY
DOO
4 comments

Over-Engineering

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
2010
05/11
CATEGORY
DOO
TAGS




3 comments

¿Por que escribo este Blog?

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.

2010
05/11
CATEGORY
Personales
2 comments

Recent entry

Archive

Category

Follow

Get every new post delivered to your Inbox.