¿Qué tan 'simple' es una solución KISS real? [cerrado]

Aprendamos un KISS francés:

  

La perfección está en el centro de la ciudad, sin pasarse a más de   ajouter, más lorsqu'il n'y a plus rien à retirer. - Antoine de Saint-Exupéry

Que se traduce a:

  

La perfección se logra, no cuando no hay nada más que agregar, sino   cuando no queda nada que quitar. - Antoine de Saint-Exupéry

Escenario

Necesitas cortar y pellizcar.

Solución A: no BESO

SoluciónB:KISS

En cuanto a una definición exacta : es difícil definir una escala absoluta para medir la simplicidad. Sobre todo porque la verdadera simplicidad impide la verdadera comprensión del problema en cuestión, y eso rara vez es posible. Pero digamos que las soluciones A y B ilustran la diferencia entre las soluciones que tienden a la sobrecomplicación y la simplicidad respectivamente.

"Haz las cosas lo más simples posible, pero no más simples" -Einstein

Mantener el código lo más simple posible, pero no más simple, depende del problema que se resuelva. Mientras el problema que se resuelve tiende a cambiar, también lo hace KISS.

Hay un equilibrio entre la ingeniería excesiva (¡oh, este parece ser un gran lugar para mostrar mis habilidades de Patrón de diseño!) y la ingeniería insuficiente (si solo usara una fábrica no tendría este acoplamiento que me causó para hacer 20 cambios de código ...). El objetivo es la mantenibilidad.

Simple no significa romper buenos principios de programación. De hecho, significa más de lo contrario.

  

¿SIMPLE significa demasiado corto para que funcione pero es difícil de mantener y   extender?

No. Ser difícil de mantener y extender es un gran síntoma de complejidad. De hecho, me parece que convertir el código en extensible conduce a un código más simple, ya que, para empezar, al no tratar todos los casos, puede mantener el código base más simple.

  

¿SIMPLE significa romper muchos de los principios de la POO?

No. La mayoría de los principios de OOP están diseñados para mantener el código más limpio y más organizado, lo que al final es más simple.

  

¿SIMPLE significa hacer trampa?

No. escribiendo duro para mantener el código & hacks bajo el disfraz de mantener los plazos es.

  

¿SIMPLE significa simplemente mantener los plazos sin demoras? etc.

No. Los plazos y la simplicidad de su código son dos cuestiones separadas. Escribir código simple no toma más tiempo para escribir (aunque es un error común).

Esto es muy difícil de explicar porque simple no significa lo mismo para todos.

Ejemplo. Algunos desarrolladores piensan que ?: es simple, pero otros piensan que una declaración if es mejor. Cuando se llega a este nivel, no puedes complacer a todos.

En general, medios simples sin complejidad . Para entender la simplicidad, necesitamos entender la complejidad.

Hay dos tipos de complejidad:

  

Complejidad esencial se refiere a una situación en la que todo es razonable   las soluciones a un problema deben ser complicadas (y posiblemente confusas)   Porque las soluciones "simples" no resolverían adecuadamente el problema.   - Wikipedia

     

La complejidad accidental es la complejidad que surge en los programas informáticos   o su proceso de desarrollo (programación informática) que es   No esencial para el problema a resolver.   - Wikipedia

Puede verificar la complejidad esencial con las siguientes preguntas:

¿Es esta solución simple? ¿Puedo explicárselo a mi compañero en un par de minutos y lo obtienen? ¿Hay una solución más simple al problema? En caso afirmativo, ¿hay alguna compensación entre la solución complicada y la solución simple? ¿Podemos vivir con esas compensaciones? Por ejemplo, muchos programadores cometen un error al micro optimizar todo y su solución (y el código también) se vuelve demasiado complicado.

Comprobando su complejidad accidental:

¿Es el código simple? Si vuelvo a utilizarlo dentro de tres meses, ¿cuánto tiempo me tomará construir el contexto en mi cerebro para poder hacer el cambio que necesito hacer? ¿Todo en mi código fuente tiene un propósito claro y transmite ese propósito de manera efectiva para mí y para otros desarrolladores ? ¿Qué tan difícil es probar mi código? Por lo general, cuanto más complicado es su código, más difícil es realizar una prueba unitaria, por lo que generalmente lo uso como una medida de complejidad. Usualmente quieres clases y métodos pequeños, bien nombrados y enfocados. Los patrones de diseño usualmente te ayudan a lograr estos también.

Si te encuentras con ganas de usar un patrón de diseño solo porque acabas de leerlo, es probable que se presente una complejidad accidental. Si te encuentras con ganas de poner algo porque piensas que 'es inteligente' probablemente introducirá una complejidad accidental.

Espero que esto ayude y no lo olvides: Simple no significa FÁCIL .

Siempre he sentido que los principios detrás de X11 ( enlace ) valieron la pena. No siempre logro este objetivo.

Específicamente, sigo teniendo que recordarme ... "No agregue nuevas funciones a menos que conozca alguna aplicación real que la requiera" y "Si puede obtener el 90 por ciento del efecto deseado para el 10 por ciento del trabajo, use la solución más sencilla".

  

La pregunta es: ¿Puede escribir la definición EXACTA de SIMPLE en términos de   ¿Principio de KISS? -si los hay.

No.

Simple: en este contexto particular es exactamente lo opuesto a complejo. Simple no es necesariamente necesario: toda persona de mente estúpida tiene que entenderlo, pero debes asegurarte de poder entenderlo, incluso si no lo has escrito tú mismo.

La complejidad podría lograrse si las referencias son fáciles de entender: ¡deshazte de ellas! Muchos archivos / clases vinculados entre sí - de ninguna manera! Y código complicado (es decir, bucles encadenados, múltiples capas de ITE, etc.), nadie quiere leer eso.

En mi opinión: es muy fácil agregar otra función, en las clases también puedes agregar funciones privadas, para que no te metas con la interfaz. Entonces, ¿por qué no usar esta ventaja y limitar sus funciones / procedimientos a 50 líneas? Tal vez incluso menos. Consigue algunos nombres significativos. De esta manera usted deja obsoletos la mayoría de los comentarios. De esta manera, sus funciones son fáciles de leer, fáciles de modificar / ampliar.

Por supuesto ... las últimas oraciones habrían funcionado como: En las clases hay disponibilidad para definir funciones privadas, solo usa esta posibilidad para dividir las funciones en 50 liners para que sea mucho más legible (no olvides buenos nombres, por lo que no necesita comentar mucho).

PERO: es mucho más simple (!) leer todo si hay una parada completa que muestra: Terminé un pensamiento, continuemos con el siguiente.

Eso es lo que definiría como simple.