language agnostic - Reutilización del código: ¿Vale la pena?

language-agnostic code-reuse (18)

Creo que el mejor enfoque es intentar diseñar código con buenas interfaces y separación de responsabilidades entre clases sin preocuparse demasiado por la reutilización. Pero al menos si diseñas de esta manera estás dejando abierta la posibilidad de reutilización. Una buena regla general es preguntarse "si vuelvo a este código después de 3 meses, ¿lo entenderé y podría extenderlo si tuviera que hacerlo?"

OMI una de las peores prácticas en la industria es cuando un equipo recibe el visto bueno para irse y escribir su propio marco "reutilizable" ...

Todos escribimos clases y códigos reutilizables.

Tenemos en cuenta la configurabilidad para permitirnos reutilizar esta fantástica nueva clase una y otra vez.

Les decimos a nuestros jefes que pasar este tiempo extra ahora nos ahorrará tiempo y dinero más adelante.

Pero en realidad, para aquellos de nosotros que no escribimos bibliotecas de terceros, y dedicamos nuestro tiempo a trabajar en una aplicación como un todo, ¿cuántas veces esa clase en la que pasaste tiempo extra escribiendo para ser reutilizada realmente se reutiliza en otro proyecto? ?

¿Cuántas clases personalizadas tiene en su biblioteca que se usarán en más de un proyecto?

Estoy de acuerdo con usted en la medida en que no tiene sentido codificar de forma que la clase sea fácil de usar fuera de la aplicación actual. La mayoría si nosotros no hacemos esto y en los entornos empresariales no es necesario. Si otra aplicación necesita esta funcionalidad en una fecha posterior, la extracción y la divulgación del código se pueden realizar como parte de ese segundo proyecto, y es probable que la administración esté de acuerdo con este punto de vista.

Sin embargo, es una buena práctica hacer que su código sea reutilizable dentro de las restricciones de la aplicación actual. Refactorice su código para evitar la duplicación dentro de su ámbito de trabajo actual. De esta manera, es más fácil trabajar con él en una fecha posterior. No codifique tanto para reutilizar como para cambiar, el cambio es mucho más común.

Existe una diferencia entre la capacidad de configuración y la reutilización: la primera puede ser extremadamente útil en muchas situaciones diferentes, cuando el entorno cambia o lo que sea, lo que hace que las cosas se puedan configurar como yo lo entiendo, es principalmente un caso de separación de código y datos. eso es solo una buena práctica en realidad.

Diseñar para la reutilización solo es realmente útil si está creando algo que planea usar como biblioteca para múltiples proyectos. A medida que pasan los años, me he vuelto cada vez más consciente del principio de YAGNI y en estos días simplemente intento escribir un código limpio y robusto para la tarea en cuestión. Mi experiencia ha sido que si se va a reutilizar algo, es muy poco probable que prediga exactamente cómo será necesario reutilizarlo, por lo que es mucho mejor agregar solo el código que necesita por ahora. De esta forma, si necesita reutilizarlo en el futuro, puede agregar cosas nuevas que hagan exactamente lo que necesita sin tener que romper ninguna funcionalidad existente que haya escrito en el pasado, tratando de anticipar cómo podría necesitarla ahora.

Puede encontrar que después de hacer esto un par de veces tiene una biblioteca que es estable y robusta y no necesita que la cambie porque realmente hace todo lo que necesita, para mí es mucho más fácil permitir que eso suceda. ese camino evolutivo que perder demasiado tiempo adivinando sobre el futuro.

Gran pregunta!
Creo que "diseñar para reutilizar" es el camino equivocado. Me parece que el código que escribo para que funcione, limpio y bonito, es reutilizable. ¡El diseño real para reutilización solo ocurre la primera vez que el código se vuelve a usar!

Pasar tiempo de antemano tratando de hacer que algo sea reutilizable tiende a ser una pérdida de tiempo, porque nunca se sabe lo que tendrá que ser reutilizado.

Dicho esto, en mi trabajo tenemos una colección de bibliotecas (grandes, de 500 MB o más) que se reutiliza para casi todos los proyectos, en su mayoría de dominio específico.

Hay opiniones muy diferentes sobre qué hace que el código sea reutilizable. Diría que su tiempo pasó bien haciendo que el código sea claro y esté bien factorizado (es decir, separación entre responsabilidades).

Un beneficio adicional de esto es una mejor reutilización. El principal beneficio es hacer que el código sea más fácil de comprender, cambiar y depurar.

Para envolverlo No haga complejos esquemas de configuración, puntos de extensión y eventos solo para hacerlo reutilizable. Intente encontrar las piezas móviles correctas para que el código se pueda componer en respuesta a las nuevas necesidades.

Leppie escribió:

Mi regla general común es:
Si lo repites una vez, cópialo.
Si lo repite dos veces, refactorícelo

Y agregaría, asegúrese de que se agregue un comentario a ambas partes del código para indicar la duplicación en caso de que haya un error. No desea arreglarlo en una parte y no en la otra (BTDTGTT).

Robar

Me gusta el modelo LISP en el que continuamente amplías el idioma. Finalmente terminas con un lenguaje específico de dominio para tu dominio problemático. No es que realmente escriba ningún ceceo, pero en los idiomas que uso más a menudo --- Lua y C en este momento --- normalmente saco algo de un módulo y lo vuelvo a usar en lugar de clonarlo y modificarlo.

Para un programador de C, el ejemplo por excelencia de este enfoque es el libro de Dave Hanson C Interfaces and Implementations . Dave tomó todas las ideas reutilizables que tenía al escribir tres o cuatro compiladores y las puso todas en un libro --- y el software es gratis. Cosas fabulosas Ahora si escribo el código C y quiero usarlo una segunda vez, hago una interfaz en estilo Hanson. Algunas cosas que hice este término: matrices bidimensionales, matrices bidimensionales con bloqueo, mapas de bits bidimensionales, lectores y escritores para archivos pbmplus, etc. Con esta infraestructura en su lugar, fue fácil escribir un programa que había estado esperando durante años, que es eliminar los bordes negros de los escaneos de fotocopias de páginas de libros.

Así que estoy de acuerdo con quien haya dicho cuándo quieres volver a usarlo, sácalo, pero no antes.

Mi 2c es que la ética de la reutilización de código debe ser una cosa de la empresa, no solo una cuestión de proyecto. Esto significa que cuando comienzas un nuevo proyecto, la preocupación principal es "¿en qué otros proyectos puedo robar código para realizar este trabajo tan rápido y tan rápido como sea posible?".

Esto entrará en conflicto con la pregunta "¿cuál es el mejor (o el más moderno) lenguaje / herramienta para el trabajo?"

Las empresas que tienen este enfoque terminan con un grupo de ingenieros que pueden cambiar fácilmente de un proyecto a otro, porque el lenguaje, el marco y la base de código interno son consistentes.

La desventaja es que cambiar a un "nuevo" lenguaje o marco es mucho más difícil desde el punto de vista político, aunque deberá suceder en algún momento.

Mi regla general común es:

Si lo repites una vez, cópialo.
Si lo repite dos veces, refactorícelo.

No soy experto en metodología XP (ni en ninguna metodología), pero creo que el principio YAGNI podría aplicarse aquí.

Solo modifique el código para reutilizarlo cuando tenga que reutilizarlo.

Si estás seguro de que no vas a necesitarlo de nuevo, no te molestes. Ni siquiera si crees que podría ser útil. Refactorícelo cuando realmente lo necesite de nuevo ...

Sin embargo, no hacerlo reutilizable no es excusa para no hacerlo transparente. Cada vez que escribo código de la manera más transparente posible, siempre resulta ser 99% reutilizable ya ...

Una de las razones por las que SOA ha estado fallando, o no ha desaparecido aún, es que es difícil reutilizar un servicio: o bien es demasiado específico y no puede usarse en otro lugar, o es demasiado genérico (y generalmente muy complejo) y no satisface las necesidades de diferentes clientes.

Esto no es "reutilización del código", es "reutilización del servicio", pero hay algunos conceptos comunes.

Una vez que superas el nivel de los servicios técnicos, he visto muy poca reutilización real en el mundo real.

Si lo piensas, las razones son claras. Supongamos que la aplicación widget_bodger contiene el 90% de la funcionalidad que necesita de lo que simplemente agregaría la funcionalidad faltante a la aplicación.

O digamos que el negocio admiró una función de "bip" realmente genial en el widget_bodger y quería que se incorporara en la aplicación gernerate_executive_expenses. Ah resuse, podrías pensar, pero luego profundizas en el código y encuentras que la aplicación GEE es una de las aplicaciones más antiguas de la compañía, está escrita en C, debe ejecutarse en hardware altamente disponible y lo único que se puede determinar es el algoritmo básico .

A menudo, el código "reutilizable" es un código que se abstrae y se modulariza, y, para mí, el beneficio principal no es la reutilización, sino más bien el aumento de la capacidad de prueba. Porque cuando aísla y modulariza el código, generalmente se vuelve más comprobable. La reutilización es un efecto secundario conveniente pero a menudo no utilizado.

Y en otra nota, Juval Lowry aboga por la programación basada en interfaces, ya que sostiene que las interfaces son el único componente de la reutilización. Cualquier otra cosa tiene una funcionalidad implícita (difícil de reutilizar) mientras que las interfaces definen un contrato que es implícitamente reutilizable.

En mi humilde opinión, es probable que se reutilice cierto código con frecuencia, y tiene sentido prepararlo para su reutilización frecuente. Otro código no lo es, y probablemente no necesite desarrollarse más allá de resolver el problema inmediato.

Por supuesto, tenga en cuenta que decir la diferencia es NP-difícil. :)

Otro beneficio con la reutilización es que puede seguir fácilmente dónde pasan las cosas en la base de datos. si tiene un millón de líneas de código, puede tomar horas encontrar todos los lugares donde la aplicación se comporta de cierta manera. Con un IDE moderno, puede hacer clic en "buscar referencias" y encontrará, en un par de segundos, todos los lugares donde se utiliza su componente / método. Esto puede ser útil cuando desea agregar nuevas características, corregir errores o simplemente quiere aprender cómo funciona el sistema.

Al igual que otros carteles, han dicho que si va a copiar el código y volver a usarlo, se alegrará de haberlo hecho una vez que comience a depurar su código copiado.

Tenemos algunos, pero tenemos muchos más proyectos con la funcionalidad que usted desea pero que se hacen a su manera, por lo que la mayoría de las veces terminan canibalizando características de proyectos anteriores y reimpleándolos en su nuevo proyecto. Yo argumentaría que esto aún cuenta, todavía está obteniendo el beneficio de haber escrito el código antes, y todavía ahorra tiempo.

Además, descubrí que es solo la segunda vez que intentas usar la funcionalidad y resulta obvio dónde se encuentra la reutilización, y si tratas de generalizar algo de forma especulativa, casi siempre te equivocas y tienes que cambiarla la próxima vez.