He estado en una situación muy similar a la tuya hace aproximadamente un año. Comencé a trabajar con poca experiencia en programación (aunque, para empezar, sabía un poco de OO y algunos otros idiomas) y la única persona que me enseñaba tenía muy poco tiempo. Siempre me ayudó, pero sentí que no me gustaría hacer todas las preguntas que tenía.
Otros ya han sugerido cosas extremadamente útiles aquí (por ejemplo, pruebas de unidad de escritura, pero desde mi propia experiencia, eso es algo que habría ido un poco "demasiado lejos" para mí desde el principio, o comentar partes del código usted mismo, pero eso puede ser difícil dependiendo del primer punto / pregunta que le haré en un minuto). Los siguientes puntos resumen lo que hice y lo que me ayudó, pero depende mucho de dónde se encuentran exactamente sus problemas.
También, estoy de acuerdo con @AK_ quien dijo que realmente no necesitas comentarios en C #. Puede que no sea 100% correcto (creo que hay áreas en las que los comentarios definitivamente ayudan, por ejemplo, el código de reflexión), pero en esencia lo es. Si realmente escribe 'código limpio' con métodos y variables bien nombrados, y tiene muchos 'fragmentos' de código, serán casi totalmente innecesarios. Cada vez que sentí la necesidad de comentarios al leer el código hasta el momento, luego de entender lo que hizo, me sentí muy descontento con la forma en que se hizo y pensé que podría haber sido mucho más claro en primer lugar por una buena refactorización.
Editar: Estoy hablando específicamente de C # comentarios aquí, no de documentación (ya sea documentación separada o comentarios XML), ya que creo que la documentación siempre es importante.
-
Identifique cuáles son exactamente sus problemas y si puede clasificarlos. Es decir, ¿sigue teniendo problemas con el lenguaje en sí o no comprende una sintaxis específica (por ejemplo, expresiones lambda y LINQ en general, o Reflexión)? Si no entiende las líneas de código, no entenderá lo que hace todo el método / bloque, por lo que comentarlo usted mismo será difícil. Más bien, obtenga un buen libro ('C # en pocas palabras' fue para mí, pero escuché que 'C # en profundidad' también es espectacular) y lea sobre las cosas que encuentra. Clasificar estos problemas de antemano hace que esto sea más fácil, ya que puede llenar 'vacíos más grandes' a la vez, o incluso preguntar a su jefe, ya que ya no son muchas preguntas, sino más bien explicar un solo tema o las construcciones más utilizadas para que puede obtener un gran 'impulso' en esta área rápidamente.
-
Paralelamente a lo anterior, intenté familiarizarme con la "codificación limpia" y las mejores prácticas generales (no específicas del idioma). El efecto de esto puede no ser inmediato, pero se pagará tarde o temprano, ya sea cuando tenga que extender las cosas existentes o se pregunte por qué alguien creó tantos métodos pequeños en lugar de uno donde todo está contenido ;-)
-
Comprende los patrones de diseño comunes. Es posible que aparezcan aquí y allá en el código que está leyendo, y si los reconoce, inmediatamente le dará un momento de a-ha. Incluso si entiendes lo que hace el código que ves allí, puede que te preguntes por qué se hace de esta manera, y descubrir esto por ti mismo a menudo no es tan fácil.
Por favor, no tome el texto anterior como yo haciendo suposiciones sobre su "habilidad", a menudo, accidentalmente, cambio entre hablar de mis experiencias y hablar "con usted". Se entiende principalmente como lo que encontré y lo que hice .
Como han dicho otros, esta puede ser una experiencia muy buena y es bastante estándar en el trabajo leer un código que no es el tuyo y del que no sabes mucho de antemano. Pero puede ser realmente satisfactorio comprender finalmente lo que está sucediendo allí y reconocerse a sí mismo mejorando en esta 'habilidad' en particular. Aproveche esto como una oportunidad para aprender mucho mucho en muy poco tiempo, ¡buena suerte! :)