traducir - desing o design
¿Qué hiciste para desarrollar buenas prácticas de diseño de código? (19)
He estado programando c ++ por cuatro años y java por dos, siento que tengo una gran comprensión de los idiomas, aunque tampoco soy un hechicero. Parece que una vez que alcanzo la marca de finalización del 75%, mi código parece ser una espantosa bola de espaguetis, a veces hasta el punto de ser ilegible. ¿Qué has hecho para producir un buen código legible?
Refactoring Triage
Recientemente, participé en la refactorización de un proyecto bastante grande en un relativamente corto período de tiempo. Esto requirió que realicemos un tipo de triage de refactorización. Los objetivos que elegimos para mejorar el mantenimiento y la legibilidad fueron los siguientes:
Eliminar el código no utilizado
Cualquier código que no se llame, no debe ser parte del proyecto.
Esto incluye código comentado, o código que no tiene un caso de uso.
Limpieza de comentarios
Los comentarios en el cuerpo del código deben ser lo más concisos posible, y solo existen cuando el código no es comprensible ...
Pero si el código no es comprensible, probablemente deba volver a escribirlo.
Las interfaces externas para clases, funciones y estructuras deben ser comentadas, pero los comentarios deben ser sobre cómo usar la interfaz, no cómo funciona la implementación.
Acoplar jerarquías de herencia
Usa la herencia para expresar las relaciones "es una".
La herencia es buena para el polimorfismo (como usamos Interface for).
No es bueno para la reutilización de código, la composición es mejor para esas circunstancias.
Seguir estándares de codificación coherentes
Convenciones de nombres
Estructura de archivo
Evite los "números mágicos", en su lugar use constantes con nombre
- Conozca a su audiencia (otros programadores, desarrolladores, arquitectos, gerentes de proyectos)
- Haga revisiones de código con otros.
- Observe el dominio (comercial y de cliente) para modelar clases / objetos que tengan sentido para ellos.
- Lea el código completo (aunque solo tengo 9 capítulos).
No necesariamente en ese orden de prioridad.
Aprenda a reconocer el desarrollo del spaghetti mess temprano y sea despiadado en la refactorización cuando note que una mala decisión de diseño comienza a causar problemas.
Siempre debe prestar atención a las cosas que ya ha escrito y estar dispuesto a cambiar las cosas cuando se dé cuenta de que se podría haber hecho de una manera mejor. La clave, sin embargo, es poder reconocer estas cosas temprano para que dedique un tiempo mínimo a arreglarlas.
Dado que el tema de la refactorización ha surgido, sugiero usar un IDE que tenga buenas herramientas de refactorización como Eclipse .
Cambiar nombres de variables, nombres de clases, clases de factoraje son solo algunas de las herramientas de refactorización que son muy simples de hacer. Para mí, la capacidad de refactorizar solo me hizo abandonar el editor de texto que estaba usando (para todos menos el más simple de los proyectos).
Como dijo que usa Java y C ++, Eclipse puede ser una buena opción, ya que admite ambos idiomas. (A través de las herramientas de desarrollo de Java y las herramientas de desarrollo C / C ++ , respectivamente).
Si su IDE ya tiene funciones de refactorización, úselos. Podría ayudarlo a reorganizar su código para que no sea un desastre.
El algo que seguí es bastante simple:
- Estudia el código que consideras bueno
- Decide qué aspectos del código que estudias son mejores que en tu código
- Mejore su código hasta que esté satisfecho con la forma en que lee
Más tarde, leí EL libro Refactoring: Mejorando el diseño del código existente (enlace de Amason) . Contiene consejos concretos de do-s y dont-s para un código limpio y bonito con ejemplos de Java y Python.
El código de espagueti se evita fácilmente mediante refactorización. La refabricación se realiza fácilmente cuando tiene pruebas unitarias. El desarrollo controlado por pruebas lo obliga a escribir las pruebas unitarias antes de escribir el código. TDD le mostrará si su código es fácil de usar y si el diseño es intuitivo.
Entonces, para responder a su pregunta, le diré que necesita agregar TDD y Refactoring a su caja de herramientas.
En términos de legibilidad, hay muchos pequeños hábitos que he formado que me ayudan a mantener mi código "visible", en otras palabras, legible hasta el punto en que puedo mirar una sola pantalla y saber cuáles son los bloques de código. en esa pantalla hacer.
Usa mucho espacio en blanco. Puse espacios alrededor de todo. Nada me molesta más que leer código donde algún programador "inteligente" ha agrupado a todos los operadores en una ecuación sin espacio en blanco. ¿A quién cree que está ayudando? El compilador?
Mantenga los métodos cortos. Si un método se acerca a una pantalla llena de texto, divídalo en métodos más pequeños.
Refactor constantemente No hace falta decirlo, y mantener tus métodos cortos es parte de esto.
Tirar código de distancia. Normalmente escribo todo al menos dos veces. Codificaré una solución completa, sabiendo muy bien que está mal estructurada. Una vez que haya terminado, lo descartaré todo y comenzaré de nuevo, pero ahora con mucho más conocimiento sobre el problema, así como las trampas que debo esperar.
Encontré un mecanismo de diseño que funcionó para mí. Tiende a ser algo parecido a los bordes, es decir, yo "sé" o creo que sí, lo que las capas inferiores deben hacer, y "sé" cuál es la interfaz superior.
De eso se puede generar algún tipo de código de trabajo bastante temprano, y es más fácil mantenerlo modular.
La respuesta correcta debería ser diseñar todo el asunto, pero en mi experiencia, a menudo no tienes la posibilidad / habilidad de hacerlo, así que haz lo que puedas, luego hazlo mejor.
Escribir Solid Code y Code Complete son excelentes libros de referencia para la calidad del código, pero un buen diseño es mucho más difícil de lograr ya que todos pensamos que nuestros problemas de programación son únicos.
Fallar algunas veces Cuando escribe código, mire hacia atrás unos meses más tarde y descubra qué funciona bien y qué no. Sus fallas son sus mayores fortalezas, porque puede usarlas para mejorar sus esfuerzos futuros.
Lea el brillante libro Code Complete de Steve McConnell. Si tuviera que recomendar solo un libro que todo desarrollador de software debería haber leído, eso sería todo.
Lee toneladas de código y toneladas de libros. Por ejemplo, navega por www.koders.com
Leer el código completo Esta es la máxima referencia de buenas prácticas de codificación.
También la experiencia en el mantenimiento de su propio código desordenado le enseñará;)
Para reformular @jxie: Desarrollo basado en prueba, ambos requieren y crean un código desacoplado.
El libro Refactoring tuvo un mayor impacto en mis ideas sobre cómo escribir un buen código, pero puede ser porque me golpeó en el momento correcto.
Obtener su código limpio y claro importa. Mucho. Bien por ti pensando en eso.
Recordé lo que no me gustó del código de otras personas, esas cosas que lo hicieron descuidado. Pero sobre todo, lo que me mantiene teniendo buenas prácticas de codificación es leer mi antiguo código ilegible y preguntarme qué demonios estaba pensando. Así que ahora cuando codigo quiero hacerlo, así sé exactamente lo que estaba haciendo cuando volví a leer el código.
Siempre lea el código de otras personas. Esto ayuda de muchas maneras a ver cómo mejorar sus prácticas de diseño.
También descargué StyleCop . ¡Lo cual ayuda mucho!
Soy un firme defensor del mantra de aprender haciendo. Cuanto más codifique, más trabajará en el código de otro desarrollador, y cuanto más lea sobre desarrollo, mejor será su código. Los tutoriales a menudo usan malas prácticas y mala forma, porque están tratando de enseñar conceptos generales. Código de nivel de producción real es en lo que desea trabajar, sumergirse y respirar. No todos los trabajos que tenga tendrán un código perfecto, pero cuanto más vea y aprenda de ese código, mejor será su desarrollador. Se apasiona por mejorar tu trabajo y actúa en consecuencia. Lea el código que nunca ha visto antes, consulte los artículos sobre seguridad, marcos y tiempo de ejecución. Aplique ese conocimiento, y pronto todo se filtrará en su trabajo.
pruebas unitarias !!! si tiene pruebas unitarias, parece forzar la modularidad, porque para poder escribir (bien) la prueba unitaria, necesita tener componentes pequeños que sean fáciles de probar; de lo contrario, esas pruebas unitarias nunca se escribirán =)
Escribir un bosquejo aproximado de lo que quiere que haga su código y qué partes tendrá su código mejora en gran medida la forma en que su código no crece por cualquier problema parcial que aborde, pero crece para llenar los vacíos en un plan que hizo de antemano. El lápiz y el papel funcionan, al igual que algunos archivos .txt simples.
La respuesta está trabajando con interfaces, eso es proporcionar un nivel de abstracción que te ayudará más adelante.
Mi metodología para el desarrollo: 1. Lea el requisito 2. ¿Prefiere el diseño de alto nivel en UML 3. escribir interfaces? Este es el diseño de detalle, para casi cualquier clase debe tener interfaz y usar solo referencias de interfaz, por lo que la clase sin interfaz es clase privada. 4. escribir la prueba de unidad para cada clase 5. implementar el código.
Además, no crees funciones de más de 20 líneas. no crees clases de más de 200 líneas.
modifique su código