Parece que muchas veces en stackoverflow, las personas (especialmente los programadores) tienden a complicar demasiado una solución a un problema donde la solución es mucho más complicada que el problema original. No soy un experto de ninguna manera, pero muchas veces trato de elegir la solución más simple que funcione (y obviamente esto no funciona EN TODAS PARTES), pero he tenido bastante éxito al sugerir soluciones simples en el trabajo que la gente parece pasar por alto para soluciones mucho más complicadas?

¿Es esto algo normal para los programadores ... o simplemente no estoy pensando en la perspectiva correcta?

Obviamente, algunos programadores están ansiosos por mostrar cuán inteligentes son haciendo un código escandalosamente complicado que nadie puede entender. Otros programadores están disparando a un nivel tan alto que la complicación en las soluciones es una evolución natural.

Uno de los peores códigos que he visto fue un método que tenía más de 2000 líneas de código. Sin duda, este código era complejo, pero también era muy pobre.

Creo que un buen programador evita un código demasiado complicado. Esto incluye evitar la tentación de forzar que un patrón de diseño se ajuste a una solución que realmente no lo requiere. También incluye evitar objetos de Dios, botones mágicos, optimización prematura, generalización prematura y otros antipatrones.

Estoy constantemente refactorizando y buscando oportunidades para simplificar mis soluciones porque el crecimiento de la complejidad es algo orgánico. Como muchas otras cosas orgánicas, debe recortarse y podarse si queremos que siga siendo utilizable. Odio tener que interactuar con soluciones demasiado complicadas porque con una mayor complejidad aumenta la probabilidad de romper el código.

Creo que la legibilidad es el elemento más importante del mantenimiento del código, y las soluciones demasiado complicadas casi siempre disminuyen la legibilidad y aumentan los costos de mantenimiento.

He visto un montón de código que era más complejo de lo necesario y casi siempre por estas tres razones:

1) Sobre-diseñado debido a generalizaciones prematuras o tratando de anticipar necesidades futuras que nunca surgieron

2) Los desarrolladores querían aprender / experimentar con un nuevo patrón de diseño o tecnología que no habían usado antes y lo calzaron incluso cuando era excesivo. Lo hacen porque hace que su trabajo sea más interesante y aprenden algo nuevo.

3) Se agregaron características y correcciones de errores, pero el código existente no se refactorizó correctamente en ese momento junto con él. Puede que solo sea una pequeña pieza de duplicación o agregar otro argumento de marca en un método, pero todo se suma. Efectivamente, se agregan hacks y no toma mucho tiempo para que todo se complique demasiado debido a todos los olores de código. Esto es lo más común y generalmente solo por no saber mejor o por la presión del tiempo.

Es absolutamente una cosa común. Como dicen la mayoría de los libros, un buen desarrollador sabe cómo mantenerlo simple. Es demasiado fácil complicar demasiado algo con una nueva tecnología o un marco "genial" que acaba de encontrar, por lo que comienza a buscar formas de usarlo, en lugar de pensar desde la perspectiva de los problemas.

Como dijo Martin Fowler, quienes aprenden una nueva tecnología tienen un problema a corto plazo en el que sus soluciones basadas en "tecnología".

No creo que sea normal para todos los programadores, pero definitivamente he visto a muchos programadores hacer esto.

Creo que algunas personas creen que algunas personas ven hacer algo realmente simple 'demasiado fácil', y que no es un buen escaparate de sus habilidades. Por lo tanto, tienen que hacer una solución grande y compleja que sea la forma de decir "¡mira lo que puedo hacer!", Aunque puede que no sea la mejor solución para el problema en cuestión.

He visto que los programadores suelen escribir varias líneas de código para realizar una tarea que no sabían que ya estaba integrada en el lenguaje. Esto no es exactamente intencional, pero ciertamente puede prevenirse.

Depende de lo que llames "simple". Algunas personas ven el código altamente refactorizado como más "complejo" porque hay más código y múltiples gráficos de llamadas. Sin embargo, este código es más "simple" porque es mucho más fácil hacer cambios.

A menudo encuentro que una función grande parece "simple" hasta que necesita hacer cambios, luego se vuelve compleja rápidamente.

En otras palabras, simple está en el ojo del espectador en muchos casos.

El problema es si no puede ver claramente las soluciones simples (aquí es donde entran en juego las discusiones con colegas) o si generaliza demasiado demasiado pronto.

En otras palabras, crea bucles simples en las funciones avanzadas de la biblioteca porque cree que lo necesitará para su próximo proyecto de todos modos (excepto que no lo hará en esta forma exacta). Haga esto durante demasiado tiempo y tendrá una aplicación inmensamente compleja con un núcleo muy simple.

También puede encontrar que necesita tener un código muy robusto, y toda la robustez lo hace complejo de forma predeterminada. Sin embargo, no creo que este sea tu problema.

En algunos casos, podría ser la complejidad de encontrar una solución limpia / simple.

Hay una cita que no puedo recordar o que encuentra algo que va solo: "El código no se completa una vez que ha escrito todo lo que necesita escribir, sino que se completa solo cuando no le queda nada que eliminar"

La falta de claridad dificultará la capacidad de las personas para eliminar todo el exceso.

Los mejores ingenieros son los que pueden resolver problemas realmente complicados y convertirlos en soluciones fáciles de implementar y fáciles de entender. Suena simple, pero no hay muchos ingenieros / desarrolladores como ese que existan. De hecho, no hay muchas personas así que existan. En realidad, la mayoría de la gente hace exactamente lo contrario. Toman problemas simples y los complican más allá del reconocimiento. Basta con mirar a nuestros políticos para ver un ejemplo de personas que logran resolver problemas simples y convertirlos en un caos total. Los programadores no son diferentes en este sentido.

Personalmente, nunca he intentado intencionalmente hacer que una pieza de software sea más complicada. Sin embargo, terminé algo y pensé "wow, eso es demasiado complicado" y volví a ello y refactoricé. Algunas personas pueden ver esto y pensar que funciona y que es lo suficientemente bueno y no lo refactoriza.

Se alega que un hombre sabio dijo que debería mantener las cosas lo más simple posible, pero no más simple. Lo mismo podría aplicarse al código. A veces hay que usar una técnica que algunos consideran compleja (la recursión puede ser un buen ejemplo, a menudo asusta a los programadores junior).

Sin embargo, en general creo que el código complejo a menudo surge orgánicamente. Un problema simple se resuelve con un código simple, luego el alcance se expande y el código se modifica sin pensarlo demasiado, y con el tiempo se obtiene un código que intenta cubrir el nuevo problema pero que realmente fue diseñado para resolver un problema diferente. Se convierte en una colcha de retazos de diferentes piezas de lógica. Dicho código a menudo puede parecer mucho más complejo de lo que requiere el problema, pero fue así porque cada pequeño cambio parecía, en ese momento, ser la forma más fácil de hacer que el código funcionara.

No creo que la mayoría de los desarrolladores se propongan deliberadamente hacer que el código sea complejo (aunque obtienes el extraño espectáculo de quién usará alguna técnica para demostrar su propia habilidad), creo que el código simplemente se pone así si no se mantiene y refactoriza agresivamente .

Otra razón que aún no se ha planteado es que las personas pueden complicar demasiado las soluciones entregadas para asegurarse de que necesitará sus servicios más adelante para admitir estas soluciones. En otras palabras: para la seguridad laboral.

Tal vez un problema de un error clásico?

30. Revelador dorado.

Los desarrolladores están fascinados por las nuevas tecnologías y a veces están ansiosos por probar nuevas características de su idioma o entorno o por crear su propia implementación de una característica ingeniosa que vieron en otro producto, ya sea que se requiera o no en su producto. El esfuerzo requerido para diseñar, implementar, probar, documentar y admitir características que no son necesarias alarga el cronograma.

• Steve McConnell, Desarrollo rápido.

Sí, a veces complicamos demasiado el código para entretenernos. Principalmente, aunque la percepción de que el código se está complicando demasiado proviene de un participante ignorante o junior en el proyecto.

SÍ ... y he pagado el precio muchas veces.

Mi pizarra ahora tiene una declaración en asteriscos en la parte superior que dice

"Si no es simple, no está bien"

... y cada vez que hago prototipos de algo en la pizarra siempre me llama la atención.

Realmente funciona para mí porque mis diseños complejos se vuelven mucho más simples, lo que se traduce en un código más limpio.