En desarrollo de software, de religión no se habla
En el libro Code Complete, Steve McConnell dice:
Managers of programming projects aren’t always aware that certain programming issues are matters of religion. If you’re a manager and you try to require compliance with certain programming practices, you’re inviting your programmers’ ire. Here’s a list of religious issues:
-
Programming language - Indentation style
- Placing of braces
- Choice of IDE
- Commenting style
- Efficiency vs. readability trade-offs
- Choice of methodology—for example, scrum vs. extreme programming vs. evolutionary delivery
- Programming utilities
- Naming conventions
- Use of gotos
- Use of global variables
- Measurements, especially productivity measures such as lines of code per day
¿Están de acuerdo? ¿Descartarían alguno? El libro es de 2004, de modo que algunos se quedaron viejos directamente pero otros son claramente objetables. Hago mi lista de objetables:
- Indentation style
- Placing of braces
- Choice of IDE
- Programming utilities
- Naming conventions
- Use of gotos
- Use of global variables
Realmente ¿queda alguien programando que sea capaz de enojarse en una discusión sobre el uso del goto o sobre el lugar donde ponemos las llaves?
Seguimos pensando..
Hola Ernesto, ¿cómo estás?
ResponderBorrarYo soy responsable de un equipo en una sw factory, y para lograr cierto nivel de productividad consideramos necesario que cualquiera del equipo pueda seguir/sentir el código de otro como si hubiese sido generado por uno mismo.
En mi experiencia real eso se logra cuando todo el equipo adopta determinadas normas de codificación, entre las que figuran las 7 que mencionas en tu post.
Pensémoslo de otra forma: si fuese una fábrica de cualquier otra cosa, ¿Cómo crees que resultaría el producto terminado si cada operario de cada puesto de trabajo de la línea de producción apretase tornillos, armase/pintase partes, pegara etiquetas/instrucciones, etc. cómo mejor le parezca, de acuerdo a su humor/creatividad/energía en un determinado momento?
En conclusión, a tu pregunta de si queda alguien programando, que sea capaz de enojarse por el uso del goto o sobre el lugar donde ponemos las llaves, la respuesta es: si, YO!! =D
Seguimos pensando... siempre!!
--
GS
Hola Ernesto.
ResponderBorrarOpino como el artículo, todo es como la religión, en el sentido de cómo se ponen los que discuten. También soy responsable de equipos de desarrollo pero hago lo contrario de GS, trato que sean mínimos los acuerdos (sobre identación, nombres, etc) y que dentro de esos parámetros (bastante amplios) cada uno puede hacer cómo le parezca. La regla es no cambiar el estilo cuando se está tocando código de otro. Eso tiene varias ventajas, cuando el programador está haciendo código nuevo está más cómodo que si tuviera que seguir normas estrictas que no comparte en su fuero íntimo. Si está siguiendo código de otro está tan incómodo como lo hubiera estado con normas estrictas. Además cuando mira el código el líder de proyecto dice "esto es letra de Fulano" (con solo mirar el estilo).
Creo que ser más o menos estricto en estos puntos también es una cuestión de religión.
Opino que el GOTO sigue existiendo. Ahora se llama RETURN o EXIT o LOOP o CONTINUE (de acuerdo al lenguaje). Y también se pueden poner reglas. Es lo mismo escribir dos returns o un return?
if(esta_condicion_rara){
return false;
}
mas_cosas();
return resultado;
// vs
if(esta_condicion_rara){
resultado=false;
}else{ // sí, los dos corchetes van acá!
mas_cosas();
}
return resultado;
Saludos. Buen blog.
Hola Emilio, ¿Cómo estás?
BorrarSólo quería hacer algunas aclaraciones, para terminar de redondear el concepto de que las pautas en este tema son necesarias, porque brinda cierto grado de homogeneidad en la medición del rendimiento del equipo, asimismo permite la resolución de ciertos conflictos.
Por ejemplo:
-"Uh, pero este código es un lío! A MI me lleva 200hs arreglarlo"
-"Este código no da para más! hay que hacer una REINGENIERIA".
Ahí es donde a quien debe responder por la performance del le sube la bilirrubina directa o conjugada a 10.000,00.- mg/dl (valores normales en adultos: 0 a 0,3 mg/dl) =P
Hablando en serio y yendo al punto, sumo algunas aclaraciones a mi comentario inicial:
1. Cuando digo "para lograr cierto nivel de productividad consideramos necesario" estoy hablando de que es el mismo equipo quien considera la necesidad, no los jefes.
2. Cuando digo "cuando todo el equipo adopta determinadas normas de codificación" estoy refiriéndome a normas/pautas, que un miembro del equipo puede elegir seguir o no, y en mi experiencia, sucede que el equipo "autoregula" al miembro que no sigue las pautas, porque ya todos en el equipo han comprobado "en carne propia" lo que implica seguirlas o no seguirlas: horas y horas y horas de soporte y clientes que te sofocan porque sencillamente no lográs meter el fix en el código que ya se ha vuelto inmantenible, versus miembros del equipo que quiere tomar guardias!! pagas!! porque ya saben de antemano que arreglar un bug no va a ser una tortura, porque el código es mantenible.
3. Las normas/pautas que aplicamos en el equipo no suprimen la creatividad, por lo que "el código de fulano" sigue siendo reconocible, y su estilo en la resolución de una funcionalidad es totalmente respetable, siempre y cuando no le encarajine la vida al compañero de equipo que tiene que venir detrás de él a mantener la solución de la que fue responsable en 1ra instancia.
Como ya habrás podido notar, mi visión es más amplia que la de un líder de equipo, y si bien exige un acto de fé (la parte religiosa de la cuestión) como la aceptación de normas/pautas, al final la religiosidad busca que cada miembro del equipo tenga una actitud y pensamiento que estime por sobre todo la utilidad y el valor práctico de las cosas.
Un saludo y seguimos pensando... siempre!!
--
GS
Gracias Emilio por tu comentario.
BorrarLo mismo a vos Gustavo.