c# - refactorizacion - Código de refactorización: ¿Cuándo hacer qué?
ejemplos de refactorizacion de codigo (10)
Desde que comencé a usar .NET, recién he estado creando clases de ayuda o clases parciales para mantener el código ubicado y contenido en sus propios pequeños contenedores, etc.
Lo que quiero saber es cuáles son las mejores prácticas para hacer que los códigos sean tan limpios y pulidos como sea posible.
Obviamente, el código limpio es subjetivo, pero me refiero a cuándo usar cosas (no cómo usarlas), como polimorfismo, herencia, interfaces, clases y cómo diseñar clases de manera más adecuada (para hacerlas más útiles, no solo decir '' DatabaseHelper '', como algunos consideraron esta mala práctica en el código huele wiki ).
¿Hay algún recurso que pueda ayudar con este tipo de toma de decisiones?
Sin tener en cuenta que ni siquiera he comenzado un curso de ingeniería de software o CS, y que un recurso de enseñanza es bastante limitado en la vida real.
Acabo de obtener una copia de Code Complete y descubrí que había una sección sobre esto.
Aunque todavía leeré el libro de respuestas aceptadas, lo que Code Complete me ha enseñado ha mejorado de forma espectacular la forma en que pienso sobre el diseño de clases.
Antes de hoy, no sabía lo que era un ADT (tipo de datos abstractos), y ahora sé cómo desarrollar clases que se adhieran a la encapsulación.
Aquí hay una reseña en el punto de un libro llamado Clean Code .
El libro es aparentemente un poco seco pero muy bueno.
Echa un vistazo a los comentarios y el libro de Martin Fowler sobre Refactorización
Hay una página web dedicada a la refactorización en http://www.refactoring.com/ . Incluye muchas referencias a recursos adicionales sobre el tema del código de refactorización, así como una lista de correo para analizar los problemas relacionados con la refactorización.
Por último, pero no menos importante, hay un gran (y aún creciente) catálogo de refactorizaciones disponibles que se extiende más allá de lo que está escrito en el (muy recomendado) libro de refactorización de Martin Fowler.
Jeff Atwood hizo una buena publicación en el blog sobre la refactorización y el código de olores , es posible que desee comprobarlo.
El código de refactorización en .NET toma algún tiempo para grok. Necesita conocer algunos principios de diseño orientados a objetos (o técnicas de diseño ) para refactorizar de forma efectiva y mercilessly .
En resumen, usted refactoriza el código para eliminar olores de código y hacer los cambios más fáciles de hacer. Además, no exageres.
Mi regla de oro es dejar el código en una forma no peor que la que encontraste .
La idea es trabajar hacia lo mejor , sin tratar de lograr el resultado perfecto, o ir hasta el final.
Las refactorizaciones individuales a veces tienen un beneficio cuestionable y, como ejemplo extremo, podría argumentarse si m_Pi es un nombre mejor que m_PI . Sin embargo, la mayoría de las veces, una opción es más consistente y menos sorprendente, aunque no obviamente "mejor".
Una situación en la que normalmente me encuentro refactorizando automáticamente es antes de implementar una característica en un código.
A menudo hay algunos TODO que esperan ser alimentados, algunas inconsistencias o, a veces, una funcionalidad personalizada que últimamente ha adquirido un mejor soporte de biblioteca. Hacer estos cambios antes de implementar la solicitud de función real me da cierta comprensión del código y verifico la funcionalidad "anterior".
Otro punto es después de corregir errores. Después, entonces la antes-reproducción no se ve afectada, y la corrección de errores y la refactorización son dos confirmaciones separadas.
Recomendaría Domain Driven Design . Creo que los principios de YAGNI y AlwaysRefactor son dos simplistas. La vieja pregunta sobre el tema es ¿refactorizo "if (someArgument == someValue)" en una función o la dejo en línea?
No hay respuesta de sí o no. DDD aconseja refactorizar si la prueba representa una regla de negocios. La refactorización no es (solo) sobre la reutilización sino sobre aclarar las intenciones.
Una verdadera revelación para mí fue la refactorización: mejorar el diseño del código existente :
Con una capacitación adecuada, un diseñador de sistemas experto puede tomar un mal diseño y volver a trabajarlo en un código robusto y bien diseñado. En este libro, Martin Fowler le muestra dónde se pueden encontrar las oportunidades de refactorización, y cómo rehacer un diseño malo en uno bueno.
Me ayudó a refactorizar el código de forma eficiente y sistemática. También me ayudó mucho en las discusiones con otros desarrolladores, cuando su holy code debe ser cambiado ...
Trabajar eficazmente con Legacy Code es uno de los mejores libros que he visto sobre este tema.
No deje de lado el título del libro: en lugar de tratar la Refactorización como un concepto formal (que tiene su lugar), este libro tiene muchos consejos simples sobre "por qué no pensé en eso". Cosas como "pasar por una clase y eliminar cualquier método no directamente relacionado con esa clase y ponerlos en una diferente".
Por ejemplo, tiene una cuadrícula y un código para persistir en el diseño de esa cuadrícula. Probablemente pueda mover con seguridad el código persistente de diseño a una clase diferente.
- Vuelva a factorizar su código cuando está causando problemas. Cualquier problema lo hará: rendimiento, scallabillity, integración, mantenimiento, cualquier cosa que te haga pasar más tiempo cuando debas. No está roto, no lo arregles aunque no creas que esté limpio o que esté a la altura de los estándares modernos.
- No dedique demasiado tiempo a hacer el código perfecto. Nunca alcanzarás la perfección, pero podrías pasar mucho tiempo tratando de hacerlo. Recuerde la ley de rendimientos decrecientes.
- Dentro de un proyecto solo vuelva a factorizar el código cuando en realidad esté trabajando en la funcionalidad que depende de él. Es decir, si tiene una historia de usuario para las llamadas de iteración para "cambiar el mecanismo de carga" o "corregir el error en la carga del archivo", podría volver a factorizar el código de carga del archivo. Sin embargo, si su historia de usuario se trata de "actualizar el diseño de la interfaz de usuario de carga de archivos", no entre en la lógica comercial.