Статья эта вызревала давно. Название у неё, конечно, провокационное, потому что да, я буду писать про неразрешимые вопросы, но это будут не те вопросы, про которые вы подумали. Я работаю программистом больше тридцати лет, и за это время наша индустрия сильно изменилась. Изменились и мои приоритеты.
Я с удивлением обнаружил, что вещи, казавшиеся важными, с высоты опыта оказались второстепенными. А незаметные — превратились в огромные проблемы.
Исторически, программирование выросло из математики, и до сих пор его иногда называют прикладной математикой. В таком — математическом — программировании понятие неразрешимых проблем строго формализовано.
Даже сама наша дисциплина выросла из неразрешимой задачи — Давид Гильберт назвал её Entscheidungsproblem — и, если перевести название на русский, получится смешной каламбур.
Неразрешимая проблема разрешения.
Именно с ней пытались справиться Чёрч и Тьюринг, доказав в конце концов, что справиться с ней невозможно. Чёрч прибегнул к помощи разработанного им лямбда-исчисления, а Тьюринг — к помощи воображаемой машины, очень похожей на печатную.
Тьюринг также обнаружил первую неразрешимую проблему в программировании — проблему остановки. Он выяснил, что написать программу, которая может проверить правильность другой программы, в общем случае нельзя. В каких-то ограниченных случаях можно, а в общем — нет.
Вот что мы называем неразрешимыми проблемами. Вот что называл неразрешимыми проблемами и я, когда был моложе. Но время шло, я обогащался опытом — чаще негативным, из-за опыта обрастал цинизмом, и, в конце концов осознал, что есть проблемы гораздо более неприятные.
Я не отрицаю, что академические знание о мире важны и нужны. Полезно опознавать NP-полные задачи, полезно знать задачи неразрешимые, и в целом, полезно понимать причины, а не зубрить правила.
Но в реальном мире эти знания оказываются не слишком востребованными. Мы знаем, что эти проблемы неразрешимы, и просто туда не лезем. Сталкиваясь при этом с другими трудностями, с которыми, кажется, мы можем справиться. Поговорим о них.
Собеседования
Мы сейчас ограничимся программистской спецификой. Понятно, что у рекрутеров, тимлидов и HR-менеджеров свои трудности с соискателями. Вольётся ли человек в коллектив? Это не наша забота. Наша забота — за час времени определить технический уровень кандидата.
Сейчас общепризнанно, что нестандартные задачки для этого не сильно подходят: когда-то их давали в Microsoft, но потом перестали. Иногда их дают в других компаниях. Мы научились более-менее отвечать на вопросы, почему люки круглые, или сколько заправок в Нью-Йорке, но, похоже, они не помогают работодателю оценить программиста.
Потому что на работе — обычно — нам не приходится решать нестандартные задачи. Нам не приходится решать олимпиадные задачи. И что мы оцениваем, задавая вопрос про люки — не известно никому.
Давайте расставим все точки над i: сообразительность программисту нужна. Но обычно на работе у нас есть время на проверку гипотез и время для рождения небанальных идей. В конце концов, у нас достаточно уютные офисы, а у многих — даже и приемлемый уровень шума на рабочем месте. Нам не приходится за пять минут придумывать что-нибудь оригинальное, испытывая при этом серьёзный стресс.
Когда я проводил собеседования, я собирал вопросы, то останавливался на тех, где сообразительность не требовалась и алгоритм был очевидным. Основная трудность тех вопросов была в том, чтобы заметить особые случаи и граничные условия.
Реализуя двоичный поиск или быструю сортировку, мы разбиваем массив на подмассивы. И прежде, чем что-то делать с подмассивом, мы проверяем, не пустой ли он. Это правило должно быть записано у нас на подкорке, после всех ошибок, когда мы про него забывали. Так?
Честно, я не знаю. У меня не было шанса проверить свои гипотезы про правильные вопросы.
Единственная информация, которую я могу назвать объективной, найдена мною в книге Даниэля Канемана “Думай медленно… решай быстро”.
Мы провели несколько сот собеседований по новому методу, а спустя несколько месяцев
собрали данные об успехах солдат от офицеров тех подразделений, к которым приписали новобранцев. Результаты нас порадовали. Как и предполагалось в работе Мила, новая процедура собеседования значительно превзошла старую в результативности.
Что же это за процедура? На самом деле, неважно. В книге написано:
Хорошо предсказывают значимые результаты простые равновесные формулы, основанные на существующей статистике или здравом смысле. Алгоритм, сочинённый “на коленке“, по результативности часто соперничает с оптимально взвешенной формулой и с легкостью превосходит прогноз эксперта.
Канеман утверждает, что любая разумная формула работает лучше интуиции. Прочитав об этом, я стал задавать соискателям вопросы и записывать количество правильных ответов. Всё ещё не доверяя подобному “примитивному” подходу, я ранжировал вопросы по сложности. Это было несколько лет назад.
Сейчас я думаю, что вопросы должны быть простыми, чтобы на них можно было ответить “да”, “нет”, “пять” или “никогда”. Посмотри на код, и скажи, что он напечатает. Напиши функцию, которая заполнит массив числами 1 и 3 по-очереди. Что-то в этом роде.
Я проходил собеседование много раз, и время от времени лажал. Я забывал совершенно очевидные вещи, которые не должен был забывать и неправильно отвечал на вопросы, на которые точно знал ответ. Я не ощущал какого-то стресса, мне просто хотелось понравиться и я спешил с ответами.
Ошибиться может любой. Чтобы нивелировать эффект случайных ошибок, вопросов должно быть много. Здесь срабатывает закон больших чисел. По закону больших чисел, чем больше испытаний мы провели, тем ближе наши практические результаты к теоретическим. Если мы бросили монету два раза, то с большой вероятностью можем получить “все орлы” или “все решки”. А двадцать раз, то вероятность “всех орлов” или “всех решек” одна миллионная.
Возвращаясь к теме собеседований: если у вас всего два-три вопроса, на них может засыпаться даже хороший программист просто потому, что такова природа малых выборок. Но если вы зададите двадцать вопросов, хороший программист ответит правильно на большее число вопросов, чем плохой.
Хороший ли это способ? Я не знаю. Канеман проводил исследования и, если верить ему, это самый работающий способ. Большинству моих коллег он не нравится: они считают, что интуиция работает лучше каких-то там формул. В целом, в индустрии всё ещё нет общепризнанного мнения, как проводить собеседования.
Онбординг
Онбординг — это адаптация сотрудника, только что вышедшего на работу. Вам должны рассказать, где здесь гардероб, туалет и столовая, как зовут соседей слева и справа, как подключиться к корпоративной почте и каковы ценности компании.
С этим обычно никаких проблем не возникает.
Затем вам дают проект — из тех, что мы называем legacy. Триста человеко-лет — десять лет и тридцать программистов. Часть из них сидит сейчас рядом с вами, но другая часть давно уволилась. Ваша задача — разобраться в проекте как можно быстрее.
Что такое этот проект? Количество файлов (модулей) — от четырёх до восьми тысяч. Размер отдельных модулей — до пяти тысяч строк. Размер отдельных методов — до четырёхсот строк, кодогенерацию в расчёт не берём. Даже чтобы прочитать весь код, нужно полгода. А его надо не просто прочитать, но и понять. Сколько времени занимает такой — беспощадный и сермяжный — онбординг?
Никто не знает. Если проект целиком не знают даже старожилы, то и у вас нет никаких шансов. Возможно, онбординг, как и день сурка, будет длится вечно. К счастью у нас есть четыре волшебных средства, которые помогают нам в адаптации. Комментарии, документация, тесты и помощь коллег.
Мысленно наблюдаю на вашем лице саркастическую ухмылку. У меня сейчас такая же. Давайте поговорим про них: комментарии, документацию, тесты и помощь коллег.
Комментарии похожи на персонажей французской комедии. В этих комедиях всегда есть неуклюжий герой, человек не на своём месте. Он оказывается там, где он не нужен, и не попадает туда, куда должен был попасть. Типичный такой Пьер Ришар.
Комментарии похожи на мсье Ришара — там, где они нужны, их нет. Но там, где код очевиден даже младенцу, вы найдёте их в изобилии.
Комментарии устаревают, комментарии лгут. Комментарии написаны людьми, которые не умеют писать понятно. Комментарии не помогают разобраться, как работает программа. Вам всё равно придётся читать код и сидеть в отладчике.
Бывают ли хорошие комментарии? Возможно. Надо ли их писать? Наверное. Как? Пишите хорошие комментарии и не пишите плохие. Совет выглядит дурацким как раз потому, что он дурацкий и не прячется за сложными формулировками. Этому дурацкому совету не последует никто, поэтому я не боюсь его давать. Я не знаю, как писать хорошие комментарии. Любого, кто знает, вы можете проверить — возьмите его код и отдайте новичку. Если новичок будет ругаться, считайте, что вас обманывают.
А сразу за комментариями в списке волшебных средств следует документация.
Документация — это комментарии, вынесенные из текста программы. На самом деле, с документацией, кажется, не так всё и плохо. По крайней мере, хорошая документация встречается, правда, почему то, в проектах крупных программистских компаний. И то не во всех. Один раз я по документации пытался подключиться к платёжной системе. Потратил две недели, в основном, потому, что в документации была фактическая ошибка, а я не мог связаться с реальными разработчиками. На моём пути грудью вставала служба поддержки. Но эта история закончилась хорошо: я растопил ледяные сердца операторов и меня пропустили к разработчикам, которые за две минуты рассказали, что и как надо делать.
А они ведь деньги на этом зарабатывают. Если же речь идёт о легаси-проекте, то там качество документации такое же, как и у комментариев. Она неполная, она противоречивая, она не соответствует коду. Удачного онбординга!
Тесты. В идеале тесты — это короткие функции, которые рассказывают нам о коде. Что вернёт binary_search, если элемент в массиве не найден? Смотрим в тест, и он подсказывает, что результатом будет минус один. На практике, модульных тестов довольно мало. Там, где они есть, они большие, на тридцать или сорок строк. И они очень неустойчивы. После каждой правки падает десяток тестов, и вам трудно разобраться, почему.
Ещё у тестов высокий порог входа. Выучить по книге C++ проще, чем научиться писать модульные тесты, тем более перед кодом. Не верите? Спросите у знакомых программистов. Тех, кто знает C++ и не ходил при этом на курсы — довольно много. А вот тех, кто реально практикует TDD — проценты. Буквально. Два-три человека на сто знакомых программистов.
Что же, остаётся надеяться на помощь коллег. Тех самых коллег, у которые свои задачи на спринт. Руководство гонит, поэтому сегодня они помогают, а завтра им некогда. А послезавтра ты получаешь задачу, которую сделал коллега, уволившийся три года назад. Никто в команде не знает, как этот код работает. Времени у тебя два дня. Дерзай!
Код-ревью
Код-ревью — моя любимая тема. Здесь прекрасно всё, даже трудно выбрать, с чего начать. Да, вы и сами всё знаете.
Начнём с главного-очевидного. Почему-то так вышло, что среди программистов много душнил. Мы любим спорить, любим сомневаться даже в очевидном, плюём на авторитеты. И при этом, высказывая своё — безусловно ценное — мнение, редко заботимся о тонкой душевной организации коллег.
Когда нас называют идиотами, мы конечно, возмущаемся. А когда мы называем идиотами — нет.
Код-ревью — неиссякаемый источник напряжения в команде. Программистов надо учить давать конструктивную обратную связь. Но если они не хотят учиться, вы их не заставите.
Вторая здравая мысль: чтобы разобраться в чужом коде, надо потратить больше времени, чем на личное написание этого кода. Обычно ведь как — дали тебе задачу, ты построил в голове модель решения, и реализовал. А в чужом коде модель решения уже есть, и она не твоя. Надо сначала понять, что тут вообще происходит!
Вывод: качественное ревью требует времени. А ведь на спринт есть и свои задачи, да и переключаться не хочется. Сначала я тут в потоке своё дорешаю, потом твоё посмотрю. Так и получается, что результаты ревью приходят к коллеге через пару дней, когда он сам уже в другой задаче и весь контекст позабыл.
Третья мысль: существующие средства код-ревью — страница Pull Request или Merge Request — не очень подходят для вдумчивого изучения исходников. Бывает и такое, что изменения влияют на код в другом модуле, на который мы даже и не смотрим.
Наконец, ещё одно соображение, четвёртое. Я уже лет пять не работают на «своём» проекте, который бы писал с нуля. Прихожу в проекты на легаси.
Через три месяца онбординга меня включают в ревьюверы. Но я этот проект всё ещё не знаю. Чтобы сделать код-ревью более-менее качественно, надо потратить несколько часов и своего времени, и времени человека, чей код я исследую. Через пару созвонов от меня просто начинают бегать.
Поэтому я делаю код-ревью в режиме “кажется, здесь нет никакой дичи”. Возможно, этого достаточно.
Заключение
Вот вам несколько неразрешимых задач современной индустрии. Возможно, вы со мной не согласны, возможно, в вашей компании удалось справиться хотя бы с одной из них. Тогда напишите в комментариях — положительный опыт всегда интересен.
Или, возможно, вы знаете другие неразрешимые задачи (ну, помимо проблемы останова, конечно!) Или у вас есть поучительные истории из жизни. Такие истории гораздо интереснее, чем положительный опыт, так что тем более пишите!
Комментарии (24)
rukhi7
15.04.2024 12:15+2Документация — это комментарии, вынесенные из текста программы.
вот это очень сомнительное утверждение, если документация НЕ начинается с того зачем начали писать программу, то есть что хотели запрограммировать, вряд ли это будет хорошая документация. То зачем начали писать программу очевидно было известно до появления этой самой программы, поэтому не может быть изначально комментарием к программе, хотя в комментарии это потом добавить конечно можно, но это будет выдержка из документации в коментариях, а не наоборот.
Вот так и появляются неразрешимые проблемы, ставим телегу впереди лошади, и пытаемся изобрести самую иновационную телегу для такой конструкции, а все как-то не получается. Вопрос с ведущей телегой в связке лошадь-телега в обратной последовательности оказывается неразрешимым, и никому в голову не приходит просто их местами поменять, как после такой перемены о неразрешимых проблемах рассуждать?
markshevchenko Автор
15.04.2024 12:15+1Ну, я писал о том, как реально бывает, а не о том, как хотелось бы, чтобы было. Я согласен, что документация должна быть хорошей. Но на практике она почему то везде плохая. Ну, почти везде.
Часто её заставляют писать программистов. А писать документацию надо уметь, и не все программисты умеют. И начинают они с того, что знают лучше всего: с потрохов программы.
CorwinH
15.04.2024 12:15А писать документацию надо уметь
Хорошо, когда этим занимается специально обученный человек - технический писатель.
markshevchenko Автор
15.04.2024 12:15Я совершенно согласен. Правда, по какой-то причине я ни разу не видел технического писателя ни в одной из команд, где я работал.
kekoz
15.04.2024 12:15+1Я работал несколько лет в проекте, где на четверых с половиной программистов было два технических писателя. Половина среди программистов — это один из технических писателей. Да, он участвовал и в разработке.
Первый писал документацию пользователя, и делать это хреново у него просто не было никакой возможности — принимали продукт такие матёрые монстры, что за любой непонятный момент или просто отсутствующий (потому, что “ну, всё же очевидно же!”) спустили бы с него семь шкур, после чего распяли бы и бросили на съедение крокодилам.
А второй, который “половина программиста”, был прежде всего этаким архивариусом — он подшивал в свои талмуды буквально всё, начиная с диаграмм, что мы рисовали на “дейликах”, заканчивая салфетками, на которых во время посиделок рисовалась внезапно пришедшая с очередным тостом идея. Его писательство было предназначено отчасти для самих нас (идея, пришедшая с тостом, могла с утра оказаться безвозвратно или до очередной попойки утерянной), но главным образом для новых программистов, вписывающихся в проект — именно с целью предельно сократить во времени пресловутый “онбординг.” Валерик, привет тебе, ты чертовски крут в этой роли!
Важно заметить — на наличии этих двух должностей жёстко настаивала прежде всего сама команда. И я вполне допускаю, что в большинстве проектов без технических писателей причина их отсутствия — в отсутствии такой вот жёсткой позиции самих разработчиков.
markshevchenko Автор
15.04.2024 12:15Очень здорово, что где-то хорошая документация есть. Да она, очевидно есть. Пусть MSDN это проект коммерческой компании, там люди за зарплату пишут. Но ведь и во многих open source проектах с документацией все в порядке.
Просто почему то в разнообразных легаси проектах с документацией всё плохо.
rukhi7
15.04.2024 12:15+1Часто её заставляют писать программистов.
ну да пытаются выяснить что же должна делать написанная программистом программа, и как это вообще могло бы работать с точки зрения автора, а он бедный не знает, он знает только как переменные присваиваются, и то не точно.
ManGegenMann
15.04.2024 12:15Вообще документация на фичу должна появиться раньше кода фичи. Это собственно описание фичи, БД, классов и функционала. Непонятно как без этого вообще получается что-то сделать.
Sklott
15.04.2024 12:15Если не считать требование к фичи, которые как-бы по умолчанию должны быть раньше кода, то по моему опыту писать документ вместо кода в подавляющем большинстве случаев малопродуктивно.
Потому что документ, в отличии от кода, невозможно отладить, протестировать и т.д. и т.п. И когда заставлют писать, скажем дизайн перед кодом, то получается, что придумали какой-то более менее рабочий дизайн, написали документ, пошли писать код и столкнулись с какой-то проблемой. Код правится чтобы обойти эту проблему, на дизайн все уже забили, он же уже написан!. и в результате дизайн не отражает код и в таком виде практически не имеет никакой ценности.
Возможно, если вместо текста использвоать какие-то специальные инструменты (ну например, пример из головы, какой-нибудь анализатор SQL запросов), то это могло бы быть эффективней написание кода, но простой текст и/или диаграмки все-же не тянут.
На эту тему недавно здесь на хабре была статейка в которой предлагалась писать дизайн на некотором формализованном языке и "тестировать" ее относительно кода, вот в таком подходе возможно было-бы все лучше, но и то я думаю написать хороший дизайн перед написанием когда целиком никогда не получится, максимум итеративный подход, когда на первой итерации прикидываем какой-то подход, пробуем его закодировать, вылавливаем проблеммы, исправляем паралелльно дизайн и код. И чтобы документ реально исправлялся нужны автоматические инструменты, типа "тестов" соответсвия дизайна-кода, иначе нельзя быть уверенным, что дизайн актуален.
Sklott
15.04.2024 12:15Мне кажется вы перепутали документацию "о программе" и требования "к программе". Хотя чисто формально требования и можно считать документацией, но на смом деле они практически ничего вам не скажут о программе. 10 программистов получив одни и те-же требоваия напишут 10 разных программ.
А вот когда идет речь про документацию "о программе": дизайн, описание интерфеса, user manual тот-же самый и т.п., то это уже реально "выдержка из комментариев", плюс в 99% случаях не соответсвует реальной программе, т.к. код првится часто (баги-то надо править), а документация только когда прижмет.
Batalmv
15.04.2024 12:15+3Мне кажется здесь нет никаких неразрешимых проблем. Есть банальное осознание того факта, что успех не гарантирован и все. Просто "потому что". Но можно повысить шансы на него
Собеседования
Вот яркий пример. Посмотрите сколько распадается браков, сколько людей увольняется и т.д. Статистика точно говорит, что неуспех возможен и вполне вероятен, а если у вас денег по низу рынка - то шансы найти хорошего спеца ничуть не выше чем беспроблемное авто за штуку баксов
Онбординг ... и легаси
Тут мне кажестя проблема в вопросе, которій является плохим (а хороший - это то, который содержит половину ответа). Ок, вам дали legacy код необъятного размера. Зачем вам считать количество строк? Напишите программу, которая это подсчитает за пару минут и успокойтесь.
Вам нужно научиться его собирать и понять, как новую версию допихать до прода. Это ваша первая и главная задача. Точнее две. Собирать из исходником что-то работающее и знать, как из кода сделать "пакет" установки". Все остальное потом
Будет день - будет пища. Этим принципом надо руководствоваться, если впереди что-то большое и не очень понятное.
Будет баг - вот и посмотрите. Попросят допилить фичу - вот тут и уточнить, где лежат требования к тому что есть и как к нему можно прилепить что-то новое
Но конечно елси вы (непоняно зачем) поставили задачу "разобраться во всем", то очевидро что такая задача может быть решена только за все время мира :)
Комментарии
Вообще по фиг, тем более что в 99% случаев им можно верить, если они есть
Документация ... Потратил две недели, в основном, потому, что в документации была фактическая ошибка, а я не мог связаться с реальными разработчиками
Ну добрались же. Никто не идеален, но так как код проверяется, а дока нет - там могут быть ошибки. У всех были такие эпизоды и ваш метод отлично работает
Код-ревью
Я, хвала богам, делаю это не часто и обычно просто ищу там то, что я там ожидаю увидеть. Для этого надо свои ожидания озвучить до того :) Потом их или найти, либо нет
Плюс ... не надо проверять все. Зачем? Кто-то ездит на БМВ, кто-то на мерсе, но если их сравнить - это две абсолютно разные изделия с общими идеями. Но обе ездят. Так зачем вам быть такими детальными?
Если требований нет - все верно, ищем очевидную "дичь" и не паримся
---------------
Вы зачем-то сравнили реальную жизнь и идеальную мат. модель. Это не имеет смысла, так как модель мира (как минимум в части управления) работает совершенно по другому
Politura
15.04.2024 12:15+1К счастью у нас есть четыре волшебных средства, которые помогают нам в адаптации. Комментарии, документация, тесты и помощь коллег.
Несколько раз проходил оный этап, включая дремучее легаси с классами размером более десяти тысяч строк. Больше всего помогает дебаг, опыт копания в других легаси, ибо шаблоны плюс-минус одинаковые, ну и навигация ИДЕ.
MonkAlex
15.04.2024 12:15Но дебаг по факту последнее средство - он медленный и неэффективный. Бывает что вот он код, а запустить нормально очень тяжело, вокруг ещё пара тысяч строк кода инфраструктурного, в которых не хочется разбираться.
Поэтому если у нас есть коллеги, то это лучше, чем дебаг =)
В тесты и комменты с документацией я верю слабо. Документация нужна и помогает в начале, но она отстает и мне лично всегда её не хватает. Коллеги - лучший источник информации, а дальше действительно только дебаг (и упомянутая навигация в IDE).
cortl
15.04.2024 12:15В монолите - да, а в микросервисах дебаг не поможет, там логи: гигабайт, третий, пятый... А ещё надо все условия/конфиги соблюсти чтобы система взлетела, а их стотыщмильонов. А документация дырявая. И дай бог, чтобы коллеги знали хоть 30 процннтов из того, что нужно. Аналитики сами к разрабам с вопросами идут, а тестировщики заводят баги из-за того, что тоже не знают правильные условия/конфиги для нормального полёта системы. Короче, помощи ждать неоткуда. Погибай сам как знаешь, разраб! (
adeshere
15.04.2024 12:15+4Если мы бросили монету два раза, то с большой вероятностью можем получить “все орлы” или “все решки”. А тысячу раз, то вероятность “всех орлов” или “всех решек” одна миллионная.
Такое впечатление, что тут автор немного погорячился ;-)
Если бросить монету тысячу раз, то вероятность “всех орлов” или “всех решек” будет 1/2^1000, что очень грубо (по порядку величины) равно 1/10^300 (Считаем, что в килобайте тысяча байт ;-) Напомню, одна миллионная - это 1/10^6. То есть, в нашем случае "немного" - это 10^294. Для сравнения, число нуклонов в видимой части Вселенной
порядка 10^80.
То есть, если каждый нуклон в нашем мире заменить на Метагалактику, а в затем в каждой из них сделать еще раз то же самое, то общее число нуклонов в такой "Метагалактике в кубе" будет всего лишь в 1000000000000000000000000000000000000000000000000000000 раз меньше, чем та ошибка, которую совершил автор ;-)
А вот чтобы получить вероятность “всех орлов” или “всех решек” порядка одной миллионной, монету надо бросить всего лишь раз 20...
markshevchenko Автор
15.04.2024 12:15+1Да, вы совершенно правы, это моя ошибка. Я просто метался в этом месте, сначала написал тысячу, потому подумал, что это выбивается из примера с вопросами. Никто же не будет задавать тысячу вопросов.
Поменял на двадцать, забыл убрать тысячу. Решил убрать тысячу, убрал двадцать. Всё потому, что середина рабочего дня, тем более понедельника. Созвоны, программирование, опять созвоны, опять программирование, и где-то в перерывах исправление ошибок.
Спасибо. Всё исправил, теперь там двадцать
adeshere
15.04.2024 12:15+1Да не парьтесь Вы так ;-) Статья неплохая, свой плюс от меня она получила ;-) А ошибки такого плана у всех бывают. Мы же почти всегда (увы!) живем в условиях дефицита времени, а вовсе не только на собеседовании... А возможность вылизывать статью до бесконечности сейчас мало у кого есть. Главное-то сказано правильно, и опечатка на эту суть не влияет.
Так что давайте смиримся с тем, что написание идеальной (в т.ч. безошибочной) статьи - это тоже одна из "неразрешимых задач современной индустрии" ;-) Для этого и нужна критика в комментариях. Я пытался сделать ее не обидной, а цифры меня даже немного повеселили. Надеюсь, Вас тоже ;-)
boldape
15.04.2024 12:15Код ревью.
Хороший писатель != хороший читатель. Из опыта я знаю, что хороший читатель на вес золота, очень редкая птица. Но это навык, который тренируется так же как и решение олимпиадных задач, как подготовка к собеседованиям в фаанги. Правда я не знаю как тренироваться эффективно, не могу ничего посоветовать. Хотя. На моей 3 работе у нас была практика дежурства - это когда один программист весь спринт (2 недели) занимается исключительно и только фиксом крашей. На сегодняшний день я пересмотрел тысячи кол стэков и пофиксил около тысячи крашей и уверен что эта практика помогает не только быть аккуратнее с УБ в своем коде, но и значительно развивает навык чтения в целом. Но первые свои такие дежурства вспоминаются очень больно, сидишь как дурак и пялишься в стэк часами не понимаю буквально все, но это проходит довольно быстро. Писать новый код значительно легче чем чинить старый - тренируйтесь на крышах и багах, они значительно лучше развивают навык чтения кода чем написание нового кода.
Тесты.
Юниты, тдд, моки и прочие баз ворды не помогают. Помогают тесты которые проверяют ожидаемое поведение вашего продукта, а не куска кода. Такие тесты очень устойчивы к изменениям в реализации, не требуют много подготовительной работы и самые понятные. Если ваш продукт это библиотека то тесты которые проверяют его называются юнит тесты, если изолированная фича /микросеовис то интеграционные, если приложение то энд ту энд. Не надо тратить ресурсы на не те тесты, сосредоточьтесь на тех которые будут больше всего полезны вашему продукту.
Комментарии.
Я их не читаю, но пишу. Пишу когда вопрос почему я сделал что то не так как обычно/другие. Что делает код я могу разобраться всегда, зачем он делает именно это я могу узнать из баг трэкера, а вот почему часто не может ответить и сам автор.
Документация.
Не нужна, если есть доступ к исходникам, нужна если нет.
Помощь коллег.
Я тут посмотрел код и вижу что он делает вот это (детальное описание), через гит нашел пару тикетов и вижу зачем он это делает (пункты из задач). В моем тикете мне нужно сделать вот так (описание задачи и предполагаемое решение а лучше пара). Для этого мне нужно поменять вот этот кусок код, но я не знаю почему он делает так и не сломаю ли я что то если переделаю. Из Гита я вижу что ты работал над этим кодом, расскажи какие риски ты видишь или к кому обратиться за помощью. Вот такой запрос о помощи не игнорируется никогда - надо быть готовым к тому что бы вам помогли.
Чаще всего вместо этого я вижу дичь на ревью, потому что человек не захотел подготовиться, а потом начинает активно защищаться когда я заставляю исправить код.
AYamangulov
15.04.2024 12:15+1Тьюринг также обнаружил первую неразрешимую проблему в программировании — проблему остановки. Он выяснил, что написать программу, которая может проверить правильность другой программы, в общем случае нельзя. В каких-то ограниченных случаях можно, а в общем — нет.
Упс! Немного не в тему статьи, но раз уж упоминается этот прискорбный эпизод, то стоило также упомянуть, что проблему остановки Тьюринг рассматривал, насколько мне известно, в рамках собственной вычислительной модели. А в других моделях? Ставлю математикам новую "теорему тысячелетия" - докажите, что существует неограниченное количество вычислительных моделей (назовем их независимымыми парадигмами), не сводимых к модели Тьюринга. Вторичная теорема - докажите, что в таких моделях неизбежно существуют задачи, неразрешимые в одной модели, но успешно разрешимые в альтернативной. Подсказка - для первой теоремы давно найдены частные решения, но не общее (см. сверхтьюринговые вычисления). Следовательно, вторая теорема может быть верна, хотя общего решения тоже нет, насколько мне известно. Хотя в частных случаях ее верность также очевидна, пример - в квантовых вычислениях существуют решения задач, в принципе неразрешимых в неквантовых. Но это так, к слову, тем кому интересно.
Glays
15.04.2024 12:15+3Проблема названная онбордингом как мне кажется на деле гораздо существеннее. Легаси, которое нужно изучать, может возникнуть сразу после написания кода. В проектах где работаешь не один параллельно возникают пласты кода с которым абсолютно не знаком. Даже сам можешь написать кусок кода который работает непонятно почему, но времени разбираться нет. Или забыть после отпуска, на какой версии API в итоге остановились.
Как раз код-ревью это не проблема, а решение. При правильном применении код-ревью становится тем онбордингом, который помогает погрузиться в проект с колёс. Ревьювер же не обязан что-то написать в ревью. Его задача просмотреть код и попытаться понять, может чуть увеличить бас фактор. Так же можно помочь и коллеге с какими-то досадными недоразумениями и самому воспринять что-то новое для себя, что сам не практикуешь.
Почему-то совсем ничего не написано про контроль версий. А ведь аккуратная работа с системой контроля версий и трекингом задач довольно не плохо заменяет комментарии и документацию кода (не бизнес). Блейм и анализ лога версий - это и ретроспективный код-ревью и онбординг.
Так что, по моему, проблема погружения в код хоть и существуют, но сильно упрощается культурой (код-ревью) и технологией (контроль версий)
khe404
15.04.2024 12:15+1Прочитал статью и как интересно она отражает реальность. Доктора обсуждают болезни, танцоры движения, писатели сюжеты для книг. А тут программисты обсуждают неразрешимые проблемы программирования. Которые на поверку оказываются социальными.
У программирования как раздела математики нет проблем, просто потому что проблемы математики носят не прикладной, а теоретический характер и являются не столько проблемами, сколько законами и ограничениями мироустройства, зато у программирования есть проблемы социальные.
Как подобрать коллектив, как наладить работу, как настроить постороннего человека выполнять задачи поставленные перед коллективом, как наладить образование. Это из того что раскрыто в статье, а за кадром наверное осталось, как удержать спрос, как монетизировать фичи, как не вляпаться в налоговые и административные ограничения, как не накосячить в других аспектах.
Программирование из раздела сакральных знаний выходит в массы и как результат критерии отбора становятся более ремесленными. Раньше в этой области трудились победители математических олимпиад и на собеседовании их пытались выявлять, задавая олимпиадные задачки, а теперь нужно найти человека который будет тянуть рутину.
Раньше куски кода рождались с целью превозмочь ограничения реальности на каждом шагу, а нынче нужно просто прикручивать фичу к уже существующему коду, в котором нужно хоть немного разобраться и впаять костыль, так чтобы и дальше можно было поддерживать работающую кодовую базу.
Очень похоже, что в программировании мы столкнулись с кризисом идей, не появляется новых программ. Картинки меняются а суть остается прежней. Во главу угла поставлена монетизация.
Новые идеи не требуют всего того что описано в статье. Если для реализации идеи нужно больше чем 1 человек, то это скорее всего не самая лучшая идея. Для реализации алгоритма обратного распространения ошибки не нужна команда из 100 человек... И ТДД с УМЛ тоже будут только удлинять путь от идеи к монетизации.
Как итог в коде рожденном на базе идеи нет документации, нет комментариев. Все это приходит на этапе, когда более менее удачную идею начинают насыщать маркетинговыми фичами и нанимают "команду".
Мы наблюдаем то, что новое, пока еще не устоявшееся ремесло начинает обрастать терминологией, критериями успеха, процессами. Мы просто наблюдаем как программирование растет и переживает кризисы взросления. Мы счастливые люди, на нашем веку программирование из ассемблерных кодов развилось в социальное явление.
А проблемы программирования это наверное все же нечто совсем другое и гораздо более математически точное.
event1
15.04.2024 12:15Необоснованное применение квантора всеобщности detected.
Все указанные области не являются какими-то супер-проблемами индустрии. Просто для них нет универсального решения. Как нет самого лучшего языка программирования
Например, собеседования в мегакорпорацию со 100к разработчиков, среднюю компанию с 200-ми разработчиков и в команду на 10 разработчиков надо проводить по-разному.
В команду на 10 человек, когда кто-то ушёл (что редкость), открывается вакансия, собеседуются кандидаты, находится подходящий, вакансия закрывается. Кандидата выбирает руководитель/и своим волевым решением. Если руководитель верит в свою проницательность, то можно нанимать просто по результату 2-часовой беседы. Дальше ждём 3 года до следующего увольнения.
В средней компании вакансий обычно чуть больше чем есть подходящих кандидатов. По-этому, техдир описывает критерии отсева, а на втором этапе собеседует кандидатов сам. Критерий отсева обычно включает какое-то техническое задание и какие-то формализованные оценки.
В мегакорпорацию, во-первых, нужен процесс и методология, потому что наём происходит более или менее одинаково во все 150 офисов по всему миру. Во-вторых, туда все хотят попасть и нужен дешёвый процесс, который отсеет 95 кандидатов из сотни. По-этому, там 15 этапов интервью, лайв-кодинг и спецкурсы подготовки прохождения собеса.
Dominux
15.04.2024 12:15Я работаю программистом больше тридцати лет
Ещё один дед, остановившийся в развитии где-то там. Честно, если статья начинается с этих слов - то 99.9% это не то, что заявлено. Прям как в жизни: кто кичится возрастом или опытом, часто оказываются отсталыми.
Кликбэйтный тайтл "Неразрешимые проблемы программирования" в итоге должен быть ничем иным как "Сложные проблемы разработки". Ни слова о программировании я не увидел, только о процессе разработки и типичных трудностях ворклофлоу
В остальном статья хорошая, но хотелось бы больше форматирования, а то кроме подзаголовков просто партянки текста "мыслей и чувств автора". Я конечно понимаю, что небрежность, с которой некоторые авторы относятся к написанию кода, переносится также и на текст статей, делая их едва ли читаемым лонгридом, но можно же было к 30ти годам разработки на одном месте научиться оформлять статьи?
MonkAlex
По ревью согласен.
А с остальным деваться некуда совсем, к сожалению =) Не придумали мы пока ничего лучше.