www.javahispano.org: Tu lenguaje, tu comunidad

Comentarios: 2

• remoh 26/03/2008 23:25

  Hola luis, lo primero gracias por escucharnos :P

  El concepto que comentas es interesante, debe existir alguien que se responsabilize de los niveles de calidad en el código, aunque esto puede entenderse de distintas formas, me explico, con una cosa que hay que tener cuidado es en que esa responsabilidad no derive en la creación de "islas de conocimiento" donde determinados modulos sólo hay una o dos personas dentro del proyecto con el conocimiento suficiente para modificarlos/mantenerlos. En mi experiencia este es el efecto que he visto más habitualmente y el que más problemas termina causando a medio/largo plazo. Cada responsable termina montando su "cortijo" en cada módulo con sus propias normas (de estilo, codificación etc,etc), o peor aún, estableciendo como norma la falta de normas. Esto al final generá graves problema de dependencia de determinadas personas dentro de un proyecto y convierte en imposible la movilidad y el intercambio de funciones dentro de un proyecto, multiplicando los gastos en mantenimiento de un proyecto.
  

  Por ejemplo una de las practicas de XP es la propiedad colectiva del código, que deriva en una responsabilidad colectiva, es decir, todos los mienbros del proyecto deben ser capaces de responsabilizarse de cada linea de código del proyecto. Esto sólo es posible con mobilidad dentro de un proyecto, también otras tecnicas como la programación en parejas o las revisiones peer-to-peer sirven para fomentar esta responsabilidad colectiva. En mi opinión esta responabilidad colectiva es más deseable que una responsabilidad individualizada, por los problemas que comentaba antes.

  Esto por supuesto es, como casi siempre, más facil decirlo que hacerlo, en proyectos medios/pequeños (hasta 15 personas aprox según XP) y con mienbros con un nivel tecnico elevado puede dar muy buenos resultados. En otros escenarios como proyectos de mayor embergadura o con personal de menor capacitación tecnica quizas sea conveniente establecer mecanismos de control más rigidos, incluso tener un serie de personas encargadas de mantener una calidad y homogeneización adecuada en toda la base de código. Otra alternativa es subdividir un proyecto grande en pequeños nucleos agiles y trazar sólo unas lineas generales delegando la responsabilidad de cada subproyecto a cada uno de los grupos agiles de trabajo.

  Como casi siempre en ingenieria del software no hay respuestas únicas, habrá que analizar cada contexto para buscar la mejor solución, lo que si que esta claro es que la organización debe de poner los medios y la atención necesaria en la calidad del codigo que produce y preocuparse de realizar esta definición de responsabilidades ya sea colectiva o individualizada.

   

• venkman 27/03/2008 09:18

  Sin querer desviar el tema a otras cosas...

  "y con miembros con un nivel tecnico elevado"

  Porque probablemente esa es una de las principales pegas de la propiedad colectiva del código, que se hace necesario reducir el nivel a la media del grupo. Si todo el grupo tiene un nivel alto, bien, pero si no, los "mejores" tendrán que reducir su nivel para que el resto pueda seguirles.

   

  Respecto a lo que se dice en el blog ("Entendemos como “responsable sobre el código” a la persona conocedora del código y que es capaz de garantizar su correcto funcionamiento."), yo estoy con lo que dice remoh. Me parece que hacer que la garantía del correcto funcionamiento recaiga sobre una persona, acaba creando parcelas.

  Y es más, el problema de garantizar el correcto funcionamiento de un programa, es un clásico con una dificultad no trivial, en algunos casos no resoluble completamente. Poner a una persona que diga que algo funciona bien "porque lo digo yo" es un tanto ingenuo, por muy bueno que sea ese responsable. Creo que es mejor optar por mecanismos como tests y pruebas que permitan comprobar la corrección hasta donde alcanza la definición del proyecto. Si estableces unas pruebas y el código lo pasa, la garantía no es total, pero al menos sí cubre lo definido en las pruebas. (Evidentemente surge entonces el problema de definir unas pruebas suficientemente buenas, pero si hablamos de ingeniería esto es algo que ya está resuelto: No necesita ser perfecto, sólo necesitas decir cómo es de bueno (*)).

  Es decir, que una persona puede ser responsable de un código, sí, por ser quien lo conoce o quien lo ha revisado, normalizado o lo que queráis. Y puede ser responsable de la correción del código a nivel moral (por decirlo de algún modo). Pero la garantía de funcionamiento correcto (limitado) a nivel formal, nunca puede dejarse descansar sobre el "yo digo que está bien" de ninguna persona. Ni de una pareja de personas, ni de un grupo.

  Por otra parte, la asociación metodologías ágiles <-> necesidad de excelencia es falsa (emmo). La necesidad de excelencia no deriva de la agilidad ni de la mayor relación con el cliente. Es un ejemplo muy clásico el del desarrollo de proyectos militares, donde el modelo es completamente en cascada y para nada ágil. Los requerimientos de calidad elevados son los que realmente derivan en la necesidad de excelencia y responsabilidad.

   

   

  (*) Por si no queda claro esto, hablo de que en cualquier ingeniería se manejan tolerancias y márgenes de error como herramienta básica y fundamental de garantía limitada de corrección. Una herramienta tal es precisa hasta un margen de tanto y con una tolerancia de cuanto. No es perfecta, pero se establecen los márgenes en los que es válida.