Qué hacer cuando sus colegas no valoran la capacidad de mantenimiento del código [duplicado]

12

Hace algunos años que trabajo en el mismo departamento de desarrollo de software. En ese tiempo, la estancia media de un desarrollador ha sido de 6-9 meses. Un puñado ha existido durante más de 2 años, pero la mayoría de nuestros 20 desarrolladores vienen y van a una tasa relativamente alta.

Como resultado, la mayoría de nuestros proyectos se han convertido en pesadillas de mantenimiento. Los contratistas entrarán, codificarán algunos parches de liberación y se irán.

Nuestro departamento tiene pautas de desarrollo (nosotros hacemos TDD) pero no se aplican.

Recientemente, he estado presionando para que nuestro departamento produzca un código más mantenible. He estado pidiendo revisiones de código obligatorias y TDD obligatorias. La gerencia está totalmente de acuerdo conmigo ... en teoría.

En la práctica, TDD siempre sale por la ventana. La justificación es siempre que, en nuestro dominio, debemos entregar AHORA.

Les sigo diciendo a los colegas que estamos cavando un hoyo para nosotros mismos, y que nuestro enfoque actual del desarrollo de software le está costando mucho dinero a nuestro departamento ... pero parece caer en oídos sordos.

¿Qué puedo hacer para que mis colegas vean el valor de la capacidad de mantenimiento del código? ¿Cómo puedo explicar que las ganancias a corto plazo sin una visión a largo plazo no son sostenibles?

    
pregunta MetaFight 12.04.2013 - 19:13

3 respuestas

16

No es a tus colegas a quienes debes convencer.

Si la administración realmente estuviera de acuerdo con usted, estarían aplicando las revisiones de código y TDD. Tal como están, solo asienten con la cabeza para hacer que dejes de molestarlos.

Veo dos opciones aquí:

  1. Haga un discurso a la administración superior sobre cómo la alta rotación de empleados y la gran cantidad de informes de errores que enfrentan los clientes les están costando dinero. Incluya en su lanzamiento una solución viable que incluya revisiones de códigos forzados, TDD, etc. Envuelva un marco de tiempo alrededor de él y prometa entregarlo. Podrían hacerte un administrador encargado de arreglarlo.

  2. Deja. Si sabes que va a colapsar, ¿por qué quedarte?

respondido por el Dan Pichelman 12.04.2013 - 19:40
4

Veo que esto sucede mucho cuando un desarrollador trabaja en un proyecto exclusivamente durante un largo período de tiempo. Saben dónde están las trampas y cómo trabajar alrededor de ellas, por lo que generalmente no les importa que existan. La forma número uno de convencer a los desarrolladores para que empleen estándares de codificación comunes y las mejores prácticas es hacer que trabajen en el código de otros desarrolladores de vez en cuando. Verán rápidamente el valor del código de autodocumentación, el manejo adecuado de las excepciones, la limpieza del código muerto, etc. Haga esto una o dos veces y sus desarrolladores se complacerán en adoptar estas prácticas.

Con los gerentes, usualmente es una historia diferente. Los buenos gerentes responderán a las quejas de los desarrolladores y buscarán de manera proactiva formas de mejorar las prácticas de codificación de su empresa. A los malos administradores no les importará, siempre que el producto salga a tiempo. Para este tipo de gerentes, tendrá mostrar a ellos lo que está mal con la forma en que está haciendo las cosas. Explique que demora entre dos y tres veces el tiempo necesario para capacitar a un nuevo desarrollador, o que lleva días encontrar errores que podrían solucionarse en cuestión de minutos, todo porque la base del código es un desastre. Si es posible, muestre casos reales y concretos de los costos asociados con el código mal mantenido.

    
respondido por el p.s.w.g 12.04.2013 - 23:18
-1

Atornille explicando las cosas a las personas .

Es posible que sea más fácil incorporar a la administración / a otros desarrolladores con algún tipo de integración continua. Entonces, si las pruebas no pasan, el código no se envía. Fin de la historia.

    
respondido por el CamelBlues 12.04.2013 - 23:30

Lea otras preguntas en las etiquetas