Comments 28
По ревью согласен.
А с остальным деваться некуда совсем, к сожалению =) Не придумали мы пока ничего лучше.
Документация — это комментарии, вынесенные из текста программы.
вот это очень сомнительное утверждение, если документация НЕ начинается с того зачем начали писать программу, то есть что хотели запрограммировать, вряд ли это будет хорошая документация. То зачем начали писать программу очевидно было известно до появления этой самой программы, поэтому не может быть изначально комментарием к программе, хотя в комментарии это потом добавить конечно можно, но это будет выдержка из документации в коментариях, а не наоборот.
Вот так и появляются неразрешимые проблемы, ставим телегу впереди лошади, и пытаемся изобрести самую иновационную телегу для такой конструкции, а все как-то не получается. Вопрос с ведущей телегой в связке лошадь-телега в обратной последовательности оказывается неразрешимым, и никому в голову не приходит просто их местами поменять, как после такой перемены о неразрешимых проблемах рассуждать?
Ну, я писал о том, как реально бывает, а не о том, как хотелось бы, чтобы было. Я согласен, что документация должна быть хорошей. Но на практике она почему то везде плохая. Ну, почти везде.
Часто её заставляют писать программистов. А писать документацию надо уметь, и не все программисты умеют. И начинают они с того, что знают лучше всего: с потрохов программы.
А писать документацию надо уметь
Хорошо, когда этим занимается специально обученный человек - технический писатель.
Я совершенно согласен. Правда, по какой-то причине я ни разу не видел технического писателя ни в одной из команд, где я работал.
Я работал несколько лет в проекте, где на четверых с половиной программистов было два технических писателя. Половина среди программистов — это один из технических писателей. Да, он участвовал и в разработке.
Первый писал документацию пользователя, и делать это хреново у него просто не было никакой возможности — принимали продукт такие матёрые монстры, что за любой непонятный момент или просто отсутствующий (потому, что “ну, всё же очевидно же!”) спустили бы с него семь шкур, после чего распяли бы и бросили на съедение крокодилам.
А второй, который “половина программиста”, был прежде всего этаким архивариусом — он подшивал в свои талмуды буквально всё, начиная с диаграмм, что мы рисовали на “дейликах”, заканчивая салфетками, на которых во время посиделок рисовалась внезапно пришедшая с очередным тостом идея. Его писательство было предназначено отчасти для самих нас (идея, пришедшая с тостом, могла с утра оказаться безвозвратно или до очередной попойки утерянной), но главным образом для новых программистов, вписывающихся в проект — именно с целью предельно сократить во времени пресловутый “онбординг.” Валерик, привет тебе, ты чертовски крут в этой роли!
Важно заметить — на наличии этих двух должностей жёстко настаивала прежде всего сама команда. И я вполне допускаю, что в большинстве проектов без технических писателей причина их отсутствия — в отсутствии такой вот жёсткой позиции самих разработчиков.
Часто её заставляют писать программистов.
ну да пытаются выяснить что же должна делать написанная программистом программа, и как это вообще могло бы работать с точки зрения автора, а он бедный не знает, он знает только как переменные присваиваются, и то не точно.
Вообще документация на фичу должна появиться раньше кода фичи. Это собственно описание фичи, БД, классов и функционала. Непонятно как без этого вообще получается что-то сделать.
Если не считать требование к фичи, которые как-бы по умолчанию должны быть раньше кода, то по моему опыту писать документ вместо кода в подавляющем большинстве случаев малопродуктивно.
Потому что документ, в отличии от кода, невозможно отладить, протестировать и т.д. и т.п. И когда заставлют писать, скажем дизайн перед кодом, то получается, что придумали какой-то более менее рабочий дизайн, написали документ, пошли писать код и столкнулись с какой-то проблемой. Код правится чтобы обойти эту проблему, на дизайн все уже забили, он же уже написан!. и в результате дизайн не отражает код и в таком виде практически не имеет никакой ценности.
Возможно, если вместо текста использвоать какие-то специальные инструменты (ну например, пример из головы, какой-нибудь анализатор SQL запросов), то это могло бы быть эффективней написание кода, но простой текст и/или диаграмки все-же не тянут.
На эту тему недавно здесь на хабре была статейка в которой предлагалась писать дизайн на некотором формализованном языке и "тестировать" ее относительно кода, вот в таком подходе возможно было-бы все лучше, но и то я думаю написать хороший дизайн перед написанием когда целиком никогда не получится, максимум итеративный подход, когда на первой итерации прикидываем какой-то подход, пробуем его закодировать, вылавливаем проблеммы, исправляем паралелльно дизайн и код. И чтобы документ реально исправлялся нужны автоматические инструменты, типа "тестов" соответсвия дизайна-кода, иначе нельзя быть уверенным, что дизайн актуален.
Мне кажется вы перепутали документацию "о программе" и требования "к программе". Хотя чисто формально требования и можно считать документацией, но на смом деле они практически ничего вам не скажут о программе. 10 программистов получив одни и те-же требоваия напишут 10 разных программ.
А вот когда идет речь про документацию "о программе": дизайн, описание интерфеса, user manual тот-же самый и т.п., то это уже реально "выдержка из комментариев", плюс в 99% случаях не соответсвует реальной программе, т.к. код првится часто (баги-то надо править), а документация только когда прижмет.
> если документация НЕ начинается с того зачем начали писать программу, то есть что хотели запрограммировать, вряд ли это будет хорошая документация
Так и в хороших комментариях надо писать не о том, что делает код (это и по коду понятно), а о том, зачем здесь этот код. Так что документация и комментарии — довольно близкие понятия, оба нужны чтобы ответить на возможные вопросы.
более того и сам код вполне подходит под определение документации.
Более то, если вы посмотрите какой нибудь MPEG-стандарт, вы найдете там много С-подобного псевдо кода, потому что в некоторых случаях оказывается что С-подобный код это самый простой способ описания способа вычислений. То есть код является частью стандарта, а значит частью документации.
Мне кажется здесь нет никаких неразрешимых проблем. Есть банальное осознание того факта, что успех не гарантирован и все. Просто "потому что". Но можно повысить шансы на него
Собеседования
Вот яркий пример. Посмотрите сколько распадается браков, сколько людей увольняется и т.д. Статистика точно говорит, что неуспех возможен и вполне вероятен, а если у вас денег по низу рынка - то шансы найти хорошего спеца ничуть не выше чем беспроблемное авто за штуку баксов
Онбординг ... и легаси
Тут мне кажестя проблема в вопросе, которій является плохим (а хороший - это то, который содержит половину ответа). Ок, вам дали legacy код необъятного размера. Зачем вам считать количество строк? Напишите программу, которая это подсчитает за пару минут и успокойтесь.
Вам нужно научиться его собирать и понять, как новую версию допихать до прода. Это ваша первая и главная задача. Точнее две. Собирать из исходником что-то работающее и знать, как из кода сделать "пакет" установки". Все остальное потом
Будет день - будет пища. Этим принципом надо руководствоваться, если впереди что-то большое и не очень понятное.
Будет баг - вот и посмотрите. Попросят допилить фичу - вот тут и уточнить, где лежат требования к тому что есть и как к нему можно прилепить что-то новое
Но конечно елси вы (непоняно зачем) поставили задачу "разобраться во всем", то очевидро что такая задача может быть решена только за все время мира :)
Комментарии
Вообще по фиг, тем более что в 99% случаев им можно верить, если они есть
Документация ... Потратил две недели, в основном, потому, что в документации была фактическая ошибка, а я не мог связаться с реальными разработчиками
Ну добрались же. Никто не идеален, но так как код проверяется, а дока нет - там могут быть ошибки. У всех были такие эпизоды и ваш метод отлично работает
Код-ревью
Я, хвала богам, делаю это не часто и обычно просто ищу там то, что я там ожидаю увидеть. Для этого надо свои ожидания озвучить до того :) Потом их или найти, либо нет
Плюс ... не надо проверять все. Зачем? Кто-то ездит на БМВ, кто-то на мерсе, но если их сравнить - это две абсолютно разные изделия с общими идеями. Но обе ездят. Так зачем вам быть такими детальными?
Если требований нет - все верно, ищем очевидную "дичь" и не паримся
---------------
Вы зачем-то сравнили реальную жизнь и идеальную мат. модель. Это не имеет смысла, так как модель мира (как минимум в части управления) работает совершенно по другому
К счастью у нас есть четыре волшебных средства, которые помогают нам в адаптации. Комментарии, документация, тесты и помощь коллег.
Несколько раз проходил оный этап, включая дремучее легаси с классами размером более десяти тысяч строк. Больше всего помогает дебаг, опыт копания в других легаси, ибо шаблоны плюс-минус одинаковые, ну и навигация ИДЕ.
Но дебаг по факту последнее средство - он медленный и неэффективный. Бывает что вот он код, а запустить нормально очень тяжело, вокруг ещё пара тысяч строк кода инфраструктурного, в которых не хочется разбираться.
Поэтому если у нас есть коллеги, то это лучше, чем дебаг =)
В тесты и комменты с документацией я верю слабо. Документация нужна и помогает в начале, но она отстает и мне лично всегда её не хватает. Коллеги - лучший источник информации, а дальше действительно только дебаг (и упомянутая навигация в IDE).
В монолите - да, а в микросервисах дебаг не поможет, там логи: гигабайт, третий, пятый... А ещё надо все условия/конфиги соблюсти чтобы система взлетела, а их стотыщмильонов. А документация дырявая. И дай бог, чтобы коллеги знали хоть 30 процннтов из того, что нужно. Аналитики сами к разрабам с вопросами идут, а тестировщики заводят баги из-за того, что тоже не знают правильные условия/конфиги для нормального полёта системы. Короче, помощи ждать неоткуда. Погибай сам как знаешь, разраб! (
Если мы бросили монету два раза, то с большой вероятностью можем получить “все орлы” или “все решки”. А тысячу раз, то вероятность “всех орлов” или “всех решек” одна миллионная.
Такое впечатление, что тут автор немного погорячился ;-)
Если бросить монету тысячу раз, то вероятность “всех орлов” или “всех решек” будет 1/2^1000, что очень грубо (по порядку величины) равно 1/10^300 (Считаем, что в килобайте тысяча байт ;-) Напомню, одна миллионная - это 1/10^6. То есть, в нашем случае "немного" - это 10^294. Для сравнения, число нуклонов в видимой части Вселенной
порядка 10^80.
То есть, если каждый нуклон в нашем мире заменить на Метагалактику, а в затем в каждой из них сделать еще раз то же самое, то общее число нуклонов в такой "Метагалактике в кубе" будет всего лишь в 1000000000000000000000000000000000000000000000000000000 раз меньше, чем та ошибка, которую совершил автор ;-)
А вот чтобы получить вероятность “всех орлов” или “всех решек” порядка одной миллионной, монету надо бросить всего лишь раз 20...
Да, вы совершенно правы, это моя ошибка. Я просто метался в этом месте, сначала написал тысячу, потому подумал, что это выбивается из примера с вопросами. Никто же не будет задавать тысячу вопросов.
Поменял на двадцать, забыл убрать тысячу. Решил убрать тысячу, убрал двадцать. Всё потому, что середина рабочего дня, тем более понедельника. Созвоны, программирование, опять созвоны, опять программирование, и где-то в перерывах исправление ошибок.
Спасибо. Всё исправил, теперь там двадцать
Да не парьтесь Вы так ;-) Статья неплохая, свой плюс от меня она получила ;-) А ошибки такого плана у всех бывают. Мы же почти всегда (увы!) живем в условиях дефицита времени, а вовсе не только на собеседовании... А возможность вылизывать статью до бесконечности сейчас мало у кого есть. Главное-то сказано правильно, и опечатка на эту суть не влияет.
Так что давайте смиримся с тем, что написание идеальной (в т.ч. безошибочной) статьи - это тоже одна из "неразрешимых задач современной индустрии" ;-) Для этого и нужна критика в комментариях. Я пытался сделать ее не обидной, а цифры меня даже немного повеселили. Надеюсь, Вас тоже ;-)
Благодарю за конструктивный ответ!
(у меня года три назад начальник в ответ на фразу "тут ~1000 коммитов. Прогон на "годный/не-годный" занимает 5 минут. Значит, бисектом мы где-то за час справимся (из них 10 минут на сктипт-автоматизацию).). На что осталось ощущение, что он тупо не знает, что такое бисект. Годы прошли, оказалось, что так и есть, увы...
Код ревью.
Хороший писатель != хороший читатель. Из опыта я знаю, что хороший читатель на вес золота, очень редкая птица. Но это навык, который тренируется так же как и решение олимпиадных задач, как подготовка к собеседованиям в фаанги. Правда я не знаю как тренироваться эффективно, не могу ничего посоветовать. Хотя. На моей 3 работе у нас была практика дежурства - это когда один программист весь спринт (2 недели) занимается исключительно и только фиксом крашей. На сегодняшний день я пересмотрел тысячи кол стэков и пофиксил около тысячи крашей и уверен что эта практика помогает не только быть аккуратнее с УБ в своем коде, но и значительно развивает навык чтения в целом. Но первые свои такие дежурства вспоминаются очень больно, сидишь как дурак и пялишься в стэк часами не понимаю буквально все, но это проходит довольно быстро. Писать новый код значительно легче чем чинить старый - тренируйтесь на крышах и багах, они значительно лучше развивают навык чтения кода чем написание нового кода.
Тесты.
Юниты, тдд, моки и прочие баз ворды не помогают. Помогают тесты которые проверяют ожидаемое поведение вашего продукта, а не куска кода. Такие тесты очень устойчивы к изменениям в реализации, не требуют много подготовительной работы и самые понятные. Если ваш продукт это библиотека то тесты которые проверяют его называются юнит тесты, если изолированная фича /микросеовис то интеграционные, если приложение то энд ту энд. Не надо тратить ресурсы на не те тесты, сосредоточьтесь на тех которые будут больше всего полезны вашему продукту.
Комментарии.
Я их не читаю, но пишу. Пишу когда вопрос почему я сделал что то не так как обычно/другие. Что делает код я могу разобраться всегда, зачем он делает именно это я могу узнать из баг трэкера, а вот почему часто не может ответить и сам автор.
Документация.
Не нужна, если есть доступ к исходникам, нужна если нет.
Помощь коллег.
Я тут посмотрел код и вижу что он делает вот это (детальное описание), через гит нашел пару тикетов и вижу зачем он это делает (пункты из задач). В моем тикете мне нужно сделать вот так (описание задачи и предполагаемое решение а лучше пара). Для этого мне нужно поменять вот этот кусок код, но я не знаю почему он делает так и не сломаю ли я что то если переделаю. Из Гита я вижу что ты работал над этим кодом, расскажи какие риски ты видишь или к кому обратиться за помощью. Вот такой запрос о помощи не игнорируется никогда - надо быть готовым к тому что бы вам помогли.
Чаще всего вместо этого я вижу дичь на ревью, потому что человек не захотел подготовиться, а потом начинает активно защищаться когда я заставляю исправить код.
Тьюринг также обнаружил первую неразрешимую проблему в программировании — проблему остановки. Он выяснил, что написать программу, которая может проверить правильность другой программы, в общем случае нельзя. В каких-то ограниченных случаях можно, а в общем — нет.
Упс! Немного не в тему статьи, но раз уж упоминается этот прискорбный эпизод, то стоило также упомянуть, что проблему остановки Тьюринг рассматривал, насколько мне известно, в рамках собственной вычислительной модели. А в других моделях? Ставлю математикам новую "теорему тысячелетия" - докажите, что существует неограниченное количество вычислительных моделей (назовем их независимымыми парадигмами), не сводимых к модели Тьюринга. Вторичная теорема - докажите, что в таких моделях неизбежно существуют задачи, неразрешимые в одной модели, но успешно разрешимые в альтернативной. Подсказка - для первой теоремы давно найдены частные решения, но не общее (см. сверхтьюринговые вычисления). Следовательно, вторая теорема может быть верна, хотя общего решения тоже нет, насколько мне известно. Хотя в частных случаях ее верность также очевидна, пример - в квантовых вычислениях существуют решения задач, в принципе неразрешимых в неквантовых. Но это так, к слову, тем кому интересно.
Проблема названная онбордингом как мне кажется на деле гораздо существеннее. Легаси, которое нужно изучать, может возникнуть сразу после написания кода. В проектах где работаешь не один параллельно возникают пласты кода с которым абсолютно не знаком. Даже сам можешь написать кусок кода который работает непонятно почему, но времени разбираться нет. Или забыть после отпуска, на какой версии API в итоге остановились.
Как раз код-ревью это не проблема, а решение. При правильном применении код-ревью становится тем онбордингом, который помогает погрузиться в проект с колёс. Ревьювер же не обязан что-то написать в ревью. Его задача просмотреть код и попытаться понять, может чуть увеличить бас фактор. Так же можно помочь и коллеге с какими-то досадными недоразумениями и самому воспринять что-то новое для себя, что сам не практикуешь.
Почему-то совсем ничего не написано про контроль версий. А ведь аккуратная работа с системой контроля версий и трекингом задач довольно не плохо заменяет комментарии и документацию кода (не бизнес). Блейм и анализ лога версий - это и ретроспективный код-ревью и онбординг.
Так что, по моему, проблема погружения в код хоть и существуют, но сильно упрощается культурой (код-ревью) и технологией (контроль версий)
Прочитал статью и как интересно она отражает реальность. Доктора обсуждают болезни, танцоры движения, писатели сюжеты для книг. А тут программисты обсуждают неразрешимые проблемы программирования. Которые на поверку оказываются социальными.
У программирования как раздела математики нет проблем, просто потому что проблемы математики носят не прикладной, а теоретический характер и являются не столько проблемами, сколько законами и ограничениями мироустройства, зато у программирования есть проблемы социальные.
Как подобрать коллектив, как наладить работу, как настроить постороннего человека выполнять задачи поставленные перед коллективом, как наладить образование. Это из того что раскрыто в статье, а за кадром наверное осталось, как удержать спрос, как монетизировать фичи, как не вляпаться в налоговые и административные ограничения, как не накосячить в других аспектах.
Программирование из раздела сакральных знаний выходит в массы и как результат критерии отбора становятся более ремесленными. Раньше в этой области трудились победители математических олимпиад и на собеседовании их пытались выявлять, задавая олимпиадные задачки, а теперь нужно найти человека который будет тянуть рутину.
Раньше куски кода рождались с целью превозмочь ограничения реальности на каждом шагу, а нынче нужно просто прикручивать фичу к уже существующему коду, в котором нужно хоть немного разобраться и впаять костыль, так чтобы и дальше можно было поддерживать работающую кодовую базу.
Очень похоже, что в программировании мы столкнулись с кризисом идей, не появляется новых программ. Картинки меняются а суть остается прежней. Во главу угла поставлена монетизация.
Новые идеи не требуют всего того что описано в статье. Если для реализации идеи нужно больше чем 1 человек, то это скорее всего не самая лучшая идея. Для реализации алгоритма обратного распространения ошибки не нужна команда из 100 человек... И ТДД с УМЛ тоже будут только удлинять путь от идеи к монетизации.
Как итог в коде рожденном на базе идеи нет документации, нет комментариев. Все это приходит на этапе, когда более менее удачную идею начинают насыщать маркетинговыми фичами и нанимают "команду".
Мы наблюдаем то, что новое, пока еще не устоявшееся ремесло начинает обрастать терминологией, критериями успеха, процессами. Мы просто наблюдаем как программирование растет и переживает кризисы взросления. Мы счастливые люди, на нашем веку программирование из ассемблерных кодов развилось в социальное явление.
А проблемы программирования это наверное все же нечто совсем другое и гораздо более математически точное.
Необоснованное применение квантора всеобщности detected.
Все указанные области не являются какими-то супер-проблемами индустрии. Просто для них нет универсального решения. Как нет самого лучшего языка программирования
Например, собеседования в мегакорпорацию со 100к разработчиков, среднюю компанию с 200-ми разработчиков и в команду на 10 разработчиков надо проводить по-разному.
В команду на 10 человек, когда кто-то ушёл (что редкость), открывается вакансия, собеседуются кандидаты, находится подходящий, вакансия закрывается. Кандидата выбирает руководитель/и своим волевым решением. Если руководитель верит в свою проницательность, то можно нанимать просто по результату 2-часовой беседы. Дальше ждём 3 года до следующего увольнения.
В средней компании вакансий обычно чуть больше чем есть подходящих кандидатов. По-этому, техдир описывает критерии отсева, а на втором этапе собеседует кандидатов сам. Критерий отсева обычно включает какое-то техническое задание и какие-то формализованные оценки.
В мегакорпорацию, во-первых, нужен процесс и методология, потому что наём происходит более или менее одинаково во все 150 офисов по всему миру. Во-вторых, туда все хотят попасть и нужен дешёвый процесс, который отсеет 95 кандидатов из сотни. По-этому, там 15 этапов интервью, лайв-кодинг и спецкурсы подготовки прохождения собеса.
Я работаю программистом больше тридцати лет
Ещё один дед, остановившийся в развитии где-то там. Честно, если статья начинается с этих слов - то 99.9% это не то, что заявлено. Прям как в жизни: кто кичится возрастом или опытом, часто оказываются отсталыми.
Кликбэйтный тайтл "Неразрешимые проблемы программирования" в итоге должен быть ничем иным как "Сложные проблемы разработки". Ни слова о программировании я не увидел, только о процессе разработки и типичных трудностях ворклофлоу
В остальном статья хорошая, но хотелось бы больше форматирования, а то кроме подзаголовков просто партянки текста "мыслей и чувств автора". Я конечно понимаю, что небрежность, с которой некоторые авторы относятся к написанию кода, переносится также и на текст статей, делая их едва ли читаемым лонгридом, но можно же было к 30ти годам разработки на одном месте научиться оформлять статьи?
Неразрешимые проблемы программирования