¿Muchos desarrolladores tienden a usar patrones complicados cuando no es necesario? De alguna manera, la mayoría de las veces, creo que si realmente encuentra el lugar correcto, el código se verá simple y directo.

Hay un principio de diseño llamado KISS (Keep it simple stupid), que básicamente apoya la idea de la simplicidad como un objetivo de diseño. Sin embargo, lo he visto tergiversado, mal aplicado o mal interpretado suficientes veces, que siento que debería decir un poco más. Los problemas del mundo real no son bonitos, elegantes o ideales, pueden ser complejos y puede haber límites reales a la cantidad de reducción de la complejidad que es posible. Sería mejor decir: “Todo debe hacerse lo más simple posible, pero no más simple”, que es una versión de la navaja de afeitar de Occam que a menudo se atribuye erróneamente a Einstein.

Más corto es más simple antipatrón:

Conduce a un código claro e ilegible.

Mi parte es simple antipatrón:

El servidor se simplifica al hacer que el cliente sea más complicado o viceversa. O a una escala menor entre quien llama y quien llama. Un mejor objetivo aquí sería tener una interfaz simple , significativa y completa.

Incorrecto es un antipatrón más simple:

Se utiliza como excusa para una funcionalidad incorrecta o incompleta.

Más lento es un antipatrón más simple:

Se utiliza para justificar el uso de algoritmos cuadráticos utilizados en lugar de los lineales. A menudo combinado con una tergiversación de la [*] “optimización prematura es la raíz de todo mal” de Dijkstra, lo que significa que los algoritmos malos son aceptables.

Un patrón único para todos (código compartido) anti-patrón:

Intenta simplificar algo tratándolo de la misma manera que otra cosa (aunque la otra cosa es lo suficientemente diferente como para hacer que ambas cosas sean más complejas).

Era un antipatrón refactorizador (más genérico):

Si la refactorización no condujo a un código de mejor calidad, entonces no lo acepte solo porque fue una refactorización.

En caso de que ocurra algo (sobre ingeniería) antipatrón:

Hace mucho trabajo innecesario para proporcionar soporte para algo que probablemente nunca se usará y que probablemente no funcione. A veces, la “simplificación” se justifica por una regla idealista como “no codificar”.

[*] Como se atribuye comúnmente. Probablemente mal atribuido, tal vez en realidad de Knuth.

Estás hablando de sobre ingeniería . Ocurre cuando el desarrollador / arquitecto de software aburrido lee un libro sobre “Patrones de diseño” (o toma un curso sobre él).

Luego quiere aplicar lo que aprendió. Estas son “mejores prácticas”, aprobadas por la autoridad llamada “GOF” (?!) Y son medida de la antigüedad en las entrevistas de trabajo … ¿cómo podrían estar equivocadas?

Joel Spolsky llamó a esas personas “astronautas de la arquitectura”. Crecen principalmente en grandes empresas internacionales y rara vez en nuevas empresas.

Resolver un problema con múltiples superpatrones habla de que conoce los patrones (y está ansioso por escribir código largo). Resolver el mismo problema con una sola línea de código … ¡habla de maestría!

Recientemente vi un video en YouTube que resaltó un punto muy interesante: que el código incorrecto es disciplinado, meticuloso y de acuerdo con todas las mejores prácticas y cosas de codificación. No es un código que escribes por accidente; De hecho, tienes que hacer un gran esfuerzo para hacer algo que se parezca a FizzBuzz Enterprise Edition

Aquí está el video:

TL; DR: Parece que el problema es que algunas personas no son lo suficientemente flojas 🙂

Esta es una pregunta difícil. Lo que buscamos los desarrolladores no es solo el código que funciona ahora, sino el código que puede agregarse en el futuro que extenderá este código o colisionará con él. A veces, una solución “simple” ahora puede venir y mordernos en un año a partir de ahora convirtiéndose en un desastre complicado, a veces un patrón complicado ahora puede ahorrarnos tiempo en el futuro haciendo que el desarrollo de nuevas funciones sea “simple”. A medida que aumenta la escala de un proyecto, se hace más claro que tenemos que elegir entre simple ahora y simple más adelante, ya que cada vez es más evidente que ambos no pueden existir.

Realmente depende del alcance del proyecto. Si el proyecto es pequeño, entonces el código simple y los patrones simples pueden ser la mejor opción, pero para proyectos a gran escala un patrón “complejo” con código simple puede ser una mejor ruta a seguir ya que estaremos desarrollando para mantener en el futuro.

Lo simple es difícil. Asegúrate de tomar esto en ambos sentidos: si tienes esa sensación, significa que puedes hacer cosas difíciles; si sigues trabajando en ello significa que harás cosas difíciles.

No basta con ver dónde se puede mejorar algo, mucha gente hace esto. No muchos continúan haciéndolo (programadores incluidos) porque, bueno … lo simple es difícil.