¿Qué patrones de diseño tienen más probabilidades de ser utilizados por los programadores principiantes sin darse cuenta?

Esta pregunta me hizo sonreír un poco. Es probable que los programadores novatos piensen que están usando algún patrón de diseño específico, pero en realidad no lo siguen correctamente … y no se dan cuenta. Esto es solo una cuestión de experiencia. No puedo pensar en ninguna circunstancia en la que accidentalmente use un patrón de diseño. Es mucho más probable que accidentalmente no esté utilizando un patrón de diseño específico.

En general, no es una buena idea usar patrones de diseño “por accidente”, ya sea que sepa que lo está haciendo o que se vea forzado por el marco que está utilizando (y si realmente desea convertirse en programador, se da cuenta de que lo está utilizando eso). El más común es MVC: casi todos los marcos de UI lo implementan hoy en día (pocos ejemplos de Ruby on Rails, PHP Cake, ExpressJS, .NET MVC, etc.). En Java y .Net, puede utilizar con frecuencia el Método de fábrica para crear una instancia del controlador de base de datos para una base de datos específica. Los singleton también son bastante comunes, una vez más en Java y .Net, pero también en otros idiomas. Si se refiere al conjunto completo de Gang of Four, hay algunas estructuras integradas en los lenguajes modernos o bibliotecas estándar que usan esos patrones y los programadores novatos no se dan cuenta de que los están usando, lo que (como Peter Roca menciona a continuación) hace los usan de manera inapropiada.

Si puede llamarse como un patrón, GTD (Hacer las cosas) es probablemente el más común. El lenguaje podría ser cualquier cosa, pero el “olor a código” debería ser relativamente el mismo: demasiado complejo, no optimizado, falta de documentación en línea y convención de nomenclatura incorrecta (en una variable o función).

Cuando un desarrollador inexperto intenta escribir código, generalmente tiene total autonomía para el código, y esto continúa hasta el punto en que solo ellos pueden entender el código. Debido a la falta de ciclos de lanzamiento, pruebas unitarias, bloque de documentación, tienden a producir elementos incompletos. Y aunque esta actitud puede servirles bien por un tiempo, impresiona al jefe y hace que el programador se sienta bien consigo mismo y confirma la idea de que él sabe lo que está haciendo (aunque no lo sabe), a largo plazo no lo haría.

Lo bueno es que, después de 7 años, APRENDERÁN de vez en cuando y comprenderán lentamente cómo escribir un mejor software y un sistema más predecible, adoptando un “patrón de diseño” común.

PD: Así me vi hace 7 años.