¿Qué tan importante es limpiar el código de otra persona cuando se enfrenta a una fecha límite ajustada? [cerrado]

(Estoy hablando del código HTML / CSS (no de los lenguajes de programación) pero creo que también enfrentamos el mismo problema que con los programadores).

Soy el diseñador principal de un equipo y a menudo tengo que reelaborar la producción de mis juniors en plazos ajustados.

Me enfrento a 2 problemas:

1. Su estilo de codificación es un poco desordenado.
2. La estética no es buena.

Creo que su estilo de codificación es un conjunto mixto sin ninguna convención / estándar adecuado. Estoy dividido entre limpiar el código o simplemente lidiar con su código (incluso copiar cómo hacen las cosas).

Me resulta frustrante seguir su estilo de codificación, ya que siento que podría aprender malos hábitos. Pero entonces, esa es la forma más rápida de cumplir con la fecha límite.

Para aquellos con mucha más experiencia, ¿cuál es más efectivo? ¿Debo guardar la limpieza para más tarde? ¿O limpiar a lo largo del camino mientras hago los cambios?

(Sin embargo, no quiero parecer arrogante, pero esa es la realidad. Les llevará más años escribir un código mejor. Lo sé, escribí código desordenado cuando comencé).

Creo que está viendo el problema de la manera incorrecta: está perdiendo una gran oportunidad de enseñar a los jóvenes cómo escribir un mejor código.

Si habitualmente reescribe su código, puede darles a sus juniors la impresión de que no valoran su trabajo, lo que reducirá su moral y no les ayudará a codificar mejor la próxima vez.

Creo que un mejor enfoque es agregar al proceso de desarrollo de su equipo una tarea de revisión de código. No tiene que ser sobre cada parte del código comprometido, y no tiene que (solo diría que no debería) ser conducido solo por usted, siempre que un miembro de su equipo termine una tarea lo suficientemente grande como debería emparejarse con uno (o más) de sus compañeros de equipo, explicarles el código y recibir opiniones constructivas y críticas sobre su diseño, estilo de codificación, posibles errores y problemas de seguridad, etc.

Cuando el compañero de equipo que revisa el código es usted, aprenderá de su experiencia mucho más que cuando simplemente reescribe su código (tienen la oportunidad de escuchar la razón por la que se debe cambiar el código), y podría ofenderse menos.

Darles la oportunidad de realizar también revisiones de código mejorará aún más sus habilidades, al ver cómo otras personas escriben código y por qué, y elevará su autoestima.

También aprenderán mucho si les da la oportunidad de revisar su código. Puede que también aprendas algo, ¡así que no lo hagas solo por espectáculo!

He dicho esto antes y lo diré nuevamente "el código de trabajo es más valioso que el código bonito".

Si cambia el código, hay muchas posibilidades de que cambie su comportamiento, si este es un código probado, entonces acaba de invalidar todo el esfuerzo de prueba y deberá repetir las pruebas.

Por supuesto, aliente a sus juniors a escribir un código claro y comprensible, pero si va a volver a escribir todo lo que escriben, entonces está malgastando el dinero de sus empleadores varias veces. Tienen que pagar por tus juniors, luego pagar por ti para que hagas lo que ya les han pagado a tus juniors, y luego pagar por ti una vez más para hacer el trabajo para el que realmente te contrataron.

• La respuesta corta es no. Cuando los tiempos son difíciles, a veces solo tienes que bajar la cabeza y tomar la bala estética. ;)

• Una respuesta más pragmática es marcarlo en el tiempo. Presupuesta una hora para ejecutar y limpiar un aspecto específico del código. Luego verifíquelo y haga un trabajo real. Pero se honesto contigo mismo acerca de mantenerlo restringido.

• A veces, sin embargo, un poco de limpieza hace que el trabajo vaya más rápido. Incluso algunos cambios rápidos de tipo de búsqueda y reemplazo hacen que todo sea mucho más accesible.

• Ten cuidado con las guerras de estilo. Especialmente en una situación de fecha límite ajustada, si vas a deshacer algunas preferencias estilísticas que el otro programador simplemente volverá a hacer, entonces nuevamente es mejor esperar hasta que tengas tiempo para realmente resolver cómo quieres abordar esas cuestiones estilísticas de forma cooperativa. (Lo que significa algo de toma y daca).

Pero hay un valor de juicio en la respuesta. Yo diría "moderadamente" importante. El código limpio realmente puede hacer que el trabajo vaya más rápido, y la calidad del código es, después de todo, parte de la entrega. No creo que pueda tocar el código (incluso el mío) sin pasar algún tiempo en la limpieza. Pero asegúrate de que preocuparte por el estilo y el formato, y las guerras de estilo, no se vuelvan más importantes que llevar el código a producción.

Al arreglar el código y tener una fecha límite, normalmente uso dos reglas:

El código es horrible, pero es posible encontrar un problema en un tiempo razonable y solucionarlo.

Arreglo un problema y dejo el resto intacto .

El código es tan desordenado que es realmente difícil encontrar un problema allí. Arreglar algo provoca que se rompa inmediatamente otra cosa. Probablemente sería más rápido escribir ese código desde cero que arreglarlo.

Entonces no tengo otra opción que reescribir / refactorizar hasta que el código esté lo suficientemente limpio como para localizar y corregir el error.

El caso límite es:

El código es desordenado y realmente malo. Todavía es posible corregir un error en un tiempo razonable, pero la estructura del código hará que sea realmente difícil de mantener. Es muy probable que cualquier nueva característica introduzca nuevos errores o cause una disminución significativa del rendimiento.

En ese caso, el código debe corregirse, pero solo cuando se implementen nuevas funciones, durante el tiempo de inactividad, ¡nunca en el tiempo de corrección de errores antes de la fecha límite!

Me interesaría saber en qué punto de su proceso encuentra este problema.

Estrictamente hablando, en este mundo ideal mágico en el que ninguno de nosotros habitamos, todo el código promocionado o implementado debería ser perfecto. No es así, a veces hay que ser pragmático.

Sin embargo, si tiene un proceso de revisión de código, debe resaltarlo antes de realizar la prueba. Si constantemente se enfrenta a plazos, ¿los problemas de las estimaciones de entrega significan que un componente clave de cualquier proceso de desarrollo, es decir, la revisión del código, se está estrangulando?

Sus juniors nunca van a aprender a sentarse y absorber mejores formas de hacer las cosas si no se toman el tiempo para que sea parte de su proceso de desarrollo para aprender. Me parece que no estás haciendo eso.

Depende de la cultura general. Si los plazos ajustados son esporádicos, acepte que tendrá que hacer la limpieza más tarde. Si son constantes, entonces usted está acumulando estructuralmente una deuda técnica y debe abordar el problema con la administración. Si no abordan sus inquietudes, mejor comience a buscar otras oportunidades de trabajo, ya que la cultura de la empresa probablemente cumpla con los principios darwinianos pronto.

Para ayudar a frenar el problema en el futuro, desarrolle un documento interno de Normas y prácticas de codificación que todos los empleados deben seguir.

Para el lote actual, limpie el código de acuerdo con el documento de S&P mientras refactoriza el código, pero solo cuando lo refactorice.

Soy bastante inexperto con la programación. Sin embargo, como estudiante, a menudo me comprometo a la revisión por pares y las asociaciones en proyectos. Si hay tiempo suficiente para terminar un proyecto, seguiré adelante y limpiaré el código de un miembro del equipo para mayor claridad y legibilidad. Más a menudo que no, me resultará difícil incluso examinar las primeras 100 líneas más o menos. En estos casos, estoy más que dispuesto a extender una mano para ayudar a enseñar a un compañero programador mejores hábitos y codificación. Si simplemente no hay suficiente tiempo, simplemente copio / pego, y trabajo mis proyectos en el panorama general que trata con sus interfaces pobres. Después, estoy seguro de ofrecer muchos consejos sobre la técnica de codificación. Cuando se trata de la revisión por pares, las críticas constructivas (independientemente de lo inoportunas) solo benefician tanto a él como a mí a largo plazo.

En general, si tiene tiempo de sobra, tómelo para enseñar a sus recién llegados cómo llevar a cabo su trabajo para que todos sean beneficiosos. Tómese un minuto y enséñeles qué ha funcionado para usted y qué no. Si no tiene el tiempo, descubra su trabajo por ahora y asegúrese de volver a ellos cuando tenga la oportunidad. Hágales saber que hay mejores formas de hacer las cosas, especialmente si trabajará con ellos en el futuro.

Mejorar la calidad general es muy superior al uso de una sola persona como "filtro" para un grupo más grande. En esa nota:

• La programación en pareja funciona como una versión mejorada de la revisión de código para comprender cómo desarrollarla; es como la diferencia entre leer y hacer, contar y mostrar. Ver cómo evoluciona el código y discutir rápidamente los cambios es inmensamente útil para comprender no solo el cómo sino el por qué de la refactorización y el buen código. En mi experiencia, es más rápido que desarrollar solo, ya que las ideas se lanzan continuamente, terminando con un resultado general de mayor calidad y una mejor comprensión tanto del código como del pensamiento de la otra persona.
• Las herramientas de revestimiento pueden verificar que se sigue el estilo de codificación. Esto les enseña a todos cómo formatear el código, y los errores deberían desaparecer rápidamente una vez que los desarrolladores recuerden el estándar.
  • Realice estas partes del proceso de compilación para asegurarse de que se solucione antes de comprometerse.
  • Use plantillas de idioma para asegurarse de que su CSS, HTML, JavaScript y el código del lado del servidor se puedan verificar por separado.
• Las herramientas de validación pueden verificar que la salida generada sea sensata. Estos también deberían ser parte del proceso de construcción.

La mejor práctica sería tener una guía de estilo de codificación y revisiones periódicas, de modo que cuando se acerque a una fecha límite, no se enfrente a este problema.

Mi recomendación es que muestres liderazgo y encabeces la revisión regular del código. La administración no se ve presionada desde la parte superior para garantizar que se realicen revisiones periódicas del código, pero mi experiencia es que quedarán impresionados cuando un programador se adelanta para programar y realizar revisiones periódicas del código.

Hay muchos beneficios para su gente, que:

• aprende mejor estilo
• seguir mejores prácticas
• aprender a investigar lo que están haciendo

Y algunos beneficios para ti, serás:

• más eficiente durante las depuraciones de último minuto (que siempre sucederá)
• reconocido como experto y líder tanto por su equipo como por la gerencia

Puedo ver la razón en las respuestas "no arregles lo que funciona" y "no pierdas tu tiempo en lo que no es importante para el cliente". Los PM están preocupados por los riesgos y esto está bien.

También entiendo que la mayoría de la gente no toma bien este tipo de solución. Yo también entiendo esto.

Dicho eso, creo que la mayoría de los plazos son artificiales. Los sistemas reales viven cada vez más que los plazos y el mal diseño que haces hoy te defenderá para siempre. La gente corre para entregar algo en unos pocos meses y pasa años después de esto arreglando algunas malas decisiones en un código que se está ejecutando en producción.

La deuda tecnológica es la palabra. Volverá algún día y alguien lo pagará.

Entonces, en mi opinión, creo que tienes razón al arreglar el diseño roto, y ser profesional (especialmente para los juniors) también significa que debes saber cómo recibir críticas y cómo aprender de ellas, incluso si no es cortés. De hecho, la mayor parte de la vida no es cortés de todos modos.

Cualquier respuesta directa será extrema. Claramente, hay casos en los que la fecha límite es tan ajustada que debe usar un código feo, y hay casos en los que el código es tan feo que vale la pena perder el plazo para mejorarlo. Lo que necesita son métodos para juzgar en qué se encuentra, y quizás métodos para establecer plazos realistas que permitan tiempo para escribir un código mejor.

No guarde la limpieza para más tarde. A menos que habitualmente tenga períodos sin nada que hacer más que refactorizar, no hay un "posterior" en el que de alguna manera se convierta en una prioridad más alta para ordenar el código de lo que es ahora. La rutina es "rojo, verde, refactor", no "rojo, verde, hacer algo completamente diferente durante dos semanas, refactorizar". Siendo realistas, no cambiará el código hasta la próxima vez que lo vuelva a visitar por alguna otra razón, y probablemente también tendrá una fecha límite. Sus opciones reales son arreglarlo ahora o dejarlo.

Por supuesto, un código bien diseñado es mejor que un código mal diseñado, suponiendo que planee volver a leerlo. Si planea nunca volver a leerlo, no lo arregle . Envíe lo primero que pase las pruebas. Pero ese es un escenario bastante raro, para la mayoría de los programadores ocurre aproximadamente nunca. Ignorando ese caso, solo usted tiene los detalles de su caso real para juzgar cuánto cuesta arreglarlo y cuánto cuesta (en un mantenimiento futuro aumentado) no arreglarlo.

Hay ciertas cosas que no son más difíciles de arreglar en el punto en que el código requiere mantenimiento, de lo que deben arreglarse ahora. Estos no te benefician mucho para arreglar ahora. Los más obvios son triviales de corregir (errores de espacios en blanco y similares), por lo que es difícil imaginar que tenga tiempo para hacer esta pregunta, pero no para solucionarlos ;-) Para aquellos que no son triviales y son de este tipo, entonces está bien , tienes un código que no es ideal pero debes ser pragmático. Funciona y estás en una fecha límite. Úsalo.

Hay ciertas cosas que son mucho más fáciles de arreglar ahora de lo que serán más adelante cuando (a) no estén tan frescas en la mente de todos; (b) se han escrito otras cosas que se basan en ellas o las imitan. Estos son mucho más valiosos de solucionar ahora, así que priorícelos. Si no tiene tiempo en sus plazos para arreglarlos, entonces debe esforzarse al máximo para plazos más largos, porque está acumulando deudas en su base de código que probablemente tendrá que pagar la próxima vez que visite el código.

El método preferido para arreglar el código es a través de un proceso de revisión. Comente los problemas que tiene con él y envíelo al junior para que lo cambie . Puede dar ejemplos de lo que quiere decir y dejar que el junior encuentre todos los casos en el código al que se aplican, pero no solo termine su código para ellos. Si lo hace, no les dará medios para mejorar.

Debería escribir problemas comunes en una guía de estilo que diga "no haga esto, haga esto en su lugar", y explique por qué. En última instancia, se permite que la razón sea "para que nuestro código sea estéticamente coherente", pero si no está preparado para escribir sus reglas con alguna justificación, entonces probablemente tampoco debería aplicarlas. Simplemente deje a cada programador libre para elegir.

Finalmente, tenga cuidado con la tendencia a modificar las cosas indefinidamente. Los rendimientos disminuyen, y debes aprender a través de la experiencia donde todavía son buenos. Es absolutamente esencial que se forme una idea realista de lo que es lo suficientemente bueno, o de lo contrario no puede tener esa negociación en la que se asegura de que sus plazos le den tiempo para crear un código "suficientemente bueno". Dedique su tiempo a cosas que no son lo suficientemente buenas.

Como muchos han dicho antes, todo lo que arrojes al aire siempre volverá a caer. Creo en una fuerte uniformidad en una base de código. Por supuesto, algunas cosas realmente no importan tanto. Convenciones de nomenclatura sobre variables locales dentro de un procedimiento, por ejemplo. Sin embargo, para cualquier cosa estructural, debe repararse de inmediato, antes de la fusión final en el tronco principal. Puede que solo sea un poco de mala calidad cuando se mira el procedimiento individual o la clase, pero si todos cometen un código "ligeramente feo", en general se vuelve realmente feo.

El código feo que funciona a menudo funciona bien el 90% del tiempo, pero se desmorona en los bordes. Asegurarse de que no sea así, generalmente es lo suficientemente simple siguiendo solo unas pocas reglas simples. Primero, debería ser obligatorio para cada programador definir y documentar restricciones exactas para cada procedimiento o bloque funcional que producen.

En segundo lugar, para cada procedimiento debe haber una prueba contra esas restricciones. Esto debería ser una simple prueba de unidad que el programador puede (y debe) ejecutar localmente contra su procedimiento antes de comprometerse. Obviamente, esto es más fácil de administrar con un conjunto de pruebas adecuado, pero incluso sin una prueba debe escribirse y posiblemente confirmarse en una clase parcial que pueda excluirse de la compilación.

En tercer lugar, un entorno de desarrollo estandarizado con herramientas preconfiguradas es invaluable. Un servidor TS es excelente para esto. Todos tienen las mismas herramientas (y versiones) exactas, las mismas configuraciones y las mismas actualizaciones. Instale una herramienta de refactorización como CodeRush o Resharper, preconfigurada según sus estándares, e instruya a sus programadores que rechazará cualquier confirmación que todavía tenga advertencias. Ahora puede usar el tiempo de revisión del código de su equipo para mejorar realmente su conjunto de reglas a partir de sus comentarios, y su equipo se corregirá felizmente sin que tenga que limpiar constantemente después. También es mucho más fácil para un programador recibir críticas de código de una herramienta configurada correctamente que de un colega o jefe, donde los estándares pueden parecer arbitrariamente definidos o no se entienden adecuadamente. Si el IDE le dice que su código es de mala calidad, nadie discutirá con eso y será corregido. Encontrará que la calidad del código aumentará dramáticamente, y el equipo en su conjunto pasará MUCHO menos tiempo refactorizando y limpiando después de unas pocas semanas. Los programadores también se acostumbrarán a las reglas y dejarán de escribir códigos basura.

Por último, la solución simple aquí es simplemente dar a los programadores un incentivo para mejorar. Los programadores son por definición competitivos. Todos quieren tener el código más bonito o más rápido. Una buena manera de motivar a todos, mejorar la productividad y erradicar al incompetente es calcular una tabla de puntaje ponderado semanal para todos, quitando puntos por compromisos rechazados y fechas límite incumplidas, por ejemplo. Muestre el N principal en la reunión semanal del equipo, tal vez incluso pague el almuerzo a quien sea el primero en los promedios del mes.

Sugiero usar una herramienta de revisión. Si tiene un repositorio basado en Git, puede usar la herramienta de revisión de Gerrit . Después de algunos compromisos rechazados, el equipo aprenderá los estándares que desea seguir y los compromisos futuros no requerirán ningún trabajo adicional de su parte.

Los commits esperarán su aceptación. Si ve alguna línea que deba reescribirse, puede escribir comentarios y sus compañeros de equipo pueden arreglar el código por su cuenta según sus requisitos. Es realmente una buena manera de aprender los estándares de codificación de los miembros del equipo .