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

38

(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é).

Gato y ratón
fuente
1
Si tiene la opción, busque productos JetBrains (Re-Sharper para C #, IntelliJ para Java e incluso algunos lenguajes 'dinámicos') que pueden realizar cambios idiomáticos en todo el proyecto en toda la solución, con muy poca inversión de tiempo. (También se puede usar para enseñar interactivamente al joven lo que es idomático. Pero asegúrese de que usted y ellos acuerden las mismas configuraciones para el proyecto. (Y asegúrese de hacer todo eso en una confirmación por separado, para que no se mezcle cambios sustantivos y cosméticos en el mismo commit),
David Bullock
2
Implementar una guía de estilo / minimanual? Quiero decir, eso no les hará escribir mejor código, pero todos son capaces de seguir pautas que requieren escribir cosas triviales de una manera particular.
Peteris
10
Ya veo que tienes un problema con la falta de trabajo en equipo aquí. Deberías estar educando y cuidando al menor; no solo reescribiendo su código y quejándose de ello.
James
3
@Ramhound desde que Turing ideó la máquina de Turing, supongo. Pero volviendo al punto, si usted es el senior, eso debería hacer que los junior lo escuchen. Enséñeles cómo hacer lo correcto (o en la forma de convección). Pero es importante pedir su opinión y tal vez tengan algunas ideas sobre cómo hacer las cosas de una mejor manera. Además, si está utilizando CSS sin procesar para cualquier proyecto no trivial, lo está haciendo mal, intente que su proyecto adopte LESS o SASS.
Hoffmann

Respuestas:

79

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!

Uri Agassi
fuente
Estoy 100% de acuerdo con usted, sin embargo, me pregunto cómo aplicar esto en presencia de plazos ajustados. ¿Sugiere hacer revisiones de código a pesar de que pueden absorber más de nuestro valioso tiempo limitado (tanto en el proceso de revisión como en las correcciones realizadas después de la revisión)?
Phil
3
No creo que un miembro del equipo deba alterar el trabajo de otro miembro del equipo sin su cooperación / consentimiento. La persona que escribió el código debe ser responsable de ello, y a menos que el código contenga un error crítico y el escritor original no esté disponible, estar en un horario apretado no es motivo para cambiar el código de otra persona. Si encuentra el código demasiado desordenado, comuníquelo al desarrollador y dígale que lo limpie para la próxima versión.
Uri Agassi
23
@Phil Al calcular una fecha límite, se debe tener en cuenta el tiempo para las sesiones de revisión de código. No es un paso adicional sobre el proceso de desarrollo, es una parte integral del proceso de desarrollo.
dj18
2
Además, capacitar a los jóvenes a través de la revisión del código puede tener una cierta cantidad de tiempo ahora (lo cual, como dice dj18, debe tenerse en cuenta en sus plazos y estimaciones de todos modos), pero se pagará a su debido tiempo muchas veces a medida que lo libere para hacerlo. Obra más original. Si sus plazos son tan ajustados que nunca tendrá la oportunidad de hacerlo, huele más bien a una espiral de muerte ...
Julia Hayward
2
@JustinPaulson no me malinterpreten: el hecho de que alguien haya escrito un código no hace que este código sea "suyo". Una semana después, otro miembro del equipo tendrá una tarea que requerirá que modifique ese código, y definitivamente debe cambiar el código según sus necesidades. Sin embargo, no veo un caso de uso en el que alguien deba "limpiar" el código de otra persona en aras de la limpieza, especialmente no como algo de último minuto en un plazo ajustado.
Uri Agassi
29

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.

James Anderson
fuente
11
"Si se trata de un código probado, acaba de invalidar todo el esfuerzo de prueba y tendrá que repetir las pruebas". No, no invalidaste ningún esfuerzo de prueba. Solo tendrá que volver a ejecutar las pruebas, lo que debe hacer para cada confirmación de todos modos. Si eso lleva tanto tiempo que se considera inviable, las pruebas son basura y deben corregirse.
l0b0
77
Vale la pena señalar que escribir continuamente código descuidado para "hacer que funcione" conducirá a una gran bola de barro . Está bien si es una excepción, y no la regla. Si se convierte en la regla, debe hablar con su jefe de que los plazos no son lo único que debe tener en cuenta.
Neil
20
El problema es que el código feo rápidamente se convierte en código roto.
Telastyn
1
@ramhound, claro, pero el OP (y casi todos los demás) no está hablando de código que simplemente usa estándares antiguos, sino de código incómodo, inconsistente y de mala calidad.
Telastyn
1
@JamesAnderson Esta es una perspectiva extremadamente miope. El código se escribe una vez, pero se mantiene durante toda la vida útil del producto. La mayoría de la codificación es refactorización. ¿Cuánto tiempo está escribiendo el código en una pantalla en blanco antes de ajustarlo y ver si se ejecuta como se esperaba? Por lo tanto, está refactorizando, incluso en la primera hora después de comenzar una nueva clase. El costo de refactorizar el código feo en las subsiguientes correcciones de errores y mejoras superará el costo de un poco de tiempo dedicado por adelantado a las revisiones de código y llevar al equipo hacia un estándar claro.
Scott Shipp
16
  • 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.

Robar
fuente
9

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!

Marinero danubiano
fuente
El problema con el "caso límite" es que otros módulos tienden a surgir y hacen uso de ese código. Entonces se vuelve muy arriesgado cambiar ya que otros módulos ahora pueden confiar en un comportamiento "incorrecto / indeseable". Así que terminas atascado con un código que es realmente difícil de mantener y que te da vergüenza cada vez que lo ves y te hace querer ir a otro lugar por trabajo. Como mínimo, alguien que sepa lo que está haciendo debe anular el código incorrecto. De esa manera, se puede arreglar en un momento posterior sin incurrir en el mismo riesgo que dejarlo hasta que alguien tenga tiempo para solucionarlo.
Dunk
6

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.

temptar
fuente
4

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.

usuario1703394
fuente
3

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.

Casey
fuente
He trabajado para algunas grandes empresas muy orientadas al proceso que estaban dispuestas a gastar muchísimo dinero para garantizar el cumplimiento de los estándares y prácticas de codificación. NUNCA FUERON hasta que las herramientas automatizadas comenzaron a aplicarlas.
Dunk
@Dunk ¿El ejército estadounidense cuenta como "grande y orientado a procesos"? Usan S & Ps todo el tiempo: stroustrup.com/JSF-AV-rules.pdf
Casey
Ciertamente cuentan como el estándar de oro para la codificación de estándares y prácticas. Todo contrato los requiere. Sin embargo, a pesar de que las empresas intentan adherirse a sus estándares y prácticas, no sucede de manera confiable y consistente. Simplemente están sucediendo muchas cosas. Es por eso que las herramientas automatizadas son necesarias si desea incluir la palabra "must" en su sugerencia, como lo hizo. El DOD reconoció la imposibilidad de adherirse a las normas por medios manuales y es por eso que el Congreso aprobó una ley en 2011 que exige que los contratistas de defensa comiencen a usar herramientas automatizadas para realizar estas verificaciones.
Dunk
Por cierto, no estoy diciendo que no hay necesidad de codificar estándares y prácticas. Absolutamente hay una necesidad. Solo tengo una disputa con la parte "todos los empleados deben seguir", a menos que también mencione algo sobre hacer cumplir esto a través de herramientas automatizadas.
Dunk
@Dunk El equipo de JSF-AV debe haber reconocido esto, el documento menciona específicamente el uso de herramientas automatizadas como una forma de hacer cumplir los S & Ps (en 2005)
Casey
2

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.

Harrison McCullough
fuente
2

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.
l0b0
fuente
2

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
Aaron Hall
fuente
1
El problema con las guías de estilo de codificación es que tienden a convertirse en libros. La mayoría de las personas están dispuestas a aprender y seguir un conjunto de reglas bastante modesto. Desafortunadamente, en algún momento estas guías siempre van más allá de la capacidad de las personas para aprender y recordar todas las reglas. Necesita una herramienta que haga comprobaciones de estilo automáticamente, punto. Las revisiones de código no deberían ser para realizar verificaciones gramaticales, deberían ser para encontrar errores y malentendidos.
Dunk
Como programador de Python y líder de la revisión de código, imprimí PEP 8 y ​​la guía de estilo de Python de Google al menos una docena de veces para pasar. Cualquier programador que no aprenda de ellos se encontrará rezagado respecto de los que sí lo hacen. Dicho esto, estoy de acuerdo en que un verificador de estilo también es una buena práctica si puede implementarlo.
Aaron Hall
No uso Python, por lo que no conozco las herramientas disponibles, pero si confía en las revisiones de código para hacer cumplir sus reglas de estilo, está desperdiciando cientos (si no miles) de horas al año por algo que usted podría hacerse por usted esencialmente sin costo de tiempo. Ciertamente no seguiría adelante e implementaría una versión local. Gastaría el dinero para comprar una versión comercial que sea MUCHO mejor que cualquier cosa que pueda construirse en casa fuera de tiempo. Incluso las herramientas caras se amortizarán muchas veces.
Dunk
Python, siendo la cornucopia de código abierto que es, tiene todo tipo de herramientas gratuitas (pylint, pep8, pyflakes), algunas de las cuales hemos combinado y mejorado, que desde que tenemos miles de desarrolladores, realmente se adapta muy bien.
Aaron Hall
1
: Me refería a su fragmento "si puede implementarlo". Si pudieras comprar un corrector de estilo, entonces ese es el camino a seguir. Si puede hacer que su equipo implemente algo tan útil como esto en un tiempo razonable, entonces debe haber una empresa / código abierto que ya lo haya hecho. Por lo tanto, sería mucho más rentable simplemente comprarlo. Estoy seguro de que sería mejor y más actualizado que una versión local "no productiva". Si tiene miles de desarrolladores, entonces subestimé enormemente la cantidad de ahorro que proporcionaría una herramienta automatizada de verificación de estilo / seguridad.
Dunk
2

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.

León
fuente
0

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.

Steve Jessop
fuente
0

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.

Mono Código Borracho
fuente
0

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 .

Kasper Ziemianek
fuente