Почему программирование — это сложно

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Привет! Меня зовут Владислав Василенко, я сотрудничаю с компанией Dev.Pro в роли Software Engineer и считаю, что программирование — это сложно.

Время от времени мне попадаются различные видео, статьи или новости о том, что программирование — это легко и для каждого. Честно говоря, в самом начале своего пути я тоже так думал. Программирование казалось мне очень простым, ведь вся информация была доступна в интернете. Я помню воодушевление, которое переполняло меня после первых строк кода, а также разочарование от первых проблем, которых со временем хоть и стало меньше, но их сложность выросла. Наверное, если бы я изначально знал, что программирование — это сложно, многих ошибок можно было избежать.

В этой статье я собрал одни из самых распространенных проблем, с которыми сталкиваются разработчики, и которые делают программирование сложным. В первую очередь, статья будет полезна тем, кто только задумывается о начале своего пути в IT.

Как сильно я бы не хотел затронуть все аспекты, вполне допускаю, что мог что-то забыть. Если вы хотите поделиться трудностями, с которыми сталкивались, или у вас есть свои доводы в сторону того, что программирование — это сложно или легко, то с радостью жду всех в комментариях.

Чужой код

Наверное, каждый из нас сталкивался с ситуацией, когда собственный код, написанный ранее, становился непонятным и терял значение. В таких случаях приходилось тратить немного времени, чтобы заполнить пробелы в памяти, но все же ничего критичного не происходило.

Другое дело, когда нам достается чужой код, значение которого мы можем вовсе не знать. Обычно, когда наступает такая ситуация, лучшим решением является спросить человека, который написал этот код, о его предназначении, актуальности и т. д. Но также бывают ситуации, когда непонятный код есть, а человека, который бы его объяснил, — нет. А теперь, если вспомнить, что неотъемлемая часть программирования — это улучшение/дополнение старого кода либо полный рефакторинг, то подобные проблемы выходят на первый план.

Проблема работы с чужим кодом чаще всего возникает из-за следующих причин:

  • Слишком много/мало кода. Обычно в жизни встречаются две полярные ситуации: 100 методов против 10. Несмотря на количество методов, функционал работает исправно в обоих случаях, однако поддержка и возможность быстро понять суть функционала хромают в обоих случаях. Размазывание логики или же жесткая инкапсуляция ради уменьшения количества методов негативно сказывается на читабельности такого кода, что приводит к тому, что ваши коллеги тратят лишнее время на попытки понять весь этот функционал.
  • Нейминг. Все мы когда-то читали или слышали про «Clean Code», но ваш коллега мог случайно упустить эти знания, поэтому среди его кода вы запросто можете увидеть что-то подобное, где название ни класса, ни метода не дают понять, что это и зачем нужно. А тратить время на то, чтобы разобраться в чужом коде, не хочется никому.
class DataRecords {
 public loadDataRecord(): void {
   // implementation of getting data from DB
 }
}
  • Отсутствие комментариев. Чужой код — это чаще всего совершенно другой контекст, без погружения в который трудно понять все примененные решения. В итоге время снова будет потрачено на попытки вникнуть в суть. А если вы еще и любитель рефакторинга, то без комментариев посчитаете все не нужным и перепишете, хоть это и не было необходимым.

Окей, с причинами разобрались, как можно это пофиксить? На самом деле существует ультимативное решение для обеих сторон — ревьювать больше ПРов. Те, кто создают подобные проблемы, смогут подчеркнуть для себя примеры хорошего кода или обратят внимание на непонятный код коллег и смогут провести параллель с собой. Те же, кто обычно страдает при работе с чужим кодом, смогут научиться быстро вникать в контекст чужого кода, а также они смогут обратить внимание коллег на проблемные места в ПРе.

Приступ рефакторинга

Хоть раз, но, наверное, у каждого программиста бывало желание переписать чужой код, потому что так будет «лучше». Я специально использовал здесь кавычки, потому что чаще всего это «лучше» будет заметно только с технической стороны, а для бизнеса такой рефакторинг не имеет никакого значения. Даже не всегда «с технической стороны» означает, что все разработчики единогласно поддержат такие изменения, ведь кому-то и ваш код может показаться таким, который нуждается в рефакторинге. На самом деле, кроме двойной работы, которая может возникать в ходе такого приступа, существует угроза создать конфликт.

Среди программистов нередки случаи присвоения кода и ревности к нему, когда другие разработчики что-то там «костылят». Такая позиция и отношение являются довольно опасными, потому что они не только смещают ваш фокус на определенный функционал, ограничивая возможности развиваться, но и могут послужить причиной конфликта. Среди основных причин появления этой проблемы:

  • Новый человек. Часто новые люди приходят на проект со своими амбициями, багажом знаний и «best practices» — порой все это становится толчком к навязыванию их точки зрения и попытке переделать все на лучший лад.
  • Непонимание командной работы. Эта причина применима по большей части для «ревнивцев». Программирование — чаще всего работа в команде, что подразумевает отсутствие подобных претензий на код, ведь в рамках одной команды рано или поздно кто-то добавит изменения в такие места.

В качестве решения подобной проблемы я могу выделить три основных пункта:

  1. Проявлять желание показать пример «хорошего кода» на новых фичах, а не на рефакторинге существующих.
  2. При повторной работе с частью функционала не забывать его актуализировать, удалять что-то лишнее.
  3. Не ассоциировать себя с определенным функционалом, зажимая таким образом в рамки.

Та самая опечатка

Сейчас я попробую описать ситуацию, знакомую почти каждому программисту: баг фиксится в одну строчку, но вы тратите на него целый день. Это то, что уже постигло вас или может ждать в будущем, но определенно к такому необходимо быть готовым.

Вообще ситуации с банальными ошибками, занимающими колоссальное количество времени на их исправление, — это одно из самых нелюбимых занятий разработчиков. Ведь для их решения приходится проверять свои последние изменения, пробовать найти взаимосвязь между ошибкой и кодом, который может ее вызывать. А часто бывает так, что в логах и вовсе нет никакой ошибки, но поведение системы просто сбоит да еще и делает это рандомно. Чаще всего подобное происходит из-за следующих причин:

  • Спешка. Все мы помним про дедлайны, а особенно про те, что «на вчера». Конечно, иногда бывают безвыходные ситуации, когда из-за спешки какая-то опечатка, вызывающая баг, оказывается в продакшене. А как я написал выше, такие ошибки могут проявляться случайно, поэтому даже у QA нет возможности ее заблаговременно выявить.
  • Отсутствие сосредоточенности. Бывает так, что вы пишите код и решаете сделать себе чай. Пока закипает чайник, вы смотрите в окно, а вернувшись за рабочее место, уже не помните на чем остановились, поэтому просто продолжаете писать код. Иногда это не приводит ни к чему страшному, но возникают ситуации, когда после такого чая вы проводите несколько часов дебага.

Из подобной проблемы можно сделать вывод, что если ваш коллега очень внимательно всматривается в монитор, то он ищет ту самую опечатку, поэтому лучше его не отвлекать. А чтобы избегать подобных проблем необходимо прокачивать тайм-менеджмент и умение концентрироваться на определенной проблеме. Если же дедлайн все-таки «на вчера», то необходимо научиться объяснять менеджменту или бизнесу, что такой подход нежелателен и сопряжен с рядом рисков.

Вместо выводов

Когда-то я тоже сделал выбор изучать программирование с мыслью о том, что в этом нет ничего сложного. Как следствие, в процессе обучения я совершил много ошибок: пытался ухватить все и сразу, не старался понять суть и точно не думал о том, что нужно сбавить темп, иначе полученные знания вчера могут забыться уже завтра. Порой мой мозг просто закипал, и мне приходилось брать паузу, чтобы просто осмыслить информацию, которую я только что изучил. Тогда я не думал о том, что меня ждет впереди. Мне было очень сложно представить, что будет на настоящей работе, и какие проблемы и трудности ждут меня там.

В этой статье я постарался рассмотреть различные проблемы, которые делают программирование сложным и с которыми столкнулся я сам, либо мне рассказали о них коллеги. Можно уверенно сказать, что данная отрасль подходит не всем, и ее выбор должен быть осознанным.

На этом статья подходит к своему логическому завершению, а если у вас остались какие-то вопросы, комментарии или предложения, то с радостью готов обсудить!

👍ПодобаєтьсяСподобалось24
До обраногоВ обраному5
LinkedIn

Найкращі коментарі пропустити

Статья дельная, однако слишком узкий круг рассматриваемых проблем. По сути тут все сводится исключительно к кодингу, но если глянуть шире, то программирование выглядит еще куда более сложным занятием. Есть разные операционки, разные БД, мидлвер, интерфейсы, интеграция, версии, потоки, постоянно что-то с чем-то конфликтует, часто версии используемых продуктов устаревают и перестают что-то поддерживать, рассинхрон по тайм зонам, единицам измерения, языкам, кодировкам символов, сюда же и регулярное ’протухание’ паролей, нехватка ресурсов на сервере, различие протоколов коммуникации, закрытые порты и вообще разнообразные фаерволы и ВПНы, требования по безопасности, надежности и устойчивости продукта, кроссбраузерность и кроссплатформенность, требования законодательства и различных регуляторов и аудита. Не говоря о технической документации, которую тоже нужно готовить. Список факторов, определяющих сложность разработки ПО, бесконечен.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мабуть не зовсім в тему статті. Мій сумарний «стаж» програмування починається ще зі школи і продовжується років 20. Але програмувати я так і не навчився. Тобто навчився але не до такого рівня щоб мені за це платили :D «мне попадаются различные видео, статьи или новости о том, что программирование — это легко и для каждого» — тому все таки хочеться вірити, що це не більше ніж реклама, і я такий далеко не один :)

та я ніби трохи задрот :) Писав багато всякого різного, бувало зависав на довсі місяці. Але все рівно — вперся в певний рівень і далі нажаль нікуди :( Це ше було в далекі 200-чні. Після цього ще кілька разів міняв стек, але нажаль мрія так і залишилась мрією. Зараз і поріг входу сильно вищий ніж 10 — 15 років тому.

Складно сказати. Робив щось на зразок Paint для малювання простих анімації під Windows по молодості. Я робив кілька Android апп (без бекенд). Робив багато всякого різного під мікроконтроллери. Бавився трохи з Java і автомейшеном для QA як план «B» для моєї «девелопорської» кар’єри. Але код рев’ювери давали сильно скептичні висновки щодо моїх можливостей. Та і я сам просто бачу, що часто просто не розумію коду який пишуть деви. І написати такого не зможу. Тому ідею з розробкою остаточно закинув кілька років тому. Просто цікаво чи є ще такі унікуми як — які довго програмують як хоббі, але з кар’єрою нічого не вийшло.

Ви не один у кого не вийшло.

test_2digits (test_value)
{
  A a_value create_from (test_value);
  ASSERT_EQ ( a_value.2digits() == (create_from(test_value).2digits()) );
}

Статья дельная, однако слишком узкий круг рассматриваемых проблем. По сути тут все сводится исключительно к кодингу, но если глянуть шире, то программирование выглядит еще куда более сложным занятием. Есть разные операционки, разные БД, мидлвер, интерфейсы, интеграция, версии, потоки, постоянно что-то с чем-то конфликтует, часто версии используемых продуктов устаревают и перестают что-то поддерживать, рассинхрон по тайм зонам, единицам измерения, языкам, кодировкам символов, сюда же и регулярное ’протухание’ паролей, нехватка ресурсов на сервере, различие протоколов коммуникации, закрытые порты и вообще разнообразные фаерволы и ВПНы, требования по безопасности, надежности и устойчивости продукта, кроссбраузерность и кроссплатформенность, требования законодательства и различных регуляторов и аудита. Не говоря о технической документации, которую тоже нужно готовить. Список факторов, определяющих сложность разработки ПО, бесконечен.

Я прямо отсюда чувствую боль автора :)

Есть идеи для сиквелов: 1) «Почему нейрохирургия — это сложно»; 2) «Почему генная инженерия — это сложно»,... Не благодарите :)

Стаття на Хабрі — must have reading. Вочевидь її автор знайомий, що таке storytelling.

Владислав звісно молодець, що написав дану статтю, програмування дійсно складне. І напевне, перш за все для тих хто не готовий постійно вчитись і копатись у деталях.
У мене в голові тільки фраза «А кому зараз легко?».

Если код написан через универсальный интерфейс, то он сложен даже по сравнению с юриспруденцией. Но юристы, внезапно, в развитых странах стоят дороже кодеров. И работать любят ой, не спеша. Почасово, разумеется.

Думать это сложно, думать это больно.

Это it, тут работает кто попало, какая голова?

Думаю, что перечисленное не очень-то и важно. Программирование сложно по другой причине: не работают привычные методы обучения, которым мы пользуемся в повседневности.

Та люди просто логику никогда не изучали, и для них очень больно думать логически. Вот и выходит сложно, такая же проблема есть в цифровой электронике.

Просто обычное обучение это делать что-то с ошибками, уменьшая число ошибок со временем. Например, там мы учим иностранные языки, играем в сквошь, и т. п. Но в программировании это не работает: чтобы программа работала, она должна быть без ошибок. А вот разобраться в чём дело, запустить дебаггер... Это как раз, как если бы перед тем как скзать фразу, полезть в гугл, посмотреть какие слова более точно используются в данном контексте. Или, например, записывать на видео свои подачи в теннисе и сравнивать его в подачами Беккера и добиваться полного сходтва. Это хорошие рабочие методики, но они очень идут вразрез с обычным опытом.

Если непонятно, что написал сам, ПИШЕМ ДОКу. Если не хотим объяснять новым сотрудникам, ПИШЕМ ДОКу. Хотим повысить осознанность коллег, ПИШЕМ ДОКу.
Все уже придумали до нас

угу, потом нанимают специальных ДОКу писателей, у которых артефакты труда — эти самые ДОКи. И как итог мировой океан самоповторяющихся документов, и сплошь масло масляное.

Это где это такое бывает? Фантастика. Ни разу за пятнадцать лет даже не слышал, чтобы в IT проекте проблемой был излишек документации...

А конкретнее? Теоретически — да, можно вообразить раздутый штат техписателей, пишущих ни о чем. Практически — всегда техписателей и результатов их труда — большой дефицит и нехватка. Вот я и прошу пример где удалось их собрать в избыточном количестве?

Я ведь не могу привести в пример свой кейс -> это ведь закрытые для сторонних глаз «документы». Документация по одним и тем же workflow описываются, апдейтятся и апруваются разного рода менеджерами/техрайтерами/инженерами, никак не сообщаясь друг с другом, внося сумятицу в общее понимание.

Недавно пришел на 7 летний ентерпрайз проект. Документации — море! Плюс около 50 часов всяких видео. Вот только все это после создания никогда не менялось — а значит на 80% устарело! И это естественно: где взять столько времени что бы держать столько документации в актуальном состоянии? Тут какого-то архивариуса нанимать надо.
В итоге информации — море, но найти актуальную — невозможно. Хочешь понят как работает сейчас (а не как было год назад) — смотри в код и разбирайся.

Хм. Мы, возможно, говорим об одном и том же, но полностью разными терминами. Я называю это «документации не хватает» — актуальной, конечно. Такой, что ускоряла бы работу с кодом. Ее не хватает, техписателей для ее создания и поддержки не хватает. То, что есть море устаревшей неупорядоченной информации — это дело третье. Вы называете это «документации — море!». Но я понял, ок, спасибо.

Такой, что ускоряла бы работу с кодом. Ее не хватает, техписателей для ее создания и поддержки не хватает.

Посмотрите сколько приходится платить девелоперам что бы они написали код. Раньше еще приходилось нанимать тестировщиков, которые проверят то, что девелоперы сделали. Теперь предложите бизнесу нанять еще столько-же технических писателей, которые будут писать документацию, которая объясняет девелоперам код, который они написали ... Потом еще не лишним будет набрать побольше менеджеров, которые будут координировать всю эту толпу народа...

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

И через 5 лет имеем 100500 док, написанных разными авторами. Естественно, ни одна из них уже не соответствует текущему положению дел, а только вводит в заблуждение.
Сейчас в моде аджайл: а это значит что все меняется каждый спринт, то как работало 2 недели назад уже переделали по-другому. Попробуйте найти свой код, который писали год назад — и увидите что его уже перекостыляли так, что от изначальной идеи ничего не осталось. И что толку от доки?

Як казав один колега: якщо хочете сховати тіло, викладіть його на конфлюенс.

Проблема актуализации документации вечна. Никакой технический писака не будет поспевать за кодом который пишут команды разрабов. Да и смысла в этом нет. Что полезно, так это иметь high-level архитектурную документацию по контексту и компонентам, их связям. Команды разрабов в тестах, особенно E2E описывают что да как используя Gherkin Language, чтобы читабельно было. Ну и по хорошему бы flow diagrams иметь в актуальном состоянии

Все верно. Лучше самого разработчика вряд-ли кто-то опишет что именно он сделал и, что важнее, почему именно так. Часто прочитать код не проблема, проблема понять нахрена)

Ну вот и зачем ты спойлер выложил? Неинтересно ж будет кодить «рок-звёздам».

Єдине що корисне в цій статті для новачків, хто тільки починає вчитись, це кінець статті про те, щоб не перенавантажувати себе і не хвататись за все відразу. Решту, це вже для людей, які рівня хоча би трейні. Людина, яка почала тільки вчитись хіба, що буде open source дивитись чийсь, щоб ревювати пули і так глибоко роздумувати над тим, як автор. На практиці ж ніхто так не буде робити. На жаль будучи ментором в декількох людей різних рівнів, я не побачив практичності статті для початківців, які лишень починають вчитись. Лише для трейні-джунів, які вже мають роботу і стикнулись з першими проблемами. Хоча автор запевняє, що це стаття для тих хто задумується про початок ІТ карєри.
Дякую за статтю та докладені зусилля. Проте варто в майбутньому попрацювати над інформацією для цільової аудиторії, або ж вказувати цю цільову аудиторію відповідно до статті.

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

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

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

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

Тому я мушу погодитись що програмування це достатньо просто, у порівнянні з іншими складними професіями.

Думать вообще сложное занятие.

Что мне нравится на доу, так это то, что всегда найдётся полным-полно экспертов, мало смыслящих в теме, но всегда готовых вставить свои две копейки.

Наивный. Это вообще у людей так везде. А кто вообще думать только на уровне крысы — обязательно в начальники лезет. И у него даже получается... если выше него уже такие же.

Програмуваня , інженерія програмного забеспечення й продуктова розробка це різні речі . Програмувати не складно й це може робити кожний . Бути інженером у команді й колективно писати код це вже інша історія. Розуміти продукт й бути його частиною це вже зовсім інше.
Про код в чужій голові я розповідаю тут youtu.be/oxSDPX90mEE

Це послідовні рівні, досить умовно це:
Вміти писати робочий код
Розуміти тих, хто пише код з тобою
Розуміти тих, для кого цей продукт робиться

Тобто почати працювати і приносити якусь користь в сучасному світі розробки не так вже й важко.

Нейминг. Все мы когда-то читали или слышали про «Clean Code»
Отсутствие комментариев

От КлінКод і інша ідіалістична маєчня якраз диктують що код має бути на 100% self explanatory, і тому коментарів НЕ МАЄ БУТИ ВЗАГАЛІ ЯК ЯВИЩА. Мовляв якщо вони є — це означає що щось пішло не так, тому взагалі взагалі взагалі перестаньте писати коментарі (приклад: medium.com/...​ode-comments-28fef5272752 ). Ну або вже пишіть якщо ви, цитую: «can’t write expressive code».

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

Але ж ні — адепти Клін Коду з боку замовника зовсім недавно відхиляли мої PR-и по причині «присутні коментарі». Мовляв раз є коменти — значить щось не ок. Але що саме не ок вони пояснити не могли (бо в коді то все було ок), і просто сказали видалити коментарі ¯\_(ツ)_/¯

вот вам сходу блеск и нищета аутсорса )))

А до чого тут аутсорс?

Аутсорс тут побоку, вони своїм так само ті PR-и ревьювають. Ми якраз до такої дічі не звикли.

Це вже скоріше наслідок «аутстафу» — бо тіми змішані між нами і ними. Але в аутсорсі часто замовник взагалі не має своїх розробників, тому такої ситуації не може виникнути в принципі.

да, согласен. просто для меня эти обе модели одинаково «аутсорс» — ну как ксерокс )

Ага. Але вони там таке виробляють і без нас — аутсорс в форматі аутстафу просто дозволив нам зазирнути що там у них в їх «продуктах» твориться.

Клін Коду з боку замовника зовсім недавно відхиляли мої PR-и по причині «присутні коментарі».

Сам по себе clean code не запрещает комментарии в коде, просто советует минимизировать их количество и если писать их, то по делу. Поэтому, почему они адепты clean code непонятно, просто им не нравятся комментарии.

Я встречался с прямо противоположным кейсом. Не принимались PR без комментариев, описывающих все методы, свойства и т.д. Т.е. в прямом смысле все — нужно было описывать назначение не только интерфейсных методов, которые выкидываются наружу как API, но и все приватные методы, поля... И эти ребята тоже считали себя адептами clean code и плакаты с принципами были развешаны по всему офису.

Поэтому, почему они адепты clean code непонятно, просто им не нравятся комментарии

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

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

Куди бахнув? Не заапрувають такий PR

“Good code is like a good joke — it needs no explanation” ©

А от і підліткового максималізму підвезли

підліткового

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

це виключення

А от відкрийте той же Clean Code і подивіться розділ «Good comments».

В теории так и есть. Весь смысл языков программирования — это сформулировать задачу для компьютера на языке понятном ЧЕЛОВЕКУ !
Все эти ООП, патерны, бест практисы — это все только для того, что бы один человек мог понять код другого. Поэтому если приходится писать комментарии — значит автор не сумел ясно выразить свое решение языком программирования. И обратно: если джун жалуется на отсутствие комментариев а коде — то в большинстве случаев это просто потому что он недостаточно знает язык программирования (включая ООП, патерны и т.д.).
Вы когда нибудь видели что бы математики требовали писать комментарии к математическим формулам?!

математики требовали писать комментарии к математическим формулам

вони взагалі цілі книги пишуть по багато сторінок :)

Одними лише формулами, а будь-який інший текст — порушення бест практіс? Ви явно в жодну таку книгу не заглядали.

А тепер відкриваєм Мартіна «Clean Code: a handbook of agile software craftsmanship» і дивимся Chapter 4: Comments підсекцію Good Comments. Всю критику відправляти Роберту Мартіну ;-)

Открываем. Оттуда же:

Comments are not like Schindler’s List. They are not „pure good.” Indeed, comments are, at best, a necessary evil. If our programming languages were expressive enough, or if we had the talent to subtly wield those languages to express our intent, we would not need comments very much—perhaps not at all.

Ну и не единым Мартином же.

Don’t comment bad code—rewrite it.

— Brian W. Kernighan and P. J. Plaugher ©

Открываем. Оттуда же

А тепер ще раз — йдем і читаєм весь розділ Good comments.
Якби сама назва розділу вже натякає.

Don’t comment bad code—rewrite it.

Нічого не говорить про те що будь-який код із коментарями автоматично поганий.

Большинство ЯП не считая жабаскрипта и немного питона (ахтунг! троллинг :)), достаточно информативны и выразительны чтобы код читался как хорошая книга или хорошая шутка. Если не достаточно словарного запаса и грамотности то тогда приходится языками жестов пояснять.
Комментарии имеют смысл когда поясняешь например работу сложного алгоритма или почему некое решение было принятно изначально, т.е. на контекстуальном и реже семантическом уровнях.

Зачем язык жестов, есть псевдокод, и есть диаграммы, если нужно кому-то прояснить доступно, то лучше показать это на блок-схеме, чем на куче запутанного кода.

Оно то все есть, но это к проблеме актуации и наличия документации. Это роскошь. А вот понятный код это скилл.

Нужно перенимать наверное опыт умных людей, писателей, юристов, или настоящих инженеров, а не программеров. Завести ящик не нужного мусора, в который складывать все бумажки которые связаны с работой, и иногда будут нужны(это далеко не факт, но лучше когда есть, чем когда нет).

Динамика другая. В этом вихре и подходы к документации устаревают быстрее чем жизненный цикл самого документа :)
Я вот этим пользуюсь: c4model.com
Хороший баланс практичности к временным затратам на поддержку и ридабилити

Русский язык достаточно информативен. Но соглашения пользователя, тем не менее, ты не читаешь. Даже когда они на русском, украинском, про инглиш я молчу.

А вот я из тех идиотов, что читают. И знают любимую игру юристов «найди глагол», когда его на целый абзац текста может быть один, и ржут, когда не оказывается ни одного.

Большинство ЯП не считая жабаскрипта и немного питона (ахтунг! троллинг :)), достаточно информативны и выразительны чтобы код читался как хорошая книга или хорошая шутка.

Регулярные выражения достаточно информативны и выразительны чтобы код читался как /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

С каких пор regex стал языком? То ли дело Brainfuck

Тем не менее, это надо уметь понимать. Их даже кодеру читать — мозг вынесет, особенно понимая цену ошибки. А сколько такого софта, где конечному пользователю это нужно понимать, притом даже на минимальном уровне владения самим софтом, у него ничего тупо не взлетит без REGEX, а если и взлетит — так с дырками в безопасности.

недавно как раз шарился по исходникам go и как же я рад, что их писали не гении вроде Beaver Green, а простые разработчики из гугла, неспособные «ясно выразить свое решение языком программирования»
https://cs.opensource.google/go/go/+/master:src/go/printer/printer.go

Из Google Code Conventions по C++ (как-то не нашел по Go):

Comments are absolutely vital to keeping our code readable. The following rules describe what you should comment and where. But remember: while comments are very important, the best code is self-documenting. Giving sensible names to types and variables is much better than using obscure names that you must then explain through comments.

google.github.io/...​de/cppguide.html#Comments

Как ни крути, а чистый код никто не отменял. Вы бы еще код ядра Линукса привели. Для низкоуровневого кода камменты нужны. Go и Си в эту калитку. Посмотрите репозитории с чем-нибудь на C#, Scala, Kotlin, Java — комментариев будет на порядок меньше (я не говорю про камменты хедеров, параметров ф-й и классов для докогенераций). Для примера CMS-ка от Microsoft: github.com/...​ntentDefinitionManager.cs

Ну вот, из гита котлина: github.com/...​sis/api/scopes/KtScope.kt

И я согласен, что если можно обойтись без комментов, то стоит конечно. В большинстве случаев можно. Но часто бывает так, что логика сложнее чем просто гонять json’ы между клиентом и базой данных (хотя бы как здесь: github.com/...​TenantRouterMiddleware.cs). Просто не стоит бросаться в крайности.

Вопрос не в уровне кода, вопрос больше в его сложности. Если у нас реализация какого-нить алгоритма, то часто без публикации, где содержатся пояснения и доказательства, понять особо ничего и нельзя, хоть на Haskell написано. И комменты не сильно помогут.

Ну, математические тексты — это и есть комментарии к формулам, и они составляют бóльшую часть текста. Более того идеалом математического текста (хотя, возможно, уже и недостижимым на сегодняшний день) является такой труд, который, если изъять оттуда все формулы и всю математическую нотацию, останется понятным, и любой специалист в этой области сможет без труда восстановить ход размышлений и формулы.

Так что Ваше замечание некорректно: математики пишут комментарии к своим работам, и как раз эти самые комментарии и являются продуктом их работы. Иначе другие не смогут их понять.

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

Відкрию секрет — на яку галєру не підеш всюди є замовники із заскоками. Питання тільки наскільки галєра може і хоче їх заменеджити. EPAM великий і має можливості принаймні.

Так у вас же наоборот, заказчики требовали убрать комментарии или я что-то не уловил?

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

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

От КлінКод і інша ідіалістична маєчня якраз диктують що код має бути на 100% self explanatory, і тому коментарів НЕ МАЄ БУТИ ВЗАГАЛІ ЯК ЯВИЩА. Мовляв якщо вони є — це означає що щось пішло не так, тому взагалі взагалі взагалі перестаньте писати коментарі (приклад: medium.com/...​ode-comments-28fef5272752). Ну або вже пишіть якщо ви, цитую: «can’t write expressive code».

Без конкретного кейса обсуждать не имеет смысла. Если комменты были такие же, как в приведённой статье, то поделом.

Підписатись на коментарі