Ardua tarea la de enfrentarse (sí, enfrentarse es el verbo adecuado) a un código escrito por otra persona hace bastante tiempo y que no tiene ningún tipo de documentación. Uno vuelca en el código que hace parte de su forma de ser, de pensar. Por lo tanto lidiar con código de otra persona siempre es distinto que hacerlo con código propio.
El proceso de estas primeras semanas fue apropiarme, en el mejor sentido de la palabra, del código de Diego P. Y se podría decir que ya casi lo he logrado.
Si bien no comprendo del todo el 100% de los detalles, he llegado a tener una idea general de que hace cada una de las clases importantes. Algunas ideas que me ayudaron a hacer que el código me resulte más familiar:
- Cambiar el estilo de indentación y formato por el que yo uso. Esto lo hizo el Eclipse de forma automática.
- Documentar en el código los descubrimientos que voy haciendo, ningún lugar es más accesible que el propio código, especialmente cuando la IDE maneja esa documentación de forma automática.
- Renombrar las variables, métodos y clases para que tengan nombres que me resulten adecuados a mi entendimiento del código.
- Estructurar los paquetes o módulos o incluso jerarquía de clases a medidad que comprendo su funcionalidad y detecto cosas que hubiera hecho distinto.
Cabe aclarar que todos estos cambios no quieren decir que el código original sea malo, simplemente fue hecho por otra persona. Otra persona que ya no lo usará más y ahora quien debe hacer un fuerte uso y reingeniería soy sólo yo. Si tuviera que compartir ese código con la persona que lo hizo u otros desarrolladores no lo tocaría o consultaría primero.
Dejado esto en claro ahora tengo dos objetivos sobre el código:
- Entender un poco más las clases de los paquetes analysis y variable. El resto de los paquetes ya están bastante digeridos.
- Leer un poco sobre la fase callgraph de soot y ver cómo se relaciona con el análisis que hace Diego P. en su tesis.
Con respecto a lo teórico me gustaría releer
Fundamentals of Program Analysis, un libro que me prestó Diego G. y que explica la teoría más básica detrás de los análisis de programas (reticulados, dataflow, may, etc.).
