¿La mejor práctica para escribir una porción personalizada de código?

Pensar en un título es un poco complicado, pero básicamente mi pregunta es cómo mantener un sistema tan genérico (¿correcto?) Como sea posible cuando se necesita escribir un código especial para el cliente.

Mi caso es que tenemos un sistema estándar que vive en el tronco de la subversión. A veces los clientes quieren hacer un cambio que no se ajuste a ese sistema estándar, por lo que nuestra práctica es generalmente derivar el código y desarrollarlo en esa twig, pero luego se vuelve complicado cuando se necesita include trabajo troncal en un cliente especial o si una idea que un cliente desea debe estar tanto en la sucursal como en el troncal.

¿Hay una mejor manera o estándar para tratar con tales requestes porque parece que todo lo codificado es muy específico?

Sin duda es un escenario difícil.

Una opción podría ser tener la configuration para estipular si una característica está activada o no, de modo que la característica entra en la twig principal, pero solo configura la configuration en verdadero para los clientes que lo requieren. Todavía está un poco desorderado, pero creo que es más limpio que tener múltiples sucursales por cliente.

En escenarios más complejos, puede desarrollar nuevas funcionalidades como un tipo de architecture 'plug-in', donde tiene implementaciones diferentes que implementan la misma interfaz: algún tipo de fábrica podría decidir qué cargar.

No creo que haya ninguna solución mágica para mantener una base de código genérico que esté sujeta a las diferentes requestes de los clientes.

En términos de mejorar la reutilización del código, generalmente hay varias partes:

Características del lenguaje

Ser capaz de intercambiar partes más pequeñas de una aplicación es una preocupación básica del layout del lenguaje. Muchos idiomas están diseñados con methods para maximizar la reutilización. Aquí hay algunos ejemplos (algunos son específicos de C #):

  • Interfaces
  • Genéricos
  • Co / Contra-varianza
  • Inyección de dependencia
  • Patrones de layout (específicamente, relacionados con la estructura o creación)

Le permitirán reutilizar su código base más fácilmente pero, por sí solos, no son una bala de oro.

Diseño de proyecto

Incluso si explota cada característica disponible en C #, un proyecto insuficientemente pensado probablemente será difícil de intercambiar. Recomiendo que las soluciones más grandes se dividan en subunidades lógicas e independientes. Nuevamente, un ejemplo de una estructura de solución podría ser:

MyProgram // Wires up components and subunits. MyProgram.Core // Contains a core 'kernel' for your application MyProgram.IO // Contains generic interfaces and implementations for performing IO MyProgram.UI // Contains UI code that displays and interacts with your core. The core should not depend on UI elements. MyProgram.Models // Contains structure of databases, data models other components may act on MyProgram.Models.Serialization // Converts your models for IO etc. Maybe you want MyProgram.IO to be generic enough to reuse. Helpers // Generic helpers that you tend to use in multiple applications. You will want these to be in a standalone repository so that you can keep the classes validated. 

Versiones

En última instancia, es posible que no pueda manejar todos los problemas con las características del idioma y el buen layout del proyecto. Si tiene una request incómoda del cliente, a veces es posible que desee extraer (sin ramificar) los componentes que puede-reutilizar y ramificar los que necesita editar.