Acabo de firmar con McDonald's para desarrollar un sistema de reservas de eventos, con relaciones entre varios tipos de personas. Lo que me preocupa: el proyecto va a crecer sí o sí, y tarde o temprano van a querer más tipos de actividades. Pero por ahora dicen que no están seguros, así que oficialmente hay uno solo. ¿Cómo lo encaro?

Respuesta clásica de cliente: ese "no" no lo tomes al pie de la letra. No construyas las cinco actividades que quizás quieran algún día. Construí la única que te pidieron, sobre un modelo que trate las actividades como datos, no como lógica hardcodeada. Dos reglas:

  • Diseñá los puntos de extensión, no las features. Los tipos de actividades, los roles y los precios viven en tablas de la base de datos: agregar uno nuevo más adelante es insertar una fila, no refactorizar código.
  • Ocultá la flexibilidad. El cliente ve una sola actividad y nada más. El día que digan que sí, activás la nueva en vez de reconstruir.

Esa es la diferencia entre anticipar el crecimiento y el over-engineering: construís la estructura ahora, y las features solo cuando alguien las paga.

Hoy ya tenemos 5 tipos de actividades, cada uno con sus propias condiciones de visualización según el cliente. Gracias por el consejo. Armé una base que aguanta lo que venga:

  • Nuevos clientes y roles, sumados sin tocar el núcleo del sistema.
  • Nuevas actividades, cada una con su propio precio, agregadas como datos.

Diseñar pensando en la evolución desde el primer día fue lo que hizo que cada uno de estos agregados saliera barato, sin caer nunca en el over-engineering.

Mandale un email a Eliott

Currículum de Eliott Baylot

Claude es una IA y puede cometer comete errores. Chequeá las respuestas tres veces.