¿Cómo le digo (con tacto) a mi gerente de proyecto o desarrollador principal que la base de código del proyecto necesita un trabajo serio?

Me acabo de unir a un equipo de desarrollo (relativamente) pequeño que ha estado trabajando en un proyecto durante varios meses, si no un año. Como con la mayoría de los desarrolladores que se unen a un proyecto, pasé mis primeros días revisando la base de código del proyecto.

El proyecto (una aplicación de línea de negocio interna ASP.NET WebForms de tamaño mediano a grande) es, por falta de un término más descriptivo, un desastre. Hay tres problemas inmediatamente notables con los estándares de codificación:

1. El estándar es muy flojo. Describe más de lo que no debe hacer (no use la notación húngara, etc.) que lo que debe hacer.
2. El estándar no siempre se sigue. Hay inconsistencias con el formato del código en todas partes .
3. El estándar no sigue las pautas de estilo de Microsoft. En mi opinión, no tiene ningún valor desviarse de las pautas establecidas por el desarrollador del marco y el mayor contribuyente a la especificación del lenguaje.

En cuanto al punto 3, tal vez me molesta más porque me he tomado el tiempo para obtener mi MCPD con un enfoque en aplicaciones web (específicamente, ASP.NET). También soy el único profesional certificado de Microsoft en el equipo. Debido a lo que aprendí en toda mi educación escolar, autodidacta y aprendizaje en el trabajo (incluida mi preparación para los exámenes de certificación), también vi varias instancias en el código del proyecto donde las cosas simplemente no se hacen en el mejor manera.

Solo he estado en este equipo durante una semana, pero veo tantos problemas con su base de código que imagino que pasaré más tiempo luchando con lo que ya está escrito para hacer las cosas "a su manera" de lo que lo haría si estuviera trabajando en un proyecto que, por ejemplo, siguió estándares de codificación, patrones de arquitectura y mejores prácticas más ampliamente aceptados. Esto me lleva a mi pregunta:

¿Debo (y si es así, cómo) proponerle a mi jefe de proyecto y líder de equipo que el proyecto necesita una renovación importante?

No quiero entrar a su oficina, agitando mis certificados MCTS y MCPD, diciendo que la base de código de su proyecto es una mierda. Pero tampoco quiero tener que permanecer en silencio y escribir código kludgey encima de su código kludgey, porque realmente quiero escribir software de calidad y quiero que el producto final sea estable y fácil de mantener.

Podrías pasar tu tiempo discutiendo tu caso; o podrías pasar tu tiempo limpiando a medida que avanzas.

Elija Principios, patrones y prácticas de desarrollo de software ágil y código limpio y aplique lo que aprende allí mientras trabaja en el sistema. Eventualmente, la gente lo notará (para bien o para mal).

Editar También vea Trabajar efectivamente con código heredado

Por lo que describe, parece que los problemas se deben principalmente a no seguir los estándares de codificación y los problemas de nomenclatura. Eso no es un desastre , de lejos. A modo de comparación, esto es un desastre, de verdad.

¿Quizás estás acostumbrado y requiere altos estándares? En ese caso, cualquier desviación de la perfección podría considerarse un fracaso. Esa es una trampa en la que es fácil caer cuando sus demandas son altas, pero es importante mantener la perspectiva de las cosas.

Le sugiero que hable de esto como una mejora, y que ayude al equipo a actualizar su directriz y a entrenarlos para que empiecen a usarla de verdad. Realmente me gusta usar una Definición de Hecho como un punto de referencia de calidad y crear uno es un gran ejercicio de equipo en sí mismo. Pero no creo que debas hacer mucho más que eso, al menos no como un nuevo miembro del equipo.

Definitivamente no vayas agitando tu MCSD, la gente simplemente se reirá de ti con toda franqueza, ¡los certificados de MS son agradables de tener, pero de ninguna manera son una calificación profesional!

Únase ligeramente a un nuevo equipo, busque oportunidades para sugerir cambios a medida que avanza.

Espere hasta obtener la disposición de la tierra antes de obtener un código de equipo.

Podrías considerar que el problema eres tú. NINGUNA de las tres cosas que mencionó son dignas de una revisión completa de una aplicación. Son solo detalles quisquillosos.

Recuerde que el objetivo de la aplicación no es tener un código hermoso, es resolver un problema comercial. Claro que es bueno tener un código que sea consistente y siga un buen estándar, pero la falta de este no es motivo para tirar basura a toda la base de código. El hecho de que el motor esté aceitoso no significa que deba ser reconstruido.

Mira, todos odian cada base de código que no escribieron. De hecho, si espera tres años y mira su propio código, también lo odiará y pensará que necesita una reescritura completa. La verdad es que no. A menos que pueda argumentar que pasar meses haciendo que el código sea estéticamente agradable para usted en lugar de crear características para agregar valor comercial, probablemente esté ladrando en el árbol equivocado.

Nada dice que tenga que escribir código kludgy solo porque puede haber algo en la base de código. Y nada dice que el código ES incorrecto solo porque no se adhiere al estilo de su mascota. Simplemente refactorice a medida que avanza en las piezas en las que trabaja y escriba un buen código cuando trabaje en cosas nuevas.

Está bien preocuparse por estas cosas, pero si es nuevo en el equipo, no balancee el barco todavía, hasta que haya acumulado cierta credibilidad con ellos.

Parece que has elegido tres cosas (relativamente) menores para preocuparte. Hay otras cosas por las que me preocuparía más:

• ¿El código está bien documentado?
• ¿Se adhiere el código a las especificaciones / documentos de diseño?
• ¿Funciona el código?
• ¿Es fácil entender lo que hace el código?
• ¿Está considerando enviar grandes fragmentos de esta base de código a TheDailyWTF?

¿Has estado allí por una semana? No estoy seguro de que sepa lo suficiente como para hacerle propuestas al gerente del proyecto. Incluso si sospecha que el código y las prácticas de este equipo son "malos", la mejor manera de influir en estas cosas con el tiempo es ganar gradualmente su confianza y respeto. Entrar en un proyecto y después de una semana decirle al equipo que su código necesita ser reescrito no es una buena manera de ganar confianza y respeto.

Durante los primeros meses, concéntrese en dar un mejor ejemplo y hacer preguntas sobre por qué han hecho las cosas de cierta manera. Tenga cuidado con su tono cuando haga estas preguntas. Si te encuentras como el nuevo "sabelotodo", nadie escuchará tus opiniones más adelante cuando realmente estés en condiciones de influir en la forma en que se hacen las cosas.

Con el tiempo, si su código realmente es "mejor", los otros desarrolladores lo verán. Comenzarán a llegar a usted como un recurso para ayudarlos a solucionar los suyos, y luego pedirán su consejo sobre cómo deberían estar haciendo las cosas. En ese momento, estará en una excelente posición para decirle al equipo (y a la gerencia) sus opiniones sobre los estándares de codificación y similares. La duración de este proceso variará según la organización. Podrían ser solo unas pocas semanas en un entorno muy adaptable, o meses o años en una cultura más estoica. Desarrolla tu influencia una persona a la vez.

Nunca entrará en un nuevo trabajo donde pensará que la base del código es perfecta y que todo se ha hecho de la manera "correcta". Aprende a aceptar esto. Todo lo que puede hacer con el código heredado es refactorizar y avanzar poco a poco. Algunas cosas que no desea refactorizar hasta que comprenda mejor por qué hicieron lo que hicieron. Además, nadie en el negocio le va a pagar para que arregle el código de trabajo, por lo que tendría que presentar un argumento comercial sobre por qué necesita trabajar antes de intensificar y pasar el tiempo. Es mejor esperar a refactorizar el código cuando hay un cambio que debe realizar de todos modos. Es posible que no haya elegido el método que hicieron para algunas cosas, pero si funciona, tenga mucho cuidado al cambiarlo e introducir nuevos errores. Particularmente cuando no le han pedido que lo cambie.

Después de una semana, no tiene credibilidad para hacer sugerencias importantes sobre cómo hacen negocios. Si mencionas las cosas ahora, la gente se reirá de ti y nunca te tomará en serio. Primero pruébate un buen código y luego las personas estarán más inclinadas a escuchar.

Y, francamente, a nadie le importa que seas un profesional certificado de Microsoft. Cualquier persona con mucha experiencia ha visto tantos programadores malos que tenían esa certificación como buenas personas. No digo que te haga quedar mal tener una certificación, digo que no les damos mucha credibilidad porque no hemos visto dónde son efectivos nos está mostrando quién es un buen programador.

Probablemente iré por el camino de tratar de descubrir cómo presentar la propuesta con la intención de que pueda terminar no siendo capaz de justificar su posición adecuadamente. Algunas preguntas para reflexionar al crear esa propuesta:

• ¿Cuánto valor comercial se obtiene al hacer los tipos de cambios que describe aquí?
• ¿Ha considerado opciones como volver a escribir la aplicación desde cero, modificar el código existente para ponerlo a prueba o simplemente hacer pequeños cambios con el tiempo?
• ¿Sabes qué características y errores se desean ahora que te impidan hacer los cambios que deseas?

Si bien puedo apreciar querer arreglar la base de código deficiente, esto tiene que sopesarse para que tenga sentido desde el punto de vista comercial hacerlo.

Actualmente no está en condiciones de evitar el código incorrecto, por lo que tendrá que descubrir cómo contenerlo.

Los PM y los líderes de equipo solo se preocuparán de que no funcione. Su próxima preocupación será cuando le pidan que haga cambios y se pregunten por qué las cosas "simples" tardan tanto. Ahí es donde entrarás.

Comience ahora con el problema de coherencia. Cualquiera que sea el método potencialmente estándar actualmente, intente identificarlo y ver si no puede hacerlo cumplir. Si comienza con la metodología con la que nadie más está familiarizado, obtendrá un montón de retroceso.

Otros miembros del equipo pueden querer obtener la certificación y usted será un gran recurso. Esperemos que al menos quieran mejorar y mirar hacia ti para mostrarles el camino.

Quejarse de la notación húngara no le dará simpatía y es probablemente una de las últimas batallas en la lista de prioridades.

Estoy de acuerdo en que debes tener cuidado con esto. Debe construir reputación dentro del equipo antes de poder expresar críticas y proponer cambios profundos en el código o los procesos. Solo tomaría notas sobre mis hallazgos y sugerencias por el momento, y aprovecharía la oportunidad de familiarizarme con los miembros del equipo y la administración, entrar en discusiones gratuitas pero no negarme si la charla gira en torno a problemas de calidad, preguntas de codificación, etc., a veces incluso arrojando Algunas de mis propias preguntas en el estanque (pero en forma general, no demasiado señalado hacia cualquier problema concreto que he visto dentro de esta base de código). De esta manera puedo conocer la opinión de los miembros del equipo y encontrar posibles aliados.

En el mejor de los casos, es posible que una parte importante del equipo (y / o la gerencia) vea los mismos problemas que usted, solo que no ha habido ninguna iniciativa para hacer algo al respecto, o la gerencia no le ha otorgado recursos. Juntos tienen más voz para convencer a la gerencia si es necesario.

Como sugirió @Mike, seguramente es necesario hacer parte de la limpieza usted mismo, pero de nuevo, es mejor tener paciencia. Si comienza demasiado rápido, puede alienar a otros miembros del equipo que pueden tomarlo como una crítica personal. Además, su gerente puede tomar en cuenta la extensa limpieza / refactorización del código como una señal de que no está lo suficientemente enfocado en la tarea real. Por lo tanto, debe obtener algún mandato para refactorizar antes de embarcarse en un nivel más serio. Sin embargo, los pequeños cambios locales probablemente estén bien.

Además, para convencer a la gerencia, necesita una justificación comercial. La administración rara vez se mueve con descripciones de cuán inconsistente es el estilo de codificación. Debe mostrarles qué valor pueden aportar los cambios propuestos a la empresa: el resultado final es el efectivo. Si puede hacer un cálculo convincente sobre el costo versus los beneficios a largo plazo de varios cambios propuestos, y demuestra que el balance general está claramente en el lado positivo, ha mejorado notablemente sus posibilidades.

Hazlo tu mismo. Si valora ciertos estilos de codificación, trabaje en un código que viole los estilos de codificación . Extraiga un código ofensivo del control de código fuente, vuelva a formatear el código al requisito de espacios en blanco del estilo (como ejemplo) y confirme el código actualizado con el mensaje "Conforme a la regla de la guía de estilo en espacios en blanco".

Después de una semana, lo peor que probablemente pueda hacer es ir directamente a la administración con esto. Con toda probabilidad, han dedicado mucho tiempo al código y tienen cierto grado de orgullo. Probablemente saldrías como un severo "sabelotodo".

Lo que haría si fuera usted es mejorarlo a medida que avanza. A medida que se familiarice con él y trabaje en más, tendrá la oportunidad de mejorarlo. En ese momento, comenzaría a mostrar los beneficios de lo que está haciendo a otros compañeros de trabajo. Después de eso, cuando surjan reuniones de diseño para nuevos módulos, presente un argumento para lo que percibe como la mejor manera.

Y honestamente, los estándares existen por una razón pero, si funciona y funciona bien, vale 100 veces más en mi libro (especialmente después de una semana). Me preocuparía más si abrieras el código y vieras toneladas de errores lógicos o algo por el estilo.

No vaya directamente a la gerencia con este 'problema'.

Primero, hable con sus compañeros de trabajo y descubra de ellos por qué las cosas son como son. Luego puede evaluar mejor si hay un problema o no. Te sorprenderá lo que aprendas. También puedes encontrar aliados para querer limpiarlo.

Si no tienes idea de cómo llegaste a donde estás en primer lugar, es mucho más difícil salir.

Muchas buenas sugerencias aquí ya, y yo soy de la opinión de no quemar tus puentes hasta que te hayas probado a ti mismo como las otras. Lo que agregaría es discutir las cosas con tus compañeros de equipo mucho antes de alienarlos yendo primero al gerente del proyecto o al líder del equipo. Y ciertamente muéstrales antes de eso, que debes ser tomado en serio.

También parece que es más un problema estilístico que tienes con el código. Asumir el código de otra persona y ocultarse mientras se acostumbra a la forma en que lo escribió es solo parte del trabajo, incluso si es algo trivial como la forma en que lo formatearon. Entregar uno de tus 'bebés' a otra persona para que lo destrocen con sus manos sucias es aún peor ...

Si finalmente es más que eso, y el problema es más funcional que simplemente estilístico, si va a liderar el equipo / pm, es mejor plantear la necesidad de volver a trabajar en términos de dónde ahorraría dinero y esfuerzo en el futuro projecto de desarrollo. Buena refactorización.