Como líder del equipo de más de 10 desarrolladores, me gustaría promover la reutilización del código. Hemos escrito mucho código, muchos de ellos son repetitivos en los últimos años. El problema ahora es que muchos de estos códigos son simplemente duplicados de algún otro código o una ligera variación de ellos.
He comenzado el movimiento (discusión) sobre cómo convertir el código en componentes para que puedan reutilizarse para futuros proyectos, pero el problema es que me temo que los nuevos desarrolladores u otros desarrolladores que ignoran los componentes simplemente seguirán adelante y escribir lo suyo
¿Hay alguna forma de recordarles a los desarrolladores que reutilicen los componentes / mejoren la documentación / contribuyan al componente subyacente en lugar de duplicar el código existente y modificarlo o simplemente escribir el suyo propio?
¿Cómo hacer que los componentes sean fácilmente detectables, fácilmente utilizables para que todos lo usen?
Creo que cada desarrollador sabe sobre el beneficio de los componentes reutilizables y quiere usarlos, es solo que no sabemos cómo hacerlos reconocibles. Además, los desarrolladores, cuando escriben código, saben que deben escribir código reutilizable, pero carecen de la motivación para hacerlo.
fuente
Respuestas:
Necesita documentación, una adecuada. Debería ser fácil de encontrar y navegar. También necesitas disciplina. Si ya hay una solución provista en sus bibliotecas de códigos reutilizables, pero el desarrollador elige usar su propia solución (sin ninguna razón adecuada), debe revertir su solución y decirle que use la solución existente.
También estoy de acuerdo con el comentario de Euphoric a la pregunta. A menudo es imposible reutilizar cualquier cosa entre diferentes proyectos (por lo general, todas las operaciones CRUD tienen el mismo aspecto, pero generalmente no se pueden reutilizar).
fuente
Además de los factores ya mencionados "documentación", "fácil de encontrar y navegar", "disciplina" y "revisión de código"
el código reutilizable debe ser
sin los dos últimos elementos, es mucho más fácil usar "copia y herencia pasada" que no queremos.
fuente
Creo que la mejor manera de hacer que reutilicen el código es la motivación. Si pones los componentes reutilizables en proyectos adicionales, como sugirió Euphoric, pon mucho esfuerzo en ello. Donde trabajo, realizamos un proyecto que ejecuta un conjunto de interfaces predefinidas en planes de ejecución configurables y proporciona algunos servicios (por ejemplo, diferentes clases para DB_interaction, un servicio FTP, ...). El proyecto es un gran éxito, porque nuestros desarrolladores realmente quieren usar el micro-marco, ya que les está ahorrando mucho tiempo para escribir código repetitivo para proyectos similares. Lo mismo es para las bibliotecas de utilidades para listas, cadenas, etc., pero en este caso desearía usar las existentes una vez. (¿Por qué reinventar el weel?)
Conclusión: permita que sus desarrolladores experimenten los beneficios de componentes reutilizables bien probados. Pero también estoy de acuerdo con la respuesta de Andrzej Bobak: muchas cosas no son reutilizables, porque son similares, pero no iguales.
fuente
Esto va a ser difícil, porque a la gente le gusta escribir código nuevo para componentes simples y les gusta hacerlo a su manera. Es mucho más difícil aprovechar una solución existente y extenderla, que escribir una implementación completamente nueva con los nuevos requisitos. Lo que debe hacer, como se ha dicho, es iniciar un proceso de revisión de código entre el equipo para ayudar a identificar situaciones en las que los componentes existentes deberían haberse utilizado / extendido en lugar de uno nuevo.
También debe mantener una documentación muy buena y exhaustiva para que las personas puedan consultarla y encontrar fácilmente lo que necesitan. Si la documentación está incompleta o no está sincronizada con la información real, las personas no estarán motivadas para buscarla o mejorarla.
Como líder del equipo, también debe alentar a las personas a preguntarse si existe un componente similar antes de crear el suyo propio y dirigirlos a la documentación para que puedan buscarlo. Seguro que el proceso de revisión del código lo detectará si alguien omitió un componente existente, pero ¿qué pasa si ya ponen 10 horas de desarrollo en su propia implementación? Debe evitar estas situaciones haciendo cumplir un buen comportamiento de investigación en el equipo.
fuente
Hemos enfrentado este problema en un gran proyecto en el que estoy trabajando actualmente. Hemos tenido cierta rotación de desarrolladores en los últimos meses, también es una base de código bastante grande e incluso los que han estado en el proyecto desde el principio no saben cada centímetro de él.
Si bien el código a menudo está bien escrito y dividido en partes pequeñas con responsabilidades únicas y la documentación está ahí, es bastante fácil pasar por alto algo que se ha hecho. Las convenciones de nomenclatura consistentes ayudan mucho porque es fácil buscar algo en cualquier IDE. La documentación puede ser completa, pero a medida que crece, es un poco difícil leerla.
Una cosa que hicimos que, en mi opinión, mejoró enormemente la situación fue la introducción de algo que llamamos conversaciones Lightning . Cada vez que alguien escribe un código que él o ella cree que el equipo debería conocer, se organiza una breve presentación (generalmente de 5 a 15 minutos). Intentamos hacer esto una vez por semana. Los temas tienden a variar, desde nuevas características y formas de manejar problemas complejos que han surgido recientemente, pasando por enfoques de prueba / codificación, componente reutilizable, hasta charlas sobre los fundamentos de la aplicación y su refactorización.
Ciertos temas se mencionan en conversaciones similares en toda la empresa. Hemos encontrado una manera bastante eficiente de estimular el intercambio de conocimientos. Es mucho más fácil ver y recordar una breve presentación y saber dónde buscar documentación adicional o a quién dirigirse para obtener ayuda que participar en sesiones de capacitación muy largas y raramente celebradas o simplemente sentarse allí, leer los documentos de principio a fin.
Las conversaciones a nivel de toda la empresa fueron lo primero. Acabamos de adoptar este enfoque para compartir conocimientos específicos del proyecto y creo que está funcionando bastante bien.
La programación en pareja también hace que la circulación del conocimiento sea mucho más rápida.
fuente
Creo que en realidad son dos preguntas en una: intentaré responder a ambas.
1) ¿Cómo reducimos el código duplicado en una base de código?
Ayuda a recordarnos el beneficio de hacer esto: da como resultado menos errores debido a la lógica comercial duplicada y se necesita mantener menos código. La mejor manera de evitar que esto suceda es a través de la comunicación, como se menciona en las otras respuestas. Estoy totalmente de acuerdo con la recomendación de usar revisiones de código con la advertencia adicional de que debe compartir las responsabilidades de revisión de código por igual para difundir adecuadamente el conocimiento. También debe usar stand-ups diarios para que los desarrolladores a menudo reconozcan cuando alguien está tratando de resolver un problema para el que existe un código útil existente. También debe considerar el emparejamiento de código, ya que aumenta el intercambio de conocimientos y ayuda a mantener a los programadores disciplinados.
También recomendaría que sus desarrolladores estén lo más cerca posible, preferiblemente en la misma habitación. Con muchas pizarras y espacios compartidos. Luego envíelos a comer juntos. Cuanto más se "unan" sus desarrolladores, mejor se comunicarán entre sí.
No estoy de acuerdo con la recomendación de usar un wiki o similar al código del documento. No importa cuán disciplinados sean los desarrolladores, la documentación se derivará del código original. Un enfoque más efectivo sería el uso de la especificación mediante pruebas de estilo de ejemplo. Estos documentan el código de una manera que deja en claro cómo debe usarse y sus pruebas fallarán si alguien cambia el código sin cambiar los ejemplos.
Ya tiene una gran base de código con muchos códigos duplicados, por lo que probablemente debería trabajar para refactorizar esto. Puede ser difícil encontrar código duplicado que no haya sido cortado y pegado. Entonces, en lugar de hacerlo, le sugiero que analice su historial de cambios. Busque archivos que a menudo cambian al mismo tiempo. Esto probablemente indicará problemas con la encapsulación si no indica un código duplicado real y vale la pena limpiar de todos modos. Si también puede analizar su historial de corrección de errores en relación con los cambios en su código, puede encontrar puntos de acceso específicos donde las correcciones son a menudo necesarias. Analice estos puntos de acceso y probablemente encontrará que muchos de ellos se deben a una lógica comercial duplicada que un desarrollador solo ha cambiado en un lugar sin darse cuenta de que necesita cambiar dos veces.
2) ¿Cómo debemos enfocarnos en hacer widgets, componentes, bibliotecas, etc. compartidos que luego puedan usarse en otros proyectos ?
En este caso, no debería intentar ajustar la lógica de negocios, sino compartir código de marco útil. Esto puede ser un equilibrio complicado ya que el costo de crear y mantener un conjunto de componentes compartidos puede ser bastante grande y puede ser difícil predecir en qué casos vale la pena hacerlo. El enfoque que sugeriría aquí es una regla de tres strikes. No se preocupe por escribir un código similar dos veces, pero cuando necesite hacerlo por tercera vez, refactorícelo en un componente compartido. En este punto, puede estar razonablemente seguro de que será útil y tiene una buena idea de los requisitos más amplios para el componente. Obviamente, la comunicación entre desarrolladores es vital aquí.
Considere crear la mayor cantidad posible de código abierto de sus componentes compartidos. No es una lógica de negocios, por lo que no le dará a sus competidores muchas ventajas, pero significa que obtendrá revisores y mantenedores adicionales de forma gratuita.
fuente
IMMO la clave no es documentación ni herramientas, la clave es COMUNICACIÓN. Más de 10 desarrolladores no son muchas personas, algunas cosas que mejoran esta comunicación:
programación en pareja: con dos personas hay más cambios que uno de los dos sabe que el problema ya está resuelto en otra parte del proyecto y lo reutiliza.
Propiedad del código colectivo: toda la gente trabaja con las diferentes partes de los sistemas, de esta manera es mucho más fácil que sepan que algo ya se ha hecho en otra parte del proyecto, para mí esta es una práctica fundamental en un equipo.
Dedique tiempo al trabajo de proyectos horizontales: por ejemplo, un viernes o dos en un mes, y los desarrolladores en este momento pueden trabajar en sus propios proyectos que tengan cierta aplicabilidad en el proyecto de su empresa. De esta forma, los desarrolladores pueden escribir bibliotecas y componentes reutilizables, a veces su código que ya existe pero necesita limpieza y documentación.
Haga charlas y talleres: reserve un tiempo para charlas y talleres de desarrolladores, los desarrolladores pueden hablar sobre sus bibliotecas o tal vez usted pueda hacer talleres de refactorización y tomar un código duplicado y eliminar la duplicación creando un componente reutilizable.
La documentación probablemente sea necesaria, pero es solo una pequeña parte de lo que realmente necesita: mejorar la comunicación dentro de su equipo.
fuente
¿Qué pasa con el uso de un motor de búsqueda local como Lucene (o algo más específico para el código fuente) para indexar su código? Cuando alguien comienza a escribir una nueva clase o una nueva función (por ejemplo) debe intentar (como política interna) un par de búsquedas antes de escribir su propio código. De esta manera puede evitar demasiadas comunicaciones y puede confiar en buenos comentarios, métodos y nombres de clases. Me encuentro haciendo esto con los motores de búsqueda de código abierto disponibles en Internet: no sé quién escribió qué o cuál es el nombre de un método o una clase, pero con un par de búsquedas o sinónimos siempre encuentro lo que necesito.
fuente
Necesita una herramienta que ayude a sus desarrolladores a hacerlo de una manera fluida. Si sus desarrolladores descubren cuánto tiempo pueden ahorrar reutilizando los fragmentos de código (no solo en términos de escribir el código, sino obviamente para garantizar la calidad, la integración, etc.), ayudados por una herramienta eficiente que es fácil de usar y directamente integrados en el entorno de desarrollo, ¡LE ORARÁN para que adopte dicha herramienta!
Tenga cuidado de que muchas veces la realización de bibliotecas para la reutilización de código no resulte en una gran ventaja (tienden a ser demasiado poderosas y grandes ...); en cambio, me gustaría centrarme en fragmentos simples, es decir, pocas líneas de código que resuelvan una tarea en particular de manera efectiva.
De esta manera, puede forzar el uso de pautas y mejores prácticas dando ejemplos reales que puedan ser utilizados directamente por los programadores.
Existen varias herramientas para la gestión de fragmentos, recomiendo esta: http://www.snip2code.com .
(Descargo de responsabilidad: soy uno de los fundadores de Snip2Code, y estaba, junto con mis cofundadores, en su misma mentalidad hace algún tiempo: es por eso que decidimos comenzar este proyecto, que recopila todas las características que yo mencionado anteriormente, es decir, compartir fragmentos entre un equipo, integración en IDEs como Visual Studio, Eclipse, IntelliJ, Notepad ++, etc.)
fuente