Después de escribir el código, ¿por qué siento que "hubiera escrito mejor" después de algún tiempo? [cerrado]

He estado trabajando en mi proyecto de hobby en C ++ durante más de 2 años. Cada vez que escribo un módulo / función, lo codifico con mucho pensamiento. Ahora ve el problema,

do {
  --> write the code in module 'X' and test it
  --> ... forget for sometime ...
  --> revisit the same piece of code (due to some requirement)
  --> feel that "This isn't written nicely; could have been better"
} while(true);

Aquí 'X'hay cualquier módulo (ya sea pequeño / grande / mediano). Estoy observando que, esto sucede sin importar cuánto esfuerzo puse al codificar. Por lo tanto, me abstengo de ver un código que funcione. :)

¿Es este un sentimiento común para muchas personas? ¿Es este lenguaje un fenómeno específico? (Porque en C ++ uno puede escribir lo mismo de diferentes maneras).

¿Qué debo hacer si tengo este sentimiento de refactorización para un código de producción del mundo real, donde cambiar el código de trabajo no me dará muchos elogios, sino que puede generar problemas si falla?

Este fenómeno es muy común y no específico de los programadores. Cada vez que realice una tarea intelectual, notará docenas de lugares donde podría haber mejorado, después de haber alcanzado cierta distancia. Pregunte a cualquier hombre sabio (WO-) que alguna vez escribió una tesis, y ellos le dicen una cosa: "No mirarlo Usted va a encontrar un error en la primera vista."

Básicamente, hay dos cosas para evitar el ciclo de refactorización:

1. Mientras escribe y diseña, intente obtener una perspectiva distante lo antes posible. Haga que un colega mire su diseño / código. Mira de nuevo después de un fin de semana. Míralo cuando estás borracho o drogado (pero cuidado: no cambies nada hasta que estés sobrio).
2. Vive con imperfección. Si simplemente no es bonito, pero funciona bien (léase: hace un buen trabajo al cumplir con todos los requisitos, incluida la extensibilidad y la legibilidad), déjelo en pie y contente con el buen trabajo que hizo, sin esforzarse por el trabajo perfecto.

La refactorización continua es el camino a seguir. Cambiar el código de trabajo no causaría problemas y debería alentarse si se realiza correctamente. Si su código se prueba por unidad, puede refactorizar su código con confianza.

Lo único que puede predecir sobre el código de producción del mundo real es que eso cambiará. No intentes adivinar cómo va a cambiar, qué nuevas técnicas aprenderás mañana. En resumen, no intentes hacer que tu código sea "perfecto". Simplemente hazlo lo mejor que puedas con tu conocimiento actual. Además, asegúrese de que su código sea probado y extensible a fondo.

Paso el 20% -30% de mi tiempo refactorizando el código existente. Trabajo en una empresa de tecnología y la "gerencia" nunca se ha quejado de cambiar el código existente. Sin embargo, me doy cuenta de que esto puede ser un problema en algunas empresas. Martin Fowler incluso tiene una sección sobre él en su libro de refactorización .

En resumen, es un sentimiento común en mi experiencia, pero no es negativo.

Cada módulo / función nace y evoluciona en un mundo de prioridades. Una vez que es suficiente para cumplir los objetivos del mundo exterior, a menudo se deja estancar. En última instancia, todo es andamiaje en servicio para un propósito superior. Sí, debemos ser obsesivos con el código, y sí, eso también puede hacernos estancar. Tal vez sería un buen movimiento para usted alejarse un poco del código en sí mismo y reflexionar más sobre los procesos que ocurren dentro de usted, el productor del código.

¿Es este un sentimiento común para muchas personas? ¿Es este lenguaje un fenómeno específico?

Eso significa que está expandiendo sus conocimientos y puntos de vista.

Si no tiene tareas de mayor prioridad, siempre debe regresar y mejorar su código.

Siempre pensé que una persona toma una clase de matemáticas para fortalecer sus habilidades en la clase anterior. Álgebra parecía difícil, hasta que tomaste Álgebra II; Entonces las habilidades que aprendiste en Álgebra se volvieron útiles. Es lo mismo en programación, escritura, carpintería o cualquier otra cosa.

Al tomar un curso de programación, aprendió sobre If-then-else, que hizo muchas cosas hasta que aprendió sobre los interruptores. Cuando estás aprendiendo algo nuevo, pasas por esta progresión, todos lo hacen.

Tengo la misma sensación cada vez que leo la mayoría del código escrito por mí mismo en el pasado. Esto es bueno, significa que su conocimiento y estilo de codificación ha mejorado con los años.

En cuanto a cambiar el código de producción en funcionamiento, es un gran no-no a menos que haya detectado errores obvios. No solo porque podría ser una pérdida de tiempo, sino más importante ya que la gran mayoría de los errores de software creados son del tipo que se introduce cuando se realizan cambios en los programas lanzados. Estadísticamente es probable que introduzcas errores imprevistos. Si no está roto, no lo arregles.

Desarrollar una aplicación significa mejorarla y mejorarla; Este es un proceso continuo, por lo que mientras programa, gana más experiencia y conocimiento. También significa que también está desarrollando, por lo que cuando revisa su antiguo código puede descubrir que se puede mejorar.

Si no tiene este sentimiento, significa una de dos cosas:

1. Todavía estás en el mismo nivel de habilidad.
2. Su código ya es perfecto (poco probable).