code-reuse - tag - html codes list

¿Qué técnicas usas para maximizar la reutilización del código? (6)

Refactor sin piedad y esperar lo mejor.

Actualización (4 años después y con suerte más sabia)

Como el comentario de S.Lott dice: Presta atención a Naming. Difunde la palabra a todos los "committers" en el equipo. Los buenos nombres hacen que las cosas se puedan buscar y, por lo tanto, reduce la duplicación.
Tenga UNA forma de hacer algo y mantenerlo ACCESIBLE y BÚSQUEDA.
Escriba el código para el programador promedio (LCD). No sea inteligente donde lo simple sea suficiente. (Eso incluye la compulsión de hornear zapatos con patrón de diseño y los desórdenes relacionados)
Adopte un conjunto común de convenciones, estilos, pautas, estándares, etc. temprano. Asegure la aceptación y, por lo tanto, el cumplimiento dentro del equipo. (¡Esto significa que todos usan las pestañas (o espacios)!). No importa lo que elija, el objetivo es que el código se vea coherente
Tener un portero (respetado por el equipo), que observa todos los registros de banderas rojas.
Escriba el código test-first / outside-in. Por lo general, esto asegura que tu código sea utilizable por múltiples clientes. (Ver la viñeta del GOOS sobre la independencia del contexto)

Hace algunos años me contaron acerca de un estudio sobre la reutilización de código. Aparentemente, se descubrió que, en promedio, los programadores tienen una ventana de 7 minutos cuando buscan el código para reutilizar. Si no encuentran el código que se adapte a sus necesidades dentro de esa ventana, escribirán el suyo.

Esto se presentó en el contexto de la necesidad de administrar cuidadosamente el código para su reutilización para garantizar que pueda encontrar lo que necesita dentro de la ventana.

¿Cómo maneja usted (individuos y organizaciones) su fuente para que sea más fácil de reutilizar? ¿Mantiene específicamente una biblioteca de reutilización? Y si es así, ¿cómo lo indexa para maximizar su tasa de acierto?

Intenta usar TDD si no lo eres ya, es mi respuesta inicial.

Creo que el uso de TDD es una gran manera de mantener el acoplamiento de código bajo, entre otros beneficios. Si bien eso no impide que el mismo comportamiento se implemente dos veces, hace que sea mucho más fácil cuando identifica un área en la que puede eliminar la duplicación.

Otro beneficio, TDD tiene un paso para eliminar dupication (refactoring) como parte del ciclo.

Además, las pruebas forman parte de la documentación de los códigos, lo que facilita la identificación del comportamiento duplicado.

Una pregunta compleja:

Algunas partes del código se pueden generalizar como bibliotecas o API. Tenemos una biblioteca común que se mantiene actualizada con soluciones a problemas comunes. Típicamente: validación, almacenamiento en caché, clases de acceso a datos, registro, etc.
Algunas partes son específicas de la aplicación. No se pueden generalizar fácilmente. Los convertimos en HowTos y hacemos presentaciones internas. El código también se recicla mediante el uso de un SCM fácilmente navegable (en nuestro caso, SVN).
También tenemos herramientas que generan código que una mano no se puede reciclar, por otra, siempre es similar (piense en llamar a un procedimiento almacenado).
La programación en pares también es una forma útil de difundir el conocimiento de las soluciones existentes. Usamos eso cuando sea posible o apropiado.
La última técnica es la matrícula. Cada codificador tiene un tutor al que hacer referencia. Dado que los tutores son pocos, hay mucho intercambio entre ellos y este conocimiento se puede difundir de arriba hacia abajo.

La organización es clave. Si espacios de nombres e intellisense están disponibles, la función correcta se puede restringir y finalmente encontrar. Si no encuentran exactamente lo que quieren, es posible que encuentren algo cercano o relacionado. El código que simplemente se mezcla en un solo grupo lo hace fácil de encontrar, pero las personas nunca encontrarán el método que desean lo suficientemente rápido.

La consistencia es también crítica, tanto con el nombre como con la ubicación. Si decide cambiar su estilo en algún momento del proyecto, retroceda y cambie todo para que se ajuste a ese estilo. Puede ser un proceso muy largo y aburrido, pero es mejor que tratar de tener que utilizar una biblioteca incoherente.

Tener un marco que sea apoyado activamente.
Conozca la base de código existente / haga que los otros desarrolladores conozcan la base de código. Si su grupo / compañía es lo suficientemente grande, tenga a alguien que conozca la base de códigos y se le puede pedir orientación.
Documento, documento, documento. El código no documentado es inútil para su reutilización porque lleva demasiado tiempo entender su funcionamiento interno.
Tener buenas interfaces. Tipos fáciles, estructuras o clases fáciles. Cuanto más complicado es algo, menos se usará en otro proyecto.
Optimizar y depurar código reutilizable. Los desarrolladores que experimenten errores en el código de otras personas por enésima vez comenzarán a codificar el código ya existente de nuevo.

Perfile toda la aplicación y comience a refactorizar desde la sección más pesada del código. (80% del tiempo dedicado al 20% del código más usado)

Utilice una herramienta de generación de perfiles que tenga la capacidad de identificar fugas de memoria, llamadas repetidas, llamadas prolongadas, memoria no actualizada, recursos no expuestos, etc.

Por regla, el código nuevo siempre usa las mejores prácticas.