La capacidad de mantenimiento es una parte importante del desarrollo de software profesional. De hecho, el mantenimiento es casi siempre la parte más larga del ciclo de vida del software, ya que dura desde el lanzamiento del proyecto hasta el final de los tiempos.
Además, los proyectos en mantenimiento representan una gran mayoría del número total de proyectos. De acuerdo con http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-numbers-of-programmers-in-maintenance-vs-development/ , la proporción de proyectos en mantenimiento es de aproximadamente 2 / 3.
Recientemente me encontré con esta pregunta , donde el chico se ve bastante sorprendido al descubrir que su trabajo es principalmente de mantenimiento. Entonces decidí abrir una discusión (francés) en el sitio principal de la comunidad francesa de profesionales de desarrollo de software ( http://www.developpez.com/ ). La discusión se titula "¿Están los estudiantes suficientemente capacitados para la realidad del desarrollo de software profesional?" y se trata principalmente de mantenibilidad . Se señaló que, al menos en Francia, las personas no están lo suficientemente preparadas para enfrentar el mantenimiento en ambos aspectos:
- mantener el código existente
- hacer código mantenible
Mi pregunta aquí se hace eco de esta discusión y tiene como objetivo encontrar una buena manera de enseñar la mantenibilidad.
- ¿Cómo podemos enseñar mantenibilidad?
- ¿Qué tipo de ejercicio sugerirías?
- Si ha recibido una buena formación en materia de mantenimiento, ¿qué tipo particular de cursos tomó?
[editar] Después de algunos malentendidos, creo que debo aclarar mi pregunta. Como líder de proyecto y desarrollador de software, a menudo trabajo con aprendices o estudiantes recién graduados. Una vez me gradué recientemente. La cuestión es que los estudiantes generalmente no están familiarizados con principios como SOLID que aumentan la capacidad de mantenimiento de un proyecto. A menudo terminamos teniendo dificultades importantes para que los proyectos evolucionen (bajo mantenimiento). Lo que estoy buscando aquí es un ejemplo académico concreto de enseñanza exitosa sobre la importancia de la mantenibilidad y cómo hacer un mejor código con respecto a este punto en particular; o posibles sugerencias para mejorar la forma en que se capacita a los estudiantes.
fuente
Respuestas:
Eso es una cuestión de práctica.
La forma más directa de practicarlo de una manera controlada que se me ocurre es simular un proyecto de mantenimiento típico de la siguiente manera.
Obtenga un proyecto ( Proyecto A ) que esté bien hecho e introduzca algunos problemas al respecto: inyecte algunos errores, una buena cantidad de código duplicado y muerto, elimine algunas características, pruebas unitarias y documentación aquí y allá, etc. Incluso puede tener un dedicado nombre para eso, como Proyecto A - versión dañada .
Establezca un rastreador de problemas y complételo con solicitudes correspondientes a daños particulares que haya realizado. Establezca reglas y prácticas básicas para el proceso de desarrollo: confirmaciones de VCS, revisiones de código, control de calidad, etc., considere tomar lo que pueda de la lista de verificación provista en The Joel Test .
Corrija errores, agregue pruebas unitarias faltantes, documentación y características.
Refactor.
Mantenimiento / mejora de proyectos originales para uso de los estudiantes del próximo año
- Proyecto A versión 2.0 y Proyecto A - versión dañada 2.0 , respectivamente.
Al mejorar la versión dañada me refiero a hacer un mejor daño educativo. :)
De las prácticas mencionadas anteriormente, preste especial atención a las revisiones de código . Esta es probablemente la forma más efectiva de garantizar que el código sea fácil de mantener, como se indica, por ejemplo, en la respuesta principal en la pregunta relacionada .
fuente
Descargo de responsabilidad: acabo de obtener mi título de CS. No soy un profesor.
Esto puede sonar obvio, pero creo que la mejor manera de enseñar el mantenimiento del código es hacer que los estudiantes realicen el mantenimiento del código. Esto es lo que haría:
La idea es no solo que los estudiantes trabajen con el código de otra persona, sino que también desarrollen una apreciación por el código mantenible que, con suerte, mejorará sus habilidades de diseño.
fuente
La mantenibilidad es una virtud, no una habilidad. Hay muchos caminos para crear proyectos que se puedan mantener, pero ninguna fórmula que garantice su producción.
Si valoras virtudes como la amabilidad y la generosidad, buscas formas de practicar lo mismo en tu vida diaria. Lo mismo ocurre con la capacidad de mantenimiento: si usted y su organización valoran la capacidad de mantenimiento, lo tendrán en cuenta mientras diseñan e implementan su proyecto. Será una razón legítima para dedicar un poco más de tiempo a construir algo porque sabe que se aprecia la facilidad de mantenimiento. Por el contrario, se desaconseja dedicar más tiempo por el mantenimiento en una organización que no lo valora.
Si desea enseñar a las personas a hacer que las cosas se mantengan, debe comenzar dejando en claro que su organización valora la mantenibilidad. Especifíquelo en los requisitos para sus proyectos. Conviértalo en uno de los criterios para una revisión exitosa del código. En resumen, haga que la mantenibilidad sea parte de su cultura .
Luego, esté dispuesto a dedicar algunos recursos para mejorar la mantenibilidad en sus proyectos existentes. Identifique aquellas partes de un proyecto donde los errores continúan apareciendo, o donde corregirlos o hacer cambios es muy difícil y toma mucho tiempo, y rediseñe o refactorice para facilitar el mantenimiento.
Finalmente, adoctrine a los nuevos desarrolladores en su cultura de mantenibilidad asignándolos a equipos que ya lo practican a diario. No hay mejor manera de ayudar a alguien a adoptar un valor que darles muchos buenos ejemplos y orientación.
fuente
Por mi parte, no me gusta el término Mantenible en relación con el desarrollo de software. La realidad es que todo el software es mantenible ya que puede estar sujeto a trabajos de mantenimiento, por lo que el verdadero problema es si el software es caro o económico de mantener, en términos relativos. Sé que esto suena como una declaración muy pedante para hacer al comienzo de una respuesta, sin embargo, mi punto se aclarará en un momento.
El problema con los grados de TI que se especializan en el desarrollo de software es que realmente solo enseñan a los estudiantes el mínimo mínimo que los estudiantes necesitan saber sobre la escritura de software. Las habilidades y conocimientos profesionales se obtienen a través del aprendizaje que se realiza en los primeros años posteriorescalificación para el grado. Esto es cuando un graduado comienza a trabajar en proyectos que realmente importan a un cliente, en un entorno donde hay una gran presión para realizar, y la expectativa es crear un producto con un estándar profesional. Lamentablemente, muchas empresas no fomentan una cultura en la que se mantengan los estándares profesionales en software y, como resultado, terminan con proyectos que resultan costosos de desarrollar y mantener. Desafortunadamente para nuestros graduados, aprenden muchos malos hábitos en tales entornos en los primeros años de sus carreras, y puede pasar mucho tiempo antes de que aprendan cómo superar estos hábitos ... si es que lo hacen.
Sería mejor enseñarles a los estudiantes cómo escribir código limpio y cómo identificar los problemas en el software que generalmente terminan incurriendo en deudas técnicas . Consulte los libros sobre Código limpio , Refactorización y Desarrollo de software Lean como punto de partida como punto de partida, y enseñe a los estudiantes a escribir pruebas unitarias antes del código de implementación para asegurarse de que haya un alto grado de cobertura de prueba. Enseñe a los estudiantes a reconocer patrones duplicados y repetitivos dentro de su código, y cómo refactorizar el código para eliminar dicha duplicación. Ayude a los alumnos a comprender y aplicar principios como SÓLIDO y SECO. Lo que es más importante, elimine esta idea de que la capacidad de mantener el código es algo que se basa únicamente en el diseño y la implementación del código, y en su lugar inculca un sentido de artesanía y calidad en la producción de software desde el principio, buscando refine el código a medida que se implementa para minimizar el impacto de la deuda técnica y, por lo tanto, mantener el costo de mantener el software al mínimo a lo largo del tiempo.
fuente
Creo que la mejor manera de aprender este tipo de habilidades es haciendo revisiones de código y programaciones de pares. Durante las revisiones de código, el personal experimentado puede señalar cómo hacer que el código sea más fácil de mantener (generalmente haciéndolo más legible) y justificar por qué ciertas opciones pueden crear un código más fácil de mantener.
La programación en pareja es una forma aún mejor de enseñar este tipo de cosas, ya que brinda al personal menos experimentado la experiencia directa de mantener el código con alguien que ya sabe cómo hacerlo bien.
También hay algunos libros excelentes que puedes leer sobre cómo escribir código limpio y fácil de mantener. Clean Code viene a la mente.
Es difícil obtener esta experiencia a través de la academia, ya que los estudiantes rara vez modifican bases de código grandes. La mayoría de estas habilidades vendrán del aprendizaje en el trabajo, y las revisiones de código y la programación de pares realmente pueden facilitar este aprendizaje.
fuente
Buen código = Menos mantenimiento y funciones fáciles de mejorar / agregar.
Código incorrecto = pesadilla de mantenimiento
Básicamente, tenemos que comunicarles a los estudiantes que "cada vez que hay un código malo en un proyecto, un nuevo desarrollador que se unirá a la compañía porque el autor original del código sufrirá y cómo se verá afectado el software ".
Entonces, una de las mejores maneras de enseñarle al alumno sobre el mantenimiento del software es mostrar el ejemplo del código bueno y el código malo y pedirles que agreguen una función y luego enseñarles que escribir un buen código no es solo para la satisfacción personal sino también para hacer Es fácil para las personas que van a mantener el código.
Ejercicio:
1) Tener un código incorrecto preescrito (por ejemplo, código duplicado), un método que dice "calcular el pago de la hipoteca" se escribe en 9 lugares en un proyecto.
Pídale al estudiante que mejore la función para "agregar un recargo del 1.2% a todos los pagos de la hipoteca".
Ahora el alumno verá el dolor de localizar y corregir el código en los 9 lugares. Hay muchas posibilidades de que no pueda localizar los 9 lugares donde se calcula el "pago de la hipoteca".
2) Ahora muestre el código Good que tiene este método que calcula el pago de la hipoteca en un solo lugar . demuestre al alumno que es fácil mejorar un código bien escrito y explíquele cómo mejora la capacidad de mantenimiento del código / proyecto.
Por cierto, me encantó su enfoque de exponer a los estudiantes a la mantenibilidad del software.
fuente
@mattmattj: dado que hay MUCHAS respuestas y el enlace que publiqué también tiene algunos buenos indicadores, agregaré algo que espero no sea una repetición de las respuestas ya publicadas.
Primero, uno DEBE definir "mantenibilidad" - no hay una única definición aceptada por todos - similar a la de la arquitectura de software. Por lo tanto, elija uno que considere más importante, que lo abarque todo y dígalo en 3-4 líneas como máximo. Luego, puede hablar sobre algunas métricas, como: tiempo para recordar / comprender su propio código (o el de otra persona), la cantidad de WTF por minuto / hora, etc. para decir después de eso.
Algunos ejercicios (puede parecer un poco superpuesto con algunas de las respuestas, por favor, perdónalo)
Aquí es donde sienta las bases de la capacidad de mantenimiento: cada línea de código modificada / actualizada le cuesta dinero a la empresa. Cuanto más fácil sea leer y recordar el código, mejor / más rápida será la modificación que ayudaría a disminuir el tiempo de comercialización. Muy importante en el espacio tecnológico acelerado de hoy. La mantenibilidad es la clave para la evolución eficiente de los sistemas.
Es importante comprender la diferencia entre el desarrollo greenfield y brownfield: no todos los proyectos o sistemas se crearían desde cero (es bastante difícil de encontrar o ser parte de proyectos "desde cero"). Explicando que el campo es "inherentemente" marrón y debe dedicar tiempo a moldearlo a medida que avanza con la eliminación gradual cuando crece "fuera de control" (solo es posible cuando la deriva es demasiado e "imposible de mantener"). Cuanto antes lo acepten, mejor. Esto es difícil ya que la programación es intrínsecamente creativa, pero mejorar el código de otra persona no se percibe como tal, gírelo. Creatividad existe la capacidad de comprender el código y luego aplicar "su" creatividad para mejorarlo; si se mantiene mejor, podrá mejorarlo de manera más creativa en el futuro.
Siéntase libre de referirse a la analogía de los espaguetis en el enlace anterior ... espero que esto ayude a alcanzar algunos puntos en casa. ¡Las otras respuestas ayudan a llenar los vacíos y deberían ayudarlo con la enseñanza! ¡La mejor de las suertes!
fuente