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

Question

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

Algunos problemas que tenemos son:

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

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

Ideas que tengo:

• Trate el componente como un proyecto de código abierto y solicite a los equipos que envíen parches.
• Totalmente no permite modificaciones personalizadas al 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índrom típico no inventado aquí).

Después de 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, y mucho menos cómo y cuándo usarlos adecuadamente.

Cuando tiene una nueva contratación, ¿recibe capacitación formal en su biblioteca de componentes comunes?

Luego está el problema de por qué se recompensa 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 reconocimiento dan a las personas que se toman el tiempo para sugerir o enviar mejoras? ¿Se escriben en el boletín de la compañía? ¿Obtener un bono en efectivo? ¿Obtener su foto en el tablero de bulliten?

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

Answer 2

Estamos tratando de avanzar hacia sistemas más basados ??en servicios, de modo que si creamos una funcionalidad particular para un proyecto, se pueda 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: recientemente creamos un servicio de creación de PDF) que otros (probablemente exagerado para una utilidad de manipulación de cadenas).

Answer 3

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

Siempre existe el compromiso de

• convencer a la gente para que use su componente
• mantenga un nivel razonable de calidad al mismo tiempo

No estoy seguro de qué es lo mejor que puede hacer en su caso, pero en general intente implementar la lógica central usted mismo, mantenga el componente configurable / extensible para que las personas no necesiten cambiar el núcleo todo el tiempo y ofrezcan un buen soporte . Por alguna razón, algunos desarrolladores siempre tienden a reinventar la rueda por estúpida que sea, por lo que no me preocuparía demasiado por eso.

Answer 4

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

Answer 5

Trátelos de la misma manera que lo haría con bibliotecas de terceros. Ni siquiera permitiría que los otros equipos vieran la fuente; hacerlo puede generar muchas críticas y pérdidas de tiempo.

Answer 6

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

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

• la forma esperada de hacer lo que quieres,
• acuerdo para agregar la función requerida (o dirigir a un minion para que lo haga),
• permiso para implementar la función requerida en el componente común,

De lo que se trata es de comenzar a escribir soluciones provisionales, comenzar una bifurcación o escribir 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. Había, 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 era modificar el componente original para tener más opciones de compilación.