Actualmente estoy cursando una maestría en un campo STEM y trabajando en una tesis. Para mi tesis de maestría, mi asesor me sugirió expandir el código del software del grupo y agregarle nuevas funciones. Sin embargo, es muy grande (algunos archivos tienen miles de líneas) y es difícil de leer. Consiste en muchos archivos diferentes y apenas hay comentarios que expliquen qué hacen las funciones, el significado de las variables, etc. No hay documentación que explique qué hacen las funciones/clases. Parece que cada vez que me enfoco en lo que hace una función, hay múltiples funciones/variables que están definidas en otro archivo y esas funciones/clases en sí mismas tienen cientos de líneas de largo.
Si bien mi asesor mencionó que está dispuesto a ayudarme con cualquier pregunta que tenga, la mayoría de los problemas que tengo están relacionados con el código, ya que es tan gigantesco que ni siquiera sé por dónde empezar a hacer preguntas. Pero el profesor no sabe mucho sobre el código, así que tengo que preguntarle al posdoctorado cada vez que tengo preguntas sobre el código. Sin embargo, el postdoctorado ni siquiera sabe mucho del código (sabe C++, pero la mayor parte del código fue escrito por un postdoctorado anterior), y me dijo que debería enviarle un correo electrónico a ese postdoctorado anterior para responder a mis preguntas sobre el código.
He hablado con algunas personas sobre esto y me han dicho que es una situación muy mala. ¿Debo dejar este grupo y unirme a uno nuevo, incluso si eso significa que tengo que retrasar mi graduación por un semestre adicional (suponiendo que me graduaré a tiempo si continúo con este grupo actual)?
Ha pasado un mes desde que me uní a este grupo y espero terminar para la próxima primavera, pero no sé qué tan realista es esa meta.
Sería muy cauteloso al abordar este tema de tesis. Hay una gran cantidad de esfuerzo de programación aquí, pero no está tratando de obtener una maestría en ingeniería de software, por lo que necesariamente será un proyecto en el que pasará la mayor parte de su tiempo haciendo un trabajo que en realidad está fuera de su disciplina. Además, existe el riesgo de que nunca pueda comprender varios aspectos del código o que entienda mal las cosas y luego haga cambios que rompan el código.
Esta no es una respuesta completa de ninguna manera y está muy lejos de ser mi campo, pero me pregunto si existe la posibilidad de una alternativa antes de abandonar el barco. ¿Podría ir al posdoctorado existente y preguntarle si hay algún proyecto relacionado con el código base, que podría hacer en el tiempo disponible, que ayudaría a avanzar en su trabajo? Luego, llévale esa idea al supervisor y dile que la discutiste con el posdoctorado. Puede obtener un poco de supervisión informal y podría trabajar en una parte del código sobre la que podría recibir asesoramiento... si fuera técnicamente posible, todos estuvieran dispuestos, etc.
siento oír hablar de las dificultades. Yo también era estudiante de posgrado y la mayoría de mis amigos actuales con los que interactúo casi a diario son estudiantes de posgrado. Como señaló Greg, este escenario es muy común pero ciertamente está lejos de ser ideal. Entiendo muy bien sus preocupaciones ya que estuve en este escenario no hace mucho tiempo. Estaba depurando un código escrito por un postdoctorado anterior que estaba en C++ y solo era un novato en C++. Mi supervisor sabía que yo era un novato y no sabía mucho sobre los detalles del código. Sin embargo, solo estaba depurando el código, por lo que no necesitaba suficiente experiencia para agregar nuevas funciones. Al final, después de un par de meses de esfuerzo, pude arreglar el código. Esa fue mi historia.
Sin embargo, en tu caso hay 4 posibilidades:
1) Su supervisor prevé algunas funciones útiles, pero no tiene idea de cuánto esfuerzo implica implementarlas o piensa que puede que no requiera mucho esfuerzo, pero en realidad lo requiere. - (Mal escenario)
2) Su supervisor tiene una buena idea de cuánto esfuerzo es y necesita que lo haga para que pueda usar estas nuevas características en su trabajo (a continuación) y escribir una tesis basada en ello. - (No es un mal escenario a menos que tenga diferentes gustos por los temas en los que desea trabajar para su tesis).
3) Tu supervisor tiene una buena idea de cuánto esfuerzo es y necesita que lo hagas como algo útil para el grupo además de tu tesis. -(No es un mal escenario a menos que tome más de un mes o dos y absolutamente no pueda entrar en su tesis).
4) Tu supervisor tiene una buena idea de cuánto esfuerzo es y necesita que lo hagas porque será útil para el grupo y tomará varios meses y no te ayuda a avanzar en tu campo o no puede ir en tu tesis -(Mal escenario)
Ahora, debe averiguar en qué escenario encaja en términos generales. La forma de averiguarlo es discutir y hacer preguntas al posdoctorado en el grupo, así como a su supervisor. Solicite una reunión y discuta sus inquietudes (no se percibe como lo mejor que se puede hacer, pero en realidad es lo mejor que se puede hacer). Muchos estudiantes se preocupan de que sus supervisores los juzguen negativamente. Esta preocupación debe suspenderse ya que está en juego algo más grande. La comunicación adecuada eventualmente conducirá a buenos resultados y, a su vez, a un buen juicio de todos modos. Nuevamente, debe discutir y comprender cuán útil es este proyecto para usted. Luego, debe llegar a un consenso con los demás sobre cuánto tiempo se espera que tome y si vale la pena hacerlo. Por último, también debe discutir y poner algunas garantías en su plan, es decir,
Y otra cosa importante: Si el proyecto u otros posibles proyectos que podrías emprender en este grupo de investigación no te interesan en absoluto, entonces deberías buscar en otro lado.
Espero que esto ayude. Mis mejores deseos. Siéntase libre de hacer más preguntas en respuesta.
Como sé que algunas personas aquí pueden no estar completamente familiarizadas con la informática y la "documentación", incluyo esto para ayudar a las personas a comprender mejor el escenario.
En algún momento de la vida, si trabaja con código, independientemente de si ingresa a la investigación o a la industria, es probable que se encuentre con magic code.
En la mayoría de los casos, las magic codeobras. Nadie sabe cómo ni por qué, y es probable que el desarrollador del mago original haya seguido adelante. Así que tenemos un producto que funciona, pero nadie conoce la metodología de encantamientos que se usó para producir los resultados.
Un ejemplo de magic code:
c=["6B8CFF","B13425","6A6B04","E39D25"];a='0155000555540ABEC02EFEFC2EBFBF2BFEA803FFF00A6A002A69A8AA55AAF9D76FFD557FF5555F0541502A00A8AA00AA';with(document)for(i=0;i<96;write('<br>')){h=('000'+parseInt(a.slice(i,i+=6),16).toString(4)).slice(-12);for(j=0;j<12;write('<rp style="padding:1 8;background:#'+c[h[j++]]+'"></rp>'))
Nadie, ni siquiera las personas con conocimientos de este lenguaje, sabrán instintivamente lo que hace este fragmento de JavaScript. Hace un dibujo de Mario
Escribiendo código como este, el desarrollador sabrá lo que está haciendo, pero nadie más lo sabrá. Es una técnica notablemente eficiente que ahorra tiempo y espacio si no tiene que explicarle a nadie lo que está haciendo.
La advertencia sobre el código sin comentarios es que en algún momento se desmorona y se vuelve imposible de mejorar o comprender. Alguien antes que usted probablemente tomó el código y lo codificó sobre el código original sin comentarios, y siguió pasando la documentación para que otra persona la manejara, es decir, ahorró tiempo ahora para un eventual costo de tiempo más adelante.
En este punto, parece que "más tarde" ha alcanzado una masa crítica, donde el progreso no puede continuar a menos que se haya documentado el progreso anterior.
Dejar el proyecto lo elimina del problema, pero el problema aún existe y aterrizará en el regazo de otra persona, y si el código es tan malo como usted indica, esta aplicación está a punto de morir.
Debe reunirse con su asesor para discutir sus inquietudes, así como estos problemas:
La respuesta corta a su pregunta es, sí, es realista en el sentido de que es un escenario común, y no, no es realista en el sentido de que puede perjudicar gravemente su carrera y es posible que no quiera involucrarse en un atolladero como este.
La respuesta larga: los científicos son notoriamente malos en el desarrollo y manejo de códigos. Como resultado, a menudo termina como códigos FORTRAN indocumentados de 30 años que solo se ejecutan en una máquina Win95. Puede sonar exagerado, pero solía tener una PC vieja porque cierto software solo podía compilarse con cierto compilador Fortran que tiene la última versión que ejecuta solo Win95 o sistemas anteriores. Por lo tanto, la situación es común y, obviamente, puede ser muy agotador arreglar todo esto. Si no crees que vale la pena el esfuerzo, no te metas. Por otro lado, hay casos en los que el código puede hacer magia y magia importante. En este caso, es una oportunidad para que te conviertas en un mago y un experto en una herramienta que muchos necesitan, pero que, por razones obvias, solo puede ser utilizada por muy pocos. En otras palabras, si es un programa importante, puede ser rentable a largo plazo.
archivobajo el agua
csx
csx