Como desarrollador de software, a menudo me olvido de cómo un código que escribí funciona a un nivel alto (me refiero a nivel empresarial). ¿Cómo puedo manejar esto?

No estas solo. Casi todos los programadores del mundo tienen esto. Nuestro cerebro no es realmente mágico cuando se trata de recordar cosas. Personalmente lo considero como una unidad de procesamiento especial y eficiente, y trato de evitar que recuerde las cosas tanto como sea posible.

Entonces, re-leer tu código es inevitable, amigo mío. Hay algunos consejos que pueden ayudarte a hacerlo más rápido:

  1. Usa nombres descriptivos para variables, funciones y clases.
  2. Use comentarios para describir lo que hace algo en lugar de cómo maneja el problema.
  3. Mantenga su lógica fluye tan limpia como sea posible. Cuando no esté limpio, divídalo en funciones.
  4. Simplifica tu código. Cuanto más sencillo sea, menor será el tiempo necesario para volver a leer.
  5. Escriba el código con sus lectores (incluido su futuro) en su mente.
  6. Lea libros como Code Complete o Clean Code, son útiles para sus necesidades específicas.

Todos escuchamos esta pequeña palabra sucia “documentación”. La mayoría de los desarrolladores odian hacerlo, pero es tan necesario como escribir un buen código.

Yo trabajo en la industria de la salud, que está muy regulada. Una gran cantidad de código entra en la implementación de dichas regulaciones. A veces, agregar comentarios “de acuerdo con tal o cual regulación” es suficiente documentación, y en otras ocasiones, se necesita una redacción más extensa.

“¿Qué pasa con el código de auto-documentación?” Algunos pueden decir. El código de auto-documentación puede decirnos “qué” hace el código, pero generalmente no “por qué”.

Por lo tanto, los comentarios de alto nivel son esenciales para comprender qué hace el código y por qué está allí, especialmente un año o más después de que se escriba. Doblemente así si el lector no es el tipo que originalmente escribió el código.

Documento. Documento. Documento. Te lo enseñaron en la escuela. Tenían razón. El problema es que a medida que desarrollamos y probamos encontramos que nuestras especificaciones originales necesitan ser cambiadas. ¡Así que necesitamos cambiar realmente las especificaciones!

Los comentarios de encabezado, los comentarios en línea y la documentación adecuada son tus amigos. Usalos, usalos a ellos.

entonces no has estado comentando y documentando tu código