¿Cómo maneja su organización los componentes comunes?

Question

Un componente común es una biblioteca u otro elemento de código creado y mantenido por un grupo y utilizado por muchos grupos.

Algunos de los problemas que tenemos son:

• Los usuarios no reportan problemas con los componentes.
• Los usuarios crean soluciones para los componentes según sus necesidades.
• Rompen la compatibilidad con la versión troncal solo para cumplir con los plazos.
• Los usuarios terminan codificando sus propias soluciones (menos robustas) porque creen que es mejor.

¿Cómo maneja su organización los componentes comunes?

ideas que tengo:

• Tratar el componente como un proyecto de código abierto y requieren equipos para enviar parches.
• Totalmente no permitido modificaciones personalizadas en el código.
• ...

Answer 1

Lo que tiene aquí puede ser un problema de factores humanos en lugar de uno técnico. De hecho, puede ser principalmente un problema de aprendizaje (junto con el síndrome típico no inventado aquí).

Al haber trabajado en grandes empresas, me doy cuenta de que es difícil para una persona nueva comprender todos los recursos (es decir, bibliotecas de códigos compartidos) disponibles para él, y mucho menos cómo y cuándo utilizarlos correctamente.

Cuando tiene un nuevo empleado, ¿recibe capacitación formal en la biblioteca de componentes comunes?

Luego está el problema de por qué se premia a las personas. En el momento de la revisión, ¿los gerentes recompensan a las personas por usar los componentes comunes, mejorarlos y enviar mejoras a la biblioteca? ¿O los gerentes simplemente se preocupan por sus propios proyectos?

En cuanto a su grupo que mantiene la biblioteca común, ¿qué forma o reconexión le dan a las personas que se toman el tiempo de sugerir o presentar mejoras? ¿Se escriben en el boletín de la compañía? Obtener un bono en efectivo? Obtener su foto en el tablero bulliten?

Recuerde, es muy poco probable que las personas hagan algo por una empresa para la que no reciben reconocimiento o recompensa.

Answer 2

El único componente éxito que he visto por aquí se redistribuye en una versión compilada (* .dll). Los usuarios informan errores y solicitan características directamente con el equipo propietario, y los implementan ellos mismos. Existe una API para escribir sus propios complementos para las cosas que es más probable que cambien, por lo que las personas pueden ampliar la funcionalidad en muchos casos.

siempre existe la disyuntiva a

• convencer a la gente a usar su componente
• mantener un nivel razonable de calidad, al mismo tiempo

No está seguro de cuál es la mejor cosa hacer en su caso, pero en general trate de implementar la lógica del núcleo usted mismo, mantenga el componente configurable/extensible para que la gente no tenga que cambiar el núcleo todo el tiempo y ofrecer un buen soporte. Por alguna razón, algunos desarrolladores siempre tienden a reinventar la rueda por estúpida que sea, así que no me preocuparía demasiado.

Answer 3

Una buena manera es instituir revisiones de código periódicas. Durante estos, si encuentra una rueda inventada, puede aprovechar la oportunidad para educar a los desarrolladores para que utilicen un componente común o por qué sintieron la necesidad de reinventarlo y aliar su razonamiento con el código original. De esta forma, todos los requisitos se hacen y los componentes se mejoran para todos.

Answer 4

Trátelos de la misma forma que lo haría con las bibliotecas de terceros. Ni siquiera dejaría que los otros equipos vean la fuente, ya que hacerlo puede llevar a mucho tiempo, desperdiciando críticas y retrocesos.

Answer 5

Estamos tratando de avanzar hacia sistemas más basados ​​en servicios, de modo que si creamos una funcionalidad particular para un proyecto, se puede usar desde otro proyecto a través de un servicio web. De esta manera solo hay una instancia del código.

Naturalmente, esto funciona mejor para algunos tipos de componentes (un ejemplo: creamos recientemente un servicio de creación de PDF) que otros (probablemente exagerado para una utilidad de manipulación de cadenas).

Answer 6

¿Qué tan grande es la organización? He visto que esto se maneja muy bien en una organización pequeña (una docena de programadores en total) donde se sabe que una o dos personas son propietarias de cada componente y responden a las solicitudes de características.

Es más fácil marchar a la oficina de alguien (o por correo), explique lo que necesita, y obtener uno de:

• la forma esperada a hacer lo que quiera,
• acuerdo para añadir el característica requerida (o dirigir a un subordinado para hacerlo),
• permiso para implementar la función requerida en el componente común,

de lo que se acaba de lanzar en soluciones de escritura, a partir de un tenedor, o escribiendo un nuevo componente equivalente. Si sus programadores son inteligentes, harán lo que les parezca más fácil. El truco es asegurarse de que esto sea lo correcto.

Aparte de cosas realmente simples como listas enlazadas, no había mucha reinvención de ruedas en marcha. Hubo, muy raramente, tenedores privados para productos particulares, más comúnmente para reducir el tamaño del código cortando cosas. Pero la forma habitual de hacerlo fue modificar el componente original para tener más opciones de compilación.