Cómo convencer a la gerencia de que reformatear todo el código base de Java es seguro

https://stackoverflow.com/questions/2420174

19-09-2019
|

Pregunta

¿Cómo se podría demostrar a la gerencia que un reformateo por lotes de todos los archivos .java en una base de código grande (para colocar el código de acuerdo con los estándares de codificación de la empresa) es seguro y no afectará la funcionalidad?

Las respuestas tendrían que apaciguar tanto a los técnicos como a los no técnicos.

Editar:2010-03-12Aclaración para los técnicos entre ustedes;reformat = cambios solo en espacios en blanco - sin "organizar importaciones" ni "reordenar variables miembro, métodos, etc."

Editar:2010-03-12 Gracias por las numerosas respuestas.Me sorprende que tantos lectores hayan votado a favor de la respuesta de mrjoltcola, ya que es simplemente una declaración sobre ser paranoico y de ninguna manera propone una respuesta a mi pregunta.Además, hay incluso un comentario del mismo colaborador que reitera la pregunta.WizzardOfOdds apoyó este punto de vista (pero es posible que no haya leído todos los comentarios para verlo).-jtsampson

Editar:2010-03-12 Publicaré mi propia respuesta pronto, aunque la respuesta de John Skeet fue acertada con la sugerencia MD5 (nota -g:none para desactivar la depuración).Aunque sólo cubrió los aspectos técnicos.-jtsampson

2010-03-15 Agregué mi propia respuesta a continuación.En respuesta a lo que significa "seguro", quise decir que la funcionalidad del código Java no se vería afectada.Un simple estudio del compilador de Java muestra que este es el caso (con algunas advertencias).Esas advertencias eran "sólo espacios en blanco" y fueron señaladas por varios carteles.Sin embargo, esto no es algo que desee intentar explicarle a BizOps.Mi objetivo era obtener respuestas del tipo "cómo justificar hacer esto" y obtuve varias respuestas excelentes.

Varias personas mencionaron el control de fuentes y la "diversión" que conlleva.Específicamente no mencioné eso porque esa situación ya se entiende bien (dentro de mi contexto).Cuidado con el efecto "gasolinera".Vea mi respuesta a continuación.

Solución

Si es sólo volver a formatear, entonces eso no debería cambiar la salida del compilador. Tome un hash ( MD5 debería ser suficiente) de la construcción antes y después del cambio de formato - si que es la misma para cada archivo, que significa claramente que no puede haber alteraciones del comportamiento. No hay necesidad de ejecutar las pruebas, etc. - si la salida es byte por byte de la misma, es difícil ver cómo las pruebas se comienzan a fallar. (Por supuesto que podría ayudar a ejecutar las pruebas sólo para el espectáculo de la misma, pero no vamos a probar cualquier cosa que los binarios idénticos no lo hará.)

EDIT: Como se ha señalado en los comentarios, los binarios contienen números de línea. Asegúrese de que se compila con -g:none omitir información de depuración. Que entonces debería estar bien con los cambios de numeración de líneas -. Pero si usted está cambiando nombres que es un cambio más grave, y uno que de hecho podría ser un cambio importante

Asumo que puede reformatear y reconstruir sin que nadie el cuidado - que sólo verifica el código formateado de nuevo en control de código fuente debe dar todo caso de preocupación. No me pensar archivos de clase Java tienen nada en ellos que da una fecha de creación, etc. Sin embargo, si su "formato" cambia el orden de los campos, etc., que puede tener un efecto significativo.

Otros consejos

En un entorno empresarial, existen dos desafíos.

Técnico
Político

Desde el punto de vista técnico, los reformateadores son una tecnología madura.Combinado con hash/sumas de verificación, siempre que el lenguaje no sea sensible a los espacios en blanco, es técnicamente seguro hacerlo.También debes asegurarte de hacerlo durante un tiempo de inactividad en el que no haya bifurcaciones importantes esperando a ser fusionadas.Será imposible separar los cambios reales del reformateo, así que hágalos por separado.La fusión puede resultar muy difícil para cualquiera que trabaje en una bifurcación.Por último, solo lo haría después de haber implementado una cobertura completa del caso de prueba.Por la razón 2...

Políticamente, si no sabes cómo convencer a la dirección, ¿cómo sabes que es seguro?Más específicamente, ¿es seguro para usted?Para un desarrollador senior y de confianza, que tiene el control de los procesos en un taller, es un trabajo más fácil, pero para un desarrollador que trabaja en una organización grande, política y burocrática, debe asegurarse de cubrir todas sus necesidades. bases.

El argumento que planteé en 2010 fue quizás demasiado inteligente, pero los analizadores, reformateadores y bonitas impresoras son sólo software;Es posible que tengan errores provocados por su código base, ESPECIALMENTE si es C++.Sin pruebas unitarias en todas partes, con una base de código grande, es posible que no puedas verificar al 100% que el resultado final sea idéntico.

Como desarrollador, estoy paranoico y la idea me incomoda, pero mientras estés usando:

Fuente de control
Cobertura de prueba adecuada

entonces estás bien.

Sin embargo, reflexiona sobre esto:La dirección ahora es consciente de que está trasteando en un proyecto de un millón de líneas con un "cambio masivo".Después de reformatear se informa de un error no descubierto previamente.Ahora eres el principal sospechoso de causar este error.Si es "seguro" tiene múltiples significados.Puede que no sea seguro para usted y su trabajo.

Suena trillado, pero hace un par de años recuerdo que pasó algo así.Recibimos un informe de error un día después de una ventana de mantenimiento nocturno en la que solo había reconfigurado y reiniciado un IIS servidor.Durante varios días, la historia fue que debí haber cometido un error o haber implementado un código nuevo.Nadie lo dijo directamente, pero un vicepresidente me miró y lo dijo.Finalmente lo rastreamos hasta un error que ya estaba en el código, que había sido enviado previamente, pero que no apareció hasta que una persona de control de calidad cambió un caso de prueba recientemente, pero honestamente, algunas personas ni siquiera recuerdan esa parte;simplemente recuerdan haber llegado al día siguiente con un nuevo error.

EDITAR:En respuesta a ediciones de jtsampson.Tu pregunta no era sobre cómo hacerlo;se trataba de "Cómo convencer a la dirección de que es seguro".Tal vez debería haber preguntado en su lugar: "¿Es seguro?Si es así, cómo hacerlo de forma segura." Mi declaración señalaba la ironía de su pregunta, en el sentido de que asumió que era seguro, sin saber cómo.Aprecio el aspecto técnico del reformateo, pero estoy señalando que existe un riesgo en cualquier cosa que no sea trivial y, a menos que le pongas a la persona adecuada, podría estropearse.¿Esta tarea restará valor a las otras tareas de los programadores, desviándolos durante un par de días?¿Entrará en conflicto con las revisiones no confirmadas de algún otro codificador?¿Está la fuente bajo revisión?¿Existe algún script incrustado que sea sensible a los espacios en blanco, como Pitón?Cualquier cosa puede tener un efecto secundario inesperado;Para nuestro entorno, sería difícil conseguir una ventana de tiempo en la que no haya nadie trabajando en una rama, y el reformateo masivo hará que su fusión sea bastante fea.De ahí mi disgusto por el reformateo masivo, manual o automatizado.

Utilice un enfoque pragmático:

Generar la aplicación.
Guarde la aplicación.
Cambiar el formato del código.
Generar la aplicación.
Diff los binarios.

Me gustaría utilizar cuatro palabras.

Fuente de control. Las pruebas unitarias.

Bueno, no es en absoluto seguro y que son poco probable que convencerlos. Hablando como alguien que ha logrado un gran desarrollo que nunca consideraría en cualquier base de código comercial de la que dependía ningún ingreso. No estoy diciendo que no hay ventajas en formato de código de cómo se quiere, pero las posibilidades de que su formato no implicará cambios cierto código es nula. Eso significa que hay un gran riesgo para muy poca ganancia. Si tiene que hacerlo, hacerlo poco a poco a medida que la corrección de errores de código, no lo haga en un gran éxito. Puede ser una buena decisión para usted como programadores, pero sería una decisión terrible para ellos como la gestión.

¿Qué gestión estamos hablando aquí? Son conocedores de la tecnología suficiente para entender lo que el formato de código es y cómo Java trata a los espacios en blanco? Porque si no es así, no creo que están calificados para tomar tal decisión técnica (es decir, estas cuestiones deben ser delegadas a alguien que es responsable del código).

Pero si son o que están tratando de convencer a su "arquitecto" o alguien parecido, bueno, entonces se trata de confiar en una herramienta de terceros. Sugerir un formateador que tiene una buena reputación, aparte de eso, no hay mucho que puede hacer, ya que no lo ha codificado el formateador.

Como vía lateral, permítanme compartir una anécdota. Nuestro arquitecto decidió en un momento en volver a formatear todos los archivos. Fuera de miles de archivos de Java, no se ha encontrado ni un solo error (y esto fue hace más de medio año). Esto me hace confiar en formateador de Eclipse para el código fuente de Java. Los beneficios de este formato fueron:

Algunas clases mal formateados son ahora más fáciles de leer.
mismo formato en todas partes.

Pero también tenía algunos aspectos negativos:

Un formateador de código no es perfecto. A veces código de formato manualmente lee mejor. El formateador en particular, las luchas con muy mal código (líneas demasiado tiempo, demasiados ifs anidados, etc.).
¿Tiene otras ramas de código, como una versión antigua, que en ocasiones necesita ser parcheado? Debido a que usted puede olvidarse de la fusión entre las ramas con diferentes estilos de código (por lo menos cuando se utiliza SVN).
Usted está tocando todos los archivos (y, a veces casi todas las líneas) y arruinar la historia de todos los archivos a la vez. Me duele la trazabilidad.
En realidad, hay un pequeño beneficio en el que cada desarrollador tiene su propio formato de código, ya que comienza a aprender que el formateo, y se puede identificar inmediatamente el autor de una pieza de código

Yo personalmente creo que el negativo es mayor que el positivo. Suena como una gran idea, pero en realidad no ganar tanto como usted piensa. Cuando se encuentre con algún código terriblemente formato, cambiar el formato sólo que la clase o simplemente ese método y lo ven como un pequeño paso hacia el gran objetivo.

deje pasar las pruebas unitarias tras este proceso? Si es así, entonces usted ha vendido la idea de gestión!

Si está al rededor del código no probado, entonces usted tendrá un caso mucho más difícil de hacer.

Se desea que el "código en el cumplimiento de las normas de codificación de la compañía" [sic] y quiere convencer a la dirección?

Trivial: instalar CheckStyle , que sea parte de su proceso, darle de comer a sus pautas de codificación, y mostrarles que todo el código base miserablemente Error en CheckStyle .

Este es un buen ejemplo de la falta de adecuación técnico-comercial.

Los técnicos quieren hacerlo, ya que puede hacer que el código sea difícil de leer, pero, a menos que sea excepcionalmente mal, la verdadera razón es que ofende la sensibilidad típicamente delicados y la estética del programador medio .

Los empresarios quieren gestionar el riesgo. El riesgo puede llevarse a cabo si hay algún beneficio y no hay negocio se benefician aquí a menos que argumentar que va a ser más barato, más rápido y / o menos riesgoso para hacer el desarrollo futuro con código fuente reformateado, que con toda la honestidad es difícil de vender.

Casi por definición, cualquier cambio se ha unido riesgo. El riesgo aquí es remota, pero no es inexistente o bien (desde la perspectiva de gestión) con casi ninguna alza.

Hay otra cuestión a considerar demasiado: este tipo de cambio puede causar estragos en control de código fuente. Se hace más difícil realizar un seguimiento de lo que ha cambiado debido a que el cambio más reciente a cualquier línea será el cambio de formato por lo que tendrá que ir comparando las revisiones, lo cual es un poco más tedioso que un simple "culpa" o "anotaciones" de comandos.

Además, si usted tiene varias ramas activas un cambio de formato de su código causará estragos con sus fusiones.

Es seguro en el sentido de que los cambios de formato puros hará ninguna diferencia para lo que está compilado, y por lo tanto no hay diferencia en el comportamiento del código en tiempo de ejecución.

Vale la pena recordar que el cambio de formato grueso de código puede conducir a la "diversión" cuando se trata de control de origen más adelante - si varios colegas han código desprotegido, y un miembro del equipo llega y vuelve a formatear, entonces todas esas copias están fuera de la fecha. Peor aún, cuando actualicen sus copias de trabajo, toda clase de conflictos van a aparecer, porque esos cambios de formato afectarán enormes porciones de código, y la solución de que puede ser una pesadilla.

Al volver a formatear el código es el mismo que volver a formatear un documento en Word; se cambia el diseño y por lo tanto la legibilidad, pero no el contenido.

Si todos los archivos tienen el formato de la misma el código se vuelve más legible , que hace que el mantenimiento un poco más fácil y por lo tanto más barato. También las revisiones de código puede ser más rápido y más eficaz.

Además, dado un buen estilo de formato, los errores se pueden encontrar con mayor facilidad, ya que no se puede ocultar; pensar en si las declaraciones sin llaves y 2 declaraciones dentro de esos apoyos imaginarios.

No ser inteligente y comprobar el código y etiquetarlo antes de formatear, por lo que tiene un estado de volver a (y decirle a la gente lo fácil que sería), cambiar el formato y el registro y la etiqueta de nuevo, sin ningún otro cambio.

Responde a las siguientes preguntas para la gestión, y se le han recorrido un largo camino de convencerlos que es un cambio seguro?

¿Por qué los buenos asuntos de formato?
¿Qué cambios se harán? (Si no puede responder a esto, no se sabe lo suficiente sobre el formateo de saber que será seguro)
¿Nuestros conjuntos de pruebas unidad de probar los cambios tuvieron ningún efecto negativo? (Pista la respuesta tiene que ser sí)
¿El código existente ser etiquetados en el repositorio de código fuente por lo que tenemos un rollo rápido de vuelta opción? (Insinuar la respuesta es sí mejor)

eso lo cubre.

En realidad, probablemente estaría de su lado. Cambiar el formato de las unidades a medida que los abre para correcciones o mejoras cuando ellos serán examinados a fondo antes de volver a la producción. Deberían haber sido formateado correctamente la primera vez, pero si están en producción parece innecesaria e imprudente volver a formatear ellos sólo para el bien de estilo.

La consistencia es buena, pero "una consistencia estúpida es el duende de las mentes pequeñas".

Estoy ponerse el sombrero gerente ...

Para hacerlo como un gran proyecto, no dejaría que lo haces, no importa el argumento. Quisiera, sin embargo, estar abiertos a las estimaciones más largas a cambios debido a que está modificando los archivos existentes para incluir estos cambios de formato. Yo exigiría a tomar el formato cambia su propio registro de entrada embargo.

Gracias por todas sus respuestas.

Mi último argumento para convencer a la administración; Los bits de todas sus respuestas incluyeron. Gracias por la ayuda.

Técnica:

Reformat consiste en cambios espacio blanco (sin reordenamiento de importación, ningún miembro / método)
reformateo utilizará [especificar la herramienta y proceso]
reformateo se producirá en [especificar el tiempo dentro del ciclo de codificación para minimizar el impacto de combinación]

Antes y después de un cambio de formato:

Todas las pruebas unitarias pasarán
Todas las pruebas de integración pasarán
Todas las pruebas funcionales pasarán
Todas las pruebas de SOAP-UI pasarán
El código de bytes es el mismo (un MD5 de los archivos .class siguientes javac (-G: ninguno))

Negocio:

Objetivo:. Para cumplir con las normas de la empresa, que prescribe que nuestros archivos de origen representan con exactitud la estructura lógica de nuestro código

Cambio de reformateo contra el cambio de código (Palabra ejemplo, el documento que el anterior)
Reformat utilizará [proceso general]
reformateo se producirá en [especificar el tiempo dentro del ciclo económico para minimizar el impacto]

Prueba Piloto:

Confirmado "Formato de lote" resultó en una menor conflictos de fusión y luego "Formato como Código". .
confirmó que el código ejecutable (4k + archivos .class) sigue siendo el mismo. (Prueba de MD5)
funcionalidad confirmada no se verá afectada (pruebas automáticas / pruebas de humo)
ajustes formateador confirmados incluya únicamente los cambios de espacio en blanco.

Nota: En mi caso una prueba piloto se llevó a cabo durante 6 meses por un subconjunto de los desarrolladores utilizando una herramienta automatizada para "Formato a medida que el código" (según lo prescrito por algunas de las respuestas más arriba) . Mientras que algunos perciben que el cambio de formato causó más conflictos de combinación, en realidad esto no fue el caso.

Esta percepción fue la base de la coincidencia temporal del cambio de formato. Por ejemplo, considere la persona que no sabe nada sobre los coches. Un día, sus frenos fallan. ¿A qué atribuyen la causa? El gas, por supuesto. Fue lo último que subieron en el vehículo (el efecto "gasolinera"?). sin embargo Claramente, los frenos y un sistema de combustible son el sistema dispares como son el formato y los cambios de código. Encontramos que impropias check-ins en el contexto de nuestro proceso de construcción tenían la culpa.

Lo último que esperaba que alguien habría proporcionado un buen enlace a un estudio que muestra las ganancias de productividad relacionados con código común, ya que es difícil demostrar el ROI para el negocio. Aunque en mi caso, ya que era un estándar de la compañía que tenía el "cumplimiento" de mi lado. Yo sólo tenía que demostrar que era más tiempo para "Formato de Código como" frente a "Formato de lote"

Si está utilizando Eclipse como su plataforma de desarrollo, puede cargar todo el código en el espacio de trabajo a nivel local. Demostrar a la gerencia no hay problemas mostrándoles la pestaña problemas.

A continuación, haga clic derecho y formato a cada uno de los proyectos uno por uno -. Demostrando una vez más que no se introducen problemas

Puede hacer esto en su estación de trabajo local sin ningún daño en absoluto a su repositorio.

Sinceramente si su gestión es por lo menos técnico que temer el formato de código fuente, lo que demuestra que no hay problemas aparecen en la ficha problemas después de un formato debe ser suficiente para mostrar que el código es aún válido.

Por no hablar de que va a suponer tener la versión antigua etiquetado en control de origen no?

Una escuela de pensamiento podría ser que hacerlo sin preguntar y luego ser capaz de ir "Ver!"

Por supuesto, si destruyes todo para arriba entonces te despiden. Usted hace que sus opciones ...

Como alternativa, control de código fuente (o copias de seguridad simples) entonces siempre se puede rodar de nuevo.

Si su código tiene suficientemente cerca de cobertura de código 100%, entonces creo que el riesgo se puede reducir un poco.

Sin embargo, incluso si la gestión de acuerdo en que la base de código es seguro, creo que tendrían sus ojos en tener que justificar el pago de un empleado que pasar horas formatear código sólo para adherirse a un estándar que (creo) se introdujo a largo en el ciclo de desarrollo.

Usamos Jalopy aquí en mi trabajo actual.Es un producto bastante sólido y produce resultados realmente buenos.El desarrollador más experimentado aquí reformuló todo el código base cuando lo migró de CVS a SVN, y tuvo que realizar algunas pruebas para asegurarse de que funcionaría de principio a fin, y ahora tenemos ganchos para garantizar que eso esté verificado. en el código está formateado correctamente.

Dicho esto, no creo que puedas convencer a nadie de que cualquier herramienta sea infalible (o infalible), porque no existe tal herramienta.Si cree que el beneficio vale el tiempo y el riesgo (muy pequeño), intente convencer a su gerencia de la mayor ventaja que ve al hacer esto.Para mí, la mayor ventaja vendrá si:

Todos los desarrolladores tienen la misma configuración de formato;
El formato del código fuente se verifica en el check-in mediante un gancho en su SCM.

Porque si hace lo anterior, si su código ya está formateado, cuando compare las revisiones en su SCM verá cambios reales en la lógica del programa, y no solo cambios de formato.

Si usted tiene una buena cobertura de la unidad de prueba, los resultados de pruebas antes y después será suficiente.

A sólo un cabezas específicos arriba: si su política de la compañía incluye el miembro alfabético de clasificación, tenga en cuenta que el orden de los campos estáticos sí importa. Así que si usted incluye una regla en guardar o la limpieza que hace esto, es posible romper el código.

Técnicamente, durante la primera fase de la compilación, lexer tiras de todos los comentarios y el espacio en blanco de la fuente. Esto es mucho antes de que la semántica del código está siendo reconocido por el compilador. Por lo tanto, cualquier espacio en blanco o comentarios no pueden cambiar nada en la lógica del programa. Por el contrario, el uso de lo que podría ser el lenguaje y que le gustaría utilizarlo si la adición de un par de espacios o saltos de línea lo cambiaría la semántica?

En el lado del negocio, usted está probablemente va a utilizar algunas herramientas especializadas para eso. Estoy seguro de que anuncian en sus sitios web que funcionan muy bien.

Nota final: si tiene que convencer a su gestión de los que, tal vez usted debe buscar para encontrar una manera de trabajar con la gente más inteligente

Me gustaría pedir a la administración cuál es su base actual para creer que el código funciona - a continuación, demuestran que la misma herramienta (pruebas, documentación, pequeñas voces ...) funciona exactamente así para el código de reformateado. Me gustaría que su respuesta sea "pruebas" ...

Sé que las respuestas anteriores son todos muy bien, pero aquí es otra posible uno: Hacer un CRC en la versión compilada antes y después de un cambio de formato. Dado que la compilación no tendría en cuenta los espacios, tabulaciones, saltos de línea, etc., entonces la versión compilada debe ser idéntica a la original, y que demostraría a los gerentes semi-técnicos que todo está bien.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow