Cuando trabajo en código, enfrento muchos de los mismos desafíos que enfrentan mis compañeros de equipo, y he escrito algunas funciones y clases útiles, y ellos también. Si hay una buena comunicación, escucharé sobre algo genial que alguien armó, y seis meses después, cuando lo necesite, lo recordaré y llamaré a esa función, ahorrándome tiempo. Si no lo recuerdo, o si nunca lo supe, probablemente reinventaré la rueda.
¿Existe una práctica particular de documentar este tipo de cosas? ¿Cómo los haces fáciles de encontrar?
Si su equipo no tiene dicha documentación, ¿cómo puede saber si su rueda ya existe?
EDITAR:
Hasta ahora, todas menos una de las respuestas se ocupan de una situación ideal, así que permítanme resumir esas soluciones: documentación y comunicación; wikis, reuniones de pie, etc. Esas son cosas geniales, pero dependen de que los programadores tengan el tiempo (y las habilidades) para escribir la documentación y asistir a las reuniones y tomar notas y recordar todo.
La respuesta más popular hasta ahora (la de Caleb) es la única que podría ser utilizada por un programador que no es capaz de documentar y reunirse, y que solo hace una cosa: programar. La programación es lo que hace un programador, y sí, un gran programador puede escribir documentación, pruebas unitarias, etc., pero seamos sinceros, la mayoría de nosotros preferimos programar a documentar. Su solución es una en la que el programador reconoce el código reutilizable y lo saca a su propia clase o repositorio o lo que sea, y por el hecho de que está aislado, se vuelve fácil de encontrar y facilita la curva de aprendizaje para usarlo ... . y esto se logró mediante la programación.
En cierto modo, lo veo así: acabo de escribir tres funciones, y se me ocurre que alguien más debería saber sobre ellas. Podría documentarlos, escribirlos, anunciarlos en una reunión, etc., lo que puedo hacer, pero no es mi fortaleza, o ... puedo extraerlos a una clase, nombrarlo bien, hacer que funcionen como un cuadro negro y pegarlo donde van los archivos de otras clases. Luego, un breve correo electrónico anunciando que es fácil. Otros desarrolladores pueden escanear el código y comprenderlo mejor de lo que lo harían con una función aislada utilizada en un código que no entienden completamente: ese contexto se elimina.
Me gusta esto porque significa que tener un conjunto de archivos de clase bien nombrados, con métodos bien nombrados, es una buena solución que se logra mediante una buena programación. No requiere reuniones y suaviza la necesidad de documentación detallada.
¿Hay más ideas en este sentido ... para desarrolladores aislados y con poco tiempo?
fuente
Respuestas:
Bibliotecas Marcos. Control de versiones.
Si tiene código reutilizable, lo último que desea es que diferentes miembros del equipo copien el código fuente en su proyecto. Si lo hacen, lo más probable es que cambien un poco aquí y se ajusten un poco allí, y pronto tendrá docenas de funciones o métodos que tienen el mismo nombre pero que funcionan de manera un poco diferente. O, quizás más probablemente, el autor original continuará refinando el código para corregir errores, hacerlo más eficiente o agregar funciones, pero el código copiado nunca se actualizará. El nombre técnico para eso es un gran desastre .
La solución correcta es sacar esas cosas reutilizables de cualquier proyecto para el que lo construyó en primer lugar y ponerlo en una biblioteca o marco en su propio repositorio de control de versiones. Eso hace que sea fácil de encontrar, pero también desalienta hacer cambios sin tener en cuenta todos los demás proyectos que podrían estar utilizándolo. Puede considerar tener varias bibliotecas diferentes: una para código bien probado que ya no es probable que cambie, otra para cosas que parecen estables pero que no se han probado y revisado a fondo, una para las adiciones propuestas.
fuente
Un enfoque para eso es configurar un Wiki para ese propósito, y escribir algunos documentos de alto nivel sobre qué componentes reutilizables tiene, cómo resolvió un problema, etc.
La parte difícil es lograr que todos en su equipo mantengan constantemente esa Wiki. Pero cualquier otro tipo de documentación sufre el mismo problema.
Parte de su código también puede ser lo suficientemente bueno como para colocarlo en una biblioteca reutilizable. Esto también hace que sea más fácil encontrar el código nuevamente más tarde.
fuente
Estar en una empresa con 700 empleados, dentro de equipos que varían entre 2 y 20 personas, aquí está mi experiencia.
A nivel de equipo
Tenemos "reuniones standup" todos los días durante unos 15-20 minutos. Podemos compartir rápidamente conocimientos comunes como "Ayer hice esta función, es muy difícil".
También tenemos una wiki por proyecto. Lo que significa que podemos compartir información (técnica) sobre lo que se hace en el proyecto, incluidas las clases / funciones personalizadas que se incorporaron.
A nivel de agencia
A nivel de agencia, tenemos 4 herramientas:
A nivel de empresa
A nivel de empresa, es más organizado.
El wiki de "nivel de agencia" es en realidad parte del wiki de la compañía.
Y la wiki luego se divide en función de las tecnologías. Por lo tanto, cualquiera puede mejorarlo, buscarlo y, básicamente, darle vida a la wiki.
También hay listas de correo disponibles a las que podemos suscribirnos. Cualquier persona en la agencia puede suscribirse, y la mayoría de las personas siguen al menos una o dos tecnologías, en realidad la mayoría de las personas siguen 5-10 de ellas.
Y el VCS es, por supuesto, el mejor sistema para compartir código.
Conclusión
En resumen, no hay una solución clara. El intercambio de conocimientos siempre ha sido un gran problema, y probablemente lo seguirá siendo. Hay muchas soluciones para crear bases de conocimiento , y una probablemente podría ajustarse a su factura. Sin embargo, algunas personas están tratando de obtener una mejor KB ya que las soluciones actuales no siempre son muy inteligentes.
fuente
Bueno, todo se reduce a la comunicación.
Los Wiki son geniales y definitivamente debes instalar y usar uno. Una buena intranet interna para programadores es buena si la gente la lee y la actualiza, por lo que en realidad estás hablando de un problema de personas allí. Podría sugerir reuniones semanales de "actualización de equipo" en las que todos se reúnan y den una visión general de qué trabajo se está realizando. Los líderes tecnológicos (¡al menos!) Deberían reunirse y conversar sobre lo que cada equipo está haciendo. Las sesiones informales de "Brown Bag" son geniales, programelas a la hora del almuerzo y haga que la gente hable.
También necesita una forma de compartir código, empaquetarlo, versionarlo y distribuirlo. Las cosas serían más fáciles si tuviera un repositorio de código fuente realmente bien administrado, bien organizado en carpetas "comunes" y de proyecto.
Si no se está haciendo nada como esto, créelo con su jefe, explique cómo beneficiará a la compañía y sugiera un camino a seguir :)
fuente
Las sesiones de revisión de código pueden ayudar. Si su equipo se reúne regularmente para discutir lo que se desarrolló, entonces la persona que encontró una solución puede mostrar a los demás cómo usarla. Si alguien menciona un punto en el que se está aferrando, otros miembros del equipo podrían proponer un enfoque que aumente la reutilización de los componentes existentes.
fuente
La mejor manera de manejar algo así es tener una estructura de repositorio que tenga algunas convenciones simples para que yo sepa, como programador, si hay una función
doXYZ, más o menos dónde debería buscar esa función. Ya sea que esté utilizando espacios de nombres, directorios, módulos, complementos, paquetes, lo que sea, su código debe ser modular para que las funciones que hacen lo mismo o accedan a las mismas fuentes de datos estén en su mayoría en el mismo lugar.fuente
Idealmente, debería haber al menos otra persona además del autor haciendo una revisión del código en cada registro. El proceso de revisión del código puede ayudar a mitigar el problema de muchos métodos duplicados que se están registrando. Por supuesto, usted está limitado por el conocimiento de los revisores.
TL; DR: Revisiones de código para cada registro.
fuente