seguimiento - tracking number china
¿Cuáles son las formas efectivas de registrar y rastrear los errores de programación? (12)
"¿Qué información relacionada con mis errores debería seguir para poder mejorar como programador?"
Lee blogs de otras personas. Escribe lo tuyo. No es necesario que lo publique. Pero tienes que convertir cada error en una historia.
No ahogues esto en metadatos. Esto no es susceptible de una base de datos o incluso un rastreador de errores. Un error es una historia en la que alguien hizo una mala elección y se recuperó de ella.
Aquí está su esquema.
- Contexto. Que esta pasando.
- Situación. El problema que estabas tratando de resolver.
- Que hiciste. Por qué fue malo
- Lo que deberías haber hecho Por qué fue mejor
- Qué cambió. Que has aprendido.
También debe registrar sus éxitos en casi la misma forma.
- Contexto. Que esta pasando.
- Situación. El problema que estabas tratando de resolver.
- Que hiciste. Por qué fue bueno
- Que has aprendido.
Cuando tengas dudas, mira una película. Seriamente. Los personajes se enfrentan a elecciones, cometen errores y se recuperan de esos errores. Esa historia es la esencia del drama. Un error es lo mismo.
En ocasiones, he escuchado a personas hablar sobre los beneficios de hacer un seguimiento de los errores de programación, aunque solo sea para aumentar la conciencia de los errores comunes. Empecé a mantener una lista de errores que encuentro en mi código, junto con lo que podría haberles llevado. La pregunta principal que tengo es esta:
- ¿Qué información relacionada con mis errores debería seguir para poder mejorar como programador?
Y un par de otras preguntas relacionadas con esto:
- ¿Cómo uso esta información una vez que empiezo a registrar mis errores?
- ¿Los errores de seguimiento son realmente beneficiosos?
Buscaría tendencias o tipos similares de errores que tienden a repetirse. Una vez que esté al tanto de los tipos de errores que comete, puede estar alerta para ellos, o puede cambiar su estilo de codificación para evitarlos.
Como ejemplo, trabajé muy de cerca con mi compañero de oficina en una vida anterior. En un momento dado, estaba a la mitad de mi primera oración explicando un comportamiento extraño, y me interrumpió con "aumentar tu contador". ¡ Aún compruebo dos veces mis contadores de bucle hoy!
Creo que lo que es más útil que mantener un registro de los errores individuales es asegurarse de obtener una comprensión real de por qué fue un error en primer lugar. La mayoría de los errores provienen de una falta de comprensión sobre una cosa u otra, corrigen esa comprensión y eliminan un conjunto completo de posibles errores en el futuro. Si tuviera que registrar algo, sería lo que aprendí de la experiencia que no sabía antes, no los detalles del error que se cometió, que probablemente serán de utilidad limitada cuando lo analice más adelante.
Creo que los errores de seguimiento pueden valer la pena, pero en mi experiencia, es útil categorizarlos en algún nivel.
Cada programador cometerá suficientes errores en el transcurso de su carrera para completar una enciclopedia. Si haces una lista de verificación enorme de todos ellos, nunca obtendrás ninguna codificación porque eventualmente pasarás todo tu tiempo revisando tu lista de verificación. Entonces: clasifique sus errores de alguna manera que tenga sentido para usted, de modo que pueda revisar su lista y ver los errores más importantes para el tipo de código en el que está trabajando actualmente.
Además, para agregar a lo anterior en cuanto a qué recolectar:
- cuáles son los síntomas del error (para que pueda encontrarlo más adelante)
- cómo lo resolvió realmente
En lugar de mantener un registro de errores futuros, tal vez podría revisar su historial de errores y tratar de encontrar tipos comunes de errores que siguen ocurriendo.
Estoy tan inspirado que creo que intentaré esto mañana.
Esto solo es útil si está realmente atento con el seguimiento y la revisión. Cuando estaba trabajando en un equipo, sin importar cuánto documentara que, por ejemplo, nuestros servidores en el entorno de producción estuvieran informados y no pudieran resolver sus propios nombres de dominio o direcciones IP públicas, cada 6 meses, recibiría una llamada a las 4 AM del equipo de despliegue o del equipo de desarrollo del que era responsable un nuevo desarrollador, y lo olvidaron o no lo sabían.
Recuerdo un ingeniero en particular que era responsable de implementar y tenía listas de verificación en papel, le construimos herramientas de implementación que lo obligaban a registrar su lista de verificación, pero siempre olvidaba establecer la cadena de conexión (lo que resultaba en la llamada telefónica a las 4 am). El punto es que solo vale la pena si vas a usarlo atentamente.
He encontrado la mejor manera de usar esto mediante la implementación de sus reglas en un analizador de código como fxcop.
Sí, hacer un seguimiento de tus errores personales es beneficioso. Consulte el SEI para obtener numerosos puntos de datos ( aquí hay uno al azar). Una de esas metodologías es el Proceso de Software Personal (PSP) . Es demasiado largo para entrar aquí, pero aquí hay un libro sobre eso . También hay esta publicación gratuita de SEI en PSP.
Si te niegas a SEI y piensas que Agile es el camino a seguir, es probable que saques más provecho de un libro como Clean Code: A Handbook of Agile Software Craftsmanship (sitio web del editor) .
En pocas palabras: desarrollador disciplinado = bueno, desarrollador indisciplinado = malo.
También me gustaría hacer la pregunta de cuánto tiempo se necesitaría para realizar un seguimiento preciso de los errores, y si ese sería el mejor momento para mejorar directamente el software. Si puede hacer esto en un tiempo mínimo y puede volver a consultar sus registros para evitar errores futuros, puede ser valioso. Sin embargo, a largo plazo, creo que será mejor seguir con una lista de alto nivel de errores comunes que cometes.
Ten cuidado con lo que registras. No todas las malas situaciones son un error. Algunas situaciones son inevitables o están tan fuera de su control que no se puede hacer nada al respecto.
Una mala planificación por parte de otra persona que lo ponga en estado de pánico no es su error. Puede registrar meticulosamente los errores de todos los demás, pero ¿cuál es el punto? Si realiza un seguimiento de lo que otras personas están haciendo, debe buscar terapia.
La mala planificación que proporciona un presupuesto, un cronograma o una comunicación inadecuados sobre los cambios puede ser un problema complejo.
- No proporcionó suficiente información de planificación por adelantado.
- En la lucha por hacer frente, cometió otro error que condujo a la resolución y recuperación del problema.
En retrospectiva (que siempre es 20/20), puede ver una decisión que fue incorrecta. Sin embargo, en ese momento , se basaba en la mejor información disponible. Eso no es un error. Cualquier oración que comience "Si hubiéramos sabido que X ..." es inútil para el análisis de errores. Puede tratar de escribir una lista de verificación de todas las cosas que necesita saber la próxima vez que tome esa decisión. Pero la próxima vez, no tomará exactamente esa decisión y se perderá otra información.
- Nunca llame errores de acciones de otras personas.
- Encuentra las causas de raíz. Es una causa raíz cuando es algo que no puedes controlar.
- No llame retroactivamente a la información que apareció perdiendo un error.
- cual fue el error
- cómo se puede evitar
agregue el último a una lista de verificación apropiada, y refiérase a él tan a menudo como sea apropiado
He estado pensando lo mismo. Por el momento, guardo una pequeña hoja de cálculo con errores que corrijo. El propósito de esto es darme cuenta de los errores más comunes que se cometen.
Espero poder comenzar a ver patrones y evitar cometer errores comunes una y otra vez.
Considero que esto hace que mi trabajo sea más interesante, probablemente porque soy una persona analítica a la que le gusta recopilar datos e información de manera estructurada.
Debe intentar relacionar los errores con el uso de herramientas, hábitos, métodos o conocimientos inadecuados . En la mayoría de los casos, encontrará que habría habido formas de detectar el error antes. Me vienen a la mente cosas como seguridad de tipo, pruebas unitarias, revisión de código, estándares de codificación, mejor diseño de API, mejor documentación y entorno de trabajo.
Yo uso JIRA con un flujo de trabajo personalizado. Para un error, el último paso antes de que se cierre un problema es una pantalla que me permite seleccionar una "causa raíz". Tengo un historial de la causa raíz de cada error que ocurrió en los últimos 3 sistemas que construí.