Cómo superar y comprender el algoritmo / código de otras personas

No hay forma de que seas más rápido, excepto quizás practicar. Pero tu amigo puede ayudarte a ser más rápido.

  • Haz que tu amigo desarrolle convenciones de programación que ambos compartan
    • Si hay una técnica que ambos comparten, será más fácil comunicarse a través de la programación. Los programas son tanto para el lector como para la computadora.
    • Es bueno aprender nuevas técnicas, pero tu amigo debería estar dispuesto a explicar lo que logran. Si solo logran mostrar que tu amigo es inteligente, entonces esa no es una buena técnica para usar.
  • Haz que tus amigos comenten su código
    • Algunas veces puedes intuir cuándo el comentario en el código difiere de lo que realmente hace el código. Eso te ayuda a dirigir tu atención.
    • Los comentarios también pueden ser pistas falsas. Los comentarios deben aclarar la intención del código, no lo que hace. Por ejemplo, ‘Esto produce el cálculo X con el propósito de Y’ es más del doble de útil que “Esto produce el cálculo X ‘
  • Haz que tus amigos lo analicen, planifiquen con anticipación y refactoricen
    • Desglosar un problema es bastante útil para que sea más fácil de entender. Aislar cosas en secciones (como objetos, métodos y funciones) en función de las características de los lenguajes de programación es generalmente útil para que no tenga que entender todo de una vez o saltar de un lado a otro para comprenderlo.
    • Planear con anticipación ayudará al no escribir cosas innecesarias. Hay una regla no escrita de entropía en el código. Cuanto más trabaje en un código, más se alejará de su diseño original. Eventualmente, las partes estarán haciendo cosas que ‘no deberían’ hacer a menos que se haga una planificación anticipada para aislar las partes que van a cambiar de las partes que cambian a un ritmo diferente.
    • Refactorizador Siempre es difícil entender el código lleno de características que nunca se usan. Clases que hacen demasiadas (o muy pocas) cosas. ‘Optimizaciones’ significaba hacer algo más rápido, pero también confundir el significado.

Como con la mayoría de las otras cosas, ¡la mejor manera de mejorar es con la práctica! Sea implacable probando su propio código y buscando errores. Además, conozca a su depurador. Muchos errores provienen de cosas como errores ocasionales, como en sus declaraciones de bucle, o de copiar / pegar desde sus propios programas (o de otro modo) y olvidarse de modificar el código pegado. Solo tiene que dedicar su tiempo al frente de la pantalla y comenzará a reconocer los errores comunes, que pueden ser las primeras cosas que verifique al mirar el código de los demás. Estoy un poco sorprendido al recordar mi primer año y recordar cuánto tiempo me llevó depurar algunos de mis programas. Recuerdo varias ocasiones de pasar todo un fin de semana tratando de depurar el ensamblaje con GDB. Ahora estoy en el último año, y de vez en cuando los compañeros de clase se sorprenderán de lo rápido que puedo detectar algunos de sus errores. ¡Mejorarás con el tiempo y la práctica!

Espere y espere que el código se corrija solo.

No, en serio, ser un buen programador también es encontrar errores fácilmente. Y eso a menudo llega cuando dominas un lenguaje de programación y su depurador . Por lo tanto, mi consejo sería mejorar sus habilidades en la depuración.

Sin embargo, si su proyecto amigo es relativamente grande, ciertamente es más difícil encontrar dónde se inició el error desde cero. Entonces, diría que para manejar y comprender su código, debe hacerle las buenas preguntas que le ahorrarán mucho tiempo para encontrar la ubicación del error …

Te dejaré entrar en un secreto. Programación sin ego.

Cuando un compañero de estudios o un empleado venga y te pida ayuda, déjales que abandonen su ego, que también el tuyo. Luego le explican qué hace (o más bien debería hacer) su código. Lo atraviesan con usted mirando.

Y cada vez que tiene un problema, consigue que lo ayuden explicándoles.

El tipo de código que está tomando, escrito por otros estudiantes, acaba de ser escrito. Por un no profesional. ¿Conduciría un automóvil diseñado y construido por un estudiante de ingeniería automotriz que aún no se graduó?

Es difícil entender los errores en el código. Recuerdo haber pasado por el desensamblaje de Internet Explorer hace casi 20 años para descubrir que, bajo Win95, ciertas llamadas a la API simplemente se devolvieron sin un error, del cual los componentes envolventes de Delphi no dieron idea.

No hay atajos que no sean hacer que la persona que lo escribió lo explique.