Convertirse en un mejor solucionador de errores

Me encanta ser programador. Ahí lo dije. Sin embargo, dicho esto, me he dado cuenta últimamente de que realmente no puedo soportar la corrección de errores. En absoluto.

De hecho, mientras estoy desarrollando algo, mi productividad es extremadamente alta. Incluso cuando escribo pruebas unitarias y realizo mi propio desarrollo, generalmente soy muy productivo. Puedo concentrarme bien y puedo hacer las tareas.

Sin embargo, cuando llega el momento del control de calidad y estoy trabajando para corregir errores, mi inspiración toma una caída en picado masiva. Tengo que forzarme con medidas bastante extremas (ya sabes, música alta en BPM, cantidades excesivas de cafeína, etc.) para hacer algo . Mi trabajo generalmente está involucrado en entrar en un proyecto masivo existente y agregar nuevas características o corregir errores, por lo que no puedo decirle exactamente a mi empleador que necesito un par de semanas para escribir pruebas unitarias para todo su código :) Además, el La tecnología de servidor que utilizamos a menudo es muy prohibitiva tanto para las pruebas de unidad como de integración, ya que tiene bastantes problemas con el cargador de clases Java. No estoy completamente en contra de la corrección de errores, a veces puede ser divertido, pero no es divertido en absoluto cuando tiene que hacer cambios menores y espere de 30 segundos a 3 minutos para poder ver si funcionaron o no (debido a la forma en que funciona el sistema).

¿Cómo puedo mejorar mi productividad y motivación al corregir errores? ¿Es esto algo con lo que lidian la mayoría de los programadores?

no es divertido en absoluto cuando tienes que hacer cambios menores y esperar 30 segundos a 3 minutos para poder ver si funcionaron o no

Ese es el verdadero problema aquí. Te sientes improductivo cuando tienes que esperar tanto tiempo para recibir comentarios, lo sé. Quizás sea posible falsificar más servicios y crear mejores herramientas de prueba para que pueda obtener comentarios inmediatos.

El código heredado de pruebas unitarias es costoso o puede implicar refactorizaciones peligrosas. Sin embargo, crear mejores accesorios de prueba puede permitirle realizar pruebas manuales en segundos en comparación con minutos y puede obtener casi la misma productividad que trabajar con el nuevo código comprobable de la unidad.

Esperar tanto tiempo por los comentarios es aburrido y desmotivador, no el acto de corregir errores en sí.

La corrección de errores es una habilidad extremadamente importante que debes aprender. Leí en alguna parte que, normalmente , uno pasa el 80% del tiempo arreglando el 20% de los problemas en una aplicación.

Creo en aprender de los errores, y la corrección de errores es una oportunidad para aprender de los errores de otros . Puedes aprenderlo y serás un mejor programador en el futuro. Esta es la motivación que tuve cuando comencé a corregir muchos errores y avancé a refactorizar el código .

Personalmente, he encontrado útil dejar de pensar en los errores como 'pequeñas cosas', sino más bien como grandes exhibiciones que son tan importantes como las grandes características, a pesar de que solo implican cambiar algunas líneas de código después de horas de depuración. De esa manera, pasar un día entero para matar 3 entradas del rastreador de errores es mucho menos deprimente (el enfoque depende un poco de tu capacidad personal para convencerte de que lo crees :-).

Tal vez sea útil convertirlo en un juego, por ejemplo, junto con sus compañeros de trabajo (¿ quién repara la mayoría de los errores al día? O, lo que es peor, ¿quién hizo el menor número de reconstrucciones al día? )

He estado en tus zapatos. Cree pruebas automatizadas cuando y donde pueda. No tiene que ser todo a la vez. Cuando encuentre un error, tómese un minuto para intentar programar un caso de prueba. Si no puede programar un caso de prueba, escriba un resumen rápido en algún lugar sobre cómo probarlo manualmente, por ejemplo, haga clic aquí, escriba esto, etc. y póngalo en algún tipo de base de conocimiento.

La depuración puede ser muy aburrida, especialmente con código complicado que no escribió. Proponga un objetivo, "Arreglar el error 13533 para el viernes". Luego, establezca una recompensa si cumple con el objetivo: "Tomar una pinta con mis amigos el viernes por la noche". Esto ayudará a que sea un poco más gratificante.

Aparte de eso, a veces el trabajo es solo eso ... trabajo.

En este tipo de situación, necesita algún tipo de desafío creativo. Normalmente, está escribiendo código, pero aquí no lo está.

Pero no todo está perdido. Trabaja en resolver tus metaproblemas y pon tu energía en eso. ¿ Por qué tarda de 30 segundos a 3 minutos en recibir comentarios? ¿Cómo puedes acortar ese tiempo? (Tal vez pueda escribir algún tipo de script o aplicación de utilidad que no registre que lo ayude a hacer esto). Ese es su nuevo dominio problemático: su nuevo desafío creativo.

Personalmente, cada vez que estoy en una fase de reparación de defectos, identifico mis mayores barreras para hacerlo de manera rápida y sin dolor, y automatizo lo que necesito automatizar para eliminar esas barreras. Esto a menudo resulta en una mayor productividad y adiciones a mi cartera personal para arrancar.

En resumen, yo diría "siempre estar en desarrollo". :)

¿Es su problema de depuración o corrección de errores? Si puede depurar lo suficiente como para aislar el componente que está causando el problema, considérelo como una nueva tarea de desarrollo.

1. Escriba algunas pruebas unitarias solo para el fragmento de código que se está rompiendo. Asegúrese de tener pruebas que validen toda su funcionalidad deseada, más algunas que aíslan particularmente el comportamiento defectuoso.
2. Escriba un nuevo código que pase todas las pruebas que acaba de escribir.
3. Reemplace el código antiguo con el nuevo.
4. Ejecute algunas pruebas de integración. Aquí es donde se encontrará con los reinicios del servidor de tres minutos, pero debería minimizarse si realizó bien los pasos 1-3.
5. Voila!

Tal vez deberías mirar a Debugging Myself de Brian Hayes , un artículo que apareció en American Scientist en 1995. Podrías tomar medidas (como el uso habitual de las Condiciones de Yoda ) para reducir o eliminar los tipos de errores más odiados que produces.

Soy de la opinión de que la depuración es una habilidad diferente a la programación, aunque está relacionada. En particular, la depuración de programas multiproceso es casi completamente diferente a escribirlos.

Si el desarrollo de software es aburrido, lo estás haciendo mal. En otras palabras, no es un problema con usted, sino un problema con su plataforma y proceso. ¿Ha considerado buscar una posición utilizando un lenguaje dinámico (por ejemplo, Python, Ruby, JavaScript), donde no tiene que esperar a que se reinicie el servidor?

Es parte del trabajo, desafortunadamente. Tendrás proyectos malos y empleadores malos (no digo que sea el caso aquí, solo generalizando).

Usted puede escribir pruebas de unidad en contra de su código. Métetelo como puedas. Una vez que tenga algo que pueda mostrar a los jefes, puede cambiar el rumbo.

Use herramientas de depuración para corregir la lentitud, use pruebas unitarias para probar el nuevo código y úselas para solucionar los problemas del código existente, así como desglosar el código existente en partes más pequeñas.

Puede convertirlo en un desafío y convertirse en un héroe de mejora de procesos. Y, si no funciona, tendrá una buena experiencia para llevar al próximo empleador.

La mayoría de los programadores tienen que lidiar con problemas personales de corrección de errores en algún momento de su carrera.

El sentido correcto de la distancia de persona a trabajo es esencial para su motivación. No sobreidentifique o subidentifique con su trabajo. Si se identifica demasiado con su trabajo, pueden surgir problemas como los que ha descrito: puede ser muy reacio a corregir los errores, ya que la mitad del tiempo se culpa a sí mismo. Obtenga algo de distancia interior y descubra cómo puede trabajar racionalmente en su problema.

Con respecto a los problemas particulares en su plataforma, hay algunas maneras de mitigar los largos tiempos de implementación y prueba (y, por otro lado, los suyos no son particularmente largos).

En primer lugar, cuanto más largo sea tu tiempo de prueba, más reacio deberías ser al culto a la carga. Si realiza un cambio, piénselo hasta que esté seguro de que solucionará el error . Por supuesto, cuán seguro está sujeto a la duración de su ciclo de prueba. Pero si sus ciclos de prueba se alargan y no se pueden evitar las pruebas largas, pase más tiempo pensando y será recompensado y más feliz en la depuración porque es más rápido y tiene el efecto gratificante de un buen momento de "fiat lux". ".

En segundo lugar, sesgo más hacia las pruebas unitarias y menos hacia las pruebas de integración. Elimine todos los puntos de falla de la plataforma difícil de depurar que pueda.

La corrección de errores puede ser "impresionante" o "tediosa". Tengo algunos créditos del juego que se deben por completo a la reparación de un solo error: el error de bloqueo que nadie más podría solucionar. Pero la preparación diaria de bugzilla es alucinante. Los errores menores son tediosos. Los errores importantes son dignos.

Aquí está la realización: el hecho de que tenga una lista gigante de errores menores es en sí mismo un error importante. Simplemente no es un error de código. Es un error de proceso o gestión.

Encuentra ese error y arréglalo.

Una cosa que he encontrado entre colegas y conocidos que son buenos "depuradores / solucionadores de errores / solucionadores de problemas" es que generalmente les gusta resolver acertijos. Eso podría significar crucigramas, juegos de números (como Sudoku) y rompecabezas de lógica, etc.

Entonces, una forma en que podría convertirse en un mejor solucionador de errores sería pasar algún tiempo trabajando en sus habilidades para resolver problemas o resolver acertijos.

Aquí hay un enlace de Wikipedia que podría ser un buen punto de partida para ayudarlo a resolver mejor los problemas.

Eso sí, algunas personas son mejores para resolver problemas o simplemente lo disfrutan más. A algunas personas no les gusta en absoluto, lo que hace que sea difícil obligarse a hacerlo, pero no se equivoquen, si se obliga a aprender a resolver acertijos, será más fácil ser un buen solucionador de errores en el futuro .

La corrección de errores generalmente se siente como una tarea porque puede hacerte sentir que los errores te están quitando todo tu tiempo y te mantienen alejado de las cosas nuevas y divertidas. Sin embargo, la realidad es que la corrección de errores es una gran parte de lo que hacemos, y comienza tan pronto como escribimos la primera línea de código y ejecutamos el compilador. Cuando libera código por primera vez, probablemente ya haya pasado horas reparando errores, solo que no parece ser así porque los ha estado arreglando como parte del proceso de implementación de características. Hablando de manera realista, no importa cuán bueno sea un programador, los errores se introducirán en su sistema.

Entonces, ¿cómo lo haces divertido? Bueno, realmente no puedo responder eso por ti, ya que realmente no puedo imaginar qué es lo que flota tu barco individual. Para mí, soy un poco adicto a las herramientas, por lo que la respuesta ha sido tener una cadena de herramientas muy confiable y un proceso de desarrollo flexible que contribuya a que la reparación de errores sea menos complicada y, más simplemente, un problema para resolver con rapidez. Actualmente estoy desarrollando principalmente en C #, y siempre estoy buscando herramientas que eliminen el tedioso tiempo que desperdicia partes del software de escritura. Utilizo un primer enfoque de desarrollo de prueba compatible con una muy buena API de BDD llamada StoryQ . Uso Resharper para automatizar gran parte de mi refactorización y StyleCop para controlar cosas como el estilo de codificación. Mi última incorporación a la cadena de herramientas ha sido incluirNCrunch que ejecuta mis pruebas de forma continua y simultánea en segundo plano mientras codifico , y realmente ha sido NCrunch el que ha demostrado ser el cambio de juego.

La combinación de todas estas herramientas ha hecho que mi productividad se dispare últimamente, ya que pierdo muy poco tiempo esperando que las cosas se compilen o ejecuten. Recibo retroalimentación instantánea visualmente dentro de mi IDE para informarme que tengo problemas para solucionar, y presento mi código de prueba de tal manera que pueda identificar con solo unas pocas líneas de código el lugar exacto donde no solo ocurre una falla, pero a dónde se produce la causa de la falla debido a los encantadores informes detallados que recibo de StoryQque me dice exactamente qué partes de mi prueba pasan, cuáles fallan y en qué parte del código están las fallas. Con todo el tiempo perdido de mi tiempo de desarrollo, paso muy poco tiempo depurando activamente y más tiempo resolviendo problemas y escribiendo pruebas y códigos. La alta rotación de los problemas me mantiene ocupado y trae mucha variación en mis tareas. También me ha dado mucho tiempo para buscar otras áreas de interés durante mi jornada laboral para poder inyectar ideas nuevas e innovadoras en nuestra línea de productos y nuestros procesos.