de él, incluyendo sus fallas. • A veces al enfrentarnos a un nuevo problema no sabemos por dónde empezar. • Muchas veces empezamos a programar sin pensar y avanzamos hasta que sentimos que funciona. 7
de él, incluyendo sus fallas. • A veces al enfrentarnos a un nuevo problema no sabemos por dónde empezar. • Muchas veces empezamos a programar sin pensar y avanzamos hasta que sentimos que funciona. • También es fácil ponernos a trabajar en detalles que no abonan a resolver el problema. 7
el objetivo (Project Management Institute 2017; Spolsky 2000) • Por eso documentamos el objetivo en primer lugar. • Los buenos programadores son 10 a 20 veces mejores que los programadores promedio (McConnell 2004) 8
el objetivo (Project Management Institute 2017; Spolsky 2000) • Por eso documentamos el objetivo en primer lugar. • Los buenos programadores son 10 a 20 veces mejores que los programadores promedio (McConnell 2004) • La principal diferencia entre los mejores programadores y los peores son los hábitos. 8
que vamos a usar (Knuth 1984) Todo el software tiene errores, con la posible excepción de las cosas escritas por Daniel J. Bernstein y Donald Knuth. Manual de CouchDB 9
de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. • Especificar hasta que se pueda escribir directamente en código. 10
de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. • Especificar hasta que se pueda escribir directamente en código. • Escribir código. 10
de computadora (McConnell 2004; Knuth 1984) • Describir el problema en lenguaje natural. • Dividir el problema en partes. • Especificar hasta que se pueda escribir directamente en código. • Escribir código. • Borrar comentarios redundantes. 10
17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… • intérprete (Python, R, awk, …) 11
17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… • intérprete (Python, R, awk, …) • compilador (C, Java, Rust, …) 11
17 sobre sección de memoria 1809181984”. • Los programas se transforman de lenguaje de programación a instrucciones usando un… • intérprete (Python, R, awk, …) • compilador (C, Java, Rust, …) • A veces conviene usar lenguajes diseñados para una tarea particular (DSL, p.e. awk, CWL, yaml, …) 11
• Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. 12
• Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. 12
• Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. • La forma más sencilla de hacer los controles es hacer una especie de examen para nuestro flujo de trabajo: 12
• Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. • La forma más sencilla de hacer los controles es hacer una especie de examen para nuestro flujo de trabajo: • Tenemos cierta información en la entrada. 12
• Usamos mk para decirle a la computadora qué pasos tiene que hacer y en qué orden. • Usamos scripts para ejecutar los comandos de nuestro análisis. • Conviene hacer por separado estos comandos para poder usarlos fuera de mk y para facilitar los controles. • La forma más sencilla de hacer los controles es hacer una especie de examen para nuestro flujo de trabajo: • Tenemos cierta información en la entrada. • Sabemos que esa información debe dar un resultado. 12
causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. • Saltarse pasos puede agregar horas de trabajo. 15
causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. • Saltarse pasos puede agregar horas de trabajo. • Git nos puede ayudar a identificar dónde está el problema si hiciste muchos cambios juntos. 15
causa (Litt 1996) • Identificar el problema es el 80% de la solución. • Hay que probar cada etapa en orden para saber que funciona. • Saltarse pasos puede agregar horas de trabajo. • Git nos puede ayudar a identificar dónde está el problema si hiciste muchos cambios juntos. • Los controles nos pueden ayudar a identificar cuándo ocurre el problema. 15
2002) Algunos problemas muy comunes que nos podemos encontrar: • No encuentra el archivo. • No tiene permisos (lectura, escritura, ejecución). • Configuración incorrecta. 16
E. 1984. “Literate Programming.” The Computer Journal 27 (2): 97–111. https://doi.org/10.1093/comjnl/27.2.97. Litt, Steve. 1996. “The Universal Troubleshooting Guide.” 1996. http://troubleshooters.com/ustep6.htm. McConnell, Steve. 2004. Code Complete. 2nd ed. Redmond, Wash: Microsoft Press. Project Management Institute, ed. 2017. A Guide to the Project Management Body of Knowledge / Project Management Institute. Sixth edition. PMBOK Guide. Newtown Square, PA: Project Management Institute. Spolsky, Joel. 2000. “Painless Functional Specifications – Part 1: Why Bother?” Joel on Software. October 2, 2000. https://www.joelonsoftware.com/2000/10/02/painless-functional- specifications-part-1-why-bother/. 22