code-reuse - example - html title attribute style

¿Cómo haces código reutilizable? (14)

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

Me gustaría tener un código reutilizable que no tenga que cambiar más tarde. ¿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?

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

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

Una forma de ayudar con el código modular es utilizar la encapsulación; consulte la teoría de la encapsulación aquí: http://www.edmundkirwan.com/

Ed.

La orientación a objetos le permite refactorizar códigos 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 encuentras más de lo que inventas. Encuentra situaciones de reutilización cuando quiere reutilizar uno de sus propios paquetes para resolver un problema ligeramente diferente. Cuando desee reutilizar un paquete que no se ajusta con precisión a la nueva situación, tiene dos opciones.

Cópialo y arréglalo. Ahora tiene paquetes casi similares, un error costoso.
Haga que el paquete original sea reutilizable en dos situaciones.

Solo haz eso para volver a usarlo. Nada mas. Demasiado pensar en la reutilización "potencial" y en "otras situaciones" indefinidas puede convertirse en una pérdida de tiempo.

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

Haga esas funciones genéricas que necesita reutilizar
Use los archivos de configuración y haga que el código use las propiedades definidas en files / db
Claramente factorice su código en tales funciones / clases que proporcionan funcionalidad independiente y pueden usarse en diferentes escenarios y definir esos escenarios usando los archivos de configuración

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

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

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. NO hagas que haga más de UNA COSA . Una sola cosa.
Escriba una biblioteca (o clase) que manejará la compresión de archivos, sin necesitar nada más que el archivo que se 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.
No es necesario hacerlo perfecto la primera vez, cuando realmente 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 del código fuertemente 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.

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.

Comente, en detalle , todo lo que parece que podría 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 pocos comentarios, y pueden ahorrar horas tratando de descubrir la WTF que estaba haciendo la última vez.

Si adopta el enfoque de Desarrollo basado en pruebas, su código solo se volverá a utilizar como su refactor en función de los escenarios futuros.

Personalmente, encuentro 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.

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 fuente existentes y superarlos hasta que caiga un nuevo componente o servicio. Me refiero a tomar un componente o servicio específico y reutilizarlo sin alterarlo.

Creo que el primer paso es tener una 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 diseño caro y 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á.

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

Adhiérase al principio de responsabilidad única : 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 lo mismo.
Adhiérase al Principio de Sustitución de Liskov : 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 lo mismo.
Adherirse al principio abierto / cerrado : garantiza que su código se comporte de forma diferente sin modificar su origen, lo que significa que es más probable que se pueda volver a utilizar sin modificación directa.

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

Mantenga el código SECO. Seco significa "No repetir".
Haga que una clase / método haga solo una cosa.
Escriba pruebas unitarias para sus clases Y facilite la prueba de clases.
Elimine la lógica comercial o el código principal de cualquier código de marco
Intenta pensar de manera más abstracta y usa interfaces y clases abstractas.
Código para la extensión. Escriba un código que pueda extenderse fácilmente en el futuro.
No escriba código que no sea necesario.
Intenta reducir el acoplamiento.
Sé más modular
Escribir código como si tu código fuera una API externa

Una excelente manera de hacer que los componentes sean reutilizables sería usar Bit:

https://github.com/teambit/bit

Es un sistema de administración de componentes de código abierto y de lenguaje independiente que creamos exactamente para este propósito.

Nos permite extraer componentes de código (web, reaccionar, serveride ...) fácilmente desde 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.

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

También hay un centro comunitario gratuito para componentes reutilizables (web, de reacción, del lado del servidor o prácticamente) para componentes de código abierto . Puede usarlo para sus propios componentes o buscar y compartir con otros. Aquí hay un ejemplo de componente de código abierto con licencia de MIT, llamado " array / diff ".

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 propone crear un código reutilizable, a menudo se encuentra tratando de tener en cuenta los requisitos de comportamiento que podrían requerirse en futuros proyectos. 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 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 "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.

También, mira aquí: Escribir un código de mantenimiento

2 más cosas a considerar:

Modularidad - aquí hay una gran publicación de Addi Osmani .
Herramientas: utilizamos Bit para organizar y compartir código reutilizable.

¡Buena suerte!