Últimamente he notado muchas preguntas relacionadas con diferentes técnicas de abstracción, y las respuestas dicen básicamente que las técnicas en cuestión son "demasiado inteligentes". Creo que parte de nuestro trabajo como programadores es determinar las mejores soluciones a los problemas que tenemos que resolver, y la inteligencia es útil para hacerlo.

Entonces mi pregunta es: ¿las personas que piensan que ciertas técnicas de abstracción son demasiado inteligentes se oponen a la inteligencia per se , o hay alguna otra razón para la objeción?

EDITAR: Este combinador de analizador es un ejemplo de lo que consideraría un código inteligente. Descargué esto y lo examiné durante aproximadamente media hora. Luego atravesé la macro expansión en papel y vi la luz. Ahora que lo entiendo, parece mucho más elegante que el combinador de analizador Haskell.

Las soluciones simples son mejores para el mantenimiento a largo plazo. Y no siempre se trata solo de familiaridad con el idioma. Una línea compleja (o líneas) toma tiempo para darse cuenta, incluso si eres un experto en el idioma dado. Abre un archivo y comienza a leer: "ok, simple, simple, lo tengo, sí, ¡¿WTF ?!" Tu cerebro se detiene y ahora tienes que parar y descifrar una línea complicada. A menos que haya una razón medible y concreta para esa implementación, es "demasiado inteligente".

Descubrir lo que está sucediendo se vuelve cada vez más difícil a medida que la complejidad crece de un método inteligente a una clase inteligente a un patrón inteligente. Además de los enfoques bien conocidos, tiene que descubrir el proceso de pensamiento que llevó a la creación de una solución "inteligente", que puede ser bastante difícil.

Dicho esto, odio evitar un patrón (cuando su uso está justificado) solo porque alguien podría no entenderlo. Depende de nosotros como desarrolladores seguir aprendiendo y si no entendemos algo, es una razón para aprenderlo, no para evitarlo.

Principio de KISS

Mantenlo simple, estúpido. Las soluciones inteligentes son geniales, pero a menudo la solución más simple y directa es la mejor.

“La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición no es lo suficientemente inteligente como para depurarlo ".

Brian Kernighan

Los tontos ignoran la complejidad; los pragmáticos lo sufren; los expertos lo evitan; los genios lo quitan. - Alan Perlis

La mejor solución no siempre es la solución más inteligente. A veces las soluciones simples son igualmente buenas.

En Software, siempre debe pensar en términos de mantenibilidad. Si un código es demasiado inteligente para alguien que lo va a mantener, diría que la inteligencia no vale la pena.

Para citar a Brian Kernighan:

“La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición no es lo suficientemente inteligente como para depurarlo ".

la inteligencia es una herramienta; Por sí mismo no es dañino. Solo se vuelve dañino en un contexto donde no es necesario.

"Inteligente", cuando se aplica al código, casi siempre es solo un eufemismo de "innecesariamente complicado".

Leer un código bueno, claro y simple es bastante difícil. Leer el código "inteligente" es como estudiar poesía latina de nuevo.

La confusión surge porque "inteligente" como atributo de una persona tiene un significado completamente diferente. Este caso también puede verse como un ejemplo de por qué es difícil diseñar software para personas reales: porque son ambiguos.

Y debido a que algunos programadores sufren para comprender los protocolos sociales que la mayoría de las personas siguen, que les prohíbe denunciar directamente el código como "innecesariamente complicado", pueden tener dificultades para diferenciar entre los dos significados de la palabra inteligente . Al contrario de lo que algunos puedan pensar, creo que, en última instancia, las mejores "personas personas" (es decir, las personas que tienen empatía, introspección y paciencia) son mejores desarrolladores. Porque saben para quién escribir.

La mayoría de la gente se está centrando en la inteligencia desde un aspecto de "El código requiere descifrar demasiado para descubrir lo que está haciendo" y todas las cosas malas que conlleva, como

1. Nadie más puede resolverlo, y mucho menos mantenerlo / depurarlo.
2. La persona que escribió ni siquiera sabe lo que hace.
3. En realidad, puede no ser tan brillante para empezar
4. etc ....

Todos son puntos positivos, pero hay otro aspecto negativo de la inteligencia y ese es el viejo problema del ego. Esto causa problemas en la línea de

1. Alguien que es demasiado "inteligente" para usar las soluciones de otra persona. ¿Por qué buscar lo que otras personas han hecho cuando puedes inventar tu propia forma de desollar al mismo gato?
2. Alguien que cree haber inventado la mejor solución para un problema a menudo se negará a tomar cualquier información.
3. No permitirá que nadie modifique "su" código incluso cuando haya problemas obvios o se necesite un cambio trivial.
4. Por el contrario, piensan que son inteligentes y necesitan usar la técnica "más reciente" para demostrar cuán inteligentes son, pero no logran manejarlo bien en proyectos personales o en otro código que no sea de producción antes de pasarlo a partes críticas de el sistema.

Todos somos culpables de demasiado ego a veces, pero cuando se interpone en el camino del equipo es un problema.

Good Clever: alta relación entre líneas de código inteligentes frente a líneas de en una alternativa no inteligente. 20 líneas de código que le ahorran escribir 20000 son extremadamente buenas e inteligentes. Good Clever se trata de ahorrarte trabajo.

Bad Clever: baja relación entre las líneas de código escritas y las líneas de código guardadas. Una línea de código inteligente que le evita escribir cinco líneas de código es Bad Clever. Mal inteligente es sobre la "masturbación sintáctica".

Solo para tener en cuenta: Bad Clever casi nunca se llama "Bad Clever"; a menudo viajará bajo los alias "hermoso", "elegante", "conciso" o "sucinto".

Tengo que preguntarme sobre la definición de inteligente de todos.

Personalmente, siento que he sido inteligente cuando tomé un problema complejo y difícil, y lo implementé de una manera muy simple y directa, manteniendo un nivel aceptable de eficiencia.

tl; dr me siento inteligente cuando, durante una revisión de código, mi crítico dice "wow, eso fue más fácil de lo que pensé que sería", en lugar de "wtf es todo esto ..."

Aparte de las respuestas de la teoría enumeradas, a menudo esto se usa en el contexto de demasiado inteligente para todos los demás.

Cambie entre un equipo intensivo de rendimiento de nivel superior y un equipo de mantenimiento de nivel medio en algún momento para ver las diferencias de la vida real en lo que es "demasiado inteligente".

Dejando de lado los argumentos de la teoría, demasiado inteligente a menudo se basa en lo que los miembros del equipo menos calificados pueden trabajar razonablemente, por lo que es muy relativo al medio ambiente.

A veces he sido tan inteligente que me he equivocado.

Performante, mantenible, oportuno y barato son las formas en que mido una solución. Supongo que inteligente también podría ser parte de una solución siempre que no afecte negativamente esas cualidades.

Si el código inteligente + la cantidad de comentarios necesarios para que sea comprensible el código <= código simple, entonces digo ir por el código inteligente. Cada vez.

Creo que el problema surge cuando las personas que escriben "código inteligente" deliberadamente no lo comentan correctamente, porque solo siendo inicialmente incomprensible las generaciones futuras que lo encuentren tendrán que pasar tiempo "apreciando" lo inteligente que es.

Recuerdo una cita que he visto atribuida a muchas personas diferentes, como suelen ser las buenas citas.

Parafrasear:

Cualquier persona inteligente puede hacer el complejo simple, se necesita un genio para hacer que el complejo sea simple.

Tomar una idea compleja y simplificarla para que sea comprensible muestra la inteligencia del constructor, pero tomar una idea simple y hacerla compleja muestra que el constructor quiere ser visto como inteligente.

Si la solución 'inteligente' es difícil de resolver, entonces no debe usarse. Por ejemplo, si a través de los efectos secundarios puede contraer un cálculo complejo en una línea, es inteligente. Pero si le toma una hora a otra persona descubrir qué demonios hiciste, es demasiado inteligente.

En mi opinión, la inteligencia per se no es un problema. Por lo general, podemos hacer confusiones sobre el código "inteligente" (sin sarcasmo) y "insightfull". Lo que veo como un problema es el hecho de que generalmente el código "inteligente" (con sarcasmo) contiene requisitos implícitos no visibles, lo que hace que sea más difícil de depurar y mantener a lo largo del tiempo.

Hay varios algoritmos conocidos que son inteligentes. Quicksort es uno, en mi opinión.

El código "inteligente" (con sarcasmo) generalmente hace suposiciones sobre las variables que se configuran y los estados del sistema que están prácticamente desconectados del código "inteligente" (como archivos abiertos anteriormente, conexiones de red, bases de datos, etc.).

La cantidad de datos que tiene que cargar en su cerebro para mantener correctamente un código "inteligente" suele ser demasiado grande para tener una buena relación costo-beneficio.

El "código inteligente" es cualquier código para el cual el programador tuvo que pensar mucho o usar alguna habilidad avanzada para escribirlo. El problema es que no tiene en cuenta la necesidad de un cierto "margen de inteligencia", mejor expresado por Brian W. Kernighan:

"La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición, no es lo suficientemente inteligente como para depurarlo".

Debido a lo que parece ser la inteligencia a un desarrollador en una explosión de creatividad puede simplemente pasar por desastre y simplemente ser un ilegibles , imposible de mantener el bloque de adivinanzas oscuros para los demás.

Aún así, es un bloque de acertijos agradable, inteligente y de buen rendimiento, pero si tiene la experiencia, a menudo se dará cuenta de que le costará mucho más a su negocio (no a usted, el desarrollador) mantener eso en el medio. o a largo plazo. Por lo tanto, prefiere calmar el ardor de sus compañeros desarrolladores cuando se dejan llevar.

Excepto, por supuesto, si hay una justificación para la inteligencia. Y si hay una buena documentación que viene junto con la cosa ofuscada que acaba de escribir. Comentaste ese código inteligente, ¿verdad? Explique su intención, ¿por qué debe ser así y cómo se comporta?

Si no hay justificación, entonces es probable que sea una optimización prematura, una ingeniería excesiva o un tipo de problema de YAGNI. Si se necesitan 15 niveles de indirección para hacer algo simple, entonces hay una buena posibilidad de que también pertenezca a las categorías anteriores. Y si no está documentado, entonces es solo un problema.

Un gran código no debería requerir que el mantenedor esté al 100% todo el tiempo para entenderlo. El buen código es inteligente. Un gran código puede ser casi tan eficiente, pero mejor en muchos otros aspectos. Un gran código no debería requerir un IDE con 15 vistas para seguir el diseño de su aplicación.

Nota: hey, he escrito algunas cosas que pensé que eran inteligentes pero que atrajeron a WTF. fuera de, si no de mis co-desarrolladores, la boca de mi gerente. Hay que mirarlo desde su perspectiva.

Tiendo a ser inteligente , pero me esfuerzo por ser elegante .

Desarrolle código ahora que otros no intentarán y evitarán más adelante .

Esta es mi comprensión del problema, según mi experiencia y las otras respuestas:

1. El código que requiere inteligencia para escribir, pero resulta legible y fácil de mantener, no se considera dañino. Sin embargo, la mayoría de los desarrolladores no llamarían a ese tipo de código "inteligente"; pueden usar un término diferente como "elegante". Puede o no haber algún debate sobre si ese código existe.
2. El código de producción que requiere mucho tiempo y esfuerzo para comprender incluso por un desarrollador experimentado que esté familiarizado con el lenguaje es "inteligente" y es considerado perjudicial por todos.
3. El código de producción que requiere mucho tiempo y esfuerzo por parte de desarrolladores inexpertos es considerado perjudicial por algunos. He visto respuestas de cualquier manera, y he trabajado con desarrolladores que han dicho explícitamente que preferirían mantener todo "mínimo común denominador".

Yo conozco un chico; él es probablemente la persona más brillante que he conocido. Definitivamente es un codificador increíble, probablemente mejor que yo en toda mi vida en términos de habilidades de programación. Escribe el código como si estuviera escribiendo un documento de Word y puede revertir una lista vinculada como no lo creería. Si quieres hablar sobre cómo escribir un código muy complejo, él es tu hombre y si me encuentro con un problema increíblemente difícil, siempre recurro a él. Sin embargo, trabajar en un proyecto con él en un entorno de equipo es insoportable. No puede enfocarse directamente en el problema comercial y proporcionarle una solución lógica, eficiente y concisa. Para él, una lista de código de 1000 líneas sería mejor que 100. En lugar de utilizar las herramientas que se le proporcionan a través del IDE o el marco, lanzará su propia herramienta súper optimizada.

Si bien admiro su habilidad para hacer estas cosas complejas, lo que necesito es alguien que pueda resolver el problema y seguir adelante. No es bueno decirlo o admitirlo, pero a veces en un entorno empresarial todo lo es y solo tienes que resolver el problema y seguir con tu vida, siempre puedes volver a resolverlo más tarde y refactorizarlo para mejorar tu codigo. Hay una delgada línea entre ser inteligente y también ser un dolor en el trasero. Mi lema para mi equipo es siempre, cuál es la cosa más simple posible que funcionará en esta situación y luego irá desde allí. A veces más simple no siempre es la respuesta, pero es un buen lugar para comenzar.

"Inteligente" en este contexto significa "demasiado inteligente para su propio bien", es decir, algo que funciona ahora pero que será una pesadilla para comprender y cambiar más adelante.

Especialmente si es un truco que explota una característica oscura del lenguaje de programación, o hace uso de efectos secundarios extraños, o es una forma realmente extraña de resolver el problema en el idioma de destino.

Prefiero soluciones simples, me gusta mucho el estilo rubí. Cuando desee, por ejemplo, sumar los primeros 2 elementos de la lista. primero cortas la lista para que tenga un tamaño = 2 y luego la sumas.

Recuerdo que una vez usé 1 lista en lugar de 3 y creé una gran función que fue muy difícil de mantener / cambiar.

en el mundo de hoy no tenemos que sacrificar la claridad del código por el rendimiento (excepto c ++, no tienen que hacerlo, pero lo harán).

Por lo general, cuando necesita ser "inteligente" es solucionar un problema en el código. Si se trata de una solución alternativa y no es muy directa, obtendrá muchas caras confusas u otros efectos secundarios extraños cuando asuma ciertas condiciones (que pueden ser 100% correctas al momento de escribir el código)

Por lo tanto, inteligente == confuso == malo :( Pero también es increíble, ya que los usé para soluciones prácticas a problemas limitados.

Volver a citar por contexto y comprensión más fácil:

"La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribe el código de la manera más inteligente posible, por definición, no es lo suficientemente inteligente como para depurarlo".

Lo que Brian Kernighan escribió aquí obviamente se refiere a convolución, y utilizó la palabra ingeniosamente por error.

"La depuración es dos veces más difícil que escribir el código en primer lugar. Por lo tanto, si escribes el código lo más complicado posible, por definición, no eres lo suficientemente inteligente como para depurarlo".

Circunvolución:

A thing that is complex and difficult to follow.

Inteligente:

Showing intelligence or skill; ingenious

Los programadores educados saben que el código simple es ingenioso. El código que sea lo más inteligente posible debería ser simple por definición. Los programadores educados también evitarán trabajar y escribir código complicado como la peste. También convertirán el código complicado en código inteligente siempre que tengan la oportunidad. El código generalmente comienza enrevesado y aborda la inteligencia, ya que el conocimiento sobre el dominio y la comprensión de la capacidad cognitiva humana en la programación se entiende mejor a través de la experiencia y el conocimiento compartido.

Debido a la popularidad de esta cita y al hecho de que Brian Kernighan es bastante popular en la industria, este mal uso de la palabra tiene un impacto social negativo y, sinceramente, me gustaría ver que el hombre lo aborde. Antes de escribir este artículo, intenté ver si podía simplemente enviarle un correo electrónico, pero no pude encontrar ninguna información de contacto por correo electrónico que entendiera :(.

El impacto social negativo que he visto es que otros programadores excluyen a sus pares más inteligentes, porque ahora ven la inteligencia como un problema. El verdadero problema son los compañeros estúpidos que piensan que están siendo inteligentes al hacer las cosas de una manera unidiomática nueva, e inventando constantemente cosas nuevas cuando no hay ventaja en lugar de obtener y comprender a la comunidad en general y reutilizar las ideas inteligentes tanto como sea posible.

Sin embargo, necesito aclarar que, a menudo, obtener una comprensión es más difícil que inventar la suya. Debido al problema común en la industria de plazos poco realistas, inventar el suyo para su problema de nicho más pequeño se utilizará para ahorrar tiempo. Esto se basa en la observación de que las cosas útiles y reutilizables generalmente apuntan a un nicho más grande, o proporcionan una abstracción útil para la invención. También se basa en el hecho de que las personas se dirigen a grandes nichos para ganar más dinero, cuando a menudo esto hace que la herramienta sea extremadamente difícil de usar debido a la complejidad que implica hacer que algo sea utilizable para un área amplia de aplicaciones.

El otro impacto social negativo es que esto impide el progreso y el deseo de comprender porque en nuestro mundo egocéntrico inmediatamente negaremos nuestra propia falta de comprensión y descartaremos el código como complicado, incluso si, una vez entendida, la idea es realmente muy inteligente.

TODO Me gustaría citar algunas referencias, pero también me gustaría que la falta de referencias no impida mi capacidad de compartir información, así que citaré rápidamente lo que recuerdo como las fuentes de mi información y tal vez encontraré la información real. día (¡o puedes encontrarlo para mí! :)

• La charla de Guido Van Rossum sobre los bucles de eventos y cómo llegó a comprenderlos
• Un empleado de GitHub que declaró que evitan contratar personas inteligentes en Y-Combinator
• Gran parte de la discusión y el aprendizaje que se desarrolla en la comunidad Python. La comunidad de Python es especialmente crítica con las nuevas ideas, pero no descarta las nuevas ideas que no entienden de antemano, y normalmente puede ver las características que al principio se vieron como intrincadas, ver la luz del día como una característica / paquete de lenguaje central.
• Mi propia experiencia y opinión profesional basada en mis observaciones de 10000 pies. Sin embargo, realmente no puedo ver los detalles para iluminar desde el principio :( Espero que su experiencia y observación le digan lo mismo y alguien más pueda comentar a continuación para dar a esta respuesta algún mérito.

¡Siéntase libre de agregar sus propias citas! Además, siéntase libre de agregar comas a mi texto. No he actualizado mi conocimiento del uso de comas en inglés desde hace bastante tiempo ...

Porque a menudo las personas no conocen un idioma, modismos y patrones. Podrían tomar un libro y aprenderlo, pero no lo hacen. Y debido a esas personas, deberías escribir un código simple.

No es una inteligencia. Es un conocimiento.

No pude encontrar la palabra disciplina mencionada en ningún lado, así que voy a contribuir. No quiero publicar la respuesta, pero compartir una idea diferente sobre el asunto, tal vez una que la pregunta original no tenía en mente .

Un desarrollador inteligente es algo bueno.

Sin embargo, antes de la inteligencia vienen otros rasgos. Como te habrás dado cuenta, hablaré sobre disciplina . Un desarrollador inteligente e indisciplinado puede ser muy malo para el mantenimiento a largo plazo del sistema.

Supongamos que surge un error o entra un nuevo requisito. Un desarrollador inteligente pronto podría darse cuenta de que un par de soluciones locales harán el trabajo en 2 minutos. Si ese desarrollador es disciplinado, se abstendrá de aplicar esas correcciones al código fuente y, en cambio, encontrará una manera significativa de componer el comportamiento deseado para el sistema. De esta manera, la próxima vez que surja la necesidad de modificar las piezas de código en particular, el mantenedor tendrá un tiempo fácil para comprender el código e implementar los nuevos cambios sin romper nada. Si no, bueno, te haces una idea.