Convertirse en un mejor solucionador de errores

24

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?

Naftuli Kay
fuente
44
"así que no puedo decirle exactamente a mi empleador que necesito un par de semanas para escribir pruebas unitarias para todo su código" . ¿Hay alguna razón para eso? Lo hago mucho, y realmente vale la pena para todos. Quiero decir, si llevas 3 semanas para la prueba de la unidad, podrías ahorrarte 3 semanas de corrección de errores. Por lo general, incluso encuentro un montón de errores eventuales que quedaron totalmente bajo el radar de QA. Claro, probablemente no quieras hacer eso solo.
netcoder
10
No escriba errores en su código ... problema resuelto.
Michael Brown
3
Casi prefiero corregir errores a escribir nuevo código. Lo prefiero especialmente a escribir pruebas unitarias. Quizás soy raro.
Paul Tomblin
1
@PaulTomblin Entiendo lo que estás diciendo. Conozco a algunos desarrolladores que aman el desarrollo frontend ... a mí me gusta más el código sin interfaz de usuario. Escribir código nuevo es difícil a veces porque a veces se obtiene "bloqueo del escritor"
Michael Brown
1
Es difícil medir la "productividad" de la corrección de errores porque puede pasar mucho tiempo descubriendo lo que "no es el problema", al igual que se dice que Edision dijo que encontró "1000 maneras de NO hacer una bombilla" ", y creo que las no correcciones son a menudo instructivas para enseñarle qué pistas son importantes y la tarea actual (y futura) de corrección de errores.
Zeke Hansell

Respuestas:

21

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í.

Garrett Hall
fuente
¿Alguna vez has leído el mes mítico del hombre? Solo imagínense esperando hasta la mañana siguiente e intentando analizar el contenido del registro / volcado de la pila que estaba presente en el momento de la falla ...
sq33G
@ sq33G O peor aún, tener su equipo de prueba en India con el que solo habla por correo electrónico (historia real).
Garrett Hall
13

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 .

ManuPK
fuente
1
Lo que escribes es verdad; sin embargo, su 80% / 20% solo es cierto porque hay mucho código malo en la naturaleza. Por basura, quiero decir, prácticas poco diseñadas o sobre-diseñadas o mal diseñadas o simplemente descuidadas (programación de crack-head). Dicho esto, no hay nada de malo en que un desarrollador prefiera el desarrollo a la corrección de errores. Agregue el hecho de que la mayoría del software está mal diseñado desde el principio y ya está configurando la mayoría de los correctores de fallas.
Wil Moore III
@wilmoore: Tiene razón con el código malo, y también existe el requisito de cambio.
ManuPK
6

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? )

Alexander Gessler
fuente
Estoy totalmente en desacuerdo con hacer que sea un juego de arreglar la mayoría de los errores en un día, o cosas por el estilo. Algunos errores son triviales para aislar y corregir una vez que sabe cómo activarlos: pegue ese valor en particular en este campo y observe: la longitud restante ahora es incorrecta. (Quizás esté contando bytes en lugar de caracteres y se haya olvidado del espacio anterior, por ejemplo, U + 007F). Otros (particularmente los errores que involucran varias condiciones de carrera o subprocesos múltiples) pueden tomar fácilmente días de trabajo para reproducirse, pero pueden ser críticos cuando lo hacen. ocurrir en el campo. Sin embargo, ambos garantizan solo una entrada en el rastreador de errores.
un CVn
Contar estos errores de manera equitativa significaría que todo el mundo corregirá los errores simples en lugar de abordarlos, es decir, las condiciones de la carrera ... pero ¿no es ese el caso con la corrección de errores no motivada y desenfocada? :-) No dejar que los errores 'duros' descansen en favor de las cosas simples es un tema totalmente diferente.
Alexander Gessler
También está la cuestión de la calidad de la solución. En muchos casos, puede hacer una solución rápida a un error sin llegar a la causa, pero luego aparece un error similar en otro lugar o en otra situación. Comprender y corregir la naturaleza del error a menudo lleva más tiempo, pero generalmente conduce a una solución mucho más sólida. A menos que sea "esto está fallando todo el tiempo en producción y tenemos que publicar una solución ahora ", sé qué enfoque preferiría (e incluso si es así, volver a arreglar el hueso roto en lugar de simplemente vendar el corte sería una buena idea).
un CVn
5

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.

Michael Rice
fuente
Para este proyecto actual, tengo, de hecho, pruebas unitarias escritas. El único problema es que no importa lo que parezca ser capaz de probar usando las pruebas de mi unidad, todo se va al infierno en la producción / vida real, debido a los problemas con la tecnología del servidor. Desafortunadamente, no hay otra alternativa y no estoy en el lugar para cambiar el motor, por así decirlo.
Naftuli Kay
Debes escribir una rutina de "controlador de errores inesperados" para ayudarte a atraparlos ;-)
Zeke Hansell
2

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". :)

Erik Dietrich
fuente
Te escucho. Desearía poder hacer algo para automatizar las cosas. Tengo un servidor y un cliente, y no puedo automatizar exactamente el cliente fácilmente. Hay varias etapas en el flujo de trabajo de esta cosa y muchos de los errores surgen entre etapas, por lo que tengo que hacer una etapa de 30 segundos, luego una etapa de 3 minutos o al revés. En
pocas palabras
2

¿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!
Matthew Flynn
fuente
2

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.

Bruce Ediger
fuente
1

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?

Kevin Cline
fuente
Desafortunadamente, no es una opción en esta etapa. Además, el flujo de trabajo, como se mencionó anteriormente, requiere múltiples etapas y pasos, y los errores surgen entre estas etapas. Si escribiera esto desde cero, seguramente buscaría usar un lenguaje de script, pero estamos atrapados con lo que tenemos por ahora.
Naftuli Kay
1
@TK: En mi última empresa tuvimos un gran éxito al integrar Groovy en nuestro proceso de desarrollo de Java para automatizar procesos que antes eran manuales. No es Java, pero estaba lo suficientemente cerca y fue tan efectivo que tuvimos muy poco retroceso.
Kevin Cline
1

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.

Alan Delimon
fuente
1

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.

thiton
fuente
1

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.

jamie
fuente
1

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 .

Zeke Hansell
fuente
0

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.

S.Robins
fuente