Estilo de codificación (hacer más, luego simplificar) [duplicar]

Me suena como un buen hábito. La primera regla en la codificación es hacer que funcione. Una vez que haya hecho eso, limpie su código y hágalo limpio, comprensible y más simple si puede.

Sin embargo, si pasa mucho tiempo diseñando su solución y perdiendo mucho tiempo creando cosas que no es necesario que existan, es posible que sea un mal hábito, como si estuviera creando un montón de clases y simplemente yendo un poco excesivamente loco de disgusto. Pero mientras esté trabajando para "hacer que funcione", entonces no suena como si fuera un problema.

Mi respuesta puede ser un poco fuera de tema, pero este método funciona para mí.

Antes de comenzar a programar, debes pensar: qué tipo de estructuras necesito para resolver un problema y qué tipo de algoritmos.

A menudo encontrará que la solución ya existe y que solo tiene que implementarla en su proyecto *. Nunca intentes reinventar una rueda: si necesitas algo, siempre existe una gran posibilidad de que alguien ya lo haya hecho mejor.

Una vez que lo hagas, solo te quedarán con pegar esas partes (algoritmos y estructuras) juntas, y eso suele ser más simple que pensar en un problema en su conjunto.

* Es por eso que la educación es tan importante en TI. Cuantos más algoritmos y tipos de estructuras conozcas más a menudo, durante la programación te encontrarás pensando: "Oh, lo sé, tengo que usar esto . Oh, y aquí necesito usar que . "

Ese hábito es típico de TDD. Primero implementarlo y luego refactorizarlo. Creo que cada desarrollador no implementa la mejor manera en su primer intento. Mientras tenga pruebas unitarias para verificar que todo sigue funcionando después de la refactorización, no hay problema con eso.

Encuentro que cuando trabajo en el papel lo que quiero hacer antes de tiempo, hago un código menos innecesario. A veces termino con varios borradores en papel, por lo que sigue siendo un proceso iterativo, pero las iteraciones tienden a ser más rápidas, ya que no es necesario trabajar con el código de trabajo para darse cuenta de que algo que creías que era una buena idea ganó. no funciona después de todo (Ni siquiera tiene que ser tan detallado como el pseudocódigo; un simple dibujo puede ser muy útil. Además, no hay nada mágico en el papel, las pizarras también funcionan bien).

La limpieza del código es un buen hábito, pero también lo es apuntar a un código limpio en primer lugar. Aún tendrás que limpiar las cosas incluso si planificas con anticipación, pero para empezar no tendrás tanto desorden.

Escribir y reescribir el código no es un problema, ni escribir más código del que es absolutamente necesario. Cada vez que escribe un código y lo desecha o refactoriza, está aprendiendo; de hecho, posiblemente sea la mejor manera de aprender. Tratar de ser "óptimo" con respecto a su tipo de codificación o tiempo de escritura es realmente perjudicial para todos los involucrados.

Además, todas esas variables "Extra" son a menudo una buena idea: si te ayudan a entender tu código inicialmente, ¡es mejor dejarlo ahí! No caigas en la trampa de escribir código mínimo pensando que es la forma de hacerlo legible, el código Terse no equivale a legible.

Le sugiero que no se entusiasme demasiado con "Eliminar" su código. Si es absolutamente innecesario, claro, pero crear funciones adicionales y más variables tiende a ser algo bastante bueno, si las elimina una vez que comprende la solución, solo está perjudicando a todos los que miran el código después de usted (incluido usted mismo unos meses). más tarde).

Sin embargo, es importante mantener tu código en SECO, de hecho, ese es el principio más importante en todo el desarrollo de software, pero una vez que tu código está en SECO, reduce aún más la verbosidad de lo que te ayudó a comprenderlo y diseñarlo. suele ser perjudicial.

Los mejores codificadores y codificadores promedio suelen tener un código similar, la diferencia es el tiempo que tardan en hacerlo. Si se toma el tiempo de planificar y resolver el problema antes de comenzar a codificar, lo ayudará a convertirse en uno de los mejores codificadores. Obviamente, no podrá prever todos los problemas, por lo que tendrá que hacer que las pequeñas cosas funcionen y eso puede causar muchos problemas, por lo que lo que está haciendo se llama refactorizar el código (y esta es una buena práctica). Lo mejor que puedes hacer es resolver primero el algoritmo en papel y descubrir cómo vas a realizar la tarea. Luego codifíquelo y haga que funcione, luego refactorice para limpiar, hacer más legible y optimizar. Observe cuánto tiempo le lleva resolver / codificar / depurar y, de esos tres, la depuración debería tomar el menor tiempo posible, luego codificar un poco más y resolver el problema la mayor cantidad de tiempo. Espero que ayude.

No hay nada malo con este habbit en mi opinión. Cuanto más tiempo codifiques, mejores serán tus habilidades de codificación y resolución de problemas, por lo que todo el código "adicional" se reducirá.

He estado trabajando como ingeniero junior de software durante aproximadamente dos años, y sigo usando este tipo de enfoque, con la diferencia de que a medida que el tiempo ha pasado, he estado más a menudo dirigiéndome directamente al campo. solución / algoritmo.

Las variables de prueba siguen siendo algo común para mí, pero se usan mucho más eficientemente.

Por lo tanto, no se preocupe realmente, solo asegúrese de mantenerlo lo más limpio posible y use muchos comentarios y regiones.

Intente marcar su código extraño si es posible. Las verificaciones de variables se pueden escribir como aserciones , por ejemplo, que agregan información semántica a su código, es decir, estas propiedades deben cumplirse, etc. Dado que las aserciones generalmente se eliminan en "modo de lanzamiento" (dependiendo del idioma / plataforma), no es necesario eliminar muchas aserciones, pero pueden funcionar como una ayuda adicional de depuración al cambiar partes de su programa.

De manera similar, para las variables temporales que utiliza para la depuración de código, nómbrelas con el prefijo debug_ o algo similar, para que pueda indicar su propósito de inmediato. La programación es un proceso iterativo, por lo tanto, lo que haces es perfectamente normal.

Una cosa a tener en cuenta: las afirmaciones pueden ser incluso mejores que los comentarios para explicar su código. ¡Úsalos (sabiamente)!

La verbosidad es muy común para los programadores junior, pero usted está más avanzado que usted es consciente de esa verbosidad y trata de eliminarla.

Al principio, puede parecer un buen hábito que siempre refactoriza, pero si necesita una gran cantidad de refactorización después de la primera vez, significa que debe mejorar su rendimiento de codificación inicial.

Refactorizar más a menudo es la clave. No espere hasta que finalice su implementación antes de refactorizar. Si tu función es demasiado larga, haz una nueva función. Si su código es repetitivo, haga una función con él. Piense en refactorizar todo el tiempo cuando codifique, no solo después de terminar de codificar.

La refactorización constante lo ayudará cuando necesite revisar lo que ha escrito y es más fácil de depurar. Es común que su código no funcione correctamente después de la primera vez, e incluso usted mismo, pocos días después, podría olvidar su propia lógica si su código parece un desastre.

Supongo que tener problemas para "prever lo que se necesita" es natural, dada su corta experiencia: apenas está empezando a aprender a escribir programas. Se necesita mucha prueba y error para aprender a diseñar y esa es la habilidad necesaria para evitar la codificación extraña. Parece que estás en el camino correcto.

Tal vez usted ya escribe comentarios detallados, pero si no, puede intentar usar los comentarios como una herramienta de diseño a pequeña escala. Intenta escribir las descripciones primero. Antes de escribir una sola línea de código en un método, escriba una descripción para él: qué hace, qué parámetros toma y qué devuelve, qué efectos secundarios tiene y qué tipo de excepciones podría lanzar. También puede describir la implementación utilizando comentarios antes de escribir código. Lo mismo ocurre con las clases o los módulos: intente describirlos como un todo antes de profundizar en los detalles y la implementación.

Este enfoque te obliga a diseñar algo antes de codificar. También podría llevarlo a pensar primero en la estructura, que será esencial en el futuro.

La secuencia habitual es 'hazlo correcto, luego hazlo elegante, luego hazlo eficiente'. El primer paso puede resultar en un código tan largo como sea necesario, siempre que pueda hacer un seguimiento de lo que está pasando.

El refinamiento gradual del código es un proceso continuo, e incluso los mejores programadores dicen que algunos de sus Los días más productivos fueron cuando eliminaron 1000 líneas de código . Debería preocuparse cuando no pueda simplificar su código grande y complejo, no al revés.

El enfoque "Haz más, luego simplifica" tiene un gran inconveniente: los métodos grandes y complejos son muy difíciles de probar. Y desea una prueba que documente que su código refactorizado produce los mismos resultados.

Por lo tanto, realmente necesita comenzar a pensar en separar las preocupaciones lo antes posible, o de lo contrario pasará mucho tiempo luchando con pruebas de unidad realmente difíciles, que podrían evitarse. Necesitas pequeñas piezas de código desde el principio. Para mí, la comprensión del "Principio de Responsabilidad Única" (SRP) fue muy importante en este contexto. Además, la inyección de decencia juega un papel muy importante aquí.

Es difícil hacer esto al principio (todavía lo es para mí muchas veces), pero a medida que adquiera experiencia, poco a poco aprenderá a identificar patrones en el código y sabrá cómo dividir esos patrones en simples. y estructuras comprobables.