¿Cómo se mantiene una base de código de baja calidad?

Question

Para poder mantener el código que escribo, debo nombrar bien las variables, documentar mi código, asegurarme de que nada se repita, que las abstracciones funcionen para que no se necesiten hacks ... y comentar con moderación porque los comentarios a menudo interrumpen yo leyendo el código.

Pero muchas otras bases de código que he visto son más como una vorágine. Los nombres de las variables son foobar, las cosas se calculan incluso si nunca se necesitan, se aplican muchos hacks y parches, las abstracciones fallan, los scripts de implementación fallan ... El código es una sopa incomprensible y casi inutilizable.

¡Entonces! Soy curioso. ¿Cómo logras mantener una base de código de baja calidad?

Answer 1

Disciplina

Answer 2

Refactorización constante; cuando abre un archivo de código y ve algo extraño, puede invertir unos minutos para mejorar el diseño del código existente.

Tener un conjunto de pruebas unitarias puede ayudarlo, ya que le da confianza sobre si el código que está cambiando todavía funciona o se rompe debido a su cambio.

Es un poco como la historia de tener una ventana rota en una casa. Cuando vea una ventana rota, debe arreglarla. Si no lo arregla, las cosas comenzarán a deteriorarse a partir de ahí, y dará lugar a un desastre inmaterial.

La mayoría de mis proyectos también se incluyen en ContinuousIntegration; Además de construir y ejecutar pruebas unitarias, también se realiza un análisis de código estático (fxcop). De vez en cuando, miro los resultados e intento corregir algunas violaciones que se informan.

Answer 3

Generalmente, lo que describe es la tendencia natural de cualquier código base a aumentar la entropía. Ocurre en cada proyecto en virtud de que se desarrolla y mantiene. Para combatir este aumento constante, sugeriría lo siguiente:

1. Alguien en el equipo con suficiente autoridad tiene que preocuparse. Esta es la parte más importante. Si a nadie le importa, no se hará. Este punto parece obvio, pero no lo es.

2. Establecer estándares y mejores prácticas. La mayoría de los idiomas tienen un libro escrito por alguien sobre las mejores prácticas. Por ejemplo, en PERL hay un muy buen libro Perl Best Practices de Damain Conway. A menos que haga esto, cada persona en el equipo tiene su propia forma de escribir código, nombrar variables, comentar, etc.

3. Revisiones de código. Necesitará una lista de verificación para las revisiones de código. No es suficiente que su cambio funcione, también debe ajustarse a la lista de mejores prácticas. Configuramos una revisión de código de dos niveles, el primer nivel son revisiones de código de pares y el segundo nivel es un administrador de versiones que se preocupa por la calidad del código.

4. Revisiones de diseño. Cuando el sistema de seguimiento de errores se completa o mejora, es importante que sea revisado por una junta de control de cambios, que decide sobre la programación del trabajo y también sobre quién necesita revisar el diseño del trabajo. Aquí es donde mantiene las abstracciones del código y se asegura de que el cambio se ajuste a los documentos y objetivos de diseño del proyecto. El arquitecto de software del equipo o un diseñador principal debe formar parte del CCB.

5. Activadores de calidad del código de registro. Algunas mejores prácticas pueden ser aplicadas directamente por código. Escriba pequeños scripts que verifiquen su código para cosas como formateo, uso de tabulaciones / espacios y demás. Esto lo ayudará a pensar en la calidad del código de una manera diferente.

Algunas lectura para una referencia.

Answer 4

Las revisiones por pares establecen rápidamente una norma de calidad de código que es difícil de cuantificar en una hoja de papel. Las pruebas unitarias le permiten cambiar el código con poco miedo. Disciplina, mucha.

Answer 5

Una pregunta relacionada: ¿Cómo logran las personas escribir código de baja calidad?

Aquí está la respuesta.

Una buena estrategia para personas incompetentes en nuestra industria es esta:

1. Desarrolle la capacidad de sonar impresionante, especialmente para las personas no técnicas y semi-técnicas. Ser capaz de sonar lo suficientemente creíble para los técnicos, lo suficiente como para mantenerlos fuera de balance.

2. Crea un desorden completo del código que tocas.

3. Ahora, esta es la parte crucial: vete y busca un trabajo mejor en otro lugar justo antes de que te descubran. El mejor momento dependerá de las circunstancias particulares.

Answer 6

Me gustaría presentarle un término que escuché hace unos años: Deuda técnica . Aquí hay una (1) entrada de Wikipedia y otra de Martin Fowler (2) sitio web .

Esencialmente, no creo que las personas comiencen a construir software malo. Lo que suele suceder es que los plazos se comprimen, los requisitos se modifican o reemplazan a mediados del desarrollo y muchas otras realidades comerciales se encuentran en el corazón del desarrollo y el diseño de calidad.

De Fowler:

  

" haciendo las cosas de manera rápida y sucia   nos prepara con una deuda técnica,   que es similar a una deuda financiera.   Como una deuda financiera, la técnica   la deuda incurre en pagos de intereses, que   venir en forma de esfuerzo extra   que tenemos que hacer en el futuro   desarrollo debido a la rápida y   elección de diseño sucio. "

De Wikipedia:

  

" Actividades que pueden posponerse   incluye documentación, pruebas de escritura,   atendiendo a TODO comentarios y   abordando el compilador y el código estático   análisis de advertencias. Otras instancias de   deuda técnica incluye el conocimiento de que   no se comparte alrededor de la organización   y código que es demasiado confuso para ser   modificado fácilmente. "

Lo que he visto (y he dirigido a varios equipos de desarrollo a hacer) es refactorizar y limpiar la base del código temprano en las iteraciones de desarrollo, generalmente al comienzo antes de que se desarrolle un nuevo trabajo.

Las revisiones por pares, las pruebas unitarias y los probadores de software profesionales ayudan a pagar parte de esa deuda técnica, así como a un buen pronóstico (y una buena reutilización del código).

Si tiene el presupuesto, las pruebas automatizadas pueden ser una buena inversión siempre que esté dispuesto a pagar el mantenimiento (tiempo, esfuerzo).

Hoy en día hay muchas herramientas de calidad, como fxCop (y otras similares), sin embargo, debe elegir cuidadosamente qué enfoques va a entretener.

Debe tenerse en cuenta el esfuerzo por mantener la calidad en el diseño y en la base del código, así que piense detenidamente en la forma más efectiva y útil para su equipo de desarrollo / producto / empresa / clientes, etc.

[(1) http://en.wikipedia.org/wiki/Technical_debt ]
[(2) http://martinfowler.com/bliki/TechnicalDebt.html ]

Answer 7

Este es el caso cuando escribe el código y otras personas lo leen
1. Dejó los malos hábitos
2. Usar un procedimiento significativo , función, nombre de variable
3. Usar documentación sobre cómo funciona (procedimiento / función / cálculo / etc.) y qué resultó de qué, no haga ningún comentario innecesario
4. Intente dar estilo a su codificación para que la gente pueda saberlo (como usar el código de estilo GNU)
o
Utilice el embellecedor de código para ese
5. Piensa trabajar en equipo (incluso si estuvieras solo) y no solo tú leerás tu código (incluso si lo fuera)
6. El código de refactorización también debería ser bueno
7. Consulta con tus compañeros de equipo sobre el código que estabas escribiendo, ¿pueden leerlo?
8. Aprenda de la comunidad OpenSource , cómo funcionan y comparten códigos & amp; parches
9. Si puede, use SVN o CVS para mantener su código

y recuerde el principio KISS ( K eep I t S imple, S tupido)

y por supuesto Simple, Lean, Mean & amp;

hermoso

si se invirtió (otras personas escriben, leíste) no sabía qué decir: D (tal vez dar a las personas consejos anteriores LOL)

Answer 8

Documentación, control de fuente, pruebas unitarias y ser un buen programador.

Answer 9

Un conjunto completo de pruebas unitarias que permite cambios y refactorización sin preocuparse por romper el código existente.

Recomiendo recoger una copia de Michael Feather's "Trabajando eficazmente con código heredado".

Answer 10

Fridgemagnet dice: " Los programadores aburridos tienen bases de código inmaculadas "

Answer 11

Solo puede salirse con la suya al mantener una base de código mal cuando es un equipo de desarrollo muy pequeño (menos de 10-20 personas en un solo proyecto). Si su proyecto crece y su equipo crece, sus prácticas se ampliarán o fracasará.

El cambio sobre el que está preguntando es esencialmente la transición del hackeo a la programación y finalmente a la Ingeniería del Software.

Con Ingeniería de software, reconoce que no todos en el equipo son perfectos. Usted revisa el código, se asegura de que otros lo prueben, se verifica entre sí.

Comienza a ver la necesidad de un arquitecto que pueda digerir los deseos de los clientes y traducirlos en un documento de diseño. Esto puede consumir fácilmente un mes antes de que alguien más se agregue al proyecto (¡pero en el transcurso del tiempo de desarrollo puede ahorrar meses o incluso años!). Se asegura de que todo tenga sentido y se ajuste razonablemente bien.

Tiene documentos de diseño, generalmente basados ??en UML para que diferentes partes del equipo puedan comprender los puntos de integración. Reconoce que cualquier cosa que se haya hecho, puede que tenga que volver a hacerlo sin las personas que lo hicieron, por lo que debe documentarlo.

Su proceso de calidad se vuelve mucho más estricto y comienzan a aplicar reglas como que solo se registran cambios que abordan errores específicos durante las pruebas.

Las pruebas, la refactorización, etc. son evidentemente clave y son reforzadas por la revisión por pares y equipo.

No digo que este tipo de cosas siempre sea necesario, obviamente no lo es, pero en su pregunta, usted discute las bases de códigos crudos, y estas buenas prácticas son a menudo la solución a ese problema.

Por lo general, estas buenas prácticas se implementan después de un proyecto GIGANTE que falla completamente porque la base de código es muy mala. Luego despiden a cualquiera que no pueda evadir la culpa, contratan a algunos gerentes que ojalá tengan algo de experiencia con proyectos más grandes y (si no se quedan sin dinero) reinician desde cero.

Al menos esa es mi experiencia. YMMV

Answer 12

Solo necesita práctica, buenas herramientas y capacidad y disposición para romper los malos hábitos y aprender.

Answer 13

La codificación es muy similar a la escritura a mano. Cada uno tiene su propio estilo distintivo. Uno de los mayores desafíos que he enfrentado mientras mantengo el código heredado, es tratar de descubrir qué está sucediendo. Por lo general, se reduce a la falta de coherencia en la base de código.