Formas de romper el "Síndrome del programador perfecto" [cerrado]

Probablemente no soy el único que se siente así. Pero tengo lo que suelo llamar "El síndrome del programador perfecto", que muchos podrían decir que es lo mismo que ser perfeccionista, pero en este caso pertenece al dominio de la programación. Sin embargo, el dominio de la programación es un poco problemático para tal síndrome.

¿Alguna vez has sentido que cuando estás programando no confías o nunca confías lo suficiente como para que tu código esté limpio y sea un buen código que siga la mayoría de las mejores prácticas? Hay tantas reglas a seguir que me siento abrumado de alguna manera. No es que no me guste seguir las reglas, por supuesto, soy un programador y me encanta programar, lo veo como un arte y debo seguir las reglas. Pero también me encanta, quiero decir que quiero y me encanta seguir las reglas para tener una buena idea de lo que estoy haciendo va por el camino correcto ... pero solo desearía poder tener todo un poco más en "control" con respecto a las mejores prácticas y buen código.

Tal vez es una falta de organización? Tal vez es una falta de experiencia? Tal vez una falta de práctica? ¿Quizás es la falta de algo más que alguien pueda señalar? ¿Hay alguna forma de deshacerse de ese síndrome de alguna manera?

Dar prioridad . Lo primero es lo primero. Concéntrese en lo que importa.

Sus prioridades pueden variar, pero en general debe preocuparse por:

• Código correcto
• Código mantenible
• Código limpio
• Código simple y elegante
• Código eficiente

Quizás en ese orden. Sin embargo, el primer punto es el más importante. Sin él, el código es inútil. ¿Qué haces con un programa que no funciona correctamente?

Haz que funcione, todo lo demás es casi irrelevante para resolver los problemas que necesitas resolver. Por supuesto, yo también sufro por esto. Lo que he aprendido que ayuda es centrarse en las soluciones que funcionan . Es suficiente. Eso es el 99% del trabajo.

Es posible que desee pensar en algo como un buen código . ¿Qué es? ¿Qué tipo de gente lo escribe? ¿Cómo escribir un buen código ? Es muy simple. Escribe el código que funciona . El código de trabajo es un buen código. Todo lo demás viene después.

Por supuesto, al escribir código en un entorno profesional, en equipo , el código obvio y legible y el código mantenible se vuelven cada vez más importantes. Sin embargo, todavía la primera tarea es hacer que funcione y centrarse en eso. Solo entonces puede comenzar a refinar y refactorizar para mejorar, si es necesario.

A menudo es bastante obvio que la corrección del código es muy importante; sin embargo, todos fallamos en aceptar su importancia al escribir código. Cortamos esquinas, utilizamos la optimización prematura, tratamos de escribir código elegante incluso antes de tener un código de trabajo escrito. Es la naturaleza humana luchar por la perfección desde el principio, pero la programación y el desarrollo de software son procesos iterativos y existen prioridades. Por lo tanto, nuevamente, haz que funcione , preocúpate por todo lo demás más tarde. Comprenda la importancia del código correcto y esfuércese por él.

Si bien hay toneladas y toneladas de las llamadas buenas prácticas , creo que el sentido común es lo más importante, piense por qué las prácticas se consideran buenas, cuándo y dónde aplicarlas. Sin embargo, no se esfuerce por cumplir con todas las buenas prácticas. No hay reemplazo o sustituto para la experiencia personal. No puede evitar las trampas comunes, sin importar cuántos libros lea, seminarios a los que asista o no. Lo que importa es aprender haciendo, haciendo las cosas correctamente y divirtiéndose, siempre que sea posible.

La forma más sencilla de evitar este problema es cambiar solo lo que duele. No pulir código que sea correcto, legible y mantenible, incluso si cree que algunos cambios podrían hacerlo aún mejor. Pero una vez que, por ejemplo, intente cambiar algo y no se pueda comprender una variable cuyo propósito no esté claro, o una función que sea demasiado larga para comprender, arréglelo. No antes

Eso no significa que no deba esforzarse por obtener un código bueno y limpio en primer lugar, por supuesto que sí, pero debe considerar su primer intento "suficientemente bueno" a menos que se demuestre lo contrario.

Creo que el mejor antídoto para esto es recordarse a sí mismo que todas esas mejores prácticas y reglas de limpieza del código no existen por sí mismas, ni el código en sí mismo.

Al final, lo que importa más que cualquier otra cosa es que el software funciona y se puede utilizar. Y eso no sucederá si no lo terminas.

No me gusta la comparación de la codificación con el arte, pero a este respecto funciona: los artistas ( especialmente los autores ) a menudo también quieren seguir trabajando en una pieza porque siempre hay algo que no es perfecto. Pero, ¿qué valor tiene la perfección cuando retrasa la publicación indefinidamente y, por lo tanto, impide que alguien aprecie el trabajo?

Lo más importante a tener en cuenta es que su código siempre va a cambiar, y siempre hay margen de mejora. Ningún código es perfecto. La mayoría de las veces, una biblioteca de clase en la que trabaje hoy será muy diferente dentro de seis meses. Aprendes alguna técnica nueva o encuentras un patrón que realmente funcione para ti. Mientras el código sea fácilmente mantenible y legible, entonces debería ser bueno. Lo ideal sería tener pruebas unitarias para que sea más fácil refactorizar más adelante.

Es fácil quedar atrapado en hacer que el código se vea perfecto y seguir todos los estándares que se te ocurran. Nos pasa a todos. Mirar el código que escribí hace un par de semanas me hace pensar en hacer cambios. Agregue una propiedad aquí, refactorice el método allí. Y parece suceder al final del proyecto. Pero si te envuelves demasiado en eso, podrías terminar cometiendo un error espectacular. Lo hice un par de veces al principio de mi carrera. Un par de sesiones de corrección de errores de 3 AM me curaron de ese problema.

Hazlo al revés.

En lugar de "¿qué se puede hacer mejor?" buscar "¿qué me molesta?" hasta que nada lo haga.

Como programador, su trabajo es producir código. El propósito de las mejores prácticas es aumentar su tasa de producción haciendo que las cosas sean más fáciles de entender / hacer / recordar. Si adherirse a estas prácticas se interpone en el camino de hacer las cosas, estás haciendo algo mal. Simplemente intente producir código lo más rápido que pueda, y sus prácticas deberían evolucionar para permitirle hacer exactamente eso.

Haz que funcione, hazlo limpio, hazlo SÓLIDO, haz que funcione.

Los primeros tres son un adagio que defiendo cada vez que alguien se pregunta cómo escribir código SOLIDO en una línea de tiempo. Cuando escribes una línea de código por primera vez, simplemente tiene que funcionar, así que haz lo que tengas que hacer y no te imagines. La primera vez que vuelve a visitar una línea de código, ya no es única y debe limpiar el código para que sea legible y, por lo tanto, más fácil de mantener. La tercera vez que su cursor va en esa línea, probablemente sea un gran problema ahora, y debe refactorizarlo para que se adhiera a la metodología SOLID, abstraiga dependencias, implemente patrones y, en general, haga que el código sea más fácil de conectar o enchufar para futuras mejoras.

La elegancia en el código se logrará cuando el programador note una oportunidad, y generalmente es una función de simplificar, limpiar y mejorar en general la legibilidad y la facilidad de mantenimiento del código mientras se siguen los pasos anteriores. No es algo para maximizar .

El código de rendimiento es casi siempre la menor preocupación en los lenguajes gestionados por memoria (Java, la familia .NET, la mayoría de los lenguajes funcionales, etc.). En estos entornos, el objetivo es escribir el código correcto ("correcto" aquí definido como producir el resultado esperado en todos los casos esperados, yes comprensible y bien estructurado, y por lo tanto mantenible), y el rendimiento es secundario (por lo general, procederá en cierta medida del código correcto). En todos los casos, un algoritmo es eficaz cuando es "suficientemente bueno". Recuerde, "la optimización prematura es la raíz de todo mal"; Hacer optimizaciones que no sabe que necesitará hace poco más que perder el tiempo, ofuscar el código y, en general, evitar el progreso. Primero tiene que funcionar, luego, una vez que funciona, lo ejecutas y ves qué tan rápido se ejecuta. Si no es lo suficientemente rápido (como lo define algún punto de referencia que es un requisito publicado), lo mejora hasta que lo es, y luego se detiene .

Realmente necesitas ser pragmático sobre la programación. Sí, a todos nos gusta hacer las cosas bien, pero a usted le pagan por entregar software que funciona, no por pulirlo por el resto de su vida.

El enfoque a seguir es "hacerlo" en su vida profesional. Entregar y seguir adelante. Guarda tu perfeccionismo para proyectos personales.