¿Cómo hace un seguimiento de las clases y funciones que ha escrito su equipo?

43

Al trabajar en el código, me enfrento a muchos de los mismos desafíos que hacen mis compañeros, y he escrito algunas funciones y clases útiles, y también lo han hecho. Si hay una buena comunicación, oiré algo importante que alguien haya hecho, y seis meses más tarde, 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ía la rueda.

¿Existe una práctica particular de documentar este tipo de cosas? ¿Cómo hacer que sean fáciles de encontrar?

Si su equipo no tiene dicha documentación, ¿cómo puede saber si su rueda ya existe?

EDIT:

Todas las respuestas, excepto una, se refieren a una situación ideal, así que permítanme resumir esas soluciones: documentación & comunicación; wikis, reuniones de pie, etc. Esas son cosas muy buenas, pero dependen de que los programadores tengan el tiempo (y las habilidades) para redactar la documentación y asistir a las reuniones, tomar notas y recordar todo.

La respuesta más popular hasta ahora (Caleb's) es la única que podría ser utilizada por un programador que no puede documentar y asistir a reuniones, y que solo hace una cosa: la programación. Programar es lo que hace un programador, y sí, un gran programador puede redactar documentación, pruebas unitarias, etc., pero seamos realistas: 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 puede encontrar y facilita el aprendizaje. curva 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 conocerlas. Podría documentarlos, escribirlos, anunciarlos en una reunión, etc., lo que puedo hacer, pero no es mi fuerza, o ... puedo extraerlos a una clase, nombrarlos bien, hacer que funcionen como una caja negra, y péguela donde vayan otros archivos de clase. A continuación, un breve correo electrónico anunciando que es fácil. Otros desarrolladores pueden escanear el código y entenderlo mejor que una función aislada que se usa en un código que no comprenden completamente: ese contexto se elimina.

Me gusta esto porque significa que tener un conjunto de archivos de clase con nombre, con métodos con nombre, es una buena solución que se logra con 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 presionados por el tiempo?

    
pregunta changokun 30.04.2013 - 16:37

7 respuestas

29

Bibliotecas. Marcos Control de versiones.

Si tiene un código reutilizable, lo último que desea es que diferentes miembros del equipo copien el código fuente en su proyecto. Si lo hacen, es probable que cambien un poco aquí y se modifiquen un poco allí, y pronto tendrás docenas de funciones o métodos que tienen el mismo nombre, pero que funcionan de manera un poco diferente. O, quizás más probable, el autor original continuará refinando el código para corregir errores, hacerlo más eficiente o agregar características, pero el código copiado nunca se actualizará. El nombre técnico para eso es un gran lío freakin '.

La solución correcta es sacar ese material reutilizable del proyecto para el que lo construyó en primer lugar y colocarlo en una biblioteca o marco en su propio repositorio de control de versiones. Eso lo hace fácil de encontrar, pero también desalienta realizar cambios sin tener en cuenta todos los otros proyectos que podrían estar usándolo. Podría considerar tener varias bibliotecas diferentes: una para el código bien probado que ya no es probable que cambie, una para las cosas que parece estable pero que no se ha probado y revisado a fondo, una para las adiciones propuestas.

    
respondido por el Caleb 30.04.2013 - 17:12
13

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 tiene 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 más tarde.

    
respondido por el Doc Brown 30.04.2013 - 16:51
7

Estar en una empresa con 700 empleados, en equipos que varían entre 2 y 20 personas, aquí está mi experiencia.

En el nivel de equipo

Tenemos "reuniones de pie" 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 un 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 integraron.

En el nivel de agencia

A nivel de agencia, tenemos 4 herramientas:

  • Otro wiki. Principalmente, nos proporciona información sobre hardware y otras cosas, pero a veces la usamos para compartir información técnica para revisarla antes de ponerla en el nivel de la empresa.
  • Reuniones semanales. Son principalmente para conocer el progreso de cada equipo / proyecto, pero ya que somos en su mayoría entusiastas de la tecnología, podemos mostrar cosas interesantes.
  • Lista de correo. Tenemos un correo con todos en la agencia. Un montón de cosas interesantes / cosas divertidas / cosas útiles llegan hasta allí.
  • Repositorio VCS. Cada agencia tiene su repositorio personal donde tenemos pequeños proyectos, en su mayoría módulos que usamos en diferentes proyectos.

En el nivel de la empresa

A nivel de empresa, está 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 base a las tecnologías. Por lo tanto, cualquiera puede mejorarlo, buscarlo y, básicamente, darle una vida al wiki.

También hay listas de correo disponibles a las que podemos suscribirnos. Cualquiera 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 de 5 a 10 de ellas.

Y, por supuesto, el VCS es el mejor sistema para compartir códigos.

Conclusión

Para resumir, no hay una solución clara. El intercambio de conocimientos siempre ha sido un gran problema, y probablemente se mantendrá. Existen muchas soluciones para crear bases de conocimientos , y probablemente una podría ajustarse a su factura. Sin embargo, algunas personas están intentando mejorar su KB ya que las soluciones actuales no siempre son muy inteligentes.

    
respondido por el Florian Margaine 30.04.2013 - 17:21
6

Bueno, todo se reduce a la comunicación.

Los Wiki son excelentes y definitivamente deberías instalar y usar uno. Una buena intranet de programadores internos es buena si la gente la lee y la actualiza, por lo que en realidad estamos hablando de un problema de personas allí. Podría sugerir reuniones semanales de "actualización del equipo" en las que todos se reúnan y ofrezcan una visión general del trabajo que se está realizando. Los líderes técnicos (¡al menos!) Deben reunirse y conversar sobre lo que está haciendo cada equipo. Las sesiones informales "Brown Bag" son excelentes, programelas a la hora del almuerzo y haga que las personas hablen.

También necesita una forma de compartir código, empaquetarlo, versionarlo y distribuirlo. Las cosas serían más fáciles si tiene un repositorio de código fuente realmente bien administrado, bien organizado en carpetas "comunes" y de proyectos.

Si no se está haciendo nada como esto, pregúntele a su jefe, explique cómo beneficiará a la compañía y sugiera un camino a seguir :)

    
respondido por el Rocklan 30.04.2013 - 17:13
4

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 ideó una solución puede mostrar a los demás cómo usarla. Si alguien menciona un punto en el que se queda, otros miembros del equipo podrían proponer un enfoque que incremente la reutilización de los componentes existentes.

    
respondido por el Daenyth 30.04.2013 - 17:07
2

La mejor manera de manejar algo así es tener una estructura de repositorio que tenga algunas convenciones simples para que sepa, como programador, si hay una función doXYZ , aproximadamente donde 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, de modo que las funciones que hacen lo mismo o que accedan a las mismas fuentes de datos se encuentren casi en el mismo lugar.

    
respondido por el Jonathan Rich 30.04.2013 - 17:17
0

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 la verificación de muchos métodos duplicados. Por supuesto, está limitado por el conocimiento de los revisores.

TL; DR: Revisiones de código para cada registro.

    
respondido por el Carolyn 30.04.2013 - 22:09

Lea otras preguntas en las etiquetas