2008-11-06 14 views
37

Cualquier código puede reutilizarse 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 debes volver a usar explícitamente el código teniendo en cuenta también otras situaciones de uso del código. Pero cierto código tampoco debería ser una clase omnipotente que hace cosas.¿Cómo se hace el código reutilizable?

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

+1

Una palabra de advertencia: "código reutilizable que no tengo que cambiar más tarde" no es necesariamente algo que desea esforzarse. Cambiar tu código no es intrínsecamente negativo. Adoptar la refactorización a veces puede ser muy productivo. Entonces, ¿por qué exactamente quieres que tu código sea reutilizable? – bzlm

+0

Seguro que todos los códigos se pueden mejorar en el futuro, si está preparado. Pero cuando hago código reutilizable, espero que pueda usarlo más tarde sin necesidad de preocuparme por las cosas. – Silvercode

+0

"Código aleatorio" ?? – naught101

Respuesta

51

Consulte 10 tips on writing reusable code para obtener ayuda.

  1. Guarde el código DRY. Seco significa "No repetir".
  2. Haz que una clase/método haga una sola cosa.
  3. Escribir pruebas unitarias para sus clases Y facilitar el control de clases.
  4. Elimine la lógica de negocio o el código principal de cualquier código de estructura
  5. Intente pensar de forma más abstracta y utilice clases de Interfaces y Resumen.
  6. Código para la extensión. Escriba un código que pueda extenderse 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 al igual que su código es una API externa
+2

Esto se concentra en las tácticas. Pero las tácticas sin una buena estrategia son solo movimientos sin progreso. Primero necesita crear un plan sólido para su reutilización y luego venderlo a la gerencia superior. – RoadWarrior

+0

# 2 es genial. "Haz una cosa y hazla bien". Si las funciones/métodos son realmente autónomos, puede copiarlos en otros proyectos según sea necesario. # 6 es más difícil de entender, y creo que es probablemente algo que podría ampliarse para llenar un libro completo (y probablemente lo haya hecho) ... – naught101

+1

Para la serie "Por último pero no menos importante". Por experiencia personal, uso para desarrollar todo lo que puedo siguiendo la 10ma regla. En la aplicación MVC, mis controladores devuelven solo un JSON. La vista correcta llamará a ese servicio y construirá la página web. De esta forma, puedo exportar mi aplicación para una aplicación móvil, por ejemplo, o un cliente independiente, etc. –

12

Si se toma el enfoque de desarrollo basado en pruebas, entonces su código sólo se vuelve reutilizable como su refactor basa en los próximos escenarios.

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

3

Escribirá varios módulos (partes) al escribir un proyecto relativamente grande. En la práctica, el código reutilizable significa que tendrá crear bibliotecas que otros proyectos que necesitan esa misma funcionalidad pueden usar.

Por lo tanto, usted tiene que identificar módulos que pueden ser reutilizados, para que

  1. Identificar 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. Do NOT hazlo más de ONE THING. Una sola cosa.

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

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

Lo más importante a tener en cuenta es el desacoplamiento, si escribe la reutilización de código estrechamente acoplado es la primera víctima.

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

+0

Me gusta la idea de la biblioteca. Entonces está claro, cuando el código reutilizable está en la biblioteca. – Silvercode

1

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

  • hacer esas funciones genéricas que debe volver a usar
  • archivos de configuración y uso que el código utilizan las propiedades definidas en los archivos/db
  • factorizar claramente su código en tales funciones/clases que los que proporcionan una funcionalidad independiente y se puede utilizar en diferentes escenarios y definir los escenarios de uso de los archivos de configuración
1

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

9

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

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

Si se establece para hacer código reutilizable, a menudo se encuentra tratando de tener en cuenta los requisitos de comportamiento que pueden ser necesarios en los proyectos futuros. No importa qué tan bueno se convierta en esto, descubrirá que tiene estos requisitos de protección contra el futuro equivocados.

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 está trabajando en otro proyecto que necesita una funcionalidad similar, naturalmente adaptará su código original.

Sugiero consultar las mejores prácticas para el lenguaje/paradigma de programación elegido (por ejemplo, Patrones y SOLID para tipos Java/C#), la literatura de programación Lean/Agile y (por supuesto) el libro "Código completo" . 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.

También, ver aquí: Writing Maintainable Code

1

Como se ha mencionado, el código modular es más reutilizables que el código no modular.

Una forma de ayudar a modular el código es utilizar la encapsulación, véase la teoría encapsulación aquí: http://www.edmundkirwan.com/

Ed.

4

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 demasiado en "otras situaciones"; no tiene que crear código "omnipotente".

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

  1. Cómprelo y soluciónelo. Ahora tiene paquetes casi similares, un error costoso.

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

Haga eso para su reutilización. Nada mas. Demasiado pensar en la reutilización "potencial" y en "otras situaciones" indefinidas puede convertirse en una pérdida de tiempo.

6

Para la mayoría de las definiciones de "reutilización", 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 de origen existentes y superarlos hasta que se caiga un nuevo componente o servicio. Me refiero a tomar un componente o servicio específico y reutilizarlo sin alteración.

Creo que el primer paso es entrar en la mentalidad de que se necesitarán al menos 3 iteraciones para crear un componente reutilizable. ¿Por qué 3? Porque la primera vez que intenta volver a utilizar un componente, siempre descubre algo que no puede manejar. Entonces debes cambiarlo. Esto sucede un par de veces, hasta que finalmente tienes un componente que al menos parece ser reutilizable.

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

3

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

  • se adhieren a la Single Responsibility Principle - que asegura que su clase sólo "hace una cosa", lo que significa que es más probable es que será reutilizable para otra aplicación que incluye la misma cosa.
  • Adhiérase a Liskov Substitution Principle - asegura que su código "hace lo que se supone sin sorpresas", lo que significa que es más probable que sea reutilizable para otra aplicación que necesite lo mismo.
  • Adhiérase a Open/Closed Principle - garantiza que su código se comporte de forma diferente sin modificar su origen, lo que significa que es más probable que sea reutilizable sin modificación directa.
1

Evite reinventar la rueda. Eso es. Y eso por sí solo tiene muchos beneficios mencionados anteriormente. Si necesitas cambiar algo, entonces simplemente creas otro código, otra clase, otra constante, biblioteca, etc. Te ayuda a ti y al resto de los desarrolladores trabajando en la misma aplicación.

0

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

4

Una gran manera de hacer que el código reutilizable sería el uso de bits:

https://github.com/teambit/bit

Fue construido con la idea de hacer la reutilización de código administrado tan fácil como copiar y pegar.

Bit básicamente mata la sobrecarga de los administradores de paquetes. Le permite "marcar" cualquier código en cualquier proyecto, aislarlo (incluidas las dependencias) sin cambiar el código y ponerlo a disposición de cualquier otro proyecto (utilizando los gestores de paquetes o el propio Bit), todo sin dividir su base de código en absoluto.

Nos permite extraer fácilmente componentes de códigos reutilizables (UI, backend ...) de nuestro código y usarlos en cualquier lugar que deseemos en proyectos y aplicaciones. También son fáciles de mantener y están bien organizados, ya que Bit proporciona cambios de código de 2 vías de cualquier proyecto.

No dude en echar un vistazo y probarlo, Espero que lo encuentre útil.

0

2 más cosas a tener en cuenta:

  1. Modularidad - aquí es un gran mensaje por Addi Osmani.

  2. Herramientas - utilizamos Bit para organizar y compartir código reutilizable.

Goodluck!

Cuestiones relacionadas