Hace años que pienso lo mismo y digo sin escrupulos, el diseño y la programación lo se pueden separar, dejemos de mentir. Como puede existir un diseñador de objetos que no toque código, imposible, algunos puntos:
1) No voy a discutir del diseño iterativo y el diseño "up-front", luego de 11 años en SW puedo asegurar que el único diseño valido es el evolutivo o iterativo, no existe el otro, y si existe es inválido. No puedo pensar como entener un modelo puede ser sumamemente top-down, quizá me falte inteligencia pero el evolutivo es el único que me sale a mi.
2) TDD, es imposible poder diseñar un software sin dirigirlo por test, ok, si, soy Arquitecto, pero cuando quiero programar algo, lo tengo que dirigir por test, no puedo pensar de otra manera, si separamos el rol del diseñador y el programador, TDD pierde importancia
3) Senior y Juniors: Una de las cosas que impiden el diseño (según muchos) es que un junior no puede diseñar. "Estoy muy en desacuerdo con ello", un junior si puede diseñar, definitivamente, pero problemas pocos complejejos, sencillos. No puedo concerbir la idea de un programador que no diseñe, programar es llevar a cabo el diseño a algo tangible.
4) UML. Ugghhhh, si, me gusta, pero no para dividir dos perfiles. El perfil es el mismo, el desarrollador diseña, SI, lo hace.}
Si están por entrar a una empresa donde esos roles estén separador, digan no!
Suscribirse a:
Comentarios de la entrada (Atom)
5 comentarios:
Hola Gus, como estás?
Interesante el post. Quedan todavía personas que piensen que esto es posible y funciona?
Un par de comentarios:
Estamos completamente de acuerdo en que el diseño iterativo es el único que funciona, pero yo no estoy tan seguro con TDD, si con unit testings y con que una pieza de código sin tests está incompleta y a la larga trae muchos dolores de cabeza. Sin embargo creo que se puede escribir código primero y tests después, o durante. La mayoría de los problemas que ataca TDD se refieren a problemas que surgen al no testear el código, el único que creo que tiene realmente un sentido es que TDD te ayuda a no sobrediseñar. Algo que se puede evitar de igual forma con un buen diseño y pensando en los requerimientos pero sin escribir las pruebas antes de codear.
Con respecto al senior y al junior, me da la sensación de que en muchos lados la seniority no se mide por tu capacidad para resolver problemas complejos, sino puramente por la experiencia y el conocimiento que alguien tenga de X o Y framework. Estoy de acuerdo en que todos diseñan, pero a mayor seniority se espera mayor experiencia y capacidad para resolver problemas más difíciles de formas "más elegantes" o que tengan menos "efectos secundarios" sobre el sistema. Creo que una gran diferencia entre el senior y el junior es el abanico de soluciones posibles que puede proponer ante un mismo problema y el ojo crítico que pueda tener para descartar (u horrorizarse en algunos casos) ante algunas de ellas.
Un saludo!
Gus:
Muy interesante lo que afirmas, yo tambien lo venia pensando/diciendo hace rato.
Una pequeña observacion, en cuanto al punto 1, ojo, ahora estoy trabajando en sistemas embebidos y en algunos casos es mas facil encarar un diseño/desarrollo mas en cascada que iterativo (se programa para una especificacion dura armada y con una planificacion muy dura), por ahi lo que decis se aplica a los sistemas empresariales que no son los unicos.
4) Ojo, no solo es la empresa a la que vas a entrar sino la empresa en a que trabajas. Muchas grandes empreas tienen una vision industriaistas, donde 2 o 3 "piensan" y muchos programadrores baratos de paises emergentes programan por 2 mangos... Ese modelo me parece perverso e insostenible.
Saludos
Sebastián,
Lo de TDD, "test first" o no, es una discusión larga, yo puedo dar fe que medió mucho más resultado el test first, pero entiendo que no a todas las personas le sienta cómodo. Por que a mi al principio tambien me parecía antinatural y poco productivo, pero al tiempo me di cuenta que implementando test-first generaba mejores diseños y ser más productivo.
Me gustó mucho la otra dimensión que agregaste y que yo no tenía en cuenta, sobre la cantidad de soluciones, comparto. Y a eso agregaría que para ser más senior debessaber elegir la mas simple :)
Gona,
Seguramente un diferente dominio pueda hacer que el BDUF sea más fortuito, me resulta raro pero obviamente me gustaría escucharte en un par de meses a ver si seguis pensando igual.
Respecto a tu segundo comentario, no entendí si estás apoyando lo que dije o si pensás que en grandes empresas no se puede aplicar, o las dos :)
Un abrazo
En un par de meses hablamos si queres.. jaja
Creo que las grandes empresas intentan aplicarlo en perjuicio de sus empleados (o tercerizados, o contratados) y muchas veces de ellas mismas por ignorancia principalmente de lo que estan haciendo.
Me interesa saber que se puede hacer si ya estas en una empresa donde esos roles estan separados.
Publicar un comentario