¿Qué tiene de malo la codificación creativa? [cerrado]

Estaba viendo a Bob Ross pintar algunos "árboles felices" esta noche, y he descubierto lo que me ha estado estresando sobre mi código últimamente.

La comunidad de personas aquí y en Stack Overflow parece rechazar cualquier olor a imperfección. Mi objetivo es escribir un código respetable (y por lo tanto mantenible y funcional), mejorando mis habilidades. Sin embargo, codifico creativamente.

Permítanme explicar lo que quiero decir con "codificación creativa":

• Mis primeros pasos en un proyecto son a menudo sentarme y descifrar algún código. Para cosas más grandes, planeo un poco aquí y allá, pero sobre todo me sumerjo.
• No diagrama ninguna de mis clases, a menos que esté trabajando con otras personas que están creando otras piezas en el proyecto. Incluso entonces, ciertamente no es lo primero que hago. Normalmente no trabajo en grandes proyectos, y no encuentro que el visual sea muy útil.
• La primera ronda de código que escribo se reescribirá muchas, muchas veces mientras pruebo, simplifico, rehago y transformo el hack original en algo reutilizable, lógico y eficiente.

Durante este proceso, siempre estoy limpiando. Elimino el código no utilizado y comento cualquier cosa que no sea obvia. Pruebo constantemente.

Mi proceso parece ir en contra de lo que es aceptable en la comunidad de desarrolladores profesionales, y me gustaría entender por qué.

Sé que la mayor parte de las críticas sobre el código incorrecto es que alguien se atascó con el desorden de un ex empleado, y costó mucho tiempo y dinero arreglarlo. Eso lo entiendo. Lo que no entiendo es cómo está mal mi proceso, dado que el resultado final es similar al que obtendría al planificar todo desde el principio. (O al menos, eso es lo que he encontrado).

Mi ansiedad por el problema ha sido tan grave últimamente que he dejado de codificar hasta que sé todo lo que hay sobre cada método para resolver el problema particular en el que estoy trabajando. En otras palabras, la mayoría de las veces he dejado de codificar.

Agradezco sinceramente su aporte, sin importar sus opiniones sobre el tema.

Editar: Gracias a todos por sus respuestas. He aprendido algo de cada uno de ellos. Todos ustedes han sido de gran ayuda.

No hay nada de malo en code-test-refactor-repeat, solo dile a la gente que estás haciendo prototipos.

Por otro lado, para proyectos más grandes, encontrará que pensar un poco en el diseño por adelantado le ahorrará mucho tiempo en el ciclo oh-crap-now-what!

PD: Las técnicas de diagramación te ayudan a aprender habilidades de pensamiento visual, que son valiosas incluso si nadie más que tú ve tus diagramas.

Siempre prefiero un código claro, legible y simple a cualquier código con diseño visual UML y con diseño, donde la clase / interfaz incluya nombres de patrones como "ItemVisitor" (?!). Diseñar patrones, técnicas OO y todo lo demás son para formalizar reglas. Que las reglas provienen del sentido común.

Es imposible trabajar sin esa formalización (a menos que trabaje solo en su propio proyecto) y la sobre formalización aumenta los costos del proyecto. Nunca ignore las necesidades de otros para comprender su código. El mejor código es el más simple.

Nunca dudes en volver a escribir tu código. Voy a obtener X votos negativos (X> = 10) para esto, pero lo pondré en negrita: la reutilización del código no es lo más importante .

Antes de comenzar a codificar , debe considerar los casos de uso que el código va a implementar. Porque el software debe usarse y no desarrollarse. La usabilidad, la utilidad son dos objetivos más importantes y no importa quién vaya a usar ese software: otros desarrolladores de partes dependientes del proyecto o el usuario final.

Soy muy parecido. Escuche cuando otras personas le cuenten sobre cosas que les funcionaron, pero ignore a cualquiera que le diga lo que "debería" hacer como si hubiera algún imperativo moral. Si encuentra algo que funcione para usted, hágalo. Quiero decir, el resultado final es lo importante, ¿no? ¿A quién le importa realmente el camino que tomaste para llegar allí?

Recuerda: las personas son diferentes . Eso es bueno. No escuches a las personas que intentan que te gusten, y resiste el impulso de hacer que otras personas te quieran y te irá bien.

Parece que eres:

1. Probar cosas para encontrar el mejor enfoque (experimentación, diseño incremental)
2. Reescribiendo el código para limpiarlo (refactorizando)
3. Constantemente escribiendo pruebas (desarrollo dirigido por pruebas)

¡Lo que estás haciendo es increíble! Parece que lo estás haciendo perfectamente bien, especialmente si lo has descubierto por ti mismo y no lo has aprendido de un libro de programación (ágil). Obviamente, hay más en esto, pero tienes los valores clavados. Solo recuerde refactorizar y mejorar el diseño mientras agrega código y no debería ser necesario un BDUF .

¿Ha considerado enfocarse en una característica pequeña a la vez y lanzar después de completar cada característica? Eso podría ayudarlo a deshacerse de cualquier problema de análisis con el que esté luchando y demuestre un progreso real a su empleador.

Además, no sé de qué "comunidad de desarrollo profesional" está hablando, pero si fuera usted, les diría que regresen a sus torres de marfil para que puedan continuar con su trabajo.

Brad, no estás solo. Conozco muy buenos programadores que trabajan exactamente de la misma manera que usted describe. :)

Si limpia su código y sabe cómo hacerlo eficiente y legible, entonces ciertamente también ha desarrollado una idea de cómo escribir código limpio y eficiente por adelantado.

Además, nada se puede planificar por adelantado, y la ruta más corta para descubrir sutilezas es a menudo ejecutar el código y comprender los detalles que se pasaron por alto.

Creo que lo estás haciendo perfectamente bien, y que el estilo de programación que describes es perfectamente válido.

Creo que vale la pena completar las respuestas anteriores con una cita de Alan J. Perlis, del prólogo del conocido libro MIT "Estructura e interpretación de programas de computadora", comúnmente llamado "SICP":

Cada programa de computadora es un modelo, tramado en la mente, de un proceso real o mental. Estos procesos, que surgen de la experiencia y el pensamiento humanos, son enormes en número, intrincados en detalles y en cualquier momento solo parcialmente entendidos. Están modelados para nuestra satisfacción permanente rara vez por nuestros programas informáticos. Por lo tanto, aunque nuestros programas son colecciones discretas de símbolos cuidadosamente elaborados a mano, mosaicos de funciones entrelazadas, evolucionan continuamente: los cambiamos a medida que nuestra percepción del modelo se profundiza, amplía y generaliza hasta que el modelo finalmente alcanza un lugar metaestable dentro de otro modelo con el que luchamos ".

Hay Good Clever y Bad Clever.

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".

Definitivamente puedo reconocerme en la forma en que describe su flujo de trabajo. Aquí está la cosa: cuando comencé a trabajar en un entorno grupal, casi todo eso tenía que cambiar.

El trabajo en el que he estado durante aproximadamente 8 meses ahora es realmente mi primera experiencia trabajando en un equipo de desarrolladores en un solo proyecto. Hasta ahora, literalmente toda mi carrera ha sido como un codificador de lobo solitario que no tuvo que lidiar con todo lo que viene con el trabajo en equipo. Incluso cuando trabajaba en un grupo, siempre era un trabajo bastante aislado: tenía mi proyecto que era MÍO, o mi sección que era MÍO, etc. Era una curva de aprendizaje interesante cuando me puse al día con un Ambiente de trabajo en equipo verdaderamente colaborativo.

Esto es lo principal que me he dado cuenta: si no es muy obvio lo que estás haciendo, probablemente estés escribiendo el próximo dolor de cabeza de un colega. La mayor parte de la inquietud "orientada al proceso" que ves aquí tiene que ver con el hecho de que muchos de nosotros hemos SIDO los colegas con el dolor de cabeza. Y la mayoría de la teoría de gestión de procesos de software tiene que ver con minimizar ese dolor de cabeza.

Entonces, cosas como planificar un plan acordado con anticipación, etc. Se trata de tener un equipo a bordo y sincronizado. Si eres el equipo, ya estás sincronizado contigo mismo, y eso no es realmente necesario.

No hay nada de malo en su enfoque como forma de arte creativo. Si se está desarrollando para beneficio personal, y lo que está haciendo funciona para usted, y lo que encuentra agradable es probablemente tan importante como el resultado final como el producto en sí.

En un entorno de trabajo profesional, si las escalas de tiempo de su proyecto son cortas, tal vez alrededor de 2 a 3 semanas o menos, entonces su enfoque se llama creación rápida de prototipos y es bastante apropiado para las tareas futuras.

Sin embargo, en proyectos más largos, incluso cuando trabaja por su cuenta, este enfoque es probablemente un lujo costoso para su empleador. Pasar unos días del presupuesto del proyecto en el diseño de la arquitectura inicial y luego probar la arquitectura en función de si la administración decide cambiar la especificación por ... normalmente es un tiempo bien invertido y desarrollará sus habilidades para convertirse en un programador / arquitecto más valioso más adelante en tu carrera

Dos perspectivas:

1. Nadie tiene que mantener una pintura.

2. Cualquiera que haya visto a Bob Ross pintar una pintura sabe que las pinturas tienen estructura. Si le quitaras una lección a Bob Ross, sería que planificar con anticipación y trabajar de manera organizada hace que el proceso transcurra sin problemas y parezca simple.

Codifico casi de la misma manera. Comenzaré a escribir y, cuando veo que surgen patrones, refactorizo. De esa manera, puedes pintarte en una esquina, debes saber cuándo sentarte y pensar un problema, pero a veces solo debes apuñalarlo para comprender realmente el problema.

Pero tengo curiosidad por esto:

La comunidad de personas aquí y en Stack Overflow parece rechazar cualquier olor a imperfección. [..] Mi proceso parece ir en contra de lo que es aceptable en la comunidad de desarrolladores profesionales, y me gustaría entender por qué.

¿Cómo podría alguien en Stack Overflow conocer su proceso? ¿Y qué quieres decir con "rechazar"? Naturalmente, el código publicado en una comunidad de programación será examinado críticamente. Pero si alguien ve áreas en las que se puede mejorar su código, eso solo puede ser algo bueno, ¿verdad?

Con suerte, cuando publique una pregunta en Stackframe, limpie su código e intente reducirlo a la forma más simple posible, por respeto a sus lectores (a veces resuelve su propio problema solo tratando de hacerlo presentable para otros), en el que caso cualquier comentario es bueno. Si publica un código que sabe que es malo y sabe por qué es malo antes de publicarlo, no debe tomarlo personalmente si las personas notan que es malo.

También uso tu enfoque. Funciona mejor para mí, ya que reduce el riesgo de ingeniería excesiva.

Lo que hago muy a menudo es resolver un problema con probablemente el menor código posible, lo que generalmente conduce a dependencias evidentemente innecesarias u otros problemas de diseño. Luego refactorizo ​​el código de trabajo en un código hermoso.
Por ejemplo, reduzco las dependencias entre los diferentes módulos a interfaces concisas y pongo a pensar en qué datos se deben guardar dónde, hasta que cada módulo solo dependa de abstracciones muy minimalistas de los otros módulos. Se podría decir, pospongo la decisión final, qué módulo debe tener qué responsabilidad. Pospongo la abstracción.
Pensar demasiado en separar un problema en responsabilidades distintas, en abstracciones distintas, no es bueno. Te obligará a doblar tu implementación para que se ajuste a las abstracciones que hiciste. El código funciona, si produce los resultados que desea y si es mantenible. Un diseño funciona, si puede implementarlo a través de un buen código. Si el código no funciona, lo cambia. Ergo, si un diseño no funciona, necesitarás cambiarlo también. Solo puede ver si un diseño funciona, una vez que lo implementó.

Por lo tanto, tener un boceto simple en mente es suficiente como diseño, antes de comenzar a darle vida. Rediseño, resumen y refactorización según sea necesario .

Creo que si vas a ser bueno programando, al menos a veces tiene que ser divertido, y eso significa ser creativo.

Seguramente cuando se programe en grupos hay al menos estándares mínimos que se deben seguir, no por razones "morales", sino prácticas, cuando se aplican.

Fuera de eso, es interesante y divertido explorar los límites para ver qué se puede encontrar allí. Una vez, cuando trabajaba en un Mini en lenguaje ensamblador, descubrí que podía hacer co-rutinas que podrían cambiar de una a otra con 1 instrucción. Luego descubrí cómo hacer una auto-rutina que podría ir dos pasos hacia adelante, uno hacia atrás, etc. ¿Fue útil? Lo dudo. Ese no es el punto.

Una vez escuché una charla de Edsger Dijkstra, hablando sobre la creatividad en la programación. Mencionó cómo un estudiante encontró una manera de hacer una rotación de n bits de una palabra de n + m bits. Se hizo con 3 bitswaps. Primero intercambias los n bits, luego intercambias los m bits, luego intercambias los n + m bits completos. ¿Útil? No. ¿listo? Sí.

Es bueno sentirse libre de probar cosas que nadie en su sano juicio haría.

Este puede ser un caso de "una talla no sirve para todos". Has hecho que tu estilo funcione para los proyectos en los que has estado, entonces, ¿quién puede discutir eso? Sin embargo, las críticas que está leyendo aquí y en SO pueden estar trabajando en proyectos más grandes o en proyectos que requieren una coordinación compleja entre los miembros del equipo.

Su estilo de desarrollo podría convertirse en un problema si alguna vez estuvo involucrado en proyectos más grandes que implican la cooperación entre múltiples desarrolladores. Es difícil programarlo, es difícil hacer un seguimiento de su progreso, y no hay forma de que sus compañeros programadores planifiquen la parte de su trabajo que depende de saber qué está haciendo su parte del trabajo.

Quizás le interese leer Dreaming in Code para ver qué puede suceder cuando un proyecto grande adopta un estilo de desarrollo similar al suyo.

Hay muchas garantías de que su método no está mal, pero permítanme agregar algo de experiencia personal. Comencé tu camino, pero mientras tanto aprendí el beneficio de planificar de antemano al menos parte de la estructura general, y esto por varias razones:

• El mayor extra es que es más fácil ver qué código se puede reutilizar si se trabaja un poco. A menudo escribo un fragmento de código que, mientras escribo, de repente parece útil para otra parte del esquema general que tengo colgado al lado de mi pantalla (dibujado en papel en un estilo de solo lectura para mí).

• Tener un esquema le permite refactorizar no solo el código, sino también el esquema. A veces estoy ocupado escribiendo una clase que de repente parece útil para alguna otra parte del esquema también. Como resultado, el esquema se vuelve más simple cuando el proyecto se ejecuta en

• Cada vez que actualizo ese esquema también con la entrada requerida y la salida dada de funciones / métodos y ranuras disponibles en las clases. Esto va más rápido para reutilizar bits: no tengo que sumergirme en el código cada vez para verificar qué entra y sale exactamente. Incluso si está en los comentarios, todavía tengo que navegar para obtener los comentarios

De hecho, también uso tu método. Acabo de comenzar, probar, refactorizar, probar de nuevo, cambiar otro bit, etc., pero mi ciclo también incluye el esquema. Y cuando eso está hecho, agrego la información para la próxima que funcione en ese código.

Eso sí, esto es para proyectos en los que trabajo solo. Si trabaja con más personas en el mismo código, planificar con anticipación no es solo lógica, es esencial. Pero supongo que ya lo sabes.

Y como otros dijeron: este es mi camino, su kilometraje puede variar.