Trabajo para una gran organización humanitaria, en un software de construcción de proyectos que podría ayudar a salvar vidas en emergencias al acelerar la distribución de alimentos. Muchas ONG necesitan desesperadamente nuestro software y llevamos semanas de retraso.
Una cosa que me preocupa en este proyecto es que creo que es un enfoque excesivo en los estándares de codificación. Escribimos en python / django y usamos una versión de PEP0008, con varias modificaciones, por ejemplo, las longitudes de línea pueden llegar a 160 caracteres y todas las líneas deberían ser tan largas si es posible, no hay líneas en blanco entre importaciones, reglas de ajuste de línea que se aplican solo a ciertos tipos de clases, muchas plantillas que debemos usar, incluso si no son la mejor manera de resolver un problema, etc., etc.
Un desarrollador principal pasó una semana reescribiendo una parte importante del sistema para cumplir con los nuevos estándares de codificación, desechando varios conjuntos de pruebas en el proceso, ya que la reescritura significaba que eran "inválidas". Pasamos dos semanas reescribiendo toda la funcionalidad que se perdió y reparando errores. Él es el desarrollador principal y su palabra tiene peso, por lo que ha convencido al gerente del proyecto de que estas normas son necesarias. Los desarrolladores junior hacen lo que se les dice. Tengo la sensación de que el gerente del proyecto tiene un fuerte sentimiento de disonancia cognitiva sobre todo esto, pero no obstante está de acuerdo con vehemencia, ya que no está seguro de qué más hacer.
Hoy me metí en serios problemas porque había olvidado poner algunos espacios después de las comas en un argumento de palabra clave. Literalmente me gritaron otros dos desarrolladores y el gerente del proyecto durante una llamada de Skype. Personalmente, creo que los estándares de codificación son importantes, pero también creo que estamos perdiendo mucho tiempo obsesionándonos con ellos, y cuando verbalicé esto provocó ira. Soy visto como un alborotador en el equipo, un equipo que busca chivos expiatorios por sus fallas. Desde la introducción de los estándares de codificación, la productividad del equipo se ha desplomado considerablemente, sin embargo, esto solo refuerza la obsesión, es decir, el desarrollador principal simplemente culpa a nuestra falta de cumplimiento de los estándares por la falta de progreso. Él cree que no podemos leer el código del otro si no nos adherimos a las convenciones.
Esto está empezando a ponerse pegajoso. Ahora estoy tratando de modificar varios scripts, autopep8, pep8ify y PythonTidy para que coincidan con las convenciones. También ejecutamos pep8 contra el código fuente, pero hay tantas enmiendas implícitas a nuestro estándar que es difícil rastrearlas a todas. El desarrollador principal escoge fallas que el script pep8 no detecta y nos grita en la próxima reunión de pie. Cada semana hay nuevas adiciones a los estándares de codificación que nos obligan a reescribir el código existente, funcional y probado. Gracias a Dios todavía tenemos pruebas (revertí algunas confirmaciones y arreglé un montón de las que eliminó).
Todo el tiempo hay una presión creciente para cumplir con el plazo.
Creo que un problema fundamental es que el desarrollador principal y otro desarrollador central se niegan a confiar en otros desarrolladores para que hagan su trabajo. ¿Pero cómo lidiar con eso? No podemos hacer nuestro trabajo porque estamos demasiado ocupados reescribiendo todo.
Nunca me he encontrado con esta dinámica en un equipo de ingeniería de software. ¿Me equivoco al cuestionar su adhesión a los estándares de codificación? ¿Alguien más ha experimentado una situación similar y cómo la han enfrentado con éxito? (No estoy buscando una discusión, solo soluciones reales que la gente ha encontrado)
Respuestas:
Los estándares de codificación no son el problema. El problema es que la gerencia no puede entender cuál es el problema. Esto lleva a "¡Haz algo ... cualquier cosa!" modo. Estás buscando una solución racional, pero es un problema irracional. Lo mejor que puedes hacer es:
fuente
Alguien debe decidir si el envío o la adhesión servil a los estándares de codificación es la verdadera prioridad. Sé cuál sería mi preferencia; si está pasando la unidad y las pruebas de aceptación, digo enviar. Una vez que se envía, la compañía puede decidir si gasta o no el tiempo y el dinero para arreglar la deuda técnica.
Los problemas con espacios después de las comas se resuelven fácilmente con una herramienta de prettificación de código. Encuentre una herramienta que aplique todas sus convenciones de codificación y ejecútela en todo el código modificado antes de que se realicen las pruebas y la compilación. Los IDE decentes ya hacen esto mientras escribes el código.
fuente
Depende del grupo. Personalmente , creo que todo debe ser cuestionado. Algunas personas toman ese cuestionamiento como una afrenta; Que no confío en ellos.
Pregunté cómo estos estándares mejoran la productividad. Medí el tiempo que pasé jugando con los estándares frente a 'hacer cosas'. Al final, los poderes que se deciden cumplir con los estándares. Sucede. Me quejé de ellos más fuerte de lo habitual cuando fueron la causa de que no hiciera las cosas, pero por lo demás me concentré en hacer mi trabajo. Pelear continuamente por las cosas tampoco es bueno para la productividad ...
Si, como usted dice, las cosas son mucho peores debido a los estándares, entonces adherirse a los estándares debería invalidar el argumento del líder y abandonar el suyo. Si la gente no puede ver esa correlación objetiva (en gran medida) entre la implementación del estándar y la caída de la productividad, entonces no hay mucho más que pueda hacer. Aprende a lidiar con eso y, si no puedes, busca un lugar menos burocrático.
fuente
Las normas son algo que no debe establecerse en el último proyecto con una fecha límite inminente. Es algo que debería haberse implementado al principio del proyecto o cuando hay tiempo reservado en el cronograma del proyecto (preferiblemente después del envío inicial) para un refactor de código ofensivo (potencialmente) grande.
Si esto fue de hecho puesto al final del proyecto, entonces es un error cometido por su líder (en mi humilde opinión).
Sin embargo , esto no significa que si no está de acuerdo con su liderazgo, simplemente debe cargar con motín. Este es tu trabajo . Trabajas en equipo . Usted tiene una ventaja . Definitivamente debería haber algún nivel de democracia en el equipo, pero al final el líder es el dictador. Si él dice que hagas algo, lo haces.
Al final, al cumplir con sus solicitudes y estándares, no se le proporciona un chivo expiatorio fácil para los plazos que faltan.
Además, soy un gran defensor de los estándares de codificación (especialmente a medida que crece el tamaño de un equipo), pero deberían implementarse cuando tenga sentido.
fuente
Su pregunta fue "¿Me equivoco al cuestionar su adhesión a los estándares de codificación?". http://c0x.coding-guidelines.com/Introduction.pdf (para el lenguaje de programación C) tiene algunos estudios referenciados sobre el valor de las pautas de codificación. Consulte la sección 9 a partir de la página 39.
Los estándares de codificación se implementan por una razón. Una cosa que parece faltar en la pregunta original es la comprensión de la razón de estos estándares particulares en el proyecto particular (o en la organización particular). La decisión de implementarlos en el código existente se basó en alguna lógica. Sin conocer la lógica, es difícil comentar la "bondad" de esa decisión.
Respaldaré lo que alguien dijo que los estándares se implementan para la 'productividad a largo plazo', cuestiones como la mantenibilidad del código. Tal vez ocurrió algún evento que retrasó severamente el proyecto debido a la confusión y la mala interpretación.
Parece que hay mucha emoción en ambos lados: trate de llegar a una discusión razonada.
fuente
Como probablemente haya visto en las otras respuestas y comentarios, su proyecto tiene grandes problemas, por lo que lo que voy a sugerir no tiene grandes posibilidades de éxito, pero es algo que puede intentar sin un riesgo demasiado grande con respecto a tu propia piel
Solicite una reunión entre cuatro ojos con su desarrollador principal. Digamos que está interesado en comprender a fondo los beneficios de ser tan estricto con el estándar de codificación y por qué la base de código estaba en tan mal estado antes de introducirlos. Es muy importante que mantenga una actitud muy abierta y de "Estoy tratando de aprender" durante esta discusión. Su desarrollador principal probablemente ya esté más estresado que usted o cualquier otra persona en su equipo, y probablemente estará muy a la defensiva tan pronto como huela algo de critisicm.
Intente empujar la discusión hacia la dirección de tratar de encontrar formas de alcanzar su objetivo común; entregando software de trabajo y mantenible rápidamente.
Por ejemplo, algunas frutas bajas no deben agregar nada más a las pautas de codificación. Cada vez que eso sucede, el código que previamente se adhirió a las pautas ya no lo hace, y esto da como resultado que deba volver a escribir fragmentos de código. Esperemos que su desarrollador principal pueda ver que incluso si la regla agregada agrega valor (desde su punto de vista), podría no ser tan bueno como motivar la reescritura en esta fase del proyecto ya tardío.
Si esto funciona, puede intentar que elimine las reglas más arbitrarias que no pueden autoformarse con alguna herramienta.
fuente
Los estándares de codificación son buenos. Cambiar los estándares de codificación es costoso (bueno, es costoso si los hace menos permisivos; si un cambio en el estándar deja que todo el código existente siga cumpliendo, no es un problema), por lo que solo debe hacerse cuando sea absolutamente necesario.
Una cosa que debe hacer, tal vez, es que el líder verifique todo el código antes de confirmar / fusionar / lo que sea para asegurarse de que cumpla con el estándar, ya que aparentemente la cadena de herramientas existente parece ser incapaz de verificarlo automáticamente.
fuente
Creo en los buenos estándares de codificación, pero también creo que salvar vidas es mucho más importante.
Su mayor prioridad debe ser salvar la vida de las personas . Imagínese si este software está distribuyendo alimentos a su familia o su equipo. Cualquier otra cosa puede venir después.
La buena noticia: tienes pruebas. Las pruebas lo ayudarán a cumplir con sus estándares de codificación sin romper la funcionalidad, pero esto debería suceder después del envío , no antes.
fuente