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

Lo confieso : tengo un problema para "Mantenerlo simple y corto" la mayor parte del tiempo porque tratar de hacerlo de acuerdo con los libros que he leído, los patrones de diseño que he escuchado, etc. me da mucho entusiasmo, un entusiasmo proveniente de la sensación de que estoy en el camino correcto hacia una probable perfección.

Por otro lado, sí, me pone un estrés adicional en términos de cumplir los plazos a veces ...

Pero cada vez que me digo: "¡La próxima vez que sea simple, estúpido!" Me resulta bastante difícil hacerlo "simple" cuando llegue la próxima vez, porque comienza a sentirse extraño ... e incómodo después de un punto.

Entonces empiezo a juzgar mi comprensión de 'simple' ...

¿SIMPLE significa demasiado corto que funciona pero difícil de mantener y extender?

¿SIMPLE significa romper muchos de los principios de OOP?

¿SIMPLE significa hacer trampa?

¿SIMPLE significa simplemente mantener los plazos sin ningún trato? etc.

En realidad, ¿qué es eso?

La pregunta es : ¿Puedes escribir la definición EXACTA de SIMPLE en términos del principio KISS? -si hay.

¡Gracias!

Aprendamos un KISS francés:

La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à jubile. - 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 hay nada más que quitar. - Antoine de Saint-Exupéry

Guión

Necesitas cortar y pellizcar.

Solución A: no BESO

Solución B: BESO

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

"Hacer las cosas lo más simple posible, pero no más simple" -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 el exceso de ingeniería (¡oh hombre, este parece ser un gran lugar para mostrar mis habilidades de diseño de patrones!) Y la subingeniería (si solo usara una fábrica, no tendría este acoplamiento que me hizo 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 que funciona pero difícil de mantener y extender?

No. Ser difícil de mantener y extender es un gran síntoma de complejidad. De hecho, creo que hacer que el código sea extensible conduce a un código más simple, ya que, para empezar, no se ocupa de todos los casos, puede mantener el código base más simple.

¿SIMPLE significa romper muchos de los principios de OOP?

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. escribir duro para mantener el código y los hacks con el pretexto de mantener los plazos es.

¿SIMPLE significa simplemente mantener los plazos sin ningún trato? etc.

No. los plazos y la simplicidad de su código son dos cuestiones separadas. Escribir código simple no lleva más tiempo escribirlo (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 ifdeclaración es mejor. Cuando está por debajo de 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:

La complejidad esencial se refiere a una situación en la que todas las soluciones razonables 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 no es 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 mis compañeros en un lapso de unos minutos y lo recibirán? ¿Existe una solución más simple para el problema? En caso afirmativo, ¿hay compensaciones entre la solución complicada y la simple? ¿Podemos vivir con esas compensaciones? Por ejemplo, muchos programadores cometen un error al optimizar micro todo y su solución (y el código también) se vuelve demasiado complicada.

Comprobando su complejidad accidental:

¿El código es simple? Si vuelvo a hacerlo en 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 lo transmite efectivamente a mí y a 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 hacer una prueba unitaria, por lo que generalmente lo uso como una medida de complejidad. Por lo general, desea clases y métodos pequeños, bien nombrados y enfocados. Los patrones de diseño generalmente también te ayudan a lograrlos.

Si te encuentras con ganas de usar un patrón de diseño solo porque acabas de leerlo, probablemente introducirá 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 sentí que valía la pena tener en cuenta los principios detrás de X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ). No siempre tengo éxito en este objetivo.

Específicamente, sigo teniendo que recordarme a mí mismo ... "No agregue nuevas funciones a menos que conozca alguna aplicación real que lo 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 simple ".

La pregunta es: ¿Puedes escribir la definición EXACTA de SIMPLE en términos del principio KISS? -si hay.

No.

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

La complejidad podría lograrse si no entiendes las referencias, ¡deshazte de ellas! Muchos archivos / clases vinculados entre sí, ¡de ninguna manera! Y código complicado (es decir: bucles encadenados, múltiples capas 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 utilizar esta ventaja y limitar sus funciones / procedimientos a 50 líneas? Quizás incluso menos. Obtén algunos nombres significativos. De esta manera, la mayoría de los comentarios quedan obsoletos. 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 existe la disponibilidad para definir funciones privadas, solo use esta posibilidad para dividir las funciones en 50 líneas para que sea mucho más legible (no olvide los buenos nombres, así que no necesitas comentar tanto).

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

Eso es lo que yo definiría como simple.