Escritura código de mantenimiento

Question

¿Cuál es el factor individual más importante para escribir código mantenible (independiente del idioma)?

Answer 1

Buenos comentarios.

Answer 2

Documentación.

Answer 3

buena abstracción

Answer 4

separación de las preocupaciones (cada método hace una cosa) - Esto detiene código espagueti.

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 realizar 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 sea obvio que el cambio debe realizarse.

Answer 5

nombres de los métodos buenos

Answer 6

refactorización continua

Answer 7

pruebas unitarias automatizadas.

Puede cambiar lentamente el diseño del código a través de la refactorización si lo ha cubierto con pruebas automáticas que le indican cuándo se está rompiendo la funcionalidad existente. Las pruebas automatizadas hacen que cambiar el código sea menos riesgoso.

Answer 8

Buen diseño por adelantado. Nada puede salvar un diseño pobre.

Answer 9

Los buenos comentarios pueden hacer que incluso el peor código de spaghetti 10x sea más fácil de mantener.

Answer 10

No haga any of this stuff! Gracias a Roedy Green por las risas.

Answer 11

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 está escribiendo código con 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.

Answer 12

Escríbela para que otras personas lean. Esto significa una combinación de buenos nombres, buenos comentarios y declaraciones simples.

Érase una vez 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 sea consistente. No cambie estilos en su código. Por ejemplo, no cambie los estilos de nombre de una sección a la siguiente.

Answer 13

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.

Answer 14

Coherencia.

Answer 15

No creo que haya un solo factor en el que pueda concentrarse. 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 de lo que no debe hacer. Informativo y divertido!

http://mindprod.com/jgloss/unmain.html

De hecho, he trabajado en empresas que "normalizado" en algunas de las cosas que se mencionan en ese país. Pensarías que la mayoría de esas cosas son solo sentido común, pero podrías sorprenderte.

Answer 16

Al 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íe en mí, he estado allí. 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.

Answer 17

Como yo lo veo, la regla fundamental para 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 entender y que realice exactamente la tarea para la que está destinado, pero que también es difícil de modificar de ninguna manera. Aunque nunca había visto un código así.

Answer 18

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 pidió dos, la segunda definitivamente serían las pruebas unitarias. Fue una elección difícil entre los dos.

Answer 19

Para mí escribir código comprobable (de pago blog de Google prueba) es el código más mantenible

Answer 20

No hay un "factor más importante", que es una combinación de varios factores, como se ha señalado anteriormente.

Ahora, la mayoría de estas reglas se pueden resumir en: "escriba su código para leerlo más tarde".
O para parafrasear un consejo divertido pero bueno: "Escriba su código como si fuera mantenido por un maníaco homicida sabiendo dónde vive." ...

Answer 21

Un estilo de codificación consistente. Cosas como métodos, convenciones de nombres variables, estilos y formatos para comentarios e incluso nombres de módulos/archivos.

Answer 22

Ya voté la respuesta de Matt "Good Abstraction" pero quería agregar algo.

Documentando es todo acerca de explicando 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 se pueda mantener, 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.

Answer 23

Me gustaría ir con algunos de los otros, ABSTRACCIÓN. También ayuda cuando comprendes algunos patrones de software, GOF es un buen lugar para comenzar a hacer ese tipo de cosas.

Answer 24

Mucho 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.

Answer 25

Lea el Código Completo - cubre todo sobre esto desde la nomenclatura variable hasta las cosas realmente grandes y es todo necesario. No hay una sola cosa.

Mi enfoque actualmente se reduce a escribir código para hacer el trabajo que necesita hacerse (no para cada trabajo futuro que el código pueda necesitar) usando nombres de variables informativas y alcance variable mínimo y tratando de asegurarse de que mi el código necesita la menor documentación complementaria 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 conjunto fuerte de pruebas, puede ver si los cambios de mantenimiento van a romper cualquier cosa.

En última instancia, es una cuestión de tratar de ser reflexivo y escribir el código de futuro- solamente se escribe una vez, después de que todo el mantenimiento ...

Answer 26

pequeñas funciones y clases, bien definidos.

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.

Answer 27

Yo diría que el factor más importante es DRY. glenatron Menciónalo ya en su respuesta, entre otros factores, pero creo que ese es el más importante.

Answer 28

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. \

[Escoger un lenguaje OO con construido en contraposición a tachuelas en ayuda también]

Answer 29

supongo que la escritura de código mantenible va más allá de código. Creo que es mejor entender cuáles fueron los requisitos (y documentarlo de alguna manera, funcional y no funcional) y luego, como un nuevo empleado, se presentó cómo se convirtió en código.

Si alguien sabe por qué el código resultó ser así, entonces es más fácil mejorarlo y/o expandirlo.

Para obtener información más técnica (como un algoritmo), explíquela de manera abstracta (objetivo, principio) y luego comente las partes clave del código y/o las implementaciones de patrones.

Una cosa que hago también es crear mini-laboratorios, cajas de herramientas y plantillas de código dentro de mi aplicación para que la gente sepa cuál es el código "estándar" necesario para hacer una cosa o expandir otra (conduce a copiar/pegar pero ayuda a producir más y mejor).

Answer 30

Hay una tendencia a escribir código pensando que la computadora es su 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 su 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.

Answer 31

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.

Answer 32

Encontrar un buen mentor. Esta persona no necesariamente tiene que ser un mejor codificador que usted, sin embargo, debería ser capaz de sugerir otras estrategias para escribir el código correctamente. Un buen mentor será sugerir muchas de las respuestas dadas previamente a este tema. Pueden ser un segundo par de ojos que le permiten saber dónde están sus deficiencias, mientras mantiene un tono alentador y optimista. También serán flexibles y perfeccionarán constantemente sus habilidades como deberían. De esa manera, cuando surja el próximo gran paradigma, podrás separar mejor la paja del trigo. Esto será invaluable cuando la Programación Orientada a Objetos y el Control de Fuente sean reemplazados por la siguiente gran cosa (difícil de imaginar que yo sepa).

Answer 33

La programación es el rendimiento; nunca debes olvidar quién es tu audiencia. "Código como si la persona que termina manteniendo tu código es un psicópata violento que sabe dónde vives".

Answer 34

convenciones fuertes y sensatas que se aplican constantemente. Cosas como convenciones sobre dónde comenzar a indexar, en qué estado final dejar las cosas.

Esto hace que mucho código más fácil de entender, ya que todo su código se comportará de una manera que es más simple.

Este es al menos uno de mis mejores consejos.

Answer 35

• supuestos registro cuando los hacen - dos días más tarde que va a tomar estos supuestos por sentado, pero la próxima persona que mantiene su código no necesariamente va a cometer los mismos supuestos, y se preguntará por qué hizo lo lo hizo ...

• Código para personas - la computadora hará todo lo que le pida; código para que humans entienda su código - ¡quién sabe si puede ser usted dentro de 6 meses!

Answer 36

Ha sido un largo tiempo, pero no tengo una respuesta a lanzar en: no lo hacen 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.

Answer 37

Las funciones puras hacen que sea mucho más fácil razonar sobre el código. Asegúrese de comunicar los efectos secundarios correctamente. (es decir, los efectos secundarios generalmente se hacen cuando no se devuelve un 'resultado'. Es decir, funciones nulas.)