¿Cómo puedo promover una codificación limpia en mi lugar de trabajo?

Trabajo con muchos códigos heredados de Java y RPG en una aplicación interna de la compañía. Como es de esperar, gran parte del código está escrito en muchos estilos diferentes y, a menudo, es difícil de leer debido a las variables mal nombradas, el formato inconsistente y los comentarios contradictorios (si es que existen).

Además, una buena cantidad de código no es robusta. Muchas veces los programadores más experimentados empujan el código a la producción rápidamente, mientras que el código de los nuevos programadores se ve frenado por "revisiones de código" que la OMI no son satisfactorias. (Por lo general, toman la forma de "Funciona, debe estar bien", en lugar de una crítica seria del código). Tenemos una buena cantidad de problemas de producción, que creo que podrían atenuarse al pensar más en el diseño original y pruebas.

He estado trabajando para esta empresa durante aproximadamente 4 meses y me han felicitado por mi estilo de codificación un par de veces. Mi gerente también es fanático de la codificación más limpia de lo normal. ¿Es mi lugar tratar de impulsar un mejor estilo y una mejor codificación defensiva, o debería simplemente codificar de la mejor manera posible y esperar que mi ejemplo ayude a otros a ver cómo un código más limpio y robusto (así como una refactorización agresiva) resultará en menos depuración y tiempo de cambio?

No mencionaste tu nivel de experiencia en el tema. Sin embargo, si no eres un programador sénior, creo que lo mejor que puedes hacer es hacer bien tu propio trabajo. También mencionó que a su gerente le gusta el trabajo limpio, eso es genial. Si puede hablar con él al respecto (tal vez en un entorno semiprofesional), debe compartir sus preocupaciones sobre el problema con él. HE está en condiciones de cambiar el flujo de trabajo.

¿Qué significa el código limpio para ti?

Estoy seguro de que su definición es excelente, pero los otros tipos en su lugar de trabajo probablemente tengan su propia definición. No están equivocados, solo son diferentes a los suyos.

Debe crear pautas de codificación en las que todos en su lugar de trabajo puedan estar de acuerdo, y debe hacerlo junto con sus compañeros programadores. No intentes forzar esto a las personas, si lo haces, será contraproducente.

¡Así que reúna al equipo y comience a trabajar en una definición común de "código limpio"! No hay reglas estrictas para esto. Estás intentando unir varias mentes y eso puede generar conflictos, por lo que es posible que desees preparar el escenario con una nota positiva de que todos deben ser respetuosos y tener una mente abierta (la escritura de códigos es personal ...).

El libro Clean Code puede ser útil. ¿Podrías usar ejemplos de ese libro para hablar y ver si encuentras algo en común allí?

Hay dos cosas que pueden hacer maravillas para garantizar una calidad de código consistente y alta.

Hacer revisiones de código

Debe esforzarse por cada registro, sin importar cuán trivial, sea revisado por otra persona en el equipo. Sin excepciones. Parece que esto se interpondrá al principio, especialmente para los desarrolladores senior que piensan que no tienen nada que ganar al hacer que personas menos experimentadas revisen su código. Sin embargo, tener revisiones periódicas del código tendrá un impacto inconmensurable para cada desarrollador del equipo.

Definir un estándar y mantenerlo

En Google tenemos una guía de estilo de codificación para cada lenguaje que usamos: C ++ , Java , Python , etc. Si bien los ingenieros pueden estar en desacuerdo con la guía de estilo, no es opcional. (Y se aplica rigurosamente en las revisiones de código). Como resultado, toda la base de código - cientos de miles de líneas de código - es muy consistente.

Creo que si te apasiona el código limpio, esto se contagiará a tus colegas. La mentalidad "Funciona, debe estar bien" puede ser cambiada por personas que abogan por un buen diseño y un código limpio de una manera entusiasta.

Aunque se han publicado varias respuestas útiles aquí por un tiempo, creo que hay espacio para una más. Mi sugerencia es, como han dicho otros, hacer revisiones de código. Pero vale la pena mencionar nuevamente porque el término "revisión de código" es muy vago ... casi tan vago como "código limpio" :-). Me he dedicado mucho tiempo y esfuerzo a trabajar para lograr ese objetivo difícil de alcanzar. Y particularmente en los últimos dos años, impulsado por colegas que compartieron mi pasión, destilé mis nociones, combinadas con ideas clave de desarrolladores prominentes, en una serie titulada Zen of Code Reviews .

Mis artículos son únicos, hasta donde yo sé, ya que cubro ambos lados del pasillo: haciendo una revisión de código como autor y haciendo una revisión de código como revisor . Aunque relacionadas, las habilidades para cada uno son algo diferentes. Y ser capaz de hacer ambas cosas bien va a llevar a una mejor calidad del código. Revisar el código es tan importante como escribir código. De Verdad. Promueve la transferencia de conocimiento, fomenta la consistencia y la comunicación del equipo, lo ayuda a mejorar su habilidad y, por último, pero no menos importante, reduce el software con errores de manera muy rentable, desde el inicio hasta el punto más posible.

Los dos primeros proporcionan consejos y técnicas para preparar una revisión de código. En una palabra:

• Usted, como autor, tiene un conocimiento íntimo de por qué cada línea modificada está en su revisión de código. Muchos son obvios para un revisor educado, pero muchos no lo son. Transmita esos puntos anotando la revisión de su código antes de enviarlo a los revisores.
• Incluso antes de eso, considere cuidadosamente lo que comprende la revisión de su código: asegúrese de incluir todos los cambios relevantes para un problema e intente no incluir más de un problema.
• Asegúrese de realizar una comprobación de control de fuente (para volver a sincronizar su código con main) antes de enviarlo.
• Revise su propio código antes de enviarlo, ¡línea por línea!

Parte 1: Comentarios previos a la revisión: capacite a sus colegas para que le den mejores comentarios sobre la revisión de su código

Parte 2: Mejores prácticas: pautas para preparar una revisión de código

Y los otros dos artículos brindan consejos prácticos sobre cómo ser un mejor revisor:

• Lea primero el Jira / issue / ticket / require (como lo llame).
• Asegúrese de que las pruebas unitarias cubran los requisitos.
• Revise las pruebas unitarias para la clase de equivalencia y la integridad del valor límite.
• Asegúrese de que cada prueba unitaria haga lo suficiente, sin probar varias cosas.
• Revise el código para cumplir con los principios de SOLID.
• Tenga cuidado con reinventar ruedas, código demasiado complicado y solo código complicado.
• Evita la magia (cuerdas mágicas, entradas mágicas y, sí, incluso booleanos mágicos).
• Capture el efecto mariposa: ¿hay ondas que se perdieron (por ejemplo, inconsistencias de nomenclatura)?

Parte 3: El cuento del revisor: pautas para realizar una revisión de código

Parte 4: Revise como si fuera el propietario del código

Predicar con el ejemplo. Haz revisar tu código.

En mi experiencia, la mayoría de las aplicaciones "RPG + Java" están escritas por programadores que provienen del lado RPG, y no del lado Java, y la mentalidad de los dos mundos es muy diferente, lo cual creo que es una de las razones por las que tienes un diseño básico problemas.

Las herramientas oficiales de IBM están basadas en Eclipse, por lo que si usa eso, puede usar la mayoría de los consejos y trucos disponibles para Eclipse, y necesita encontrar cosas que den mucho a cambio por poco esfuerzo, porque básicamente necesita mostrar estos gente que vale la pena hacer en absoluto.

Una de las cosas más eficientes que he encontrado para esto, es Guardar acciones del editor de Java, donde puede pedirle que vuelva a formatear su fuente cada vez que guarde un archivo. Esto en poco tiempo dará como resultado un diseño de codificación más uniforme que facilitará la lectura. Escribí mis hallazgos aquí.

Si primero tiene la noción plantada de que puede tener sugerencias útiles, es mucho más probable que las personas escuchen ...

"Todos escriben código malo". Digerirlo y luego reconocerlo. Esto establece a todo el equipo en un plano que rompe la jerarquía e inculca en todos que todos son iguales. Es muy importante que un programador senior demuestre este comportamiento y actitud. Con estas premisas, practique la programación de pares durante la cual debe debatir, debatir (en un intervalo de tiempo) y converger en una decisión sobre lo que es correcto después de conversar por qué algo podría estar mal. Si bien la programación en pareja, una persona es superior a otra, ambos son programadores humildes y abiertos. ¡Qué mejor manera de promover buenas prácticas de codificación! :)

Una forma que no he visto mencionada en ninguna de las respuestas hasta ahora es la educación. Haga que su empresa patrocine la entrada para aquellos que quieran ir a su JavaZone o RubyConf más cercano o cualquier conferencia que sea adecuada y conveniente para usted. Encuentre cursos que sean relevantes y envíe desarrolladores seleccionados para asistir. Si su empresa es lo suficientemente grande, incluso puede ser factible organizar seminarios y cursos internos sobre temas como mejores prácticas, clases magistrales para su idioma, etc. Obtenga un buen profesor sobre el tema y prepare un curso que se adapte a la situación de su empresa.

Mi empresa está haciendo esto bastante, y aunque todavía hay quienes se niegan obstinadamente a interesarse, la conciencia general sobre problemas como estos está creciendo, y el estado general de nuestra base de código está mejorando. Incluso el curso "C básico" que hicimos durante varias rondas demostró ser esclarecedor para los desarrolladores que han estado escribiendo C durante 10-15 años. No porque sean malos programadores, sino porque tiendes a caer en hábitos y olvidas por qué, y que el lenguaje y la experiencia colectiva sobre cómo usarlo también está cambiando lentamente.