¿Cómo juegan juntos "No lo vas a necesitar" y "Ahora es mejor que nunca"?

A menudo me encuentro abrazando "ahora es mejor que nunca" cuando avanzo el SECO de un diseño. Típicamente, encuentro que necesito cultivar una comprensión de la Ubicación Autorizada Única para un conocimiento en el contexto de un sistema de otros conocimientos. Por lo tanto, tiendo a diseñar el sistema 'ahora'.

Por el contrario, esta práctica me hace construir con bastante anticipación, a pesar de una posibilidad razonable de que no la necesite.

¿Cómo cuadran estos dos patrones?

¿Qué prácticas utilizas para asegurarte de que jueguen bien?

¿Cómo les enseñas juntos sin crear confusión?

Trato de pensar con mucha anticipación también, pero generalmente no en código. Tengo una lluvia de ideas y tomo notas, con suerte organizo las cosas lo suficientemente bien como para poder referirme a ellas.

Me inclino más hacia "no lo vas a necesitar" con respecto al código, pero "ahora es mejor que nunca" con el diseño.

Al comenzar a construir un nuevo sistema, es tentador querer construir todo ahora, pero también puede minar tu impulso y tu moral. Tiendo a pensar en el diseño general y trato de dibujar una línea directa a través de él; propongo una arquitectura esquelética de extremo a extremo y la construyo primero, aplicando principios de diseño de sonido para que luego pueda evolucionarlo y refactorizar para traer en nuevas caracteristicas.

Cree la representación más simple de extremo a extremo del sistema que puede funcionar; haz eso primero, y luego tienes algo sobre lo que reflexionar. Eso tiende a ayudar a cristalizar todas esas vagas preguntas de "qué pasaría si" y te ayuda a concretar lo que necesitas para construir a continuación.

YAGNI significa que las cosas se hacen cuando deben hacerse y no antes. No significa que nunca se hagan, a menos que nunca sean necesarios. Significa que solo hace lo que le da al cliente un valor comercial inmediato . Lo que significa valor comercial inmediato es subjetivo para cada cliente y cada proyecto.

En cualquier caso, no puedes perder nada con YAGNI.

En el otro caso, pierde tiempo escribiendo código que nunca se usa, y escribiendo pruebas para código que nunca se usa, y escribiendo documentación para código que nunca se usa, y mantenimiento en código que nunca se usa, la gente se pregunta qué hace este código , y si alguna vez se usa, hasta la náusea.

Ejemplo

Si estoy trabajando en un prototipo / prueba de concepto o una versión 1.0 de una aplicación, entonces no necesito un diseño para escalar a nivel de Facebook. Demonios, no necesito un diseño para escalar al nivel de Facebook, hasta que empiezo a ver que tengo ese tipo de tráfico.

¿Crees que Zuckerberg diseñó la primera versión de Facebook para escalar a 500 millones de usuarios? No, él lo diseñó y construyó para hacer lo que necesita y no más. Si hubiera intentado en cascada el diseño para 500 millones de usuarios desde el primer día, Facebook probablemente nunca habría sido lanzado.

La forma práctica de hacer las cosas es cómo lo hizo. Comenzó con PHP y MySQL, y el rediseñado y reescrito según sea necesario en función del valor comercial , escalar a millones de usuarios fue de gran valor comercial, pero no en el día 0. En el día 0, solo lanzar algo fue el tremendo valor comercial.

Él planeó en rediseñar y volver a escribir. Lo cual es una mentalidad diferente a la planificación para el fregadero de la cocina y nunca desarrollar o entregar nada útil que esté completo.

Planear el final de la vida útil para una base de código y reescribir es Ágil y prueba de futuro. Intentar llegar a un objetivo indefinido de "flexible" simplemente termina en un fracaso cada vez. Está diseñando sin necesidad y perdiendo el tiempo, podría estar desarrollando lo que tiene valor comercial en lugar de soñar con las características que nunca se utilizarán.

El estilo Zen de Python dice:

Ahora es mejor que nunca. Aunque nunca es a menudo mejor que ahora.

La idea es que no es porque puedes definir algo ahora que deberías. ¿Lo necesitas ahora?

• Sí: ¡hazlo ahora!
• No: no lo hagas! ¡Espera la necesidad! YAGNI!

Los casos en que esto es menos obvio es en casos de refactorización. ¿Debo aplicar DRY cada vez que puedo? La respuesta no está clara porque hay momentos en los que aplicar DRY cuesta más (en tiempo invertido) que la duplicación. Sin embargo, a largo plazo, aplicar DRY hasta que tenga razones técnicas / de rendimiento para no siempre es bueno.

Entonces, YAGNI hasta que lo hagas, HAZLO AHORA. No esperes

No creo que jueguen juntos en absoluto. Creo que te inclinas de una forma u otra. Y me inclino hacia YAGNI.

Pero por lo que vale, no estoy de acuerdo con la segunda propuesta, que "Ahora es mejor que nunca". Si un requisito es importante, entonces tendrá que hacerse. Entonces "nunca" no es una posibilidad. Si no es importante, que "ahora" no es mejor - "nunca" es mejor.

Solo mis dos centavos.

¿Cómo cuadran estos dos patrones?

Son ortogonales y no tienen nada que ver entre sí.

¿Qué prácticas utilizas para asegurarte de que jueguen bien?

Um. ¿Los dos? ¿Qué más puede haber?

¿Cómo les enseñas juntos sin crear confusión?

YAGNI describe características vistas por los usuarios. No necesitas fantasía.

Ahora es mejor que nunca describe el proceso. Escribe pruebas ahora. Escribe el código ahora. No te pierdas las horas contemplando alternativas de diseño. Construye algo en lugar de hablar sobre construir algo.

Si "nunca" es la implicación de "no ahora", entonces su diseño es defectuoso.

Las decisiones locales que tome deben ser transparentes para el resto de un sistema.
Por ejemplo, si tiene un componente CookieSource, que requiere CookieFactoryque se convierta en el CookieRecipesque conoce Cookies, en función de algunos parámetros de entrada suyos, entonces CookieSourceno es necesario y, por lo tanto, no debe depender de cómo CookieFactoryse implementa y cómo CookieRecipesse representa.
Si CookieFactoryde hecho es un Bakery, eso puede tener Recipeen cuenta de acuerdo Pastryno debería importar. Y a menos que necesite esa funcionalidad, no es necesario implementarla. Y no hay ninguna razón en el mundo por la que no pueda agregarlo después, excepto si no hay una barrera de abstracción clara entre CookieSourcelos servicios que utiliza.

Cuando cree software, agregue funcionalidad según sea necesario e intente no encerrarse en las decisiones que tome. En su lugar, bloquee la decisión en una abstracción adecuada .

La solución más simple que encontré es esperar cambios al escribir código por adelantado. Cuando paso un bool a una función, normalmente lo cambio lo antes posible a un indicador / enumeración para que sea a) más legible yb) fácil de extender. De manera similar, si me doy cuenta de que estoy pasando un montón de parámetros por donde huele que necesitaré uno más, normalmente creo una estructura especial. La esperanza es que YAGNI lo haga, pero si lo haces en algún momento, no romperá a todos los usuarios de inmediato y el "trabajo gruñido" ya está hecho. A menudo, también puede agregar algunos comentarios como / * las adiciones futuras ingresan aquí * / más o menos, por lo que está claro que aún no está implementado, pero aquí está el lugar para agregarlo. Por lo general, eso es lo que más ayuda, ya que más tarde descubrí que la refactorización de interfaces es más lenta.

Diseñe con futuras extensiones en mente, pero no implemente esas extensiones hasta que las necesite.

El ejemplo que me viene a la mente es cuando Netflix comenzó por primera vez, solo podía tener una cola asociada con cada cuenta. Más tarde piratearon el soporte para múltiples colas. Como no se diseñó de esa manera desde el principio, se hizo cada vez más difícil de mantener, por lo que decidieron suspender esa función. Después del alboroto de un cliente, mordieron la bala e hicieron un rediseño para integrar varias colas correctamente.

Si alguien al principio hubiera permitido la posibilidad de que quisieran múltiples colas más tarde, podrían haberse ahorrado mucho dolor a largo plazo por muy poco esfuerzo adicional a corto plazo. No tuvieron que implementar múltiples colas de inmediato, solo asegúrense de que si alguna vez lo hicieran, no requeriría una reescritura masiva o un hack imposible de mantener.

En la superficie, parece que requeriría una habilidad similar a la de un adivino para predecir requisitos futuros, pero en la práctica, cosas como esa tienden a quedarse con un buen programador cuando se da cuenta de que está codificando algo, o que una tabla de base de datos está recopilando muchas columnas solo vagamente relacionadas.