debugging - ortografia - estrategias para mejorar la escritura en primaria
¿Cuáles son algunas buenas estrategias para corregir errores a medida que el código se vuelve más complejo? (14)
Hay dos formas de escribir programas sin errores; solo el tercero funciona. ~ Alan J. Perlis
La única forma de que ocurran errores en un programa es poniéndolo ahí por el autor. No se conocen otros mecanismos. Los programas no pueden adquirir errores al sentarse con otros programas con errores. ~ Harlan Mills
Soy "solo" un programador aficionado, pero me parece que a medida que mis programas se hacen cada vez más largos, los errores se vuelven más molestos y más difíciles de rastrear. Justo cuando todo parece funcionar sin problemas, aparecerá un nuevo problema, aparentemente espontáneo. Me puede llevar mucho tiempo descubrir qué causó el problema. Otras veces agregaré una línea de código y romperá algo en otra unidad. Esto puede ser un poco frustrante si pensara que todo estaba funcionando bien.
¿Es esto común a todos, o es más un tipo de cosa novato? Escuché sobre "pruebas unitarias", "marcos de diseño" y varios otros conceptos que parecen disminuir el funcionamiento, hacer que mis aplicaciones sean "robustas" y todo fácil de entender de un vistazo :)
Entonces, ¿cuán grande es el problema para las personas con capacitación profesional?
Gracias - Al C.
¿ Automatiza sus pruebas ? Si no lo hace, se registra creando errores sin encontrarlos.
¿Estás agregando pruebas de errores mientras los arreglas? Si no lo hace, se registra para crear los mismos errores una y otra vez.
¿Estás escribiendo pruebas unitarias ? De lo contrario, se registra para largas sesiones de depuración cuando falla una prueba.
¿Estás escribiendo tus pruebas unitarias primero ? De lo contrario, las pruebas de su unidad serán difíciles de escribir cuando sus unidades estén bien acopladas.
¿Estás refaccionando sin piedad? Si no, cada edición será más difícil y más probable que introduzca errores. (Pero asegúrese de tener buenas pruebas, primero).
Cuando arreglas un error, ¿estás arreglando toda la clase ? No solo arregles el error; no solo corrija errores similares a través de su código; cambia el juego para que nunca puedas volver a crear ese tipo de error.
El problema de "hacer una corrección, causar un problema en otra parte" es muy conocido, y de hecho es una de las principales motivaciones detrás de las pruebas unitarias.
La idea es que si escribe pruebas exhaustivas para cada pequeña parte de su sistema de forma independiente y las ejecuta en todo el sistema cada vez que realiza un cambio en cualquier lugar, verá el problema de inmediato. El principal beneficio, sin embargo, es que en el proceso de construcción de estas pruebas también mejorará su código para tener menos dependencias.
La solución típica para este tipo de problemas es reducir el acoplamiento; hacer que las diferentes partes sean menos dependientes unas de otras. Los desarrolladores más experimentados a veces tienen hábitos o habilidades de diseño para construir sistemas de esta manera. Por ejemplo, usamos interfaces e implementaciones en lugar de clases; usamos modelo-vista-controlador para interfaces de usuario, etc. Además, podemos usar herramientas que ayudan a reducir aún más las dependencias, como "inyección de dependencia" y programación orientada a aspectos.
Todos los programadores cometen errores. Los programadores buenos y experimentados construyen sus programas para que sea más fácil encontrar los errores y restringir sus efectos.
Y es un gran problema para todos. La mayoría de las empresas dedican más tiempo al mantenimiento que a escribir nuevos códigos.
Errores desagradables le pasan a todos, desde profesionales hasta aficionados. A los programadores realmente buenos se les pide que busquen errores realmente desagradables. Es parte del trabajo. Sabrá que lo hizo como desarrollador de software cuando mira fijamente un desagradable error durante dos días y, con frustración, grita: "¿Quién escribió esta basura??!?" ... solo para darte cuenta de que eras tú. :-)
Parte de la habilidad de un desarrollador de software es la capacidad de mantener un gran conjunto de elementos interrelacionados directamente en su cabeza. Parece que estás descubriendo lo que sucede cuando tu modelo mental del sistema se descompone. Con la práctica aprenderá a diseñar software que no se sienta tan frágil. Hay toneladas de libros, blogs, etc. en el tema del diseño de software. Y por supuesto para preguntas específicas.
Todo lo dicho, aquí hay un par de cosas que puedes hacer:
- Un buen depurador es invaluable. A menudo tiene que pasar por su código línea por línea para descubrir qué salió mal.
- Use un lenguaje recogido de basura como Python o Java si tiene sentido para su proyecto. GC lo ayudará a enfocarse en hacer que las cosas funcionen en lugar de atascarse al enloquecer los errores de memoria.
- Si escribe C ++, aprenda a amar RAII.
- Escribe MUCHOS de código. El software es algo así como una forma de arte. Mucha práctica lo hará mejor en eso.
Bienvenido a !
Esta es una novedad común. A medida que obtienes más experiencia, por supuesto, seguirás teniendo errores, pero serán más fáciles de encontrar y corregir porque aprenderás cómo hacer que tu código sea más modular (para que cambiar una cosa no tenga efectos de ondulación) en cualquier otro lugar), cómo probarlo y cómo estructurarlo para que falle rápidamente, cerca de la fuente del problema, en lugar de en algún lugar arbitrario. Una cosa muy básica pero útil que no requiere una infraestructura compleja para implementar es verificar las entradas a todas las funciones que tienen precondiciones no triviales con afirmaciones. Esto me ha salvado varias veces en casos en los que de otra manera hubiera obtenido segfeults extraños y un comportamiento arbitrario que hubiera sido casi imposible de depurar.
La sabiduría prevaleciente parece ser que el programador promedio crea 12 errores por cada 1000 líneas de código, depende de a quién le pregunte el número exacto, pero siempre por líneas de código, de modo que cuanto más grande sea el programa, más errores tendrá.
Los programadores de Subpar tienden a crear mucho más errores.
Los principiantes a menudo quedan atrapados por la idiosincrasia del idioma, y la falta de experiencia también tiende a provocar más errores. A medida que avance, mejorará, pero nunca creará código libre de errores ... bueno, todavía tengo errores, incluso después de 30 años, pero podría ser solo yo.
Lo que realmente cambió mis probabilidades contra la complejidad del código y los errores fue el uso de un estándar de codificación: cómo colocar los corchetes y así sucesivamente. Puede parecer aburrido e inútil, pero realmente unifica todo el código y hace que sea mucho más fácil de leer y mantener. Entonces, ¿usas un estándar de codificación?
Los errores son comunes a todos, profesionales o no.
Cuanto más grande y distribuido sea el proyecto, más cuidadoso debe ser. Un vistazo a cualquier base de datos de errores de código abierto (por ejemplo, https://bugzilla.mozilla.org/ ) lo confirmará por usted.
La industria del software ha desarrollado varios estilos y estándares de programación , que cuando se usan correctamente, hacen que el código erróneo sea más fácil de detectar o limitado en su impacto.
Por lo tanto, el entrenamiento tiene una muy buena calidad de código ... Pero al final del día, los errores aún se cuelan.
Obviamente, los errores son un gran problema para cualquier programador. Simplemente mire la lista de preguntas en para ver esto ilustrado.
La diferencia entre un aficionado y un profesional experimentado es que el profesional podrá usar su experiencia para codificar de una manera más "defensiva", evitando muchos tipos de errores en primer lugar.
Si los errores no fueran un problema, ¡podría escribir un programa de 100,000 líneas en 10 minutos!
Su pregunta es como: "Como médico aficionado, me preocupa la salud de mis pacientes: a veces, cuando no soy lo suficientemente cuidadoso, enferman. ¿La salud de los pacientes también es un problema para los médicos profesionales?"
Sí: es el problema central, incluso el único problema (para cualquier definición suficientemente completa de ''error'').
Si no estás bien organizado, tu base de código se convertirá en tu propio Zebra Puzzle . Agregar más código es como agregar más personas / animales / casas a tu rompecabezas, y pronto tienes 150 diversos animales, personas, casas y marcas de cigarrillos en tu rompecabezas y te das cuenta de que solo te tomó una semana agregar 3 líneas de código porque todo está tan relacionado que tarda una eternidad en asegurarse de que el código todavía se ejecute como usted lo desea.
El paradigma organizacional más popular parece ser la Programación Orientada a Objetos , si puedes dividir tu lógica en pequeñas unidades que pueden construirse y usarse independientemente unas de otras, entonces encontrarás errores mucho menos dolorosos cuando ocurran.
Si solo eres un programador aficionado, aprender TDD y OOP completos puede implicar más tiempo de lo que estás dispuesto a aportar. Por lo tanto, asumiendo que no quieres poner el tiempo en ellos, algunos Las sugerencias fácilmente digeribles para reducir los errores son:
Mantenga cada función haciendo una cosa. Sospeche de una función de más de, digamos, 10 líneas de longitud. Si crees que puedes dividirlo en dos funciones, probablemente deberías hacerlo. Algo que te ayudará a controlar esto es nombrar tus funciones de acuerdo con lo que están haciendo exactamente. Si encuentra que sus nombres son largos y difíciles de manejar, entonces su función probablemente esté haciendo demasiadas cosas.
Convierta las cadenas mágicas en constantes. Es decir, en lugar de usar:
personas ["mamá"]
usar en su lugar
var mom = "mom";
people[mom]
- Diseña tus funciones para hacer algo (comando) u obtener algo (consulta), pero no ambos.
Una versión extremadamente breve y digerible de OOP está aquí http://www.holub.com/publications/notes_and_slides/Everything.You.Know.is.Wrong.pdf . Si obtienes esto, tienes la esencia de OOP y estás bastante francamente por delante de muchos programadores profesionales.
Todas las demás respuestas son geniales. Añadiré dos cosas.
- El control de fuente es obligatorio . Supongo que estás en Windows aquí. El servidor de VisualSVN es gratuito y tal vez tenga 4 clics para instalar. TortoiseSVN también es gratuito y se integra en Windows Explorer, evitando las limitaciones de VS Express sin complementos. Si crea demasiados errores, puede revertir su código y comenzar de nuevo. Sin control de fuente, esto es casi imposible. Además, puede sincronizar su código si tiene una computadora portátil y una computadora de escritorio.
- La gente va a recomendar muchas técnicas como pruebas unitarias, burlas, inversión de control, desarrollo controlado por pruebas, etc. Estas son buenas prácticas, pero no trates de meter todo en tu cabeza demasiado rápido. Debes escribir código para mejorar al escribir código, así que trabaja estas técnicas lentamente en la escritura del código. Tienes que gatear antes de caminar y caminar antes de poder correr.
¡Mucha suerte en tus aventuras de codificación!
Los errores son un gran problema para todos. Siempre he descubierto que cuanto más programo, más aprendo acerca de la programación en general. ¡Me avergüenzo del código que escribí hace unos años! Comencé como aficionado y me gustó tanto que fui a la facultad de ingeniería para obtener una especialización en Ingeniería en Informática (estoy en mi último semestre). Estas son las cosas que he aprendido:
Me tomo el tiempo para realmente diseñar lo que voy a escribir y documentar el diseño. Realmente elimina muchos problemas en el futuro. Si el diseño es tan simple como anotar algunos puntos sobre lo que voy a escribir o el modelado completo de UML (:() no importa. Es la claridad de pensamiento y propósito y tener material para mirar cuando vengo. volver al código después de un tiempo que más importa.
No importa en qué idioma escriba, mantener mi código simple y legible es importante. Creo que es extremadamente importante no complicar demasiado el código y, al mismo tiempo, no simplificarlo demasiado. (¡Lección aprendida!)
Las optimizaciones de eficiencia y los trucos de fantasía deben aplicarse al final, solo cuando sea necesario y solo si se necesitan. Otra cosa es que solo los aplico si realmente sé lo que estoy haciendo y siempre pruebo mi código.
El aprendizaje de los detalles del idioma me ayuda a mantener mi código libre de errores. Por ejemplo, aprendí que scanf () es malo en C!
Otros ya han comentado sobre el zen de escribir pruebas. Me gustaría agregar que siempre debes hacer pruebas de regresión. (es decir, escriba un nuevo código, pruebe todas las partes de su código para ver si se rompe)
A veces, mantener una imagen mental del código es difícil, así que siempre doy mi código.
Utilizo métodos para asegurarme de que existe una dependencia mínima entre partes diferentes de mi código. Interfaces, jerarquías de clase, etc. (Diseño desacoplado)
Pensar antes de codificar y ser disciplinado en todo lo que escribo es otra habilidad crucial. Conozco a gente que no formatea su código para que sea legible (¡Shudder!).
Leer la fuente de otras personas para aprender las mejores prácticas es bueno. Hacer mi propia lista es mejor !. Cuando se trabaja en equipo, debe haber un conjunto común de ellos.
No seas paralizado por el análisis. Escribir pruebas, luego codificar, luego ejecutar y probar. Enjuague lavado repetir!
Aprender a leer mi propio código y peinarlo por errores es importante. Mejorar mi arsenal de habilidades de depuración fue una gran inversión. Los mantengo afilados al ayudar a mis compañeros a arreglar los errores regularmente.
Cuando hay un error en mi código, asumo que es mi error, no las computadoras y trabajo desde allí. Ese es un estado mental que realmente me ayuda.
Un par de ojos nuevos ayuda a depurar. Los programadores tienden a perder incluso los errores más obvios en su propio código cuando están agotados. Tener a alguien para mostrar tu código es genial.
tener a alguien para arrojar ideas y no ser juzgado es importante. Hablo con mi madre (que no es programadora), le lanzo ideas y encuentro soluciones. Ella me ayuda a relanzar mis ideas y refinarlas. Si ella no está disponible, hablo con mi gato mascota.
No estoy tan desanimado por los errores. Aprendí a amar eliminar errores casi tanto como la programación.
Usar el control de versiones realmente me ha ayudado a manejar diferentes ideas que obtengo mientras codifico. Eso ayuda a reducir los errores. Recomiendo usar git o cualquier otro sistema de control de versiones que te pueda gustar.
Como dijo Jay Bazzuzi - Código de refactorización. Acabo de agregar este punto después de leer su respuesta, para mantener mi lista completa. Todo el crédito va a él.
Intenta escribir un código reutilizable. Código de reutilización, tanto suyo como de las bibliotecas. Usar bibliotecas libres de errores para realizar algunas tareas comunes realmente reduce los errores (a veces).
Creo que la siguiente cita lo dice mejor: "Si la depuración es el arte de eliminar errores, la programación debe ser el arte de ponerlos".
Sin ofender a nadie que no esté de acuerdo. Espero que esta respuesta ayude.
Nota
Como han señalado otros Peter, use la Programación Orientada a Objetos si está escribiendo una gran cantidad de código. Existe un límite para la longitud del código, después del cual se vuelve más y más difícil de administrar si se escribe de forma escrita. Me gusta el procedimiento para cosas más pequeñas, como jugar con algoritmos.