Una de las cosas que siempre me han gustado es leer código de otros. Se aprende mucho, y es divertido intentar buscar optimizaciones, o bugs. En ArgoUML he estado haciendo esto alguna vez con FindBugs, y leo con calma todos los diffs enviados a la lista de commits.
Hoy Rodrigo Corral hacía un llamamiento en su blog, preguntándose cómo se podrían calcular las horas que han pasado desde principio de año hasta una fecha dada.
También habló Ricardo sobre revisiones de código en Subversion hace algún tiempo, y aún espero con ilusión que algún caminante deje un comentario a ese post sobre alguna herramienta que yo desconozca.
Hoy alguien ha mandado unas simples optimizaciones para la clase Int32 a la lista de desarrollo de Mono, un proyecto muy maduro, por lo que me sorprende que esta optimización no se haya realizado hace tiempo.
Por lo que se me ocurre una pregunta… ¿Cuántos ojos ven tu código?
Da igual la licencia que tenga, que el código esté disponible no significa que alguien lo lea.
¿Qué soluciones usas para las revisiones de código? ¿Es el Pair Programming algo realmente factible para un negocio?
Filed under: Coding, Software Engineering, Tech | Tagged: code review, QA |
Penyaskito 
Como dijo Linus “antes los suficientes ojos todos los errores son obvios”. Hablando de métodos sin optimizar fijate con Reflector en la implementación de CompareTo de Int32 en el framework de Microsoft, vas a ver código repetido en las dos sobrecargas, saludos.
Hombre, lo de que da igual la licencia… Si para empezar la licencia no permite ver ni desensamblar ni modificar el código, me dirás tú si da igual o no.
PD: Si sigues el desarrollo de Mono y colaboras/estás pensando en colaborar te recomiendo que no hagas lo que ha comentando el compañero de arriba. Otra vez, las licencias sí importan. 🙂
@bastian:
La licencia importa en cuanto a ojos potenciales, pero no quiere decir que más gente lea el código. Dentro de una misma empresa se pueden utilizar los procesos habituales del OSS, como por ejemplo, listas de correo de commits.
Hombre, quiere decir que como poco lo leerán las mismas personas (los desarrolladores “internos”). Si el proyecto es open source hay muchas más probabilidades de que alguien de fuera le eche un ojo.