Programación y comunicación
Cuando se desarrolla software la comunicación es muy importante. Hay comunicación a muchos niveles, y en ocasiones las personas que participan en el desarrollo pertenecen a profesiones distintas, en las que se emplean conceptos y enfoques muy diferentes a los de los técnicos informáticos. Sin embargo, en este comentario me voy a centrar en la comunicación entre los miembros del equipo de desarrollo, y en concreto la que tienen que mantener los analistas, arquitectos o diseñadores con los programadores.
Quiero comentar esto porque en principio puede parecer que de todos los tipos de comunicación posibles, éste debería ser uno de los menos problemáticos, y suele ser así, no obstante uno se encuentra también con ciertos problemas.
El que uno considere esta comunicación más sencilla, se debe a que los analistas y diseñadores han sido o son aún programadores, y por tanto se supone que conocen la forma de transmitir sus ideas a los programadores. Esto es razonable y suele facilitar las cosas, pero no siempre sale bien. Supongamos el siguiente caso, se tiene una aplicación en producción a la que hay que hacer unos cambios para incorporar una nueva funcionalidad. El desarrollo se deja en manos de un analista y un programador. La idea es que el analista plantee las necesidades y el programador las implemente siguiendo la arquitectura y diseño que ya emplea la aplicación.
Un analista describe un sistema empleando un vocabulario y unos conceptos propios del análisis, mientras que un programador suele pensar en términos del lenguaje de programación que conoce o tiene que usar. Suele ocurrir que los programadores tienen menos experiencia y sólo conocen (si los conocen a fondo) lenguajes de programación (pueden conocer lenguajes como UML, pero si no los emplean normalmente tampoco servirá de mucho, eso de: 'Sí, en la carrrera he dado UML', no suele funcionar). La distancia existente entre ambas mentalidades puede quedar más clara si uno piensa en un analista con varios casos de uso, y un programador intentando identificar clases, operaciones y variables en las elipses, líneas y monigotes del caso de uso.
Una vez que el analista tiene terminado el análisis, y comienza a explicárselo al programador, o simplemente se lo pasa y espera a que éste pregunte, se puede dar cuenta de que su lenguaje no funciona, que el programador no termina de entender el análisis, el programador quiere ver cosas como clases y operaciones. Ante esta situación, el analista opta por bajar a su nivel y empieza a diseñar con el programador. Esto suele acabar con el analista describiendo las cosas al más bajo nivel, aquel que entiende el programador, el de las clases y operaciones que hay que usar y si aquí se usan parámetros por valor o por referencia. En este punto el analista ha olvidado el análisis, y se ha convertido en un programador más. Esto no tendría que salir mal, de hecho parece funcionar si el analista conoce bien el lenguaje y el diseño de la aplicación. El problema está en que el programador puede seguir sin enterarse de qué van los cambios. Entiende que aquí va la clase FooBar, con las operaciones foo y bar, que foo llama a foo2, ... etc., pero el problema está en que no sabe por qué debe haber una clase FooBar, por qué debe tener las operaciones foo y bar y por qué foo debe llamar a foo2. Tarde o temprano tendrá que tomar alguna decisión por sí mismo, ya que en la implementación aparecerán cosas que no habló en su momento con el analista, y hará suposiciones que sólo podrá basar en su limitado conocimiento del problema, basado en detalles de implementación que le no permiten ver el bosque.
Esto no es un caso extremo, es un problema real y recurrente. El no tenerlo en cuenta es una garantía de su continua aparición.
Technorati tags: programacion
Quiero comentar esto porque en principio puede parecer que de todos los tipos de comunicación posibles, éste debería ser uno de los menos problemáticos, y suele ser así, no obstante uno se encuentra también con ciertos problemas.
El que uno considere esta comunicación más sencilla, se debe a que los analistas y diseñadores han sido o son aún programadores, y por tanto se supone que conocen la forma de transmitir sus ideas a los programadores. Esto es razonable y suele facilitar las cosas, pero no siempre sale bien. Supongamos el siguiente caso, se tiene una aplicación en producción a la que hay que hacer unos cambios para incorporar una nueva funcionalidad. El desarrollo se deja en manos de un analista y un programador. La idea es que el analista plantee las necesidades y el programador las implemente siguiendo la arquitectura y diseño que ya emplea la aplicación.
Un analista describe un sistema empleando un vocabulario y unos conceptos propios del análisis, mientras que un programador suele pensar en términos del lenguaje de programación que conoce o tiene que usar. Suele ocurrir que los programadores tienen menos experiencia y sólo conocen (si los conocen a fondo) lenguajes de programación (pueden conocer lenguajes como UML, pero si no los emplean normalmente tampoco servirá de mucho, eso de: 'Sí, en la carrrera he dado UML', no suele funcionar). La distancia existente entre ambas mentalidades puede quedar más clara si uno piensa en un analista con varios casos de uso, y un programador intentando identificar clases, operaciones y variables en las elipses, líneas y monigotes del caso de uso.
Una vez que el analista tiene terminado el análisis, y comienza a explicárselo al programador, o simplemente se lo pasa y espera a que éste pregunte, se puede dar cuenta de que su lenguaje no funciona, que el programador no termina de entender el análisis, el programador quiere ver cosas como clases y operaciones. Ante esta situación, el analista opta por bajar a su nivel y empieza a diseñar con el programador. Esto suele acabar con el analista describiendo las cosas al más bajo nivel, aquel que entiende el programador, el de las clases y operaciones que hay que usar y si aquí se usan parámetros por valor o por referencia. En este punto el analista ha olvidado el análisis, y se ha convertido en un programador más. Esto no tendría que salir mal, de hecho parece funcionar si el analista conoce bien el lenguaje y el diseño de la aplicación. El problema está en que el programador puede seguir sin enterarse de qué van los cambios. Entiende que aquí va la clase FooBar, con las operaciones foo y bar, que foo llama a foo2, ... etc., pero el problema está en que no sabe por qué debe haber una clase FooBar, por qué debe tener las operaciones foo y bar y por qué foo debe llamar a foo2. Tarde o temprano tendrá que tomar alguna decisión por sí mismo, ya que en la implementación aparecerán cosas que no habló en su momento con el analista, y hará suposiciones que sólo podrá basar en su limitado conocimiento del problema, basado en detalles de implementación que le no permiten ver el bosque.
Esto no es un caso extremo, es un problema real y recurrente. El no tenerlo en cuenta es una garantía de su continua aparición.
Technorati tags: programacion
[ENLACE PERMANENTE]
|
|
