Cómo modificamos el producto para un cliente específico

Entonces, vendimos al cliente un producto de software B2B.

En la presentación, le gustó todo, pero durante la implementación resultó que algo todavía no encajaba. Por supuesto, puede decir que necesita seguir las "mejores prácticas" y transformarse en un producto, y no al revés. Esto puede funcionar si tiene una marca fuerte (por ejemplo, tres letras grandes y puede enviar las tres letras pequeñas). De lo contrario, le explicarán rápidamente que el cliente logró todo gracias a sus procesos comerciales únicos, y mejor cambiemos su producto o no funcionará. Hay una opción para rechazar y referirse al hecho de que las licencias ya se han comprado, y no hay ningún lugar para ir desde el submarino. Pero en mercados relativamente estrechos, tal estrategia no funcionará por mucho tiempo.

Tenemos que modificarlo.

Los enfoques

Existen varios enfoques básicos para la adaptación del producto.

Monolito

Cualquier cambio se realiza directamente en el código fuente del producto, pero se incluye en ciertas opciones. En tales productos, como regla, hay formas monstruosas con configuraciones, a las cuales, para no confundirse, se les asignan sus números o códigos. La desventaja de este enfoque es que el código fuente se convierte en un gran espagueti, en el que hay tantos casos de uso diferentes que se vuelve muy largo y costoso de mantener. Cada opción posterior requiere más y más recursos. El rendimiento de dicho producto también deja mucho que desear. Y si el lenguaje en el que está escrito el producto no es compatible con prácticas modernas como la herencia y el polimorfismo, entonces todo se vuelve muy triste.

Copia

El cliente recibe el código fuente completo del producto con una licencia para modificarlo. A menudo, dichos proveedores le dicen al cliente que no adaptarán el producto ellos mismos, ya que será demasiado costoso (es mucho más rentable para un vendedor vender licencias que contactar a los servicios). Pero tienen subcontratistas familiares que contratan empleados relativamente baratos y de alta calidad en algún país de terceros países que están listos para ayudarlos. También hay situaciones en las que las mejoras serán realizadas directamente por los especialistas del cliente (si tienen unidades de personal). En tales casos, el código fuente se toma como punto de partida, y el código modificado no tendrá ninguna conexión con lo que era originalmente y vivirá su propia vida. En este caso, puede eliminar con seguridad al menos la mitad del producto original y reemplazarlo con su propia lógica.

Fusión

Esta es una mezcla de los dos primeros enfoques. Pero en él, el desarrollador que corrige el código siempre debe recordar: "viene la fusión". Cuando se lanza una nueva versión del producto fuente, en la mayoría de los casos deberá fusionar manualmente los cambios en el código fuente y modificado. El problema es que en cualquier conflicto será necesario recordar por qué se hicieron ciertos cambios, y esto podría ser hace mucho tiempo. Y si la refactorización de código se realizó en el producto original (por ejemplo, los bloques de código simplemente se reorganizaron), la fusión requerirá mucho tiempo.

Modularidad

Lógicamente, el enfoque más correcto. El código fuente del producto en este caso no sufre cambios, y se agregan módulos adicionales que amplían la funcionalidad. Sin embargo, para implementar dicho esquema, el producto debe tener una arquitectura que le permita expandirse de esta manera.

Descripción

Más adelante, con ejemplos, mostraré cómo expandimos los productos desarrollados sobre la base de la plataforma lsFusion abierta y gratuita.

Un elemento clave del sistema es el módulo. Un módulo es un archivo de texto con la extensión lsf , que contiene el código lsFusion . En cada módulo, se declaran tanto la lógica de dominio (funciones, clases, acciones) como la lógica de presentación (formularios, navegador). Los módulos, por regla general, se encuentran en directorios, divididos por un principio lógico. Un producto es una colección de módulos que implementan su funcionalidad y se almacenan en un repositorio separado.

Los módulos son interdependientes. Un módulo depende de otro si usa su lógica (por ejemplo, se refiere a propiedades o formas).

Cuando aparece un nuevo cliente, se inicia un repositorio separado (Git o Subversion), en el que se crearán los módulos con las modificaciones necesarias. Este repositorio define el llamado módulo superior. Cuando se inicia el servidor, solo se conectarán esos módulos, de los cuales depende directa o transitivamente a través de otros módulos. Esto le permite al cliente usar no toda la funcionalidad del producto, sino solo la parte que necesita.
Jenkins crea una tarea que combina los módulos de producto y cliente en un único archivo jar, que luego se instala en un servidor de producción o prueba.

Considere varios casos principales de mejoras que surgen en la práctica:

Supongamos que tenemos un módulo de pedido en el producto, que describe la lógica de pedido estándar:


El cliente X desea agregar un porcentaje de descuento y un precio de descuento para la línea de pedido.
Primero, se crea un nuevo módulo OrderX en el repositorio del cliente. En su encabezado, se coloca una dependencia en el módulo de pedido original:

En este módulo, declaramos nuevas propiedades bajo las cuales se crearán campos adicionales en las tablas, y las agregamos al formulario:

Hacemos que el precio con descuento no esté disponible para la grabación. Se calculará como un evento separado cuando cambie el precio inicial o el porcentaje de descuento:

Ahora debe cambiar el cálculo del importe en la línea de pedido (debe tener en cuenta nuestro precio de descuento recién creado). Para hacer esto, generalmente creamos ciertos "puntos de entrada" donde otros módulos pueden insertar su comportamiento. En lugar de la declaración inicial de la propiedad de suma en el módulo Orden, utilizamos lo siguiente:

En este caso, el valor de la propiedad de suma se recopilará en un CASO, donde CUANDO se puede dispersar en diferentes módulos. Se garantiza que si el módulo A depende del módulo B, todo CUANDO del módulo B funcionará más tarde que CUANDO del módulo A. Para calcular correctamente la cantidad descontada, se agrega la siguiente declaración al módulo OrderX :

Como resultado, si se establece un descuento, la cantidad estará sujeta a él, de lo contrario, la expresión original.

Supongamos que un cliente desea agregar una restricción de que el monto del pedido no debe exceder un cierto monto especificado. En el mismo módulo OrderX , declaramos una propiedad en la que se almacenará el valor de restricción, y lo agregamos al formulario de opciones estándar (puede crear un formulario separado con la configuración si lo desea):

Luego, en el mismo módulo, declaramos el monto del pedido, lo mostramos en el formulario y agregamos un límite a su exceso:

Y finalmente, el cliente solicitó cambiar ligeramente el diseño del formulario de edición del pedido: hacer el encabezado del pedido a la izquierda de las líneas con un separador, así como mostrar siempre los precios con una precisión de dos caracteres. Para hacer esto, se agrega el siguiente código a su módulo, que cambia el diseño estándar generado del formulario de pedido:
Como resultado, obtenemos dos módulos de pedido (en el producto), en los que se implementa la lógica básica del pedido, y OrderX (en el cliente), en el que se implementa la lógica de descuento necesaria:



Cabe señalar que el módulo OrderX puede llamarse OrderDiscount y transferirse directamente al producto. Luego, si es necesario, será posible que cada cliente conecte fácilmente la funcionalidad con descuentos.

Esto está lejos de todas las posibilidades que ofrece la plataforma para expandir la funcionalidad en módulos individuales. Por ejemplo, usando la herencia, puede implementar modularmente la lógica de registro .

Si hay algún cambio en el código fuente del producto que contradiga el código en el módulo dependiente, se generará un error cuando se inicie el servidor. Por ejemplo, si el formulario de pedido se elimina en el módulo Pedido , al inicio habrá un error de que el formulario de pedido no se encontró en el módulo OrderX . Además, el error se resaltará en el IDE . Además, el IDE tiene una función para buscar todos los errores en el proyecto, lo que le permite identificar todos los problemas que se han producido debido a la actualización de la versión del producto.

En la práctica, tenemos todos los repositorios (del producto y todos los clientes) conectados al mismo proyecto, por lo que refactorizamos con calma el producto, mientras cambiamos la lógica en los módulos del cliente donde se usa.

Conclusión

Dicha arquitectura micromodular proporciona los siguientes beneficios:

• Cada cliente está conectado solo con la funcionalidad que necesita . La estructura de su base de datos contiene solo aquellos campos que usa. La interfaz de la solución final no contiene elementos innecesarios. El servidor y el cliente no realizan eventos y comprobaciones innecesarios.
• Flexibilidad en los cambios a la funcionalidad básica . Directamente en el proyecto del cliente, puede realizar cambios en cualquier forma del producto, agregar eventos, nuevos objetos y propiedades, acciones, cambiar el diseño y mucho más.
• La entrega de nuevas mejoras requeridas por el cliente se acelera significativamente . Con cada solicitud de cambio, no necesita pensar cómo afectará a otros clientes. Debido a esto, se pueden hacer muchas mejoras y ponerlas en funcionamiento lo antes posible (a menudo en unas pocas horas).
• Un esquema más conveniente para expandir la funcionalidad del producto . Primero, se puede incluir cualquier funcionalidad para un cliente específico que esté listo para probarlo, y luego, en caso de una implementación exitosa, los módulos se transfieren completamente al repositorio del producto.
• Código base de independencia . Dado que se proporcionan muchas mejoras bajo los contratos de servicio al cliente, formalmente, todo el código desarrollado bajo estos contratos pertenece al cliente. Con este esquema, se garantiza una separación completa del código del producto que pertenece al proveedor del código propiedad del cliente. Previa solicitud, transferimos el repositorio al servidor del cliente, donde puede modificar la funcionalidad que necesita con sus propios desarrolladores. Además, si el proveedor otorga licencias para módulos de productos individuales, el cliente no tiene el código fuente de los módulos para los cuales no hay licencia. Por lo tanto, no tiene la capacidad técnica para conectarlos de forma independiente en violación de las condiciones de licencia.
  

El esquema de modularidad descrito anteriormente con la ayuda de extensiones en la programación a menudo se llama mezclar . Por ejemplo, Microsoft Dynamics introdujo recientemente el concepto de extensión, que también le permite expandir los módulos base. Sin embargo, allí se requiere mucha programación de nivel inferior, lo que a su vez requiere calificaciones más altas de los desarrolladores. Además, a diferencia de lsFusion, la expansión de eventos y restricciones requiere los "puntos de entrada" iniciales al producto para aprovechar esto.

En este momento, de acuerdo con el esquema descrito anteriormente, apoyamos e implementamos un sistema ERP para la venta minorista con más de 30 clientes relativamente grandes, que consta de más de 1000 módulos. Entre los clientes hay redes de bienes de consumo, así como farmacias, tiendas de ropa, cadenas de tiendas de lencería, mayoristas y otros. En el producto, respectivamente, hay categorías separadas de módulos que están conectados dependiendo de la industria y los procesos comerciales utilizados.