¿Cómo puedo pedirle a mi jefe (de manera educada) que comente su código?

Mi jefe me está enseñando (acabo de terminar la escuela y él quería a alguien con un poco de experiencia en programación, así que me eligió para capacitarme en lo que esa compañía se especializa) y comenzó a trabajar con aplicaciones ASP.NET MVC , algunos HTML y CSS . Estoy bien con el material de diseño web que me da (es bastante simple de entender sin aclaraciones).

Pero, por ejemplo, me da una tarea que hacer con ASP.NET MVC, me lo explica muy bien. Pero no explica nada en el código que acaba de darme. (Utilizamos el control de código fuente en Visual Studio 2013 ), por lo que son literalmente cientos de líneas de código, sin antecedentes sobre lo que se supone que debe hacer. El tipo de código que estoy viendo es un código que nunca había visto antes, por lo que es realmente difícil intentarlo.

Intentaría hacerle más preguntas, pero él siempre está trabajando (es su propio negocio), y siento que podría molestarse con todas estas preguntas que tengo en mis manos.

Entonces, solo algo que me ayudará hasta que pueda controlar las cosas, ¿cómo puedo pedirle a mi jefe que ponga comentarios en su código que me da, pero cortésmente?

Estás en el "extremo profundo" y, en mi opinión, esa es la mejor manera de aprender. No porque estés mirando cosas de las que no tienes idea, sino porque te obliga a ser más ingenioso y descubrir qué componentes juegan qué papel en un sistema en el que eres nuevo.

No ayuda que su jefe esté demasiado ocupado para manejar a alguien que sea inquisitivo (y usted está totalmente en su derecho de ser inquisitivo; tiene muchas ganas de aprender, lo cual es bueno). Pero, desafortunadamente, pedirle a tu superior que cambie su estilo y enfoque por el bien de tu aprendizaje puede no ser demasiado bueno, especialmente porque estás tratando con alguien que dices que está ocupado.

Estar sentado frente a miles de líneas de código con las que no estás familiarizado es la norma. No siempre se puede explicar en blanco y negro con comentarios. Sin embargo, por el simple hecho de aprender mientras eres nuevo en él, si sientes que definitivamente tienes que pedirle comentarios, tal vez explique por qué. Explique que se debe al hecho de que no desea molestarlo con preguntas, ya que a menudo está ocupado. Esto no solo se verá mucho menos como si le estuvieras diciendo que hiciera algo, sino que también abre el debate sobre cómo podría, en cambio, preferir dejar a un lado las preguntas para pedir tiempo.

Primero, rastrear a través de miles de líneas de código desconocido y sentirse perdido es cómo cada proyecto de software es, en todas partes, desde el principio de los tiempos.

La mayor diferencia entre usted y un programador experimentado es que no está acostumbrado.

Algunos puntos a tener en cuenta:

1. Con suficiente esfuerzo, cada bit de código es comprensible. Muchas personas se sienten frustradas si no pueden resolver algo en pocos minutos. Sé más paciente que eso.

2. Un buen jefe está lo más abierto posible a las interrupciones y preguntas. Un buen empleado se esfuerza al máximo para minimizar las interrupciones y las preguntas. Sé consciente de eso.

3. Las interrupciones son más costosas que las preguntas. Puede hacer un mejor uso de su tiempo y el tiempo de su jefe al consolidar sus debates y nunca terminar una conversación sintiéndose confundido.

4. Tu jefe es mejor programador que tú. (Probablemente). Eso no quiere decir que no se pueda ser más fuerte en algunas áreas, pero en general su experiencia es mayor. Hasta que tenga mucha experiencia, asegúrese de aprender de su experiencia tanto como pueda.

5. Si está seguro de que más comentarios ayudarían significativamente al código, pregúntele a su jefe. "Es difícil para mí entender lo que está sucediendo en algunos lugares. Cuando resuelvo las cosas, ¿te importa si agrego comentarios?" Quizás odia los comentarios. Quizás a él le encantará. Quizás sea indiferente.

Al final, sin embargo, es posible que dentro de un par de meses recuerdes haber preguntado esto y pensar, "¿Eh, me pregunto con qué tuve un problema? Esto no es tan malo. Hm, bueno, no importa".

Si su jefe no tiene tiempo para responder a todas sus preguntas, ¿por qué cree que tendrá tiempo para comentar su código heredado? Y además, ¿qué te hace pensar que sus comentarios realmente describirían los fragmentos que no entiendes por ahora? Según mi experiencia, tratar de cambiar el estilo de programación de sus jefes simplemente preguntándole no funcionará, sea cortés o no.

Lo mejor que puede hacer en tal situación: comente las partes del código que necesita comprender para hacer su trabajo usted mismo - Una vez que haya entendido esas partes, por supuesto, y después de obtener el compromiso de su jefe de que esto estará bien. Si usted o su jefe temen que podría romper algo agregando comentarios, agréguelos en una rama separada y pregúntele a su jefe si se tomará el tiempo de revisar sus comentarios antes de que se fusionen con el tronco. Dado que su jefe solo tiene un presupuesto de tiempo restringido, intente averiguar qué hace una determinada parte primero invirtiendo una cantidad de tiempo razonable. Si realmente se atasca, escriba su pregunta en una lista y pregúntele a su jefe, por ejemplo, una vez al día en lugar de molestarlo 30 minutos. Según mi experiencia, este enfoque funciona con la mayoría de las personas, incluso si están muy ocupadas, siempre que estén dispuestas a ayudarlo, lo cual seguramente es el caso en su situación.

De esta forma, está seguro de obtener los comentarios que necesita, y su jefe verá dónde necesita información adicional y si acertó. Y siempre y cuando se limite a comentar solo las cosas no obvias, existe una buena posibilidad de que sus comentarios aumenten la calidad general de la base del código, lo que podría no solo brindarle beneficios no solo a usted, sino también a todos los demás que tiene que lidiar con el código, incluido tu jefe.

En primer lugar, deja que este sea un ejemplo para comentar tu código correctamente, ¡saltamontes!

Entonces, tengo que hacer esto todo el tiempo. Tengo mi copia local verificada, la reviso y la comento. (Puedo volver a quitarlos a todos si voy a volver a revisarlo, o dejarlos dentro, si a nadie le importa). Luego, cuando realmente no puedo ver más, puedo preguntarle a alguien, aquí, creo que sí. esto (lo que comenté), ¿tengo razón? Entonces puede que hayas hecho el comentario real, pero está hecho y ese es el punto.

Esto es más que una simple solicitud personal. Estás tratando de cambiar hábitos / cultura, y eso no es fácil. Ciertamente no es algo que se pueda lograr mediante una conversación en el pasillo o un correo electrónico. Va a tomar un poco de esfuerzo de tu parte.

Sé el cambio que deseas ver en el mundo.

La cita puede atribuirse falsamente a Mahatma Gandhi, pero es un consejo aplicable. A medida que intente descifrar la base de código, escriba los comentarios que le gustaría haber visto, lo mejor que pueda, y comprométalos, después de ser revisados ​​por su jefe. Ventajas:

• Estás siendo proactivo, en lugar de regañar.
• Estás dando un buen ejemplo. En el mejor de los casos, su jefe / equipo verá los beneficios y hará lo mismo.
• Es probable que algunos de los comentarios digan /* Mystery parameter 3 */o /* 2015-02-09 AidanQuinn: Is this code ever called? */, esas son oportunidades para que sus colegas documenten el código correctamente o corrijan errores latentes.
• Si, durante la revisión previa a la confirmación, se descubre que un comentario que escribió no es exacto, entonces sus colegas ahora saben que el código no estaba claro.

Abstenerse de reescribir o refactorizar al hacer esto, y la introducción de comentarios debería ser casi libre de riesgos. Si reescribe algo, mantenga esos cambios como confirmaciones separadas.

(Sin embargo, antes de embarcarse en este proyecto, asegúrese de que sus expectativas de comentarios sean razonables. Si su idea de un código bien comentado está fuera de la norma ( Ejemplo 1 , Ejemplo 2 ), entonces solo estará haciendo el ridículo usted mismo.)

No pediría comentarios adicionales, pero aquí hay algunas ideas para usted:

1. Programe una reunión con su jefe y haga que revise el código a un alto nivel. Esto debería ayudarte a comenzar. Esperaría unas pocas horas hasta quizás medio día para que pueda ponerse al día. Esto debe incluir el diseño general, los patrones utilizados, etc.
2. Cree un proyecto de pruebas y comience a escribir pruebas unitarias contra el código, esto lo ayudará a comprenderlo sin afectarlo. ¡También puede encontrar algunos errores también!
3. Depure el código según sea necesario para comprender ciertas áreas.
4. Elimine una mejora o error del trabajo atrasado y trabaje en ello.

Los comentarios están bien, pero si el código está escrito de manera directa, debería ser comprensible después de unos días.

Además, no espere entenderlo todo, es mejor enfocarse primero en áreas clave y luego expandir el conocimiento de la base del código según sea necesario.

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 conocía un poco de OO y algunos otros idiomas) y la única persona que me enseñó tenía muy poco tiempo. Siempre fue útil, pero sentí que no me gustaría hacer todas las preguntas que tenía.

Otros ya han sugerido cosas extremadamente útiles aquí (escribir pruebas unitarias, por ejemplo, pero desde mi propia experiencia, eso es algo que habría sido un poco "demasiado lejos" para mí desde cero; o comentar partes del código usted mismo, pero eso puede será difícil dependiendo del primer punto / pregunta que te 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.

Además, tengo que estar de acuerdo con @AK_, quien dijo que realmente no necesitas comentarios en C #. Puede que eso no sea 100% correcto (creo que hay áreas en las que los comentarios definitivamente ayudan, por ejemplo, código con mucha reflexión), pero en esencia lo es. Si escribe realmente 'código limpio' con métodos y variables bien nombrados, y tiene muchas 'mordidas' pequeñas de código, serán casi totalmente innecesarias. Cada vez que sentía la necesidad de comentarios al leer el código hasta ahora, luego de comprender lo que hacía, estaba muy descontento con la forma en que se hizo y pensé que podría haber sido mucho más claro en primer lugar mediante una buena refactorización. Editar: Estoy hablando específicamente de C # comentarios aquí, no la documentación (ya sea de documentación o XML independientes comentarios), ya que creo que la documentación es siempre importante.

• Identifique cuáles son exactamente sus problemas y si puede clasificarlos. Es decir, ¿todavía tiene problemas con el lenguaje en sí o no entiende una sintaxis específica (por ejemplo, expresiones lambda y LINQ en general, o Reflexión)? Si no comprende 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, consigue un buen libro ('C # in a Nutshell' fue para mí, pero escuché que 'C # in Depth' también es espectacular) y lee sobre las cosas que encuentras. La categorización de estos problemas de antemano lo hace más fácil, ya que puede llenar 'vacíos más grandes' de una vez, o incluso preguntarle a su jefe al respecto, ya que ya no son muchas preguntas, sino más bien explicar un solo tema o las construcciones más comúnmente utilizadas para que usted puede obtener un gran "impulso"

• 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 valdrá la pena tarde o temprano, ya sea cuando tenga que extender cosas existentes o se pregunte por qué alguien creó tantos métodos pequeños en lugar de uno donde todo está contenido ;-)

• Conozca 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 a-ha. Incluso si comprende lo que el código que ve allí lo hace, puede hacer que se pregunte por qué se hace de esta manera, y descubrirlo todo por sí mismo a menudo no es tan fácil.

Por favor, no tome el texto anterior como yo haciendo suposiciones sobre su 'habilidad', a menudo cambio accidentalmente entre hablar sobre mis experiencias y hablar 'con usted'. Principalmente significa lo que encontré y lo que hice . Como han dicho otros, esta puede ser una muy buena experiencia y es más o menos el estándar en el trabajo leer código que no es el suyo y del que no sabe mucho de antemano. Pero puede ser realmente satisfactorio finalmente comprender lo que está sucediendo allí y reconocerte a ti mismo mejorando en esta 'habilidad' en particular. Aproveche esta oportunidad para aprender mucho en muy poco tiempo, ¡buena suerte! :)

Probablemente no va a lograr que cambie su estilo.

Lo que puede hacer es hacer muchas preguntas y escribir las respuestas.

Heredé una gran base de código en mi último trabajo, poca documentación y pocos comentarios. Así que intentaría durante media hora con el mismo problema, luego, si aún no podía resolverlo, iría a preguntarle a alguien que lo escribió o sabía cómo usarlo. Luego documentaría todas las cosas que me contó. La mayoría fue en nuestra documentación, algunos fueron en el código como comentarios. Después de un año allí, prácticamente había escrito una gran parte de nuestra documentación y sabía mucho sobre la base del código.

¡Buena suerte!

Estaba teniendo el mismo problema. Soy estudiante de phyzist y tengo buena experiencia en programación. Estaba programando en muchos idiomas pero nada para aplicaciones premium.

Solicité un trabajo para desarrollador web y al instante me pusieron en el back-end de la programación web. Cuando el jefe me mostró la API base para la aplicación REST de nodo, estaba pensando en tirarla. Nunca he visto funciones con devolución de llamada y una sintaxis tan extraña. Y le pregunto a mi jefe si tengo un problema si no entiendo nada en el código. Él está triste, no, está triste porque tengo 1 mes para resolverlo y mientras tanto haré un CMS para probarme con otro frontend.

Bueno, fui 1 línea de código en ese momento y busqué en Google todo lo que no sabía. Así que pasó 1 semana y estaba familiarizado con el código lo suficiente como para poder colaborar con Front Ender. Mi código al principio era una mierda, ¡pero me veo 3 meses después de eso! ¡Estoy codificando mejor y más rápido que nuestro arquitecto de software!

¡Supongo que nunca dejes de aprender! Mi moto -> Sigue aprendiendo y mantén la calma :) No dependas del jefe, sé independiente y pregúntale directamente, pero solo los problemas más difíciles. Porque serás feliz después de descubrirlo por tu propia investigación. Y recuerde cuando deje de aprender que algo anda mal, aprenda cada día cómo ser un buen programador.

Si aprende del jefe, nunca irá mejor que él. Establezca su propio estándar, aprenda a escribir a ciegas, VIM o el complemento VIM para su IDE, Linux wmii, ¡así que algún día irá más allá del jefe y será mejor que él!

Como ingeniero de software con 20 años de experiencia, principalmente trabajando en asuntos relacionados con la seguridad (SF-PD), debo decir que su jefe puede no ser la persona que desea que sea su ejemplo. La falta de comentarios es una señal de un codificador aficionado autodidacta que nunca aprendió a hacer el trabajo correctamente o de un ingeniero sin experiencia. O tal vez un ingeniero que simplemente no tiene tiempo: ¡los plazos y la conveniencia pueden hacer cosas horribles con su código! ;) Sin embargo, es definitivamente un antipatrón para todo ingeniero de software competente.

Su jefe puede ser un muy buen programador, pero parece que no es un buen ingeniero de software. Un ingeniero utiliza la experiencia grupal colectiva para evitar los escollos que otras personas ya han sido atrapadas. Los comentarios efectivos son parte de esa experiencia grupal colectiva para el software, de la misma manera que el análisis de estrés es parte de la experiencia colectiva grupal para la ingeniería mecánica. Sin embargo, lo que cuenta como comentario efectivo es más fluido, y definitivamente es algo que obtienes de la experiencia.

Lo más básico es que los comentarios no deben decir qué hace una línea de código. Hay momentos en que los comentarios para decir qué hace una función también son superfluos (especialmente en C #). El exceso de comentarios puede ser tan ineficaz (y un indicador de falta de experiencia) porque no puede encontrar las cosas importantes en la escoria. Como principiante, es posible que todavía esté trabajando en descifrar el "qué" del código, y para eso solo necesita leer y comprender lo que ha hecho.

Sin embargo, lo importante para los comentarios es que dicen POR QUÉ una línea de código o una función hace lo que hace, donde esto podría no ser obvio. ¿Necesita configurar el módulo X antes del módulo Y? ¿Es importante verificar un código de retorno para ver si un archivo ya estaba abierto, o estamos ignorando conscientemente el código de retorno porque se ha verificado en otro lugar? El "por qué" del código será relevante para todos, independientemente de su experiencia, y también lo será para él dentro de 6 meses, cuando se olvide de la buena razón para hacer algo de una manera particular. Los comentarios no son solo para otras personas, también son para ayudarte en el futuro.

Si desea evitar molestar a su jefe, haga preguntas inteligentes. Concéntrese en preguntar sobre el "por qué" y trate de resolver el "qué" usted mismo (a menos que sea realmente oscuro). A ningún buen jefe le importará que le hagan preguntas si no son el tipo de cosas que podría haber encontrado con R-ing TFM. Y a ningún buen ingeniero le importará que se le pida que haga algo que facilitará significativamente la vida de otro ingeniero, a un bajo costo para ellos. (¡Simplemente no le pidas que rellene los comentarios en toda la base de código!;)

He estado en una situación similar, yo diría

1. Es posible que su jefe quiera que aprenda el camino sucio (siguiendo el código del que no tiene idea) por una razón. Esta es la forma en que aprendemos más en un mes en el trabajo que en un año en la universidad, como se menciona en otras respuestas.

2. Esta es "la norma" como se menciona en otras respuestas. Debería estar más preocupado por dónde comenzar y cómo abordar y en qué centrarse que tratar de comprender cada línea de código de inmediato. Pregúntele a su jefe sobre las herramientas correctas y las formas de depurar / recorrer el código. Este tipo de preguntas te comprarán algunos puntos.

3. De manera regular, siga contactando a su jefe para obtener retroalimentación sobre cómo lo está haciendo, de modo que obtendrá una idea de su posición en términos percentiles, suponiendo que su jefe haya visto un buen número de personas en la misma situación y tenga una idea de cómo lo hicieron.

4. Aproveche esta oportunidad y, a medida que mejore con la comprensión del código, siga agregando comentarios que originalmente esperaba preguntarle a su jefe.

Si realmente quiere tratar de pedirle que ponga comentarios en su código (no lo recomiendo), sugeriría encontrar el código que necesita editar que realmente podría usar algunos comentarios (la mayoría se explica por sí mismo) y hacer la pregunta sobre así: "Estaba mirando este código aquí y estoy tratando de resolver [el problema que tienes] y no pude encontrar ningún comentario para ayudar a explicarlo". Básicamente, trate de demostrar que se ha esforzado por comprenderlo y explique por qué es que ambos podrían beneficiarse de los comentarios que están allí.

Probablemente el 90% del código bien escrito no necesita comentarios. Realmente solo desea documentar las partes del código que se han optimizado y se han vuelto bastante tensas. Una vez trabajé en una empresa que requería que documentaras cada código que modificabas, básicamente los comentarios terminaron siendo perjudiciales para la legibilidad del código porque a menudo se referían al código que se había eliminado o modificado más allá del reconocimiento. Tenga cuidado con los malos comentarios. Pasé una semana depurando una función y, al final, descubrí que el comentario que seguía leyendo sobre cómo establecer tal y tal indicador en "falso" era en realidad todo el problema. Establecí el indicador en "verdadero" y todo funcionó. como se suponía que debía hacerlo.

Si desea comentarios en el código para comprender por qué se ha escrito algo, lo más probable (considerando que es nuevo) aún no comprende las necesidades comerciales. Estoy seguro de que conoce toda la sintaxis y puede leer el código, pero a menos que conozca el propósito de algún código, se sentirá un poco perdido.

Una cosa que me viene a la mente es la programación de pares. Dices que tu jefe está impresionado con tu progreso, por lo que podrías sugerirle trabajar junto a él. Esto les ayudará a los dos a largo plazo. Tu jefe se verá obligado a explicar las cosas que da por sentado y aprenderás más sobre el negocio.

Como otros han mencionado, esto es bastante común, pero eso no significa que solo tengas que aguantar y seguir adelante. No necesita comprender la mayor parte del código con tanta profundidad como cree, y existen estrategias concretas para hacer que el "extremo profundo" sea mucho más superficial:

• Encuentre algo en el código relacionado con la tarea en cuestión. Por lo general, lo más fácil de buscar es algo visible para el usuario, como la etiqueta del botón en la GUI. Escribe dónde lo encontraste. Este será tu punto de anclaje.
• Ahora busque el código a un paso y anótelo. ¿Quién crea el botón? ¿Qué código se llama cuando se hace clic en el botón?
• El control de fuente a menudo es útil para encontrar código que está a un paso. Encuentre cuándo se agregó o cambió el código que está viendo, y vea qué más se registró al mismo tiempo y por qué.
• Repita hasta que entienda lo suficiente como para hacer su cambio, más un nivel más profundo para asegurarse de que no se pierda nada.
• Si se atasca en algún momento, ahora tiene una pregunta muy específica que hacer. Por ejemplo, "No puedo entender de dónde se instancia este botón".

Aquí están mis $ 0.02 al respecto. No estoy sugiriendo una respuesta exclusiva, mucho de lo que se ha dicho aquí es bastante relevante.

Intentaría un poco de ingeniería social para organizar las cosas de modo que su jefe encuentre más fácil / menos lento comentar parte de su código que no hacerlo.

Ahora, esto puede ser bastante fácil si estaba dispuesto a correr un gran riesgo y molestarlo, pero no queremos hacer eso. (nota al margen: simplemente podría no ser capaz de hacer nada sin que él escriba o dicte comentarios, insista y lo moleste indefinidamente, etc.)

¿Cuál es la alternativa, entonces? Algunas ideas, según las circunstancias.

Opción 1

1. Tómese el tiempo para entender una parte de su código como hacer X.
2. Ahora piense en una forma razonable de entenderlo mal .
3. Dígale al jefe (por correo electrónico o decir durante el desayuno o no) que actualmente está tratando de resolverlo.
4. Agregue un comentario diciendo que no está claro qué significa el código, pero lo entiende como Y; intenta hacer que este comentario sea visible para él, ¡pero no lo intentes demasiado!
5. Actúe asumiendo Y, y asegúrese de que su jefe se dé cuenta de su acción (para que no pierda su tiempo trabajando durante mucho tiempo con una suposición falsa).
6. El jefe debe tomar la iniciativa para corregirlo. En este punto, dígale algo como "Realmente desearía que este código tuviera un par de comentarios para evitar que haga una suposición incorrecta. Corregiré el comentario que agregué por mí mismo. ¿Cree que podría ayudarme con alguna descripción general? de este y aquel código? No tengo la suficiente experiencia como para descubrir la intención exacta, y solo un par de oraciones funcionarían ". O algo..

opcion 2

Estás en entrenamiento Trate de organizar una reunión semanal de frecuencia fija (¿adicional?) Con él. En esta reunión, revise algún código, pero debe venir lo suficientemente preparado para que no tenga que explicar cada línea. En algún momento, con suerte, se dará cuenta de que puede saltarse la reunión si solo agrega los comentarios.

Opción 3

Haga que otro compañero de trabajo no comprenda el mismo código que usted. Ambos se acercan al jefe en diferentes momentos haciendo las mismas preguntas. Esa es una manera segura de hacer que se dé cuenta de que no está haciendo algo ... pero no todos tienen el lujo de ayudar a los compañeros de trabajo en el mismo proyecto.

Entonces, solo algo que me ayudará hasta que pueda controlar las cosas, ¿cómo puedo pedirle a mi jefe que ponga comentarios en su código que me da, pero cortésmente?

Si no puede entender el código, ¿por qué cree que los comentarios son su solución?

No conozco su estilo de programación, pero admito que si el nombre de las funciones y variables es engañoso, hace que la comprensión de un código sea muy difícil. Pero si los nombres y funciones o incluso la organización del programa (clases, métodos, propiedades ...) son de modo que el código sea comprensible, entonces el código realmente le hablará por sí mismo.

Será mejor que le pregunte por la arquitectura del programa y si desea solicitarle algo, solicite algunos nombres más significativos para las funciones; eso es más conveniente para él.

Incluso si hay una manera de preguntar esto cortésmente, hay dos posibilidades en cuanto a lo que su jefe pensará acerca de los comentarios en su código:

1. O sería bueno tener esos comentarios en su código, o

2. Que los comentarios en su código no serían algo bueno.

Si su jefe piensa que los comentarios en su código no serían algo bueno (y hay muy buenos argumentos para esto, es decir, se supone que el código es la documentación , y ninguna documentación estipulará algo tan preciso e inequívoco) como el código que realmente lo hace ), entonces no pasará nada.

Ahora, si por casualidad su jefe piensa que los comentarios en su código serían algo bueno, entonces hay una posibilidad considerable de que le diga que estudie su código, entienda cómo funciona y proceda a agregar comentarios a su codificar a sí mismo . (También hay muy buenos argumentos para esto, es decir , necesita aprender , y su tiempo es, por definición, mucho más valioso que el suyo ).

Entonces, a menos que esté preparado para hacer esto, es mejor que no diga nada.