¿Cómo hacer que el código sea reutilizable?

Question

Cualquier código se puede reutilizar de una forma u otra, al menos si modifica el código. El código aleatorio no es muy reutilizable como tal. Cuando leo algunos libros, generalmente dicen que debe hacer explícitamente que el código sea reutilizable teniendo en cuenta también otras situaciones de uso del código. Pero cierto código tampoco debería ser una clase omnipotente para todos.

Me gustaría tener un código reutilizable que no tenga que cambiar más tarde. ¿Cómo hacer que el código sea reutilizable? ¿Cuáles son los requisitos para que el código sea reutilizable? ¿Cuáles son las cosas que definitivamente debe tener el código reutilizable y qué cosas son opcionales?

Answer 1

Consulte 10 consejos sobre cómo escribir código reutilizable para obtener ayuda.

1. Mantenga el código SECO. Seco significa "No te repitas".
2. Hacer que una clase / método haga solo una cosa.
3. Escriba pruebas unitarias para sus clases Y facilite la prueba de clases.
4. Elimine la lógica empresarial o el código principal de cualquier código marco
5. Trate de pensar de manera más abstracta y use las clases Interfaces y Abstract.
6. Código de extensión. Escriba código que pueda ampliarse fácilmente en el futuro.
7. No escriba código que no sea necesario.
8. Intente reducir el acoplamiento.
9. Sé más modular
10. Escribir código como si tu código fuera una API externa

Answer 2

Si adopta el enfoque de desarrollo basado en pruebas, su código solo se puede volver a utilizar como refactorizador en función de los próximos escenarios.

Personalmente, la refactorización constante produce un código más limpio que intentar adivinar para qué escenarios necesito codificar una clase en particular.

Answer 3

Más que nada, la facilidad de mantenimiento hace que el código sea reutilizable.

La reutilización rara vez es un objetivo valioso en sí mismo. Más bien, es un subproducto de la escritura de código que está bien estructurado, es fácil de mantener y útil.

Si se propone crear código reutilizable, a menudo se encuentra tratando de tener en cuenta los requisitos de comportamiento que podrían ser necesarios en futuros proyectos. No importa cuán bueno se vuelva en esto, encontrará que cumple estos requisitos de protección contra el futuro incorrectamente.

Por otro lado, si comienza con los requisitos básicos del proyecto actual, encontrará que su código puede ser limpio, ajustado y elegante. Cuando trabaje en otro proyecto que necesite una funcionalidad similar, naturalmente adaptará su código original.

Sugiero buscar las mejores prácticas para el lenguaje / paradigma de programación elegido (p. ej., Patrones y SOLID para los tipos Java / C #), la literatura de programación Lean / Agile y (por supuesto) el libro "Code Complete". . Comprender las ventajas y desventajas de estos enfoques mejorará su práctica de codificación sin fin. Todo su código se volverá reutilizable, pero 'por accidente', en lugar de por diseño.

Además, vea aquí: Escritura de código mantenible

Answer 4

Para la mayoría de las definiciones de "reutilizar", la reutilización de código es un mito, al menos en mi experiencia. ¿Puedes decir que tengo algunas cicatrices de esto? :-)

Por reutilización, no me refiero a tomar los archivos fuente existentes y enviarlos hasta que un nuevo componente o servicio se caiga. Me refiero a tomar un componente o servicio específico y reutilizarlo sin alteración.

Creo que el primer paso es tener una mentalidad de que tomará al menos 3 iteraciones para crear un componente reutilizable. ¿Por qué 3? Debido a que la primera vez que intenta reutilizar un componente, siempre descubre algo que no puede manejar. Entonces tienes que cambiarlo. Esto sucede un par de veces, hasta que finalmente tiene un componente que al menos parece ser reutilizable.

El otro enfoque es hacer un diseño caro y prospectivo. Pero entonces el costo es todo por adelantado, y los beneficios (pueden) aparecer en el futuro. Si su jefe insiste en que el cronograma actual del proyecto siempre domina, entonces este enfoque no funcionará.

Answer 5

Escribirás varios módulos (partes) cuando escribas un proyecto relativamente grande. El código reutilizable en la práctica significa que tendrá que crear bibliotecas que otros proyectos que necesiten la misma funcionalidad pueden usar.

Entonces, debe identificar los módulos que se pueden reutilizar, para eso

1. Identifique la competencia central de cada módulo. Por ejemplo, si su proyecto tiene que comprimir archivos, tendrá un módulo que manejará la compresión de archivos. NO haga que haga más que UNA COSA . Una sola cosa.

2. Escriba una biblioteca (o clase) que maneje la compresión de archivos, sin necesitar nada más que el archivo a comprimir, la salida y el formato de compresión. Esto desacoplará el módulo del resto del proyecto, lo que le permitirá (re) utilizarlo en una configuración diferente.

3. No es necesario que sea perfecto la primera vez, cuando reutilice la biblioteca, probablemente encontrará fallas en el diseño (por ejemplo, no lo hizo lo suficientemente modular como para poder agregue nuevos formatos de compresión fácilmente) y puede corregirlos la segunda vez y mejorar la reutilización de su módulo. Cuanto más lo reutilices (y arregles los defectos), más fácil será volver a utilizarlo.

Lo más importante a considerar es el desacoplamiento, si escribes código, la reutilización es la primera víctima.

Deje todo el estado o contexto necesarios fuera de la biblioteca. Agregue métodos para especificar el estado de la biblioteca.

Answer 6

La orientación a objetos le permite refactorizar el código en superclases. Este es quizás el tipo de reutilización más fácil, económico y efectivo. La herencia de clase ordinaria no requiere pensar mucho en `` otras situaciones ''; no tienes que construir "omnipotente" código.

Más allá de la simple herencia, la reutilización es algo que encuentras más de lo que inventas. Encuentra situaciones de reutilización cuando desea reutilizar uno de sus propios paquetes para resolver un problema ligeramente diferente. Cuando desee reutilizar un paquete que no se ajuste con precisión a la nueva situación, tiene dos opciones.

1. Cópialo y arréglalo. Ahora tiene que usar paquetes casi similares, un error costoso.

2. Haga que el paquete original sea reutilizable en dos situaciones.

Solo haz eso para reutilizarlo. Nada mas. Demasiado pensar en el "potencial" reutilizar e indefinido " otras situaciones " puede convertirse en una pérdida de tiempo.

Answer 7

Otros han mencionado estas tácticas, pero aquí están formalmente. Estos tres te llevarán muy lejos:

• Adhiérase a Responsabilidad única Principio : garantiza que su clase solo "haga una cosa", lo que significa que es más probable que sea reutilizable para otra aplicación que incluya esa misma cosa.
• Adhiérase al Liskov Principio de sustitución : garantiza que su código '' haga lo que se supone sin sorpresas '', lo que significa que es más probable que sea reutilizable para otra aplicación que necesite hacer lo mismo.
• Adhiérase al Principio abierto / cerrado : garantiza que su código se pueda hacer comportarse de manera diferente sin modificar su fuente, lo que significa que es más probable que sea reutilizable sin modificación directa.

Answer 8

Para agregar a los elementos mencionados anteriormente, diría:

• Haga que esas funciones sean genéricas que necesita reutilizar
• Use archivos de configuración y haga que el código use las propiedades definidas en files / db
• Factorice claramente su código en tales funciones / clases que proporcionen una funcionalidad independiente y puedan usarse en diferentes escenarios y defina esos escenarios usando los archivos de configuración

Answer 9

Agregaría el concepto de " Composición de clase sobre herencia de clase " (que se deriva de otras respuestas aquí). De esa manera, el "compuesto" al objeto no le importa la estructura interna del objeto del que depende, solo su comportamiento, lo que conduce a una mejor encapsulación y una capacidad de mantenimiento más fácil (pruebas, menos detalles de los que preocuparse). En lenguajes como C # y Java, a menudo es crucial ya que no existe una herencia múltiple, por lo que ayuda a evitar el infierno del gráfico de herencia que podría tener.

Answer 10

Como se mencionó, el código modular es más reutilizable que el código no modular.

Una forma de ayudar hacia el código modular es usar encapsulación, vea la teoría de encapsulación aquí: http://www.edmundkirwan.com/

Ed.

Answer 11

Evite reinventar la rueda. Eso es. Y eso por sí mismo tiene muchos beneficios mencionados anteriormente. Si necesita cambiar algo, simplemente cree otra pieza de código, otra clase, otra constante, biblioteca, etc., lo ayudará a usted y al resto de los desarrolladores a trabajar en la misma aplicación.

Answer 12

Comentario, en detalle , todo lo que parece ser confuso cuando vuelva al código la próxima vez. Los comentarios excesivamente detallados pueden ser un poco molestos, pero son mucho mejores que los comentarios dispersos, y pueden ahorrarle horas de tratar de descubrir WTF que estaba haciendo la última vez.