Як я можу попросити свого шефа (ввічливо) прокоментувати його код?

Мене навчає мій начальник (я щойно закінчив школу, і він хотів когось із невеликим досвідом програмування, тому він вибрав мене, щоб навчити мене, на чому спеціалізується ця компанія) і почав працювати з програмами ASP.NET MVC , деякими HTML та CSS . Я добре з веб-дизайном, який він мені дає (зрозуміти це досить просто без уточнення).

Але, наприклад, він дає мені завдання виконати ASP.NET MVC, він це дуже добре пояснює. Але він нічого не пояснює в коді, який він мені щойно дав. (Ми використовуємо керування джерелами у Visual Studio 2013 ), тому це буквально сотні рядків коду, без будь-якого фону щодо того, що він повинен робити. Якийсь код, який я бачу, - це код, якого я ніколи не бачив, тому це справді важко спробувати і розібратися.

Я б спробував задати йому більше запитань, але він завжди працює (це його власний бізнес), і я відчуваю, ніби він може роздратуватися з усіх цих питань, які у мене на руках.

Тож просто щось, що допоможе моїм, поки я не розберуся над речами, як я можу попросити свого начальника вписати коментарі до його коду, який він мені дає, але ввічливо?

Ти в "глибокому кінці", і, на мою думку, це найкращий спосіб вчитися. Не тому, що ви дивитесь на речі, про які ви не маєте поняття, а тому, що це змушує вас бути більш винахідливим і дізнаватися, які компоненти грають, яку роль в системі, яка вам новачка.

Це не допомагає вашому начальникові занадто зайнятий, щоб поводитись з кимось допитливим (і ви повністю в межах своїх прав, щоб бути допитливим; ви прагнете вчитися, що добре). Але, на жаль, просити свого старшого змінити свій стиль та підхід заради вашого навчання може не погіршитись, тим більше, що ти маєш справу з тим, кого ти кажеш, зайнято.

Сидіти перед тисячами рядків коду, з яким ви не знайомі, є нормою. Ви не завжди можете пояснити це чорно-білими коментарями. Однак для того, щоб дізнатися, поки ви не новачок, якщо ви відчуваєте, що вам обов'язково потрібно попросити у нього коментарів - можливо, поясніть чому. Поясніть це тому, що ви не хочете турбувати його питаннями, оскільки він часто зайнятий. Це не тільки натрапить на набагато менше, як ви говорите йому, щоб зробити щось, але це також відкриє слово для дискусій про те, як він, натомість, вважає за краще відкладати питання, задаючи час убік.

По-перше, повзання через тисячі рядків незнайомого коду і втрачається почуття - це те, як кожен програмний проект є скрізь з початку часу.

Найбільша різниця між вами та досвідченим програмістом полягає в тому, що ви до цього не звикли.

Кілька пунктів, які потрібно пам’ятати:

1. При достатньому дотриманні зусиль кожен біт коду зрозумілий. Багато людей відчувають розчарування, якщо не можуть щось зрозуміти протягом декількох хвилин. Будьте терплячішими за це.

2. Хороший начальник максимально відкритий для перебоїв і запитань. Хороший працівник намагається максимально наполегливо мінімізувати перебої та запитання. Будьте в курсі цього.

3. Перерви коштують дорожче, ніж питання. Ви можете краще використовувати свій час і час свого начальника, консолідувавши свої обговорення, і ніколи не припиняйте розмови, відчуваючи себе розгубленим.

4. Ваш начальник - кращий програміст, ніж ви. (Мабуть.) Це не означає, що ви не можете бути сильнішими в деяких сферах, але в цілому його досвід є більшим. Поки ви не маєте великого досвіду, переконайтеся, що ви навчитеся його досвіду якнайбільше.

5. Якщо ви впевнені, що більше коментарів суттєво допоможе коду, попросіть свого начальника. "Мені важко зрозуміти, що відбувається в деяких місцях. Коли я все з’ясовую, чи не заперечуєш, якщо я додаю коментарі?" Можливо, він ненавидить коментарі. Можливо, він йому сподобається. Можливо, він буде байдужим.

Зрештою, однак, можливо, через пару місяців ти згадаєш, що запитували це і думали: "Ага, мені цікаво, з чим у мене виникли проблеми? Це не так погано. Гм, ну, неважливо".

Якщо у вашого начальника немає часу відповісти на всі ваші запитання, чому ви вважаєте, чому він встигне прокоментувати свій спадковий код? І більше того, чому ви думаєте, що його коментарі справді описують шматочки та фрагменти, які ви зараз не розумієте? На мій досвід, намагатися змінити стиль програмування ваших начальників, просто запитуючи його, не вийде, ввічливий чи ні.

Найкраще, що ви можете зробити в такій ситуації: коментуйте частини коду, які потрібно зрозуміти, щоб виконати свою роботу самостійно - звичайно, коли ти зрозумієш ці частини, і, звичайно, після отримання зобов'язання від шефа, що це буде добре. Якщо ви чи ваш начальник побоюєтесь, що ви можете щось зламати, додавши коментарі, додайте їх до окремої гілки та запитайте у свого начальника, чи він знайде час, щоб переглянути ваші коментарі, перш ніж вони об'єднаються до багажника. Оскільки у вашого начальника є лише обмежений бюджет часу, спробуйте з’ясувати, що певна частина робить спочатку власноруч, вкладаючи розумну кількість часу. Якщо ви дійсно застрягли, запишіть своє запитання до списку і запитайте свого начальника, наприклад, раз на день, замість того, щоб не турбувати його будь-які 30 хвилин. На мій досвід, такий підхід працює з більшістю людей, навіть якщо вони дуже зайняті, якщо вони готові допомогти вам - що, безумовно, має місце у вашій ситуації.

Таким чином, ви впевнені, що отримаєте потрібні коментарі, і ваш начальник побачить, де вам потрібна додаткова інформація, і якщо ви все поправили. І поки ви обмежите себе коментувати лише неочевидні речі, є хороший шанс, що ваші коментарі підвищать загальну якість бази коду, що може принести користь не тільки вам, але і всім, хто повинен мати справу з кодом, включаючи вашого начальника.

По-перше, нехай це стане прикладом для того, щоб правильно коментувати свій код, коник!

Тоді я маю це робити постійно. Я перевірив свою локальну копію, і я проходжу її та коментую сам. (Я можу зняти їх все знову, якщо я збираюся перевірити його знову - або залиште їх, якщо ніхто не заперечує.) Тоді, коли я дійсно не бачу далі, я можу запитати когось, ось, я думаю, це так це (що я прокоментував), я прав? Тож ви, можливо, зробили фактичне коментування, але це зроблено, і в цьому справа.

Це більше, ніж просто особисте прохання. Ви намагаєтесь змінити звички / культуру, і це непросто. Це, звичайно, не те, що можна досягти за допомогою розмови в передпокої або електронною поштою. Це займе певні зусилля з вашого боку.

Будьте тією зміною, яку ви хочете побачити у світі.

Цитата може бути помилково віднесена до Махатми Ганді, але це відповідна порада. Коли ви намагаєтеся розгадати базу коду, пишіть коментарі, які ви хотіли б бачити, якнайкраще, і виконайте їх, після того, як їх перегляне ваш шеф. Переваги:

• Ви проявляєте ініціативність, а не нудьгу.
• Ви ставите хороший приклад. У кращому випадку ваш начальник / команда побачить переваги та наслідує його.
• Деякі з коментарів, ймовірно, скажуть /* Mystery parameter 3 */або /* 2015-02-09 AidanQuinn: Is this code ever called? */- це можливості вашим колегам або правильно документувати код, або виправити приховані помилки.
• Якщо під час перевірки перед вчиненням виявлено, що написаний вами коментар є неточним, то тепер ваші колеги знають, що код був незрозумілим.

Утримуйтесь від будь-якого переписування чи рефакторингу, як це робите, і введення коментарів повинно бути майже безризиковим. Якщо ви щось перезаписуєте, зберігайте ці зміни як окремі коміти.

(Перш ніж розпочати цей проект, будьте впевнені, що ваші очікування щодо коментарів є обґрунтованими. Якщо ваше уявлення про коментований код знаходиться поза нормою ( приклад 1 , приклад 2 ), то ви будете лише дурити себе.)

Я б не просив додаткових коментарів, але ось кілька ідей для вас:

1. Заплануйте сісти з вашим начальником і запропонуйте йому пройти код на високому рівні. Це має розпочати роботу. Я б очікував від декількох годин до, можливо, півдня, щоб ви могли швидко набрати швидкість. Сюди слід включати загальний дизайн, використовувані візерунки тощо.
2. Створіть проект тестування і починайте писати одиничні тести проти коду, це допоможе вам зрозуміти це, не впливаючи на це. Ви також можете знайти деякі помилки!
3. Налагоджуйте код у міру необхідності для розуміння певних областей.
4. Візьміть удосконалення або помилку, і не працюйте над ним.

Зауваження в порядку, але якщо код написано прямо, це повинно бути зрозумілим через кілька днів.

Також не сподівайтеся, що все це зрозуміють, краще спершу зосередитись на ключових областях, а потім розширити знання кодової бази за потребою.

Я опинився в дуже подібній ситуації до вашої приблизно рік тому. Я почав працювати з невеликим досвідом програмування (хоча я знав трохи OO та деякі інші мови для початку), і одна людина, яка навчає мене, мала дуже мало часу. Він завжди був корисний, але я відчував, що не хотів би задавати кожне моє запитання.

Інші тут вже запропонували надзвичайно корисні речі (наприклад, написання одиничних тестів, але, з мого власного досвіду, це щось, що зайшло б мені "надто далеко" з нуля; або коментувати частини коду самостійно, але це може бути бути важким залежно від першого пункту / питання, яке я вам запитаю за хвилину). Наступні моменти підсумовують те, що я зробив і що мені допомогло, але це дуже залежить від того, де саме лежать ваші проблеми.

Крім того, я маю згоду з @AK_, який сказав, що вам дуже не потрібні коментарі в C #. Це може бути не на 100% правильним (я вважаю, що там, де коментарі, безумовно, допомагають, напр., Reflection-heavy code), але по суті це так. Якщо ви пишете дійсно "чистий код" з добре названими методами та змінними, і у вас є багато невеликих "укусів" коду, вони будуть майже зовсім непотрібними. Кожен раз, коли я відчував потребу в коментарях, читаючи код до сих пір, то після того, як я зрозумів, що це робив, я був дуже незадоволений тим, як це було зроблено, і думав, що це може бути набагато зрозумілішим, в першу чергу, хорошим рефакторингом. Редагувати: я конкретно говорю тут про коментарі C # , а не про документацію (будь то окрема документація або коментарі XML), оскільки я вважаю, що документація завжди важлива.

• Визначте, які саме ваші проблеми, і чи можете ви їх класифікувати. Тобто у вас все ще виникають проблеми із самою мовою чи ви не розумієте конкретного синтаксису (наприклад, лямбда-вирази та LINQ загалом чи рефлексія)? Якщо ви не розумієте рядки коду, ви не зрозумієте, що робить весь метод / блок, тому коментувати його самостійно буде важко. Швидше, дістаньте гарну книгу ("C # в горішці" це була для мене, але я почула, що "C # в глибині" також вражає) і почитайте про речі, з якими ви стикаєтесь. Заздалегідь класифікуючи ці проблеми, це полегшить роботу, оскільки ви можете заповнити "великі прогалини" відразу, або навіть запитати свого начальника про це, оскільки це вже не багато питань, а краще пояснити одну тему або найбільш часто використовувані конструкції, щоб ви може отримати величезний "поштовх"

• Паралельно з вищесказаним я намагався ознайомитись із «чистим кодуванням» та найкращими загальними практиками (не мовними). Ефект від цього може бути не негайним, але він окупиться рано чи пізно, коли вам доведеться розширити існуючі речі або задуматися, чому хтось створив стільки маленьких методів замість того, де все міститься ;-)

• Ознайомтесь із загальними моделями дизайну. Вони можуть з’являтися тут і там у коді, який ви читаєте, і якщо ви впізнаєте їх, це негайно дасть вам a-ha момент. Навіть якщо ви розумієте, що робить код, який ви там бачите, це може змусити задуматися, чому це робиться саме так, і розібратися з цим самостійно часто не так просто.

Будь ласка, не сприймайте вищенаведений текст, як я роблю припущення щодо вашої «майстерності», я часто випадково перемикаюся між розмовами про свій досвід і розмовою «з вами». В основному мається на увазі те, що я зіткнувся , і те, що я зробив . Як говорили інші, це може бути дуже хорошим досвідом, і це майже стандарт у роботі, щоб читати код, який не є вашим власним, і про який ви не знаєте багато заздалегідь. Але це може бути справді задоволенням нарешті зрозуміти, що там відбувається, і визнати себе вдосконаленням у цій конкретній «майстерності». Скористайтеся цим, як можливість навчитися багато чого за справді короткий час, удачі! :)

Ви, мабуть, не збираєтесь змусити його змінити стиль.

Що ви можете зробити - це задати багато питань і записати відповіді.

Я успадкував величезну базу коду на останній роботі, мало документації та мало коментарів. Тож я б спробував півгодини над тією ж проблемою, то якби я все-таки не міг цього розібратися, я б пішов запитати когось, хто або написав це, або знав, як ним користуватися. Тоді я б задокументував усі речі, які він мені сказав. Більшість увійшли до нашої документації, деякі - у коді як коментарі. Через рік там я практично написав значну частину нашої документації і багато знав про кодову базу.

Удачі!

У мене була така ж проблема. Я студент фізиста і маю хороший досвід програмування. Я програмував на багатьох мовах, але нічого для преміальних заявок.

Я подав заявку на роботу для веб-розробника, і вони моментально поставили мене на задній кінець веб-програмування. Коли бос показав мені базовий api для застосування вузла REST, я думав, що викину. Я ніколи не бачив функцій із зворотним викликом і таким дивним синтаксисом. І я запитую свого боса, чи є у мене проблема, якщо я нічого не розумію в коді. Він сумно ні, йому сумно, що у мене є 1 місяць, щоб розібратися в цьому, а тим часом я зроблю CMS для тестування мене з іншим прикордонником.

Ну, і я пішов 1 рядок коду в той час і гугл кожне, що я не знаю. Так минув 1 тиждень, і я був досить добре знайомий з кодом, щоб я міг зробити деяку співпрацю з передньою стороною. Мій код на початку був лайно, але мені вже через 3 місяці! Я кодую краще і швидше, ніж наш архітектор програмного забезпечення!

Я припускаю, що ви ніколи не зупиняєте навчання! Моє мото -> Навчайтесь і зберігайте спокій :) Не залежайте від боса, будьте незалежними і не запитуйте його прямо, але тільки найскладніші проблеми. Тому що ви будете щасливі після того, як зрозумієте це власним пошуком. І пам’ятайте, коли ви перестаєте вчитися її чомусь неправильному, навчіться кожного дня, як бути хорошим програмістом.

Якщо ви дізнаєтесь від боса, ви ніколи не підете краще, ніж він встановить свій власний стандарт, навчитеся сліпому друкуванню, плагіну VIM або VIM для вашої IDE, Linux wmii, тож ви хоч би один день виходите за межі боса і будете кращі за нього!

Будучи 20-річним інженером-програмістом, в основному працюючи над питаннями, пов'язаними з безпекою (SF-PD), я повинен сказати, що ваш начальник може бути не тим, кого ви хочете бути вашим прикладом. Відсутність коментарів є ознакою або самодіяльного кодера-аматора, який ніколи не навчився правильно виконувати роботу, або недосвідченого інженера. Або, можливо, інженер, у якого просто немає часу - терміни та доцільність, можуть зробити жахливі речі для вашого коду! ;) Це, безумовно, анти-модель для кожного компетентного програмного інженера.

Ваш начальник може бути дуже хорошим кодером, але це здається, що він не хороший програмний інженер. Інженер використовує колективний груповий досвід, щоб уникнути підводних каменів, які вже виявили інші люди. Ефективне коментування є частиною цього колективного групового досвіду програмного забезпечення, так само, як аналіз напруги є частиною досвіду колективної групи в галузі машинобудування. Те, що вважається ефективним коментуванням, є більш текучим, і це, безумовно, щось, що ви отримуєте з досвіду.

Найголовніше - коментарі не повинні говорити про те, що робить рядок коду. Бувають випадки, коли коментарі, які говорять про те, що функція, теж зайві (особливо в C #). Занадто коментування може бути настільки ж неефективним (і вказівкою на відсутність досвіду), оскільки ви не можете знайти важливі речі в дросе. Як новачок, ви, можливо, ще працюєте над тим, щоб з'ясувати "що" коду, і для цього вам просто потрібно прочитати і зрозуміти, що він зробив.

Найважливішим для коментарів є те, що вони кажуть, Чому рядок коду чи функція робить те, що робить, де це може бути не очевидно. Чи потрібно встановити модуль X перед модулем Y? Чи важливо перевірити код повернення, щоб побачити, чи файл уже відкритий, чи ми свідомо ігноруємо код повернення, оскільки це було перевірено десь ще? "Чому" коду буде актуально для всіх, незалежно від досвіду - і він буде актуальним і для нього через 6 місяців, коли він забуде про хорошу причину робити щось певним чином. Коментувати не лише для інших людей, це також для того, щоб допомогти вам у майбутньому.

Якщо ви хочете уникнути роздратування свого начальника, задайте розумні запитання. Сфокусуйтесь на питанні про "чому", і спробуйте самі випрацювати "що" (якщо це справді невідомо). Жоден хороший начальник не буде проти запитання, якщо вони не є тими речами, які ви могли б знайти у R-ing TFM. І жоден хороший інженер не буде проти того, щоб його попросили зробити щось, що полегшить життя іншого інженера значно простіше, за невеликі витрати. (Просто не вимагайте від нього повторно заповнювати коментарі до всієї кодової бази!)

Я опинився в подібній ситуації

1. Ваш начальник, можливо, захоче, щоб ви навчилися брудному шляху (пройшовши код, про який у вас немає поняття) чомусь. Це те, як ми дізнаємось більше за місяць на роботі, ніж за рік у коледжі, як згадується в інших відповідях.

2. Це "норма", про яку йдеться в інших відповідях. Вам слід більше турбуватися про те, з чого почати і як слід підходити і на чому зосереджуватися, ніж намагатися зрозуміти кожен рядок коду відразу. Запитайте у свого начальника про правильні інструменти та способи налагодження / переходу через код. Цей вид запитань придбає вам кілька очок.

3. На регулярній основі продовжуйте підходити до свого начальника, щоб отримати відгуки про те, як ви робите, так що ви отримаєте уявлення, де ви стоїте в відсоткових показниках, припускаючи, що ваш начальник бачив хорошу кількість людей, що знаходяться в одній ситуації і мають уявлення про те, як вони.

4. Скористайтеся цією можливістю, і коли ви будете краще розуміти код, продовжуйте додавати коментарі, які ви спочатку очікували запитати у свого начальника.

Якщо ви дійсно хочете спробувати попросити його помістити коментарі до свого коду (я не рекомендую його), я б запропонував знайти код, який потрібно відредагувати, який би міг реально використовувати деякі коментарі (більшість - це пояснення самостійно) і задати питання про на кшталт цього "Я переглядав цей код тут, і я намагаюся з'ясувати [Випуск у вас], і я не зміг знайти жодних коментарів, які б допомогли його пояснити". В основному спробуйте показати, що ви доклали зусиль для розуміння цього, і поясніть, чому саме так ви могли скористатися коментарями.

Можливо, 90% добре написаного коду не потребує коментарів. Вам дуже хочеться задокументувати оптимізовані та досить напружені частини коду. Колись я працював у компанії, яка вимагала, щоб ви документували кожен змінений код, в основному коментарі в результаті були згубними для читабельності коду, оскільки вони часто посилалися на код, який був видалений або модифікований до невпізнання. Остерігайтеся поганих коментарів. Я витратив тиждень на налагодження функції, і врешті-решт я виявив, що коментар, який я читав про встановлення такого і такого прапора на "false", був насправді цілою проблемою. Я встановив прапор "true" і все працювало як це мало бути.

Якщо ви хочете, щоб у коментарях у коді було зрозуміло, чому щось написано, то, швидше за все, (вважаючи, що ви новий), ви ще не розумієте бізнес-потреб. Я впевнений, що ви знаєте весь синтаксис і вмієте читати код, але якщо ви не знаєте призначення якогось коду, тоді ви відчуєте себе трохи загубленим.

Одне, що спадає на думку, - це програмування пар. Ви кажете, що ваш начальник вражений вашим прогресом, тому ви можете запропонувати працювати разом з ним. Це допоможе вам обом у перспективі. Вашому начальнику доведеться пояснювати речі, які він сприймає як належне, і ви дізнаєтесь більше про бізнес.

Як вже згадували інші, це досить поширене явище, але це не означає, що вам просто доведеться висмоктувати його і пересипати. Вам не потрібно розуміти стільки коду в такій глибині, скільки ви думаєте, що ви робите, і є конкретні стратегії, щоб зробити "глибокий кінець" набагато дрібніше:

• Знайдіть щось у коді, пов’язаному із заданою задачею. Зазвичай найпростіше шукати щось таке, що бачить користувач, як-от мітка кнопки на графічному інтерфейсі. Запишіть, де ви його знайшли. Це буде вашою якорною точкою.
• Тепер знайдіть код в одному кроці і запишіть його. Хто створює кнопку? Який код викликається при натисканні кнопки?
• Контроль джерела часто корисний для пошуку коду, який знаходиться в одному кроці. Знайдіть, коли доданий чи змінений код, який ви шукаєте, і подивіться, що ще було зареєстровано, і чому.
• Повторіть, поки ви не зрозумієте достатньо, щоб внести зміни, а також на один рівень глибше, щоб переконатися, що ви нічого не пропускаєте.
• Якщо ви застрягли в будь-якій точці, тепер у вас є дуже конкретне питання. Наприклад, "я не можу зрозуміти, звідки ця кнопка отримується примірник".

Ось мої 0,02 долара з цього питання. Я не пропоную ексклюзивної відповіді, багато сказаного тут є досить актуальним.

Я б спробував трохи впорядкувати соціальну інженерію, щоб влаштувати речі так, щоб вашому начальнику було легше / менш трудомістко коментувати частину свого коду, ніж не робити.

Тепер це може бути досить легко, якщо ви були готові ризикувати і дратувати його - але ми не хочемо цього робити. (бічна примітка: Ви можете просто не змогти зробити що-небудь без того, щоб він записав або продиктував коментарі до йо, ви наполягаєте і докоряєте йому про це нескінченно тощо)

Яка альтернатива тоді? Кілька ідей, залежно від обставини.

Варіант 1

1. Знайдіть час, щоб зрозуміти частину його коду, як це робить X.
2. А тепер подумайте про розумний спосіб Y, щоб неправильно його зрозуміти .
3. Скажіть босу (електронною поштою або скажіть через сніданок чи що ні), що ви зараз намагаєтеся розібратися в цьому.
4. Додайте коментар, кажучи, що не ясно, що означає код, але ви розумієте його як Y; спробуйте зробити цей коментар видимим для нього - але не намагайтеся занадто сильно!
5. Закон за умови , Y - і зробити впевнені , ваш бос зауважує свої дії (так що вам не витрачати час роботи в протягом тривалого часу на хибному припущенні).
6. Бос повинен проявити ініціативу, щоб виправити вас. У цей момент скажіть йому щось на кшталт "Я дуже хочу, щоб у цього коду було кілька коментарів, які не давали мені зробити неправильне припущення. Я виправлю коментар, який я додав для себе. Чи ви гадаєте, ви могли б допомогти мені з деяким загальним описом цього-і-того фрагмента коду? Я недостатньо досвідчений, щоб зрозуміти точний намір, і я лише пару речень зробив би трюк ". Або щось..

Варіант 2

Ти на тренуванні. Спробуйте домовитись про (додаткову?) Щотижневу зустріч з фіксованою частотою. На цій зустрічі перегляньте якийсь код - але вам потрібно підготуватися достатньо, щоб йому не довелося пояснювати кожен окремий рядок. У якийсь момент - сподіваємось - він зрозуміє, що може пропустити зустріч, якщо просто додав коментарі.

Варіант 3

Знайдіть іншого співробітника, який не зрозуміє той самий фрагмент коду, що і ви. Ви обоє підходите до начальника в різний час, задаючи однакові запитання. Це впевнений спосіб змусити його усвідомити, що він щось не робить ... але не у всіх є розкіш корисних колег по одному проекту.

Тож просто щось, що допоможе моїм, поки я не розберуся над речами, як я можу попросити свого начальника вписати коментарі до його коду, який він мені дає, але ввічливо?

Якщо ви не можете зрозуміти код, чому ви вважаєте, що коментарі - це ваше рішення?

Я не знаю його стилю програмування, але визнаю, що якщо назва функцій і змінних вводить в оману, це робить розуміння коду дуже важким. Але якщо імена та функції або навіть організація програми (класи, методи, властивості ...) такі, що роблять код зрозумілим, то код насправді буде говорити з вами сам по собі.

Ви краще запитайте його про архітектуру програми, і якщо ви хочете запитати у нього щось, попросіть ще кілька змістовних імен для функцій; що зручніше для нього робити.

Навіть якщо є спосіб запитати це ввічливо, є дві можливості щодо того, що ваш начальник подумає про коментарі у своєму коді:

1. Або добре, що коментарі в його коді було б добре мати, або

2. Ці коментарі в його коді не були б гарною справою.

Якщо ваш начальник вважає, що коментарі до його коду були б не надто хорошими (і для цього є дуже хороші аргументи, тобто код повинен бути документацією , і жодна документація ніколи не буде визначати щось так точно і як однозначно як код, який насправді це робить ,) тоді нічого не станеться.

Тепер, якщо випадково ваш начальник вважає, що коментарі в його коді було б гарною справою, то є великий шанс, що він скаже вам вивчити його код, зрозуміти, як він працює, і продовжуйте додавати коментарі до його кодуйте себе . (Для цього теж є дуже хороші аргументи, тобто вам потрібно вчитися , і його час за визначенням набагато цінніший, ніж ваш .)

Тож, якщо ви не готові це зробити, вам може бути краще нічого не сказати.