Cómo convencerme de tolerar un código imperfecto que creé para poder dedicar tiempo a cosas más importantes

Convencerse a uno mismo de tolerar un código imperfecto es generalmente algo que se hace para proyectos de trabajo, donde lo perfecto es enemigo de lo bueno.

Como se trata de proyectos personales, creo que está bien luchar por la perfección.

Pero si se convierte en una obsesión poco saludable, algunas cosas en las que pensar:

• El código puede ser imperfecto, pero lo compartí con GitHub, por lo que otros aún pueden mejorarlo. Incluso puedo ayudar a otros a aprender dándoles la oportunidad de mejorar este código.
• Este código es imperfecto porque no soy lo suficientemente bueno como programador. Pero he aprendido de ellos, y es hora de seguir adelante.

1. Reconozca que cada vez que cambia el código de trabajo, está presentando un riesgo de errores. (Ese riesgo puede ser aceptable, o incluso inevitable, si agrega una nueva función o arregla un área que ya tiene errores).
2. Trate de trabajar en las compensaciones de costo / beneficio en su mente. Hay momentos en los que observa una característica y piensa “Sería bueno tenerla”. Cuando lo miras un poco más, podría resultar que tomará mucho más tiempo de lo que pensabas. En este punto, debe reconsiderar si la función aún vale la pena. Tal vez lo sea, y tal vez no lo sea. Un código más perfecto es una característica, por lo que debe mirar el costo / beneficio de ese código.
3. A menudo, el código más perfecto de una persona es el código menos perfecto de otra persona. A veces, estas son solo una cuestión de convenciones o preferencias personales, y cambiar las cosas que alguien más hizo para que coincidan con sus preferencias personales podría no ser el mejor uso de su tiempo.
4. Cree errores o elementos de seguimiento para las cosas que desea arreglar, y dedique algo de tiempo para dedicar a solucionar los que más le molestan. Eso le permite priorizar los que realmente le atraen, y si realmente programa el tiempo, evita que se vuelva loco por la cantidad de tiempo que dedica a ese tipo de artículos. Programa un promedio de 4 horas por semana laboral en este tipo de “impuesto”.

Ciertamente no soy la mejor persona para hablar de esto, pero creo que no debes renunciar a tratar de hacer que tu código sea perfecto (donde “perfecto” se define como “tan simple como puede ser mientras haces el trabajo” )

Sin embargo, priorice las cosas que necesita refactorizar (impacto versus esfuerzo) y considere si se deben dejar algunos cambios más profundos para la “versión 2”.

No se deje atrapar también por infinitas reescrituras: si nada ha cambiado significativamente en la tecnología subyacente o en su mente, no hay razón para creer que la próxima versión será mucho mejor que la actual. Solo concéntrate en refactorizar en este caso.

Para ayudar con la refactorización, intente construir su programa a partir de componentes ortogonales que le otorgarán simplicidad actual y libertad de acción futura.

La gente dice en retrospectiva que todo es fácil, así que llegue a ese punto y aproveche el hecho de que el código no está escrito en piedra stone

En mi opinión, el código es solo una herramienta para expresar mi mente. Como poema al poeta.
La pregunta que hizo no es un problema para mí. Porque como mi mente, no busco lo perfecto. Solo me concentro en su crecimiento.
Sobre el código, solo escribo de manera concisa y efectiva. Porque aunque tu mente es perfecta, el código no es tu mente misma. El código denota tu mente.
Entonces, la forma en que mido mi código no es el grado de perfección, sino el grado en que se expresa y el grado en que se expresará continuamente.
En realidad, el código al igual que el software es evolutivo. Tu mente tampoco es inmutable. Así que codificar para el futuro es la mejor práctica.

No voy a mentir, a veces es difícil. Especialmente cuando ves algo que es claramente ineficiente en un código que sabes que se llamará con frecuencia.

Sin embargo, una cosa a tener en cuenta: a menudo, el código que está viendo fue escrito por alguien muy inteligente, y tenían buenas razones para hacer lo que hicieron. Si tienes suerte, dejaron un comentario explicando por qué el código es como es. Si tienes más suerte, ese comentario sigue siendo relevante. Por ejemplo, he visto muchas construcciones extrañas que se implementaron debido a errores del compilador: el compilador rechazó la forma “simple”. Pero nadie volvió después de actualizar los compiladores para ver si ese hack todavía era necesario.

Entonces, supongo que si hay una respuesta breve, sería “si no está trabajando activamente en algún código, asuma que hay una buena razón para que el código sea como es, y continúe. Si usted” está convencido de que el código debe irse, tome una nota para analizarlo más tarde, o al menos hable con alguien más de su equipo para ver si conocen el historial.

Ver nuestras propias imperfecciones personales podría ser nuestra única oportunidad para crecer.
Las imperfecciones de las que somos conscientes en nuestro trabajo también son oportunidades. Que suerte tienes La conciencia es fruto cognitivo.
Muchas instalaciones que está creando ya existen en idiomas como Haskell.
Recrearlos en un lenguaje tan expresivo y poderoso es conveniente y gratificante. Un idioma como Racket podría incluso ser mejor, ya que puede crear idiomas específicos de dominio con tanta facilidad.

Date cuenta de que tampoco eres perfecto. Por lo tanto, cualquier cambio que realice probablemente introducirá posibles errores y complicaciones. Cuanto antes se dé cuenta de esto y adopte un enfoque más práctico, mejor.