9.1

Entregas: Indicaciones y Evaluación🔗

El desarrollo del compilador se hará en varias etapas, las cuales culminan en entregas a lo largo del semestre. Cada estudiante puede elegir desarrollar sólo, o trabajar en équipo de dos. En ambos casos, se permite colaboración con los demás estudiantes del curso, siguiendo el código de conducta del curso.

En la primera semana se determinará quienes quieren trabajar sólos y quienes trabajarán en équipo. En caso de trabajar en grupo de dos, las notas de entregas se aplicarán por igual a ambos integrantes. Se fijan los grupos una vez para todo el semestre, así que es importante que se ponga de acuerdo con su potencial partner respecto de sus ambiciones (¿apunta a un 5? ¿un 7?), forma de trabajar, horarios, etc.

1 Evaluación por Especificaciones🔗

Para las entregas de su compilador, adoptaremos una forma de evaluación conocida como specs grading (o mastery grading), la cual difiere bastante de lo usual. La idea es simple: se define un mínimo no negociable de logros que tiene que demostrar, y puede volver a intentar hasta conseguirlo.

Concretamente, para cada entrega, comunicaremos:

  • Una spec básica de lo que su entrega tiene que cumplir sí o sí. Si cumple con la spec básica, su entrega será aprobada y su nota será (al menos) un 5. Si no cumple, entonces su entrega será devuelta, con indicaciones, y tendrá que volver a intentar.

  • Una spec avanzada, más desafíante, que complementa la básica. Si cumple con la spec avanzada (y por ende con la spec básica también), su nota será (al menos) un 6.

Además, siempre y cuando su entrega sea aprobada, asignaremos:

  • 0.5 pto para un testing adecuado (es decir, exhaustivo y no-redundante)

  • 0.5 pto para código de calidad (ver más abajo)

Para aprobar el curso, tiene que aprobar cada una de las entregas. No sirve el promedio. La contraparte es que puede volver a intentar hasta lograrlo: ¡Puede equivocarse!

2 Entregas y Plazos🔗

En términos logísticos, para no reventar la capacidad de corrección del cuerpo docente, tendremos las siguientes restricciones:

  • El mécanismo de nuevos intentos (re-entrega) es sólo para entregas que fueron devueltas; no se puede usar para mejorar la nota de una entrega que ya está aprobada.

  • Cada entrega tendrá un deadline fijo (aprox cada 2 semanas), con una ventana de atrasos de a lo más una semana.

  • Si su entrega es devuelta, tendrá que volver a entregar lo antes posible. No hay deadline fijo para re-entregas, pero sí hay un límite de una re-entrega por semana. También podrá integrar su re-entrega en una entrega siguiente, dado que las entregas son cumulativas en terminos de features.

3 Desarrollo Continuo y Mecanismo de Entrega🔗

Para la gestión del código, procederemos de la siguiente manera:

  • Para cada estudiante o grupo, el cuerpo docente habilitará un repositorio GitHub privado, el cuál deberá ser usado para el desarrollo continuo de su compilador. El cuerpo docente tendrá acceso en lectura al repositorio.

  • Cada entrega se hace simplemente usando el mecanismo de releases de GitHub. Además, se deberá señalar en u-cursos el hash del commit correspondiente a su entrega (el cual no será modificable).

  • Cada entrega será acompañada de un breve documento de diseño de alto nivel (README.md del repositorio), que indica los puntos esenciales de su entrega, además de los problemas conocidos, y cualquier información que juzgue útil para que el cuerpo docente revise eficientemente su entrega.

En cada sesión de seguimiento, el grupo deberá:

  • Exponer avances respecto de la sesión anterior

  • Demostrar su entendimiento y comprensión del código de su compilador

Es aceptable tener problemas para avanzar y solicitar ayuda, pero es inaceptable mostrar código en su compilador que no es capaz de explicar y justificar. Les recordamos el código de conducta del curso.

4 Calidad del Código🔗

A modo de guía, aquí va una lista de puntos que se considerarán como parte de la evaluación de la calidad de su desarrollo.

  • archivo explicando a grandes rasgos que hace su entrega

  • comentarios sobre funciones, con una breve descripción de qué hacen

  • comentarios para documentar detalles sútiles y/o desafíantes

  • buena factorización de código común en funciones, diseño de abstracciones

  • emplear funciones existentes de las librerías (en particular containers) cuando sea posible

  • pattern matching exaustivo, no deberían haber warnings

  • ocupar local let-bindings para evitar repetición o exceso de paréntesis

  • indentación correcta (emplear ocamlformat si necesario)