¿Se debe esperar que los desarrolladores compilen una biblioteca interna antes del programa real?

Recientemente, un desarrollador senior con el que trabajo hizo un caso para exigir que los desarrolladores obtengan la última versión y compilen como parte de su proyecto una biblioteca interna importante. Esto contrasta con el argumento contrario de que los equipos de proyecto deberían estar trabajando en una versión estable que obtienen de un repositorio interno de Maven al que el desarrollador argumentó que tener el código fuente disponible en las máquinas desarrolladoras ahorra tiempo ya que pueden leer la fuente de las bibliotecas código para determinar si la funcionalidad requerida está disponible.

¿El desarrollador principal tiene un argumento válido? ¿O es necesario que los desarrolladores lean el código fuente de las bibliotecas en contra de la filosofía básica de encapsulación e incluso tener la biblioteca en primer lugar?

El argumento de este desarrollador senior no tiene sentido para mí.

¿Quieren agregar la sobrecarga de recuperar y compilar constantemente una biblioteca interna para que los desarrolladores puedan leer ocasionalmente el código fuente? Eso va a desperdiciar mucho más tiempo que hacer que los desarrolladores vean el código fuente solo cuando necesiten verificar si hay una función disponible.

Esta es una idea particularmente mala si la biblioteca y los clientes están siendo desarrollados por diferentes grupos de desarrollo y la biblioteca se está desarrollando activamente. Los desarrolladores del cliente no tendrán ningún aislamiento de la inestabilidad en la biblioteca.

No veo por qué el código fuente no puede estar disponible para los desarrolladores sin obligarlos a que formen parte de su compilación normal.

La sugerencia es

Los desarrolladores del lado del cliente pueden ahorrar tiempo al leer el código fuente de la biblioteca para determinar si la funcionalidad requerida está disponible

Podrías hacer una sugerencia alternativa

Podemos ahorrar tiempo si alguien documenta la biblioteca para indicar qué funcionalidad está disponible.

No compraría el argumento de que tener la capacidad de examinar la fuente localmente es un beneficio, pero si la biblioteca está en desarrollo activo (posiblemente para agregar soporte para las necesidades de su proyecto), entonces no creo que sea irrazonable exigir a los desarrolladores que descargue actualizaciones con frecuencia (posiblemente varias veces al día). Sin embargo, creo que tiene más sentido comercial hacer disponible un binario compilado (y probado en unidades) en lugar de requerir que los desarrolladores compilen desde la fuente.

¿Tiene la capacidad dentro de su proyecto de configurar algún tipo de repositorio compartido donde esté disponible la última versión compilada? Idealmente, desearía un servidor de CI que hiciera la búsqueda y la compilación en un horario, pero incluso si es solo un recurso de red que uno de los líderes del equipo es responsable de actualizar periódicamente, podría ayudar. Por supuesto, esto debería estar en el plato del equipo de la biblioteca, pero obviamente no están interesados, por lo que tendrá que recuperar su holgura.

Solía ​​trabajar para una gran empresa de software que constantemente "alimentaba" su propio software con sistemas comerciales internos.

Vieron esto como otro nivel de prueba.

Con lo que estoy de acuerdo, para una empresa, es algo bueno.

Creo que obligarlo a descargar y compilar la última versión es un paso demasiado lejos, a menos que el paso de compilación sea una parte importante de la oferta de sus empresas de vender o incluso externalizar una biblioteca.

Si bien tener el código fuente disponible puede ser un beneficio, si tiene un agente de compilación de CI que monitorea el repositorio, tiene MUCHO más sentido que ese agente compile esta biblioteca y la copie en proyectos dependientes como externo, que requerir que los desarrolladores ejecute dos pasos de compilación diferentes al crear su copia.

Actualmente estoy trabajando en un proyecto que no está conectado a un agente de compilación, que requiere compilar una sub-aplicación antes de compilar la aplicación principal. Es un dolor grave en mi parte posterior; para hacer un cambio en la sub-aplicación, primero debo compilar todo el proyecto, luego ir a una carpeta de sub-compilación, sacar el producto compilado de eso y copiarlo en una subcarpeta diferente, antes de construir todo el proyecto DE NUEVO para asegurarse de que la última versión de la sub-aplicación esté incluida en la compilación de la aplicación principal. Así NO es como debe hacerse; al menos debería haber un script de MSBuild que automatice este proceso, y preferiría que el agente de compilación actualice los elementos externos cada vez que se confirme un nuevo código en el enlace troncal.

Dado que tanta gente respondió que no tiene sentido que todos construyan una biblioteca interna, presentaré el punto de vista opuesto que podría justificar las razones:

1. Usas mucho la biblioteca y no hay documentación. Por lo tanto, todos deberían tener la fuente de referencia. Si esta es una biblioteca que se usa con mucha frecuencia, tener la referencia a mano podría ser útil

   • Claro, uno diría que deberían trabajar en la documentación y lo más probable es que su desarrollador senior sea consciente de este hecho. Pero seamos realistas, muchas veces los equipos de desarrollo terminan con una tonelada de código indocumentado, por lo que cuando necesita saber cómo funciona, va a la fuente. No debería tener que hacerlo, pero a corto plazo, esta es la mejor alternativa.
   • Por lo general, las mejores personas para poner documentación son las que mejor conocen la biblioteca. Desafortunadamente, esas son las mismas personas que generalmente son las más ocupadas, por lo que a menudo no es tan fácil para ellos dejar todo y comenzar a documentar.

2. Cuando las personas comienzan a escribir su propio código que depende de la biblioteca y algo en la biblioteca no funciona, en lugar de lanzar sus brazos al aire, si la biblioteca está construida localmente, es muy fácil entrar directamente en el código de la biblioteca

   • Esto puede ocurrir porque muchas bibliotecas están lejos de ser perfectas y aunque todos queremos trabajar con una versión "estable", todavía puede haber problemas.
   • Tal vez esté obteniendo malos resultados debido a la incomprensión de cómo se debe usar una API. Incluso con documentación, las personas a menudo hacen suposiciones equivocadas
   • Es probable que tu hombre mayor esté cansado de nuevas personas (y a veces hay muchas más personas nuevas que las que conocen el proyecto por dentro y por fuera) lanzando sus brazos al aire cada vez que un bloqueo / algún otro error parece provenir de un código de biblioteca. Entonces, en lugar de tener que acercarse a su máquina y luego al tipo que está sentado a su lado, quieren la opción de responder con estas preguntas: 1) ¿dónde está exactamente el accidente? ¿Qué módulo / archivo / línea? 2) ¿lo has depurado? ¿Qué has encontrado?
   • Sus superiores trabajaron con esta base de código (aplicación y su biblioteca principal) durante el tiempo suficiente y posiblemente él haya notado que cuando el código ya está en la máquina y está listo para ser depurado y revisado, hace su vida más fácil y hace que la gente para aprender el código base más rápido. Entonces, por esa razón, te obliga a asumir el costo inicial de construir la biblioteca en tu máquina.

No digo que su decisión esté justificada, solo señalo que a) la pregunta presentó un lado de la historia yb) podría haber motivos plausibles.

Este tipo de prueba sería mejor hacerlo de hecho. Sin embargo, la cosa debe ser realizada por probadores, no por desarrolladores . En ese sentido, no es tu trabajo ni el del desarrollador de la biblioteca.

_{Según lo que describe, parece que no hay evaluadores en el proyecto; si este es el caso, es un problema de gestión y bastante grave.}

... ahorra tiempo ya que pueden leer el código fuente de las bibliotecas para determinar si la funcionalidad requerida está disponible

Muy poco razonamiento. Cuando la biblioteca de la versión más reciente no puede compilarse con el proyecto de la versión más reciente, puede haber varias razones para eso: solo profundizar en el código fuente de lib podría ser una pérdida de tiempo.

• ¿Qué sucede si la biblioteca está bien y la falla de compilación fue causada por el error en el código del proyecto? O bien, ¿qué sucede si la falla de compilación fue causada por un cambio incompatible temporal que se supone que debe corregirse uno o dos días después? ¿Qué sucede si una falla de compilación indica un problema de integración complicado que tomará una semana o un mes para solucionarlo? Para un problema de integración, ¿el uso de una biblioteca de versiones anteriores supondría una solución o no?
   
  Cualquiera sea la razón, hacer un análisis preliminar de la falla significaría perder el tiempo del desarrollador en un trabajo que se supone que deben hacer los probadores.

Otra cosa por encima de los errores de razonamiento son las pérdidas de productividad inevitables (y bastante dolorosas en mi experiencia) que siguen cuando uno tiene que romper el flujo cambiando entre actividades de desarrollo y control de calidad.

Cuando hay probadores en el equipo, tales cosas son realmente simples y se pueden manejar mucho más fácilmente. Lo que su desarrollador "senior" le lanzó es básicamente un requisito de prueba preliminar.

Con cada cambio realizado en el proyecto o biblioteca, asegúrese de que la compilación sea exitosa.

Los pasos a seguir desde allí son actividades típicas de control de calidad: aclarar los detalles de los requisitos, diseñar un escenario de prueba formalizado, negociar cómo manejar las fallas de la prueba.

• Desde la perspectiva de SQA , esta es una tarea bastante rutinaria de diseño, configuración y mantenimiento de un procedimiento de prueba de regresión bastante simple que podría ser altamente automatizado, probablemente hasta el punto de que solo la actividad manual sería crear y mantener tickets en el rastreador de problemas y la verificación de arreglos

Lo que sugiere el Sr Dev tiene poco sentido para mí en el mejor de los casos. Es bueno poder navegar por las fuentes, pero hay mejores maneras de hacerlo.

¿Qué repositorio de artefactos estás usando? Debería poder implementar un jar de origen para que cada versión viva junto a la biblioteca compilada. La mayoría de los IDE le permitirán adjuntar esto a la biblioteca compilada para navegar por la fuente. Eclipse con el complemento Maven lo hará automáticamente.

Si necesita el código más reciente, puede implementar instantáneas de versiones.

Esto simplemente debería suceder en su script de compilación:

1. compruebe si hay una nueva versión disponible. saltar 2 de lo contrario.
2. descárguelo y compílelo y ejecute cualquier herramienta que tenga para generar una referencia API desde el código fuente localmente. muestra un registro de cambios.
3. construye tu aplicación

No veo por qué o cómo esto es un problema. Además, cuando falta algo en la referencia, puede agregarlo a las fuentes e impulsar los cambios. Por supuesto, puede parecer un poco aterrador que la biblioteca pueda cambiar justo debajo de tus pies, pero si los encargados de la biblioteca hacen su trabajo correctamente, esto es algo bueno.