¿Es simple ahora o programa con el futuro en mente?

Actualmente estoy codificando una nueva aplicación para mi empresa que está bastante involucrada. Para cumplir con la fecha límite, la funcionalidad se ha atenuado bastante para que podamos tener algo listo para el lanzamiento.

Me dieron la tarea de poner en funcionamiento la versión 1 a fin de mes. Estoy a la mitad del desarrollo y he llegado al punto ahora que hay un final a la vista.

Ayer, pasé algún tiempo ideando una solución fácil y agradable para uno de los requisitos y estoy muy orgulloso de cómo resultó. Esta mañana se envió el documento de la versión 2, y hay un requisito que requerirá que el código que escribí ayer sea destripado o cambiado severamente. Requeriría mucho trabajo en el futuro si lo dejo como está. Ahora puedo tomarme un día más para hacer que mi solución actual sea más sólida para que la característica v2 pueda agregarse con mucho menos esfuerzo, pero eso me retrasará un poco para la codificación adicional que requeriría.

No sé si estaré haciendo v2. Podría ser yo o podría ser un compañero de trabajo, o incluso un interno.

Si estuviera en mi lugar, ¿pasaría el tiempo ahora para facilitarlo en el futuro, o dejaría su solución y la trataría cuando llegue el momento?

Si la fecha límite es Carved In Stone, solo termine lo que tenga que cumplir. Asegúrese de inflar las estimaciones para v2 para acomodar los cambios de código para el nuevo requisito. También asegúrese de documentar brevemente lo que cree que tendrá que cambiar para las nuevas características de v2 para que un compañero de trabajo pueda recogerlo si se le reasigna a otra cosa.

Si hay suficiente flexibilidad en la fecha límite (1 día, por lo que parece, así que apunte a una extensión de 2.5 días), ¡entonces seguro, continúe y codifique para el futuro conocido!

Evite caer presa (temprano) al Segundo Efecto del Sistema . Aquí hay algunas buenas técnicas para aplicar:

1. Definitivamente evite descarrilar la versión 1 solo por lo que ve en la versión 2. Planificar con anticipación está bien, pero el creador de las especificaciones de v2 debería ser responsable de la falla de v2, no de v1.
2. (Si es posible) vea si puede hacer que el creador vuelva a trabajar los requisitos para la versión 2 que no requerirán los cambios más grandes ahora, y luego planifíquelos más tarde, tal vez para la v3.
3. Tenga en cuenta a YAGNI , pero trate de codificar la extensibilidad en mente: evite números mágicos, valores codificados, escriba buenas pruebas unitarias o contratos de código, etc. La aplicación de buenas técnicas desde el principio hará que la refactorización y los cambios de código sean menos dolorosos en el camino.

La mayoría de los proyectos de software que crecen como ciudades tienen éxito a largo plazo. La planificación evolutiva solo en un futuro limitado permite que su software se lance a tiempo y con las funcionalidades requeridas en el lanzamiento, y nada más. Vea este extracto de Carl Sagan:

La disposición [de una ciudad] podría ser más eficiente si todos los sistemas cívicos se construyeran en paralelo y se reemplazaran periódicamente (razón por la cual los incendios desastrosos, las grandes conflagraciones de Londres y Chicago, por ejemplo, a veces son una ayuda en la planificación de la ciudad). Pero la lenta acumulación de nuevas funciones permite a la ciudad trabajar más o menos continuamente a través de los siglos.

• Carl Sagan, Cosmos : http://www.eridanus.info/genesis.html

No agregue código hoy para el requisito del próximo mes. Hoy debe escribir el código más limpio posible para los requisitos que tiene. Soy escéptico de que un día de trabajo ahorre varios días después. He escuchado afirmaciones como esa, y no puedo recordar un solo caso en el que fuera cierto. Es posible que pueda convencerme mostrando algún código, pero mi experiencia me dice que es poco probable.

Déjalo como está.

Los desarrolladores APRECIAN un proyecto heredado que hace lo que se supone que debe hacer y nada más.

Lo que, hoy, puede parecer una buena idea para "organizar" la base de código para cumplir con un requisito de "futuro", con toda probabilidad actuará como un obstáculo para comprender el código en el futuro. A nadie le gusta lidiar con funcionalidades parcialmente implementadas y vestigios de requisitos fantasmas olvidados. No digo que ese sea el caso, pero las cosas a menudo resultan así a pesar de las mejores intenciones.

Buenas respuestas Solo agregaría: lo que hago en un caso como este es tomar una buena diferencia para poder capturar lo que he hecho y guardarlo en un lugar seguro. Entonces, si llega la oportunidad de hacerlo nuevamente en la próxima versión, será fácil.

En general, un buen desarrollador anticipa los requisitos futuros, pero cuando se acerca una fecha límite, es hora de responder a los errores en lo que ya tiene y no "sacudir el bote".

Depende. Hay una buena regla antigua: trata a otras personas como si quisieras que te traten a ti mismo. ¿Qué harías si fuera tu propio proyecto y supieras todas las prioridades?

Si definitivamente se requiere v2 y la fecha límite es solo un deseo en lugar de una necesidad difícil, entonces no cree una deuda técnica y repare sus velas mientras hace buen tiempo. Incluso si alguien más hará v2 apreciarán la previsión.

Si hay dudas sobre la necesidad de v2, entonces quédese con YAGNI. Además, si está al otro lado del espectro y tiene uno de esos clientes que constantemente le envía spam con sus ideas antes de que se formen, revise sus correos electrónicos solo 2 o 3 veces al día y no se apresure con la acción, se sorprenderá cuántos "problemas" y solicitudes se vuelven irrelevantes antes de siquiera leerlos.