Nunca estoy satisfecho con mi código, ¿cómo comencé a aceptarlo incluso cuando está bien escrito?

Estás atrapado en la codificación por el bien de la codificación.

Su objetivo es enviar software de alta calidad de forma rápida y frecuente, proporcionando valor a sus usuarios.

Si su código pasa las 4 reglas de diseño simple (pasa las pruebas, revela intención, sin duplicación, cantidad mínima de código), ¡envíelo!

Una propiedad principal que busco en el código es lo fácil que es cambiarla más tarde. Siempre que su código esté limpio, bien probado y (relativamente) fácil de cambiar, ¡envíelo! Siempre puede cambiar su código más tarde cuando surja la necesidad.

Perfecto es el enemigo de lo bueno ~ Voltaire

Mientras pueda hacer lo siguiente, siga haciéndolo:

• Aclare los nombres de las variables.
• Eliminar líneas adicionales de código.
• Reduzca las mayúsculas y minúsculas, si no, especialmente las anidadas, para que el flujo de trabajo sea más limpio.
• Reduzca la cantidad de bucles, mejore la eficiencia de las iteraciones de recopilación.
• Mejore los algoritmos para tener menos complejidad.
• Mejora las interfaces de objetos, entrada / salida de métodos, funciones.

No tiene nada de malo. Solo asegúrate de tener pruebas unitarias para proteger tu código cuando realices la refactorización, y no dejes pasar tus líneas muertas.

Si sigue haciendo las cosas anteriores, en algún momento debería ver que usa cada vez menos tiempo para escribir un buen código y optimizar su código más rápido.

Será un poco lento al principio, pero sigue haciéndolo.

Como compañero que sufre, esta es la razón por la cual su código será un poco mejor: le importa y mejorará continuamente. Pero también es por eso que los esfuerzos pasados ​​parecen pobres. Además, con el tiempo, perdemos el contexto que hizo que nuestro código ‘limpio’ pareciera limpio. No importa cuán bien escrito, todavía existe la brecha entre nuestro código y “¿por qué está este código aquí?”

He aprendido que no existe el código perfecto. El siguiente requisito se encargará de eso. Como lo hará un cambio de negocio en el mercado.

Todo ese hermoso código, que suponía que eso siempre sería cierto, ahora es fétido, líneas de espagueti fecundadas, bloqueadas por pruebas TDD que no tienes tiempo para reescribir.

La mejor cita que escuché fue

El código de producción nunca se publica : simplemente se escapa

Yo uso la regla 80/20, si su código 80% en su calidad es hora de seguir adelante. El último 19.9% ​​de calidad generalmente me llevará el 80% del tiempo para llegar al 99.9%. Se hace más fácil mejorar su código cuando se toma un descanso y es hora de refactorizarlo.

¿Cómo se verifica la calidad? Desarrollo guiado por pruebas. Escenarios de prueba positivo, negativo, inverso e inverso.