design patterns - ¿Qué tan lejos vas con YAGNI?
design-patterns project-management (14)
Sí, pero...
Tiendo a estar de acuerdo con muchas de sus consideraciones, excepto el "no desacoplamiento", porque el "ello" en YAGNI significa funcionalidad, no para pensar pasos. La introducción de algunas abstracciones (solo las necesarias para el desacoplamiento) dará sus frutos inmediatamente en términos de errores no realizados o errores encontrados y eliminados más rápidamente.
Una manera agradable (porque te ahorra pensar) de introducir esas abstracciones sería utilizar un buen marco web y simplemente seguir su estilo de estructuración de aplicaciones sugerido .
Como beneficio complementario, sería mucho más fácil agregar la seguridad, la internacionalización, el rendimiento y el escalado más adelante y su comportamiento YAGNI ahora debería ser razonablemente seguro.
(Lamentablemente, el argumento solo se aplica si ya conoces el marco web. El conocimiento reina en el reino de YAGNI).
Estoy desarrollando una nueva aplicación web revolucionaria para el mercado empresarial. Claro, muchos antes de mí pensaron que su aplicación web sería revolucionaria solo para descubrir que no es así. (O lo es, pero el negocio no es bueno de todos modos).
Así que estoy pensando, para saber si mi idea tiene alguna tracción con el costo más bajo, seguir un YAGNI extremo:
Sin características de seguridad (es decir, sin usuarios, etc.). Para cualquier cliente nuevo instalo una nueva instancia de base de datos y una nueva instancia de webapp. Cada instancia de aplicación web está protegida por una contraseña del servidor http (resumen o autorización básica, quizás sobre https).
Sin internacionalización. Solo cadena en inglés incrustada en el código fuente.
Sin desacoplamiento Solo páginas web que hablan con la base de datos.
Sin trucos de rendimiento. Sin colas, cachés, temporizadores, trabajos en segundo plano, llamadas asíncronas, etc.
Sin escalabilidad Sin partición de base de datos, sin fragmentos, sin agrupamiento o replicación.
Además, use YAGNI en el nivel micro siempre que sea adecuado.
Solo quiero comenzar el proyecto y alcanzar lo más rápido posible un punto en el que pueda vender (o intentar vender) mis características innovadoras con una interfaz de usuario sencilla y atractiva.
Si el plan falla, lo sabré temprano. Si tiene éxito, veré lo que los clientes quieren en ese momento. ¿Quieren una versión en francés? ¿O quieren usuarios y roles dentro de la organización?
¿Es esto lo que las personas quieren decir con YAGNI, o es este un ejemplo patológico y exagerado de YAGNI?
De todo corazón estoy de acuerdo con el principio de YAGNI, pero aún quieres planear para tener éxito. Si una aplicación necesita una reescritura completa cuando de repente tiene más de diez usuarios, es YAGNI demasiado llevada.
Algunas cosas que vas a necesitar Desde mi punto de vista, los dos puntos más importantes:
No te dispares en el pie al no preparar tu aplicación para la internacionalización. Si su aplicación es buena, la internacionalización estará sobre la mesa un día. Además, la capacidad de manejar caracteres extranjeros mediante el uso de UTF-8 es un requisito absoluto cuando se construye una aplicación desde cero en 2010. La internacionalización puede no parecerle tan importante a un hablante inglés, pero créanme que es esencial y el dolor de la internacionalización una aplicación posterior es horrible.
Piense dos veces acerca de las cosas sin características de seguridad. ¿Qué pasa con una organización o grupo que quiere trabajar con su aplicación con usuarios en diferentes niveles de seguridad? Podría ser que esta sea una característica de la que realmente puede prescindir: tengo un sistema de seguridad detallado integrado en muchos de mis productos que aún no se ha utilizado al máximo. Pero piense bien si su aplicación específica puede prescindir, incluso si tiene éxito.
El punto de que YAGNI es solo un gran principio entre muchos es bueno para recordar; A veces, YAGNI sugiere una decisión, pero hay razones igualmente buenas (o mejores) para preferir otra.
Aquí hay un aspecto en el que siento que algunos defensores de YAGNI pueden ir muy lejos: si te sientes cómodo con OOD / polimorfismo, generalmente te cuesta muy poco "cocer" algunos puntos de gran extensión para usarlos en el futuro, incluso en un prototipo.
Aquí hay un ejemplo ...
Está creando una aplicación web prototipo que incluye la capacidad de mostrar una versión de un informe que sea compatible con la impresión. Necesita trabajar rápidamente, pero tiene la sensación bastante buena de que los steakholders le pedirán la posibilidad de enviar el informe por correo electrónico al final de la línea.
En su código Java del lado del servidor, oculte el conocimiento del hecho de que el informe se está preparando para la impresora detrás de una interfaz. Crea una clase concreta que amplíe la interfaz para mantener esa responsabilidad. En realidad, no se apague y escriba una versión de correo electrónico de la interfaz, porque YAGNI. Pero si alguna vez lo haces, estás listo para agregarlo sin carnicería a tus funciones existentes.
En mi opinión, YAGNI se usa más comúnmente en contexto con un desarrollador que piensa "oh, sería inteligente si también agregamos la característica X. Podríamos necesitarla en el futuro". Nunca agregue funciones que no sean un requisito.
Dicho esto, su código siempre debe estar abierto para modificaciones si su cliente cree que la característica Y es absolutamente necesaria. ¡Una buena arquitectura es imprescindible!
En cuanto a la escalabilidad, colas, almacenamiento en caché: depende. ¿Cuál es el requisito para la aplicación? ¿Es un sitio de intranet utilizado por 10 usuarios simultáneos o es un sitio web popular con millones de usuarios? Depende. Encuentra los requisitos y hazlo, nada más. YAGNI. Si su requisito cambia; cambie su aplicación, debe estar abierta para modificaciones.
En mi opinión, se debe seguir YAGNI de forma predeterminada, ya que permite aumentar la productividad en gran medida .
Hay algunas excepciones, pensó. Por ejemplo, si desarrolla una biblioteca de terceros, necesita pensar al menos un poco antes de tiempo y anticipar las necesidades de algunos usuarios futuros. Eso no quiere decir que deba renunciar completamente a YAGNI, pero no debe seguirlo tan estrictamente como con un desarrollo interno.
Esto es lo que ellos llaman "prototipos". Ve a por ello.
Hay una sutileza entre YAGNI y creación de prototipos.
Cuando es una featuritis solicitada por el usuario, y usted dice que no, eso es YAGNI.
Cuando se trata de implementación (I18N, "desacoplamiento" (?), Colas, cachés, temporizadores, etc.) y te dices que no a ti mismo. Eso no es realmente YAGNI. Eso es prototipos.
La mayoría de lo que tienes aquí no parece estar dorado orientado al usuario. Yo no llamaría esto, precisamente, YAGNI.
Lo que yo haría es:
1) Diseñarlo teniendo en cuenta las decisiones arquitectónicas correctas. La internacionalización y la seguridad son probablemente imprescindibles en este caso.
2) Al desarrollar, cree los ganchos para esos principios que se implementarán más adelante. Entonces, cuando tenga tiempo y presupuesto, puede implementarlos sin hacer una remodelación importante.
3) Luego puede concentrarse en las características que harían volar su aplicación y son más importantes para sus clientes potenciales.
Entonces, creo que en este caso utilizaría más el enfoque de KISS que "YAGNI extremo" como sugirió.
No soy fanático del principio YAGNI; Veo que se usa con demasiada frecuencia en la justificación de software mal diseñado. El software excesivamente diseñado también es un problema, pero "YAGNI" realmente no deja mucho espacio para el análisis de impacto real.
Resulta que en el mundo del software, muchas de las cosas que crees que no vas a necesitar, realmente las necesitarás. Y algo más. Who''dathunkit.
He escrito una o dos aplicaciones que se suponía que eran aplicaciones desechables o remanentes que aún están en producción después de dos años. Son un dolor para mantener.
Especialmente cuando se trata de algo así como seguridad, probablemente lo necesite.
Si llevas "YAGNI" a ese extremo (y evitaré las discusiones sobre si es una buena idea o no, así como las discusiones sobre si es realmente "YAGNI"), deberías estar preparado para refactorizar sin piedad tu base de código para agregar más tarde lo dejas ahora sin crear una Bola de Barro.
Si va a desarrollar verdaderamente una aplicación web revolucionaria para el mercado empresarial, no estoy seguro de cuáles de esas cosas es A int G onna N eed.
También tus ejemplos son bastante específicos. Por ejemplo, cuando dices: "no hay características de seguridad" ... diría que los usuarios son una cosa de la que puedes prescindir, pero desinfectar tus entradas es una que no puedes. Además, la "escalabilidad" no es una cuestión de fragmentación o duplicación de la base de datos, esas son las decisiones que toma después de darse cuenta de que su aplicación no se escala bien.
Prefiero ser cuidadoso al usar YAGNI como una guía de diseño de alto nivel. Lo mejor es que hable de las características de productos extraños o de la flexibilidad extrema de los componentes de software.
Solo mi 0.2
YAGNI es bueno si hay una posibilidad decente de que nunca lo necesitarás. Si no lo necesita ahora, pero está casi seguro de que lo necesitará en un futuro previsible, es casi siempre más fácil adaptarlo por adelantado que más tarde. Cuando justifica que no se implementen cosas que no necesita en este momento, pero que casi con toda seguridad necesitarán YAGNI en un futuro próximo, ahí es donde comienzan los problemas.
YAGNI es un buen principio, pero no es el único principio de diseño. Muchos de los anteriores tienen sentido para obtener un producto frente a los usuarios rápidamente. Pero si, por ejemplo, las páginas web que hablan directamente con la base de datos comienzan a tener código duplicado, descubrirán que la esclavitud dependiente de un principio (YAGNI) con exclusión de otros (en este caso DRY) limitará su capacidad. para responder a su número cada vez mayor de solicitudes de funciones de los usuarios.
YAGNI trata de recordarle que debe ver la diferencia entre lo que puede hacer y lo que debe hacer para satisfacer sus necesidades.
Por ejemplo, si su requisito dice "deje que las personas creen cuentas e inicien sesión", simplemente use los métodos de autenticación predeterminados de su estructura y continúe con el siguiente requisito.
Su aplicación web puede admitir OpenID, Active Directory, Base de datos local, Flat File y un billón de otros tipos de métodos de autenticación, pero puede satisfacer el requisito implementando el más simple. (Para mí, YAGNI implica DTSTTCPW ).
"Puedo hacer cualquier cosa, con tiempo suficiente"
- Todos los programadores que he conocido
Yo diría que si comienzas por tirar todo el sentido común y hacer todo el proyecto de la manera más exdidante posible, entonces lo que terminarás es una gran pila de fallas ... Lo cual no es Revolucionario ( tm).
Si realmente quieres saber si te será útil, haz algunos simulacros de pantalla. Tal vez incluso solo html antiguo codificado duro. Lléveselos a clientes potenciales y ve si puedes meter tu pie en la puerta. Si algunos de ellos comienzan a picar, luego reventar el trasero y construirlo.
Tomará tiempo conseguir un contrato, obtener un pago y conseguir que alguien en el personal de sus clientes empiece a usarlo. Mientras eso está sucediendo, edifícalo.
Lo más probable es que los clientes potenciales vean su aplicación y, con un poco de suerte, le expliquen por qué no funciona. Cambia las maquetas y regresa. Itere cuando sea necesario hasta que tenga un diseño frontal para su producto que alguien esté dispuesto a pagar.