¿Cómo pueden algunos programadores leer el código y solucionar problemas muy fácilmente en una gran pila de software, como una pila de protocolos de red?

Observo que hacen esto al no considerar los problemas generales.

Yo llamo a esto ‘modificación línea por línea’. Por lo general, está bien para ‘errores de una línea’, pero es malo cuando el error es un síntoma de un error de diseño más grande.

Aquí, nuestros héroes veloces introducen rutinariamente connascencia no deseada, donde dos o más fragmentos de código deben cambiar de manera segura, pero sin estar conectados, y debilitar la cohesión del diseño.

Se necesita un gerente muy raro para desafiarlos y entrenarlos en esto. Pero esta señal de inexperiencia ciertamente necesita ser abordada.

Otras razones incluyen una mayor familiaridad con el tema o el código.

El código es difícil de leer en el mejor de los casos, y si tiene algún conocimiento previo que lo ayude a ver por qué un fragmento de código debería estar allí, es mucho más rápido descubrir si aún no es correcto.

¿Yo? Me gusta tomarme mi tiempo y obtener la solución correcta. Restauración en lugar de reparación.

Para corregir errores rápidamente en una base de código desconocida, haga suposiciones. No siempre son suposiciones “seguras”, pero pueden proporcionar una solución rápida. Debes asumir:

• Quien escribió el código maximizó la cohesión y minimizó el acoplamiento, permitiendo pequeños cambios locales.
• Que el error está en el manejo de un “caso límite”, como una condición de carrera, desbordamiento, agotamiento de recursos o datos mal formateados, lo que significa que las rutas de código para manejar condiciones de funcionamiento normales son correctas.
• Que el error es singular: una causa, un efecto, lo que significa que se puede solucionar en un solo lugar.

Estas suposiciones le permiten ignorar el 90% o más del código al buscar la causa raíz. Si las suposiciones resultan ser erróneas, no está peor ya que su inversión en la solución rápida es pequeña.

Me alegra que hayas hecho esta pregunta y soy la persona adecuada para responder según mi experiencia previa.

“Durante mis días de universidad, a pedido de la administración de la universidad, mi amigo había desarrollado 3 aplicaciones web para fines universitarios. Al momento de implementarlos en servidores locales, se enfrentó a muchos errores. Luego, con mi ayuda, resolvimos todos y cada uno de los errores en 2 días “.

Esto no hace que mi amigo sea un programador menos hábil ni yo un desarrollador de habilidades (depurador). Es solo que es extremadamente bueno para hacer el código y, por otro lado, para que el código funcione. Las habilidades de análisis mías son mejores comparativamente. Puedo predecir la causa del error con solo echar un vistazo al mal funcionamiento.

Solo asegúrese de ser bueno resolviendo problemas y analizando para llegar a ese punto.

¡Hola!

El secreto, en general, pero no siempre, es que no mira el panorama general. Apuesto a que llegará un momento en que sus “correcciones de errores” resultarán en un gran desastre si no está considerando el panorama general.

Sigue avanzando lenta y constantemente.

Bueno, al menos parte de eso es talento.

Algunas personas pueden cantar, otras pueden pintar, otras pueden bailar y otras encuentran errores en el código de otras personas.