Maldivas Arquitectura 1 – El sentido común

Antes de nada, no pretendo dar un manual de cómo se deben abordar las aplicaciones de hoy en día, tan solo traslado parte de lo que he aprendido a lo largo de mis años de desarrollo, no me considero un experto en arquitectura, tan solo tengo la experiencia de varios proyectos en los que he trabajado, tratare de daros las pautas e informaros de los errores que he visto y cometido en estos años. Espero que os ayuden en vuestro trabajo.

La arquitectura de una aplicación es con mucho la parte más importante de cualquier proyecto, la toma de decisiones en este apartado marcara el éxito o el fracaso de nuestro trabajo, por ello, deberemos pensar muy bien qué hacer en esta primera fase de desarrollo. Es aquí donde se cometen la mayoría de los errores más graves de diseño de una aplicación.Mi recomendación a la hora de decidirme por una arquitectura es la siguiente:

Primero y lo más importante “UTILIZAR EL SENTIDO COMÚN” y no dar nada por concluido hasta que no estemos verdaderamente seguros de haber llegado a la solución adecuada.

No hace mucho tiempo, cuando estábamos trabajando en la arquitectura de la aplicación actual, un arquitecto nos explico cómo aplicar el patrón Entity relationship Model, después de varios días de trabajo, el proyecto era algo así, por cada entidad lógicamente teníamos que tener un manager que nos permitiese realizar una serie de operaciones comunes, obtener un registro, obtener una lista de registros, grabar un dato de una entidad, etc, etc, acabamos la semana con un mantenimiento sencillo, que permitía dar de alta, buscar, grabar datos y movernos de un registro a otro, con una pequeña apreciación, en el manager teníamos aproximadamente mil líneas de código y en el mantenimiento teníamos otras mil, la capa de datos la habíamos hecho más o menos genérica, yo al verlo dije, esto no es viable, la aplicación así no funcionara, si tengo que implementar mil líneas en cada formulario y otras tantas en cada manager, dos mil por mantenimiento y parto de la base en el que el sistema va a tener más de mil tablas, significa que estamos hablando de 2000000 de líneas de código, y si por cualquier motivo tengo que variar una función esto me obligaría a repetirlas en los sucesivos mantenimientos, tantas lineas me parecian imposibles de mantener.

Recuerdo varias discusiones con mi equipo de trabajo, en el que alguno me decía, la arquitectura es correcta, yo he realizado de forma similar mis mantenimientos toda la vida y las aplicaciones han funcionado, y tenía razón sus aplicaciones habían funcionado pero los requerimientos eran diferentes no era lo mismo trabajar y mantener pocas tablas que trabajar con cientos de ellas. En el desarrollo de un proyecto anterior habiamos logrando realizar mantenimientos complejos sin apenas añadir ninguna línea de código utilizando basicamente herencia visual, tan solo configurando algunas propiedades del formulario, asi que sabia que podriamos optimizar mucho mas las capas. La solución final, apenas 20 líneas de código por cada mantenimiento, manager de la capa de negocios y capa de datos. Nos llevo varios meses, y rehacer el proyecto de principio a fin varias veces. Recuerdo que alguno decía, si lo rehaces una vez más abandono el trabajo…

Si no tenemos la suficiente experiencia debemos aceptarlo, un desarrollador no tiene porque ser un experto en arquitectura, tan solo conocera aquellas en las que haya trabajado, posteriormente podemos estudiar diferentes alternativas y ver la que mejor se adecua a la solución que buscamos o rodearnos de aquellas personas que si entiendan de arquitectura y que tengan experiencia en desarrollos y soluciones de problemas similares. Si una empresa se tiene que gastar dinero en pagar a una buena consultora sobre cómo realizar la arquitectura de una solución, será mejor realizar la inversión al principio que cuando nuestro proyecto este paralizado, y nos obligue a tener que rehacer la mayoría del desarrollo asumiendo los costes e implicaciones que ello supone. Debemos tener sumo cuidado con la elección de los consultores, lo mejor es preguntar a varias y asegurarnos que están capacitadas para realizar el trabajo, solicitando información sobre sus proyectos e incluso hablando con los clientes que han utilizado sus servicios, he visto empresas con proyectos millonarios que han fracasado por culpa de las consultoras.

           He oido frases como: “La aplicación tiene que estar en 6 meses, hay que empezar a trabajar ya, no podemos dedicar un mes a ver como lo hacemos”. Este es uno de los errores más comunes, no le damos la suficiente importancia a la arquitectura. Si no estamos dispuestos a pararnos y pensar cómo abordar la solución de un proyecto de la mejor forma posible, estamos condenados al fracaso. En arquitectura los errores que se cometen al principio se pagan caros al final.

Sobre los “arquitectos de software, me he asombrado a veces cuando alguna personas me dice: Yo soy arquitecto de software, se que es un término que gusta, además creo que esta de moda hoy en día, ultimamente veo aparecer arquitectos de software como por arte de magia. Recuerdo una conversación con uno… ¿cuántos años tienes? 24, ¿Desde cuándo te dedicas a la informática?  Acabe la carrera a los 22, ¿Cuántos proyectos has realizado? Muchísimos, ¿Qué duración tenían?, el mayor 6 meses…

No digo que no puedan existir Arquitectos de Software de 24 años, pero será la excepción que rompe la regla, para ser un buen arquitecto no vale haber estudiado una carrera o haber leído varios libros sobre arquitectura, patrones de diseño y mejores prácticas, sobre todo los arquitectos han tenido que participar y trabajar en varios proyectos de diversa índole, deben tener la experiencia, haber fracasado, y haber solucionado con éxito infinidad de problemas que tienen todas fases de un desarrollo. De la misma forma que un Jefe de Proyectos no será bueno si antes no ha sido desarrollador, un Arquitecto debe tener una amplia experiencia en soluciones de software, haber participado en multitud de proyectos diferentes y sobre todo, debe saber transmitir sus ideas y escuchar a los que le rodean, ¿Quién sabe más de programación?, el que está escribiendo líneas todos los días o el que desde su despacho lee de arquitectura y te dice como tienes que trabajar.

16 comentarios en “Maldivas Arquitectura 1 – El sentido común”

  1. muy deacuerdo contigo, sobre eso de que ahora salen muchos ” arquitectos “, lo bueno es que en la mayoria de casos terminan quemandose solos… a la hora de la ejecucion…, pero sobre eso de los titulos… en si veo un afan desmedido por ” mostrar titulos y papelitos” … recuerdo que una vez vi a alguien que tenia ” mcp, mcad, mcsd…” … jeje…

    Sobre la solucion final que tuviste, seria bueno si explicaras mas como quedo 🙂

    Salu2

    DDaz

  2. David, tengo previsto realizar un Post detallado sobre la arquitectura de la aplicación, quizás en un par de semanas, por anticiparte algo te diré que la solución paso por la utilización de generics, que en esos momentos acababa de aparecer con visual studio 2005, esa fue la clave para poder reducir el código de los managers de la capa de negocios y la capa de datos, en la capa de presentación tuvimos que utilizar un interface común, ya que hasta día de hoy todavía no han solucionado el problema de la utilización de generics en la invocación de los formularios.

  3. Hola Juan!
    En estos tiempos que corren existe un virus muy extendido, se llama “titulitis”, muy al hilo de lo que comentas…
    Me ha despertado la curiosidad los ultimos posts que has escrito … estaría muy interesado en ir una mañana a visitarte y conocer tu trabajo.
    Saludos!!

  4. Miguel y Daniel, no me refería a la titulitis, entiendo que haber estudiado en una universidad, haber sido capaz de sacar titulaciones como mcp, mcad, mcsd, etc, tienen un mérito enorme y sobre todo dicen de ti que tienes un nivel  técnico suficiente como para abordar casi cualquier proyecto con arquitecturas de Microsoft.

    Hoy en día hay que tener una gran capacidad para sacar cualquier carrera técnica.

    Me refiero a que determinado estatus no se puede alcanzar únicamente con una experiencia de 2 o 5 años, convertirte en un experto en c#.net puede llevar más de ese periodo.

    La preparación y a la experiencia, son características que simplemente llevan tiempo y que se dan en determinadas circunstancias, por muy bueno que sea un informático si solo ha trabajado con dispositivos móviles a lo largo de su carrera, seguro que será un experto, pero será difícil que pueda desarrollar la arquitectura de un proyecto web si nunca a participado en uno, ya que su experiencia no será suficiente.

    Por eso digo que muchos se creen Arquitectos cuando en realidad su experiencia no les permitirá elegir correctamente la solución más adecuada y por eso es tan difícil encontrar buenos arquitectos, por que se tienen que dar un cumulo de circunstancias para que alguien alcance este estatus.

    Miguel al hilo de conocernos, claro¡¡¡ cuando quieras, envíame un correo y quedamos.

  5. Quería recalcar el uso de sentido común, que hace tiempo lo escuche de un maestro que dijo: hay que usar el sentido común… y como dices el sentido común no te lo da el haber varios libros (por lo menos el sentido común que se necesita para hacer y resolver problemas de software), el sentido común te lo da la experiencia sea exitosa o no, hable un poco de eso en esta entrada (http://geeks.ms/blogs/sergiotarrillo/archive/2008/06/18/89195.aspx)

    Que sigan tus post, estoy siguiendo la serie 😀

    Saludos,

  6. Hola:

    Lo de la experiencia, me habia quedado mu claro, aunque no olvides que en estos tiempos, es relativamente facil -para el que solo busca un papel – encontrar preguntas en la www y memorizarlas…

    pero bueno al parecer no captaste bien lo que puse, si te fijas… mcp, mcad, mcsd.. es lo mismo…(ya que uno contiene al otro), cual seria el motivo de poner los 3 a la vez en una misma linea??, algo que e visto muy comunmente, es que las personas que sufren de titulitis ( como lo puso miguel) son las que a la hora de la practica -cuando las papas queman- son las que primero caen…, en cambio hay muchos, que el titulo es lo de menos, pero en la practica, te dejan asombrado por todo lo que saben, el detalle es que esto no solo pasa con ” arquitecto”, o ” programador con experiencia”, sino tambien con ” administrador de servidores, dba, etc…

    Salu2

    Ddaz

  7. Colega muy enriquecedoras tus experiencias, yo apenas tengo un año como desarrollador y aun no me he graduado de ingeniero, pero si he visto mucho en este campo el egocentrismo que se maneja…

    En fin, colega quisiera que detallaras muchísimo mas el uso de generics, por que la verdad no tenia conocimiento de esto y he desarrollado el proyecto sin generics, y creo que es tiempo de parar y cambiar la forma de trabajo…

    He buscado en internet acerca de generics, he encontrado material pero muy teorico y solo hablan de su funcionamiento y su desempeño… Quisiera que hablar de una clase en especifica de tu proyecto y nos mostraras algo de código, como es el DAO en generics como es el uso de una identidad en generics…

    Colega un saludo y espero pronto mas posts interesantes de tu proyecto y experiencias…

  8. Sergio, gracias por la entrada, no la había leído.

    Sac087, no te preocupes, intentare detallar con código parte de la arquitectura, y que sea compresible para todo el mundo, espero terminar el post a lo largo de la semana.

  9. Una pregunta Juan ¿Que opinas de poseer un framework? Yo he sido siempre partidario de ellos poero me ha sorprendido ver a gente de plain concepts “sonreirse” cuando le comentas algo del framework, no te dicen nada pero no estan muy en su favor ¿que opinas tu? ¿crees que es necesario tener un framework o al menos una fina capa en interface de usuario y acceso a datos que te permita hacer manipulaciones gordas tocando en un solo sitio? A lo mejor es que yo me he quedado anticuado, no sé, ummmmmm

  10. Julio, no sé muy bien si te refieres a un framework de terceros, si es así, te voy a intentar responder con otra pregunta ¿Cuanto control necesitas tener sobre tu aplicación? Si tu respuesta es:

    A mí el control sobre mi aplicación no me importa excesivamente, la funcionalidad que quiero implementar me la ofrece el framework, te diría adelante, utilizalo, lo erróneo seria no utilizar algo que se supone esta hecho, probado y lo utiliza más gente que tu.

    En cambio si tu respuesta es, el framework me ofrece muchas cosas, pero hay alguna que necesito implementar y con las reglas del propio framework se me hace muy difícil. Entonces si tienes un framework que no te puede ofrecer aquello que necesitas porque añadirle cualquier cosa es más complicado que hacerlo tu mismo, no lo utilices.

    La principal ventaja de los Frameworks es que el desarrollo es muy rápido, incorporan gran cantidad de utilidades Autentificación, Seguridad y otras que permiten que el desarrollo sea increíblemente rápido, en algunos, los desarrolladores hacen una labor de parametrización más que de programación.

    En proyectos en los que prima la rapidez y los requerimientos son sencillos o los recursos limitados, me refiero a “personal, capacitación, presupuesto y otros factores”, puede ser una buena idea utilizar un framework.

    Las posibles desventajas son:

    – Pierdes el control de tu aplicación, si utilizas funcionalidad ya creada, no sabes cómo funciona internamente, realizar cambios y modificaciones suele ser más costoso.
    – Cuando quieres añadir algo de funcionalidad, tienes que aprender cómo funciona el internamente, esto a veces es una tarea larga y tediosa.
    – Algunas veces no puedes romper sus reglas de negocio, estas suelen ser estrictas para hacer que todo siga funcionando.
    – Los framewoks muchas veces implementa gran cantidad de funcionalidad que nunca vas a utilizar, esto hace que las aplicaciones consuman más recursos de los necesarios.
    – Creas dependencia del proveedor. Para aumentar la funcionalidad del desarrollo dependes de su proveedor, si este abandona el proyecto, estas condenado a que tu aplicación no pueda evolucionar.

    En cualquier caso debes pensar una cosa .net es un framework excelente y todo el mundo lo usa, porque su construcción está muy bien realizada y se puede extender con facilidad.

    Así que la decisión es muy fácil, pon tus especificaciones en una balanza y elige aquella que más se adapte a tus necesidades.

    Espero haberte ayudado.

  11. Hola Juan, gracias por tu respuesta
    Hola Rodri, saludos a Jose Luis Soria.

    Haber, antes de nada, comento mi entorno o mi mundo, he pecado de no hacerlo, creo que con eso entenderemos la potencia de un framework

    A principios de los años 90 en la empresa donde entonces trabajaba nos hicimos un framework (en lenguaje C), y todas las aplicaciones se basaron en él (aplicaciones de paquetes estandard), cuando llegó windows 95 y sucesores, solo tuvimos que cambiar la parte del framework de interface de usuario, y encima nos la hicieron fuera; se la encargamos a un partner de Microsoft que hacía outsourcing, es decir, de la noche a la mañana tuvimos TODAS las aplicaciones de modo consola a modo grafico (diálogos windows). Lo mismo ocurrió con el acceso a datos, pasamos de gestor de ficheros a una BBDD con un esfuerzo muy poco costoso.

    Ahora trabajo en otra empresa muy parecida, tenemos software de aplicaciones estándard y estamos migrando a .Net, cuando hablo de framework hablo de desarrollarnos uno nosotros, no muy extenso pero que cubra areas de acceso a datos, interfaz, seguridad, publicación de información etc…

    ¿Que opinais?

    PD Si quereis posponemos el tema para otro post, avisarme y me suscribo.

    Un saludo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *