maintenance - significado - Escribir código mantenible
maintenance synonym (30)
¿Cuál es el factor individual más importante para escribir código mantenible (independiente del lenguaje)?
Registre las suposiciones cuando las haga, dos días después dará por sentadas estas suposiciones, pero la siguiente persona que mantenga su código no necesariamente hará las mismas suposiciones, y se preguntará por qué hizo lo que hizo ...
Código para personas : la computadora hará todo lo que le digas; código para que los humanos puedan entender tu código, ¡quién sabe si serás tú dentro de 6 meses!
¡No hagas nada de esto! Sin embargo, gracias a Roedy Green por las risas.
Buen diseño inicial. Nada puede salvar un diseño pobre.
Buena abstracción
Buenos comentarios Los buenos comentarios ayudan a la abstracción al establecer el propósito previsto del código, los comentarios incorrectos solo reafirman lo que el código está haciendo. Los comentarios podrían venir en forma de pruebas unitarias bien diseñadas y nombradas.
Buenos comentarios
Buenos nombres de métodos
Consistencia.
Escríbalo para que otras personas lo lean. Esto significa una combinación de buenos nombres, buenos comentarios y declaraciones simples.
Había una vez que la memoria era escasa y los ciclos eran lentos. Se animó a los programadores a escribir complejas líneas únicas de código que hicieron muchas cosas. Hoy la memoria es abundante y los tiempos de ciclo son rápidos. Debería escribir 5 líneas de código simple que las personas pueden seguir en lugar de una línea que no pueden entender.
Los buenos comentarios no tienen por qué ser largos, pero deben ser útiles.
También sé consistente. No cambie estilos en su código. Por ejemplo, no cambie los estilos de nombre de una sección a la siguiente.
Estar en soporte de 1er o 2do nivel para el software que acaba de escribir, durante un año o dos después del lanzamiento.
Confía en mí, he estado allí yo mismo. El "temor" que pueda tener de mantener o mejorar mi propio código en años es siempre un gran motivador para mejorar el mantenimiento.
Hay una tendencia a escribir código pensando que la computadora es tu audiencia.
Estrictamente hablando, eso es cierto ya que el código tiene que funcionar. Pero si usted escribe con su audiencia humana en mente, solo esa forma de pensar ayuda a producir un código más legible.
Si le preocupa que eso produzca código lento, tenga en cuenta que la mayoría de los programas casi todo el tiempo en porciones muy pequeñas de código. Comience a escribir para la legibilidad, luego use un generador de perfiles para identificar las secciones correctas para optimizar.
Leer código completo: cubre todo sobre esto, desde nombres variables hasta las cosas realmente grandes y todo es necesario. No hay una sola cosa.
Mi enfoque actualmente se reduce a escribir código para hacer el trabajo que debe hacerse (no para cada trabajo futuro que el código pueda necesitar hacer) usando nombres de variables informativas y alcance variable mínimo e intentando asegurarme de que mi código necesita tan poco documentación complementaria como sea posible. A veces, esto hace que mis nombres de variables y métodos sean un poco más detallados de lo que solían ser (mi resultado de depuración es muy compresivo cuando lo uso) pero son mucho más fáciles de entender.
La capacidad de mantenimiento también es generalmente el resultado de una práctica sólida en otros aspectos: si escribe su código de una manera agradable SECO, entonces los problemas son más fáciles de encontrar, si tiene un buen conjunto de pruebas, entonces puede ver si los cambios de mantenimiento van a continuar. para romper cualquier cosa
En definitiva, se trata de tratar de ser reflexivo y escribir para el futuro; el código solo se escribe una vez, después de eso todo es mantenimiento ...
Lo prefiero cuando la gente poda y da forma al código a medida que crece. Con demasiada frecuencia se encuentra una columna vertebral original de arquitectura decente con un lío grande y contundente colgando de ella.
Los buenos comentarios pueden hacer que incluso el peor código de spaghetti 10x sea más fácil de mantener.
No creo que haya un solo factor en el que puedas concentrarte. Si hay, creo que debería ser un buen juicio. Incluso el código bien documentado y fácil de leer puede ser difícil de mantener si un desarrollador usó un juicio deficiente durante la fase de diseño. No importa qué tan buena sea la documentación y la prueba de la unidad, el diseño incorrecto de una aplicación de producción puede ser casi imposible de solucionar.
También puede consultar algo como La Guía del Código Inmaculable para obtener ideas sobre lo que no debe hacer. Informativo y divertido!
http://mindprod.com/jgloss/unmain.html
De hecho, he trabajado en empresas que "estandarizaron" algunas de las cosas mencionadas allí. Pensarías que la mayoría de esas cosas son solo sentido común, pero podrías sorprenderte.
No existe un "factor más importante", es una combinación de varios factores, como se señaló anteriormente.
Ahora, la mayoría de estas reglas se pueden resumir en: "escribe tu código para leerlo más tarde".
O para parafrasear un consejo divertido pero bueno: "Escribe tu código como si fuera mantenido por un maníaco homicida sabiendo dónde vives" ...
Para mí, escribir código comprobable (verificar el blog de prueba de Google) es el mejor código que se puede mantener
Pruebas unitarias automatizadas.
Puede cambiar lentamente el diseño del código a través de refactorización si lo ha cubierto con pruebas automáticas que le indican cuándo está rompiendo la funcionalidad existente. Las pruebas automatizadas hacen que cambiar el código sea menos riesgoso.
Pruebas unitarias incuestionables. Si prueba su código desde el principio, tendrá un conjunto de pruebas que podrá ejecutar para validar la validez de su código cada vez que realice un cambio.
Además, cuando escribe código con la prueba unitaria, los métodos tienden a ser más pequeños ya que son más fáciles de probar. Además, debería alentarlo a que realice sus métodos en una sola tarea, una vez más, ya que es más fácil realizar la prueba de esa manera.
Refactorización continua
Separación de preocupaciones (cada método hace una cosa): esto detiene el código de Spaghetti.
EDITAR: (En respuesta al comentario de Ash) La clave para la capacidad de mantenimiento es poder descubrir rápidamente qué está haciendo el código y cómo hacer cambios para lograr una tarea.
Tener el código separado para que cada tarea sea manejada por un método dedicado hace que esto sea muy sencillo.
Por ejemplo, si quiero cambiar la forma en que se dobla un codo en el software para un robot, tener un método llamado BendElbow hace que no sea obvio que el cambio debe realizarse.
Sin lugar a dudas, escribir código diseñado para ser leído por otras personas. Esto incluye evitar el golf, la sintaxis misteriosa y los nombres de variables considerados que significan algo. Puede evitar escribir cualquier comentario si el código es lo suficientemente limpio, IMO. /
[También ayuda el hecho de elegir un idioma con OO integrado en lugar de agregarlo]
Tal como lo veo, la regla fundamental al escribir código de mantenimiento es que su código debe ser muy fácil de entender. Esto no es tan fácil como parece, y tendrás que usar todas las otras técnicas mencionadas aquí para hacerlo. Requiere una cierta cantidad de empatía porque tendrás que aprender cómo otros desarrolladores ven tu código y cómo difiere de la forma en que lo ves. Una buena forma de entender esto es retroceder y mirar algún código que escribió hace un par de años.
Ahora, supongo que sería posible, teóricamente, escribir código que sea muy fácil de comprender y que realice exactamente la tarea para la que está destinado, pero que también es difícil de modificar de alguna forma. Aunque nunca había visto un código así.
Tener buena documentación. Esto incluye código que es autodocumentado (compartimentado, descriptivo y claro), buenos comentarios, un documento de diseño detallado que es exacto a la versión final (más reciente) del código y notas descriptivas de cambio en el control de origen.
Si pediste dos, el segundo definitivamente serían pruebas unitarias. Fue una elección difícil entre los dos.
Un montón de espacio en blanco. - Código de alta densidad es difícil de comprender. Si tiene más de 6 líneas sin una línea en blanco, entonces ese grupo probablemente no sea una idea / operación cohesionada.
Buenos nombres de variables: explicativos, pero concisos. Los enormes nombres de variables son tan malos como los pequeños.
Ya voté la respuesta de Matt "Good Abstraction", pero quería agregar algo.
Documentar todo se trata de explicar cosas. Estoy totalmente a favor de Doxygen y otras herramientas de documentación automática, pero las listas crudas de funciones en una API son simplemente mejor que nada.
Si desea que su código sea mantenible, describa su solución con el nivel de abstracción adecuado y refine ese nivel hasta el código para que sea obvio lo que hace.
Yo diría que el factor más importante es SECO. glenatron Menciónalo ya en su respuesta, entre otros factores, pero creo que ese es el más importante.
funciones y clases pequeñas y bien definidas.
Es bastante fácil acostumbrarse a las diversas convenciones de codificación de otras personas, pero si todo está en una clase o función gigante, mi cabeza explota.
La programación es rendimiento; nunca debes olvidar quién es tu audiencia. "Codifique como si la persona que termina manteniendo su código es un psicópata violento que sabe dónde vive".
Ha pasado mucho tiempo, pero tengo una respuesta que arrojar: no hagas más comentarios. Esto puede sonar tonto, pero demasiados comentarios que explican cosas simples pueden hacer que el código se vuelva desordenado a medida que todos salen. Los buenos comentarios pueden hacer milagros, pero los inútiles hacen todo lo contrario.