Pull to refresh

Comments 108

А какой точки зрения придерживаетесь вы, документируете ли свой код непосредственно в исходниках?

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

«Чёрная магия» чаще встречается в legacy-проектах, в которых, возможно, уже успела полностью обновиться команда разработчиков и не осталось тех, которые разрабатывали систему с нуля. Ну а в новых проектах гораздо больше возможности писать «чистый» код.
Спустя 10 лет ваш «чистый» код «новых» проектов магически превратится в legacy.
Без комментов в сожных кусках кода все равно обойтись сложно.
Да, это практически неизбежно, потому что это жизненный цикл любого приложения. Относительно чистый код со временем переходит в legacy. Вопрос лишь в том, насколько быстро это происходит)

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

Ассемблер и низкоуровневое программирование без комментов вообще никак, увы!
«Черная магия» появляется в коде моментально, как только нет ответа на вопрос: почему так.
К сожалению за почти все 14+ лет разработки я не видел хороших вариантов именно в коде это описать и отобразить, в комментариях тоже. Не помогает и история коммитов, потому что или много изменений кода или же задача в таск трекере имеет только название и никакого анализа и описания.
Будучи архитектором, я не могу часто читать код со всеми деталями, я просто не смогу физически порой найти комментарий «почему» и буду страдать, плакать, идти к автору, если он еще работает и спрашивать почему так. И то не факт, что автор будет понимать и помнить почему так всё вышло.
Нужно описание архитектуры и бизнес истории, причем не в формате как это предлагает эджайл (или кто там это предложил) в формате: «я, как… хочу… чтобы ...» — это вот тоже не дает ответа на вопрос: «а почему ты так хочешь?». Нужны ADR и прочие архитектурные артефакты.
За сим закончу, а то начнет гореть сильно =)

Полностью согласен. Где-то должны быть отражены РЕШЕНИЯ — почему сделали так, а не иначе. Причём на всех уровнях, начиная с глобальной архитектуры. Именно это позволяет не ходить по граблям (я самый умный и я знаю как, все до меня — дураки, а начинаешь копать и выясняется, что предшественники не просто так сделали именно так и пытались таким образом обойти какую-то проблему).
Но при этом возникает другая проблема. Проектирование — оно однонаправлено. В результате имплементация получается как попало, потому что то, что нарисовано не вписывается в реальный мир. Ну, или разрабы скроили время и сделали как попало. И цикла обратной связи — синхронизации того, что реально сделано с проектной документацией… я не видел. Можно на это потратить кучу энергии и пытаться контролировать это на ручном приводе… но вряд ли это правильно.

Некоторое время назад мне пришлось разбираться с одной проблемой в нынешнем проекте. Под подозрение попала загадочная перетасовка битов перед вычислением результата. Коммит, которым эта строчка была добавлена, добавлял только эту одну строчку. Описание коммита — "исправить расположение битов". У меня ушла пара дней сопоставления документации на ECC и на наш контроллер, чтобы убедиться, что эти перестановки (плюс еще последующие 3 строки) действительно нужны.


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


Комментарии нужны не столько "что тут происходит", а "зачем это тут вообще делать".

Абсолютно верно! Особенно если это касается такой низкоуровневой логики, какая бывает в контроллерах.
В авиации есть (было) понятие «доступен летчику средней квалификации». Ну то есть к ручке управления не надо приделывать табличку: «на себя — вверх, от себя — вниз». Но если особенность конструкции не очевидна летчику средней квалификации — ее надо документировать. Аналогично придерживаемся у себя. Если код написан так, что он понятен программисту средней квалификации сам по себе — дополнительных комментариев не требуется. Если код может быть не очевиден для среднего программиста (чем бы это ни было вызвано: сложностью алгоритма, особенностями аппаратуры, странными требованиями клиента) — пишется блок «почему так».
Во всех подобных формулировках есть один нюанс. Каковы критерии определения этой квалификации? У меня одни критерии, у вас — другие. Нам может казаться, что мы определяем её одинаково, а на деле окажется по-разному.
Согласен — в любой отрасли стандарт меняется. Но обычно разработчик с опытом работы, через которого уже прошла пара джунов/стажеров — интуитивно понимает уровнь людей, на которых надо рассчитывать код. В любом случае, если кому-то приходится объяснять код — это звонок что стоит один раз написать комментарий… Второе возможное упражнение — представить что тебя подняли в 03:30 по звонку, и нужно разобраться где проблема в твоем же коде (и тут ли она?). Если когнитивных способностей разработчика (с учетом пониженной работоспособности, спутанности мыслей из-за прерванного сна, и т.д.) хватает для анализа — код можно дополнительно не документировать.
А надо ли учитывать устаревание языков, библиотек и нюансов? Ведь в ИТ это весьма быстро.
Через каких-то 5 лет приходят в проект новые люди, которые, несмотря на то, что в индустрии недавно, уже сеньоры. Но при этом они начали с более новой версии, и кое-что им будет совершенно неочевидно.
Это правильное замечание, и у меня нет на него точного ответа. На горизонте десяти лет, по нашему опыту, это пока работает. Кардинальных сдвигов в парадигме программирования (например, все разом перешли на FP или ООП вышло из моды) пока нет. Это не гарантия, что такого не случится в будущем (кто постарше из читателей помнит, например, взлет и падение языков 4GL и Rapid Application Development, или период популярности Fortran, или Delphi...). С другой стороны, я бы сказал что есть четкая тенденция к падению квалификации приходящих в отрасль людей. Если раньше почти все условные джуны имели хоть какой-то опыт программирования «для себя» (то есть они по факту сначала заинтересовались программирлованием, а потом пошли на него учиться) — теперь я лично вижу истории типа «хотел поступать в мед, но не хватило баллов — пошел на ИТ». То есть приходят реально люди, весь опыт программирования которых составляет «одна пара в неделю». Обращаясь по аналогии к авиации — это летчики выпуска ускоренной программы военного времени (хотя у нас войны вроде как и нет...). Можно почитать мемуары командиров того периода — первая задача полка, получившего пополнение — было доучить его до минимальных стандартов, которые хотя бы гарантировали что молодые кадры не разложат технику на взлете-посадке и не потеряются при полете по маршруту (даже без воздействия противника). Аналогично я вижу ситуацию и в ИТ — теоретически, можно начать писать софт так, чтобы он был понятен даже попавшему по-ошибке в ИТ медбрату — но кто будет оплачивать эти издержки? Поэтому пока фирмы огранизуют как минимум доучивание на входе (как раз до среднего программиста), или как Яндекс — фактически создают альтернативную систему среднего профессионального образования…

Все так. Фундамент был заложен 30-50 лет назад и мы до сих пор ездим на принципах и технологиях созданных туда (unix, tcp/ip, KISS, SRP) и пр. И действительно к сожалению у ребят сегодня опыт только в кодировании и конкретных фреймворках. И соответствующий узкий кругозор. С другой стороны — и пофиг. Кто-то будет головой работать (и двигать индустрию вперед) и получаать over дофига, а кто-то будет работать руками и будет заменяемым

Осталось мелочь, чтобы охарактеризовать «летчика средней квалификации», чтобы можно было разделить на летчиков, которые еще не достигли «средней» квалификации и которые уже (значительно) превысили эту квалификацию.
Ну у летчиков-то более менее просто было: учебную программу освоил, на учебном биплане вылетел, на переходном учебном самолете часы налетал — ну все, средняя квалификация достигнута. И в принципе, это и есть какой-то общий знаменатель на который можно равняться. И да, я понимаю, что у нас сейчас каждое учебное заведение, которое готовит якобы ИТ-специалистов понимает под этим то, что ему удобно. Но в целом, в текущем мире я бы ориентировался на хорошего джуна/среднего миддла. Потому что если тело с головой до этого уровня не дотягивает — его надо учить, а не работать…
Согласен почти со всеми тезисами и мыслями. Единственное что вызывает вопрос, это состав «Хирургической бригады»
  • Там (в твоем переложении на текущие реалии) есть тимлид/архитектор и старший, но нет места обычным программистам (не говоря уж о том, что титулы вообще — это не самое хорошее)
  • Инструментальщика ты назвал DevOps'ом. Но все же, на мой взгляд, девопс лучше воспринимать как процесс, а не как отдельный человек. И по-хорошему, его должны делать все, а не кто-то один.
  • Секретарь. На мой взгляд, очень расточительно иметь под это отдельного человека. Во-первых команда должны стремиться быть самоорганизующейся и самодостаточной. И многие вопросы связанные с техническими вещами или уточнениями требований от заказчика брать сама (что бы не было лишней передачи знаний и «сломанного телефона»). А не технические вопросы по проекту (и не только это) должен брать на себя владелец продукта (PO / PM)
Не забывай, что в книге и в статье описан взгляд на процессы разработки, которые были в 70-е года. По нынешним меркам, Брукс работал в «кровавом энтерпрайзе». Отсюда все эти титулы, секретари и прочее. К тому же технологическая составляющая ушла далеко вперёд, во многом повлияв на процессы. Я лишь постарался провести аналогии между тем, что было «тогда» и тем, что имеем «сейчас».
По нынешним меркам, Брукс работал в «кровавом энтерпрайзе

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

На счёт того, что любая система тяготеет к разрушению, это тоже корпоративное наблюдение из 70-х. Сегодня есть фантастические программные продукты существующие 30 и более лет, такие как linux и emacs. Мне кажется, дело в том, что инженерия ПО сделала огромный шаг вперёд: мы намного лучше понимаем, как разрабатывать, чтобы продукты жили очень долго

По комментариям, Мартин прав: чем меньше комментариев, тем лучше.
Если бы программист 70-х узнал про возможности, предоставляемые сегодняшними технологиями, которые доступны любому разработчику (контроль версий, непрерывная интеграция, облачные решения и т.п.) и сравнил бы со своими, то он подумал бы, что перед ним «человек-оркестр». Поэтому да, сегодня такая специализация будет излишней.

По поводу второй части вашего комментария позволю себе не согласиться. Возрастание энтропии — это один из основных законов, которые встречаются в разных сферах, а не что-то специфичное для индустрии разработки ПО.
Судя по книге, ещё нет. Или Брукс его не применял. То есть потребность такая уже сформировалась и примерное понимание функциональности, но подходящего инструмента у них ещё не было внедрено.
SCCS был разработан на пару лет раньше, и я даже с ним работал. Вполне себе рабочая штука, предок CVS. Был разработан в недрах Bell Labs
Сегодня есть фантастические программные продукты существующие 30 и более лет, такие как linux и emacs

и что? Это как загадка про корабль Персея. Хотя, конечно, феномен возможности существования преемственности программных средств вроде linux и emacs имеет место быть, но это именно то, что я называю моделью "коробочного софта" (в отличие от современных веб-продуктов, когда нет какого-то явного релизного цикла и в каждый момент времени есть конкретная текущая единая версия ПО, она же — последняя, ПО будто течет, как жидкость, от разработчика к заказчику или потребителю, непрерывно — концепция liquid software by Барух Садогурский)

и что?

И то, простите за автоцитату, что, инженерия улучшилась настолько, что любая система больше не тяготеет к разрушению. Выражаясь более простыми словами, если делать ревью, автотесты и своевременно рефачить, то продукт может развиваться сколь угодно долго. Пока на него есть спрос, естественно.
Это утверждение очень сложно доказать или опровергнуть, но мне кажется, что тут вряд ли что-то изменилось. Брукс по сути пишет о паре больших итераций (написали, выбросили, переписали). Сейчас в моде большая дробность, но суть не меняется — всё равно накапливается технический долг, и приходится тратить время на реорганизацию и переписывание. Ну да, придумали для этого слово «рефакторинг». А если оказывается, что в системе надо поддерживать годами одно и то же API или форматы данных, то уж точно здравствуй, энтропия.
Это утверждение очень сложно доказать или опровергнуть,

Доказательством является тот неоспоримый факт, что сегодня существует много программных продуктов, существующих и активно развивающихся более 10-и лет. При этом, объём их кодовой базы просто пипец какой огромный. И эти продукты живут и развиваются. В 70-е ничего подобного не было и не могло быть
Сейчас в моде большая дробность, но суть не меняется — всё равно накапливается технический долг, и приходится тратить время на реорганизацию и переписывание

В 70-е не было самого понятия технического долга. И никто не знал что с ним делать. Ни один менеджер не выделил бы время на его устранение. Это и была одна из причин проблем описанных Бруксом.
В 70-е не было самого понятия технического долга.

Было, только не называлось так.


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


Эта наша отрасль ухитряется делать вид, что такого не бывает.

Те инженеры, что с физическим миром работают должны делать правильно с первого раза. У них нет тех долга, так как им не надо выпускать следующую версию на следующей неделе. Когда вторая версия выпускается через 5 лет, можно весь проект выкинуть и начинать с нуля. Всё-равно, компонентная база поменялась, рынок поменялся и всё вообще поменялось.
У них нет тех долга, так как им не надо выпускать следующую версию на следующей неделе.

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

Точно так же как у нас есть расходы на поддержку продукта из за того же неудачного проектирования и дурной конструкции приложения

и что хуже — расходы на вывод из эксплуатации продукта и та же миграция пользователей/данных на следующую итерацию этого продукта или другого продукта.


Условно — когда у тебя появились пользователи — все, ты прибился гвоздями к тому, какое они поведение ожидают от системы. И его нельзя просто взять и поменять. Или тем более убить систему. Это будет или дорого в плане ресурсов (поддержка). Либо может нести репутационные риски.

Когда вторая версия выпускается через 5 лет, можно весь проект выкинуть

Нельзя. Потому что эта железка, в каком-нибудь тепловозе со сроком эксплуатации 50 лет стоит. Или внутри моста, который вообще в обозримом будущем никто заменять не будет.

имелось ввиду, что для второй версии старый проект уже не годится. Для моста это ещё более верно, так там вторая версия лет через 100 будет. Старый проект не подойдёт
Те инженеры, что с физическим миром работают должны делать правильно с первого раза.

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

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

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

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

Полагаю что Вы, пардон, мало работали в этой области. Мне вот вполне довелось работать среди тех, кто "с 75-ых" и ранее, и которые с железом до которого после выпуска дебаггером не дотянешься. Кто лучше, кто хуже — такие же, по факту, люди, как и работающие сейчас. Другие модные термины, другого уровня абстракции проблемы — вот и вся разница. Не было у них некогда VCS, кодосравнивалок, а менеджер виртуальной памяти приходилось писать самому в кодах чтоб не тормозил — так теперь вполне учатся, применяеют и удалённо работают.

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

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

А вот вся та стоимость, что следует из повышенной стоимости эксплуатации слегка кривой детали. И стоимость замены всех ее экземпляров на нормальные.


Те самые "производитель XYZ отозвал автомашины с дефектами" Это часть выплата технического долга так выглядит.

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

Да ну? Я вот книгу с типографским браком в магазин умудрился вернуть ) проблема только доказать, что это реально существенный недостаток

а я, рутер поломанный поменял у провайдера. Но, это не отзыв товара производителем, и вообще не похоже на техдолг и рефакторинг

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

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


Это если вспоминать история разработки и внедрения А-32/Т-34

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

А вот та самая ширина задницы лошади и вытекающие из неё параметры ракеты.


Был техпроцесс X, для работы в связке с ним разработан техпроцесс Y, инструменты, стандарты, практики, инфраструктура. Затем X отмер, а Y нет и даже развился.


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

Кто лучше, кто хуже — такие же, по факту, люди, как и работающие сейчас

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

Ещё навык "Создать для Лексикона шрифт для печати "как рукописный", если диссертацию принимают только рукописной"

Upd. Пардон. Не "рукописный", а "шрифт пишущей машинки"; и не "принимают только рукописной" — а "принимают набранной на пиш.машинке, на матричном принтере нельзя!".
Сейчас такое тоже умельцы смогут, но вроде претензий такого уровня больше не предъявляется.

И эти продукты живут и развиваются. В 70-е ничего подобного не было и не могло быть

Ну здрасьте, а UNIX, а существующие до сих пор пресловутые системе на КОБОЛе?
Брукс же не говорит, что это «невозможно», там вся книга про то, что надо понимать суть сложностей и методы борьбы с ними. Собственно, непонятно, что принципиально изменилось в этом вопросе.

Про «технический долг» — это да, как в анекдоте «жопа есть, а слова нет». Собственно, «философия UNIX» (которая сейчас, мне кажется сильно размылась) — это как раз один из видов ответа на данный вопрос, родом как раз из семидесятых — как уменьшать технический долг и упрощать рефакторинг. Делаем гибкий универсальный API (текстовый ввод-вывод), разбиваем систему на минимальные части, далее занимаемся ими по отдельности. Микросервисная архитектура, если угодно.
Я имел ввиду, системы которые к 70-м уже существовали бы 10-15 лет. Unix как раз появился в 70-е.
Принципиально изменилось, что мы теперь знаем про техдолг и как с ним бороться. Мы знаем что надо автоматизировать тесты и знаем как это делать. У нас есть сотня примеров успешных проектов и тысячи примеров провалившихся проектов в которых каждый может покопаться и лучше понять как проектировать хороший API.
Ну так то, что UNIX появился в 70-е, дела принципиально не меняет: вы ведь точно так же можете сказать, что «в 80-е ситуация была совсем другой, не было интернета и репозиториев», то есть с точки зрения обычной разработки ситуация была такой же, как в 70-е. Ну да, в 80-е появились персональные компьютеры, но UNIX всё равно оставался в основном проектом для мейнфреймов.

Штука не в том, что «мы знаем про...», а в том, что вы почему-то полагаете, что они про это не знали. Я так не думаю; но тут надо копать глубже в историю, конечно. На сегодняшний день книга Брукса выглядит несколько капитанской, но это ровно потому, что его идеи (как и других единомышленников, конечно) теперь считаются «здравым смыслом», ну и замечательно.
репозитории и интернет как раз и появились в 80-е. RVS вышел в 82-м, CVS — в 86-м. Как раз в 80-е, в том числе, благодаря Бруксу, ситуация начала улучшаться.
вы почему-то полагаете, что они про это не знали

Были у меня старшие товарищи из тех времён. Все, как один, смотрели на современные процессы разработки с некоторым принебрежением: мол, напридумывала молодёжь всякого, вместо того чтобы просто без багов писать. Да и, трудно поверить, что люди знали про автотесты, код-ревью и техдолг с рефакторингом, но нигде про это не написали ни статей, ни книг.
RVS вышел в 82-м, CVS — в 86-м.

Верно, то есть UNIX уже десять лет как писали к тому моменту, и ничего, справлялись.

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

Да я, в общем, не вижу в этом взгляде особых проблем: ведь тот же репозиторий нужен для того, чтобы совместно редактировать код. Но если система построена как UNIX — как коллекция небольших утилит — то ничего совместно редактировать и не надо. Конечно, хорошо бы ещё следить за версиями в своём собственном коде, но при известной дисциплине и этого можно добиться.
Я не говорю, что этот метод хорош, но при некоторых договорённостях управленческого порядка вполне работоспособен.

а и, трудно поверить, что люди знали про автотесты, код-ревью и техдолг с рефакторингом, но нигде про это не написали ни статей, ни книг.

Ну, вы утверждаете отсутствие чего-либо. Это довольно смелый подход. Если мы не будем заниматься стрельбой по движущимся мишеням, я предложу просто два контрпримера на поверхности:

Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.

Известная книга ван Тассела 1978 года. В пятой главе вполне себе про автотесты, в т.ч. про автогенерацию тестовых данных.
Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.

О, спасибо, интересно прочитать будет.

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

Статья 1976 года про code reviews, на Google Scholar можете найти полный текст.

вот она, кстати. Только там описан ревью, проводимый после написания кода. А не так как сейчас, когда, во-первый, ревью делают на каждое изменение, а во-вторых, его делают наши же коллеги.

Известная книга ван Тассела 1978 года. В пятой главе вполне себе про автотесты, в т.ч. про автогенерацию тестовых данных

Извините, но там про автотесты нет вообще, а про автогенерацию тестовых данных один абзац. Это и понятно: какие автотесты, если программа на перфокартах. Зато, есть шикарный перл: «Если вы верите, что можете писать программы правильно, так оно и будет. Если же вы убеждены, что написанная вами программа непременно содержит ошибки, — они неизбежны» (начало главы 4.32)

Конечно, отдельные элементы современных процессов появились давно: мы, таки, стоим на плечах гигантов. Но, всё-таки, целостный процесс, позволяющий создавать и развивать циклопические программные системы, сложился в последние лет 20
Про code review — я и говорю, вы мне предлагаете стрельбу по движущейся цели. Сначала «их нет», теперь они «методологически неправильны». Кто делает и когда делает review — неважно, почитайте хотя бы определение из википедии, там такие ограничения никто не ставит.

Про ван Тассела тоже мимо — читайте разделы 5.17-5.18 и около них. Более того, снова движущаяся мишень. Мне лично книга ван Тассела не слишком нравится — там много общих рассуждений и мало конкретики. Однако она ни разу не претендует на новизну и глубину — автор на некотором (довольно поверхностном) уровне обсуждает сложившиеся практики. Моя цель — показать, что такие практики были, а если требуется более глубокое и вдумчивое описание существовавших процессов — это уже другая задача.
Про code review — я и говорю, вы мне предлагаете стрельбу по движущейся цели

Естественно, с самого начала имелся ввиду процесс, более или менее, современного вида, когда каждое изменение просматривается одним-двумя коллегами. Понятно, что перепроверять проект не Кент Бек придумал.
Так-то, ревью ещё фараон Джосер Имхотепу, наверное, делал. Я бы делал, на его месте.

читайте разделы 5.17-5.18 и около них

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

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

Спасибо за комментарий. Но Вы правы и нет одновременно. Действительно, указанные подходы создают плечо при помощи которых радикально увеличивается качество кода и, как следствие — становятся возможны существенно более сложные системы. Это примерно как сравнивать ассемблер и джаву. На первом мы гораздо быстрее утыкались в возможности человеческой головы и в принципе сейчас сложность систем качественно другая. Но при этом все равно даже сейчас мы можем получить систему, которая упрется опять в предел возможности расширения. И в этом смысле ситуация ровно такая же как и была. Ну, и сложность в определенной степени перекочевала с уровня кода на уровень взаимосвязей между теми же компонентами (реверанс в сторону микросервисов). Победим эту проблему — история сделает очередной виток и упремся в что-то ещё.

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

Как раз принципиальная разница в том, что во времена Брукса мы гарантированно упирались в возможности расширения. А сейчас, можем не упереться. Причём, это происходит не случайно или по наитию, а в следствие применения известных методов.

Так мы и сейчас упремся. Просто у нас будет не 100500 методов и функций в одном монолите, а 100500 микросервисов (с соответствующими стоимостями поддержки/доработок)...

Это как загадка про корабль Персея


И всё таки это был корабль Тесея :)
Заяц стоял у книжного шкафа и ленивого перелистывал страницы какой-то книги. Со вздохом сказал:
— Реквием по надежде, — и начал ставить книгу на полку.
— Что там у тебя? — живо поинтересовался Оруженосец.
Заяц подошел к столу и положил книгу в центр.
— «Peapleware». Знаю, читал, — сказал Оруженосец. – А почему реквием и почему по надежде?
— Потому что тридцать лет назад эта книга была надеждой, а сейчас это реквием.

(с)
И вместе с вами обсудить некоторые цитаты, которые актуальны до сих пор.

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

Ради примера берем цитату:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.

В современных реалиях хорошо отлаженный onboarding — это просто мастхэв любого мало-мальски уважающего себя Team Lead/Project Manager. В нынешнее время разработка довольно хорошо параллелится и есть масса средств для контроля за ней при любом количестве участников. Я напомню, что в 1975-м еще не было так нам привычного интернета и тех инструментов, что мы используем для разработки сегодня — bug tracking, VCS, wiki…

Тем не менее мысли Брукса весьма понятны и довольно хорошо изложены, но прямо переносить их на текущую реальность не стоит, а уж тем более применять в практике.
Суть в том, что даже хорошо отлаженный onboarding требует чьего-то внимания/ресурсов. Новичок не может сам по себе, «в вакууме», въезжать в проект. Ему всё равно потребуется помощь коллег. А уж когда дедлайн на носу, мобилизуются все доступные ресурсы команды.

VCS, bug tracking, wiki — это именно те инструменты, которые дал нам технический прогресс и они облегчают нашу жизнь. Назначение их при этом не меняется. В начале документацию распечатывали на бумаге и подшивали в архивы, затем Брукс предлагал как более современное решение использовать «микрофиши» (уменьшенные в 90 раз фотокопии документов на плёнке). Сейчас мы фиксируем документацию в wiki. Но назначение инструмента от этого не меняется — распространение знаний о системе.
Понятно, что добавлять в команду новых людей за неделю до дедлайна — бессмысленно, но в цитате не упоминается дедлайн вообще, а в современной нормальной конторе новый разраб уже через месяц будет прилично подкидывать угля в топку.

Первая VCS появилась, кстати, для OS/360, но разработку SCCS начали только 72-м, так что можно только представить, как тогдашние разработчики синхронизировали кодовую базу.
«проект не укладывается в сроки» — это и называется «за неделю до дедлайна»)
В те времена неделями не мерили, месяцами, а то и годами. Это сейчас можно спринт недельный или 2-х недельный взять, тогда разработка была сильно медленней.
Именно так. Скорость разработки растёт, но суть (приближение дедлайна) не меняется.
Суть дедлайна, конечно же не меняется(кэп?)
Речь именно о цитате:
Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.

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

На самом деле очень много «но». С тем же успехом сегодня добавление новой рабочей силы может похоронить проект. Тем более — когда речь идёт не о +1-2 разработчика, а когда нужно расширение на 50-100% от текущей команды

если оказалось что вам ВНЕЗАПНО не хватает 50-100% от текущей команды то вы с самого начала делали все абсолютно не так. И такой проект думаю был мертв изначально, только вот обнаружилось это как раз к моменту дедлайна)

у нас agile и требования меняются очень часто — это риски. Которые могут привести к необходимости пересмотреть capacity.


В случае "водопада" — вы же сами понимаете, что там на старте очень сложно оценить реальный скоуп. Потому что каждый продукт уникален. Это не шаблонная работа печь пирожки. Погрешность оценок в начале просто космическая. И учитывая количество взаимосвязей — действительно может оказаться на трети проекта, что захочется докинуть еще 50% людей.


И такой проект думаю был мертв изначально, только вот обнаружилось это как раз к моменту дедлайна)

может быть )))) учитывая еще оптимистичность оценок )

не согласен, опытный лид вполне может оценить необходимый размер команды под проект, да могут быть шероховатости, но не в 50% размера команды.

Смотря от размера команды. К двоим докинуть ещё одного-двоих — ещё в пределах вообразимого и даже есть шансы на успех. Но это изначально очень камерный проект выходит, да.

Ну вы же пытаетесь опровергать не цитату, а Брукса. В книге описывается вполне чёткий сценарий:

«Предположим, что трудоемкость задачи оценивается в 12 человеко-месяцев, и три человека должны выполнить ее за 4 месяца, причем в конце каждого месяца имеются четыре контрольные точки A, B, C и D, в которых можно произвести измерения. [имеется в виду, что всего 4 точки — одна точка в конце календарного месяца]. Предположим теперь, что первая контрольная точка была достигнута лишь по истечении двух месяцев. Какие альтернативы имеются у менеджера?»

То есть какой тут онбординг — половина срока прошла, и вся наша скромная команда из трёх человек по уши в работе. Вот ещё новичков им не хватало. Сейчас, так понимаю, в этом отношении ничего не меняется.

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

Я не готов на эту тему рассуждать. Может, так, а может, и не так, it depends. По идее контрольные точки существуют для того, чтобы отслеживать прогресс по ним, а не по «ощущениям». Команда после первого месяца может сказать, что ни одна задача не закрыта, но по каждой «прогресс 95%, через три дня всё будет».

В рамках конкретной задачи я бы сказал, что надо иметь не четыре, а, скажем, восемь контрольных точек, но это тоже некий бюрократический оверхед, так что хороших бесплатных решений нет.
Не, я понимаю, что в 1975-м году не было возможности менеджеру оценить прогресс даже в небольшой команде из 4-х человек, но в эпоху аджайла, когда релизы раз в неделю раскатывают и деплой выполняется чуть ли не по каждому коммиту? IMHO, тут даже не слишком опытный менеджер в стартапе справится.
Ну тут я не вижу особого предмета для полемики. «Закон Брукса» гласит, что в определённых обстоятельствах добавление людей в проект только отодвигает сроки. Вы пишете, что не надо в такие обстоятельства попадать, а если попали, то менеджер виноват. Окей, это уже другой разговор.
Вы пишете, что не надо в такие обстоятельства попадать

Это уже Вы мне приписываете что-то. Изначально я написал, что Брукс для своих выводов основывался на работе IT индустрии 1975-года и для 2021-го года многие его выводы уже несостоятельны и неактуальны.
Суть в том, что даже хорошо отлаженный onboarding требует чьего-то внимания/ресурсов. Новичок не может сам по себе, «в вакууме», въезжать в проект. Ему всё равно потребуется помощь коллег.

Предположительно, это может делать тот самый человек, что проект документирует. Заодно и проверит, насколько хорошо эта документация написана.


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

Не у каждой команды есть возможность выделить человека на fulltime только лишь на документацию и onboarding. По поводу документации Брукс к тому же говорит, что её должен писать именно тот, кто пишет код — и это правильно.

Без отдельного человека, как мы видим, получается плохо. Именно потому что существует конфликт интересов. В этой dreamteam по Бруксу как раз не хватает 'хранителя знания', главное умение которого вытягивать неявное знание из остальных и фиксировать его.


Его роль размазана по людям, из которых это знание как раз вытягивать надо, и которого они не замечают.

Кроме онбординга любой новичок в проекте неизбежно добавит, например, нагрузку на кодревью(оно ведь проводится?). И на синхронизацию(она ведь проводится?). И на тестирование — до интеграции его веток(оно ведь проводится?) и результата после интеграции(- // — // -).
И если первая часть скорее добавилась за эти годы, а третья расширилась, то вторая никуда не девалась.

1. Кодревью в те года если и проводились, то весьма ограниченно, так как не было подходящих средств, напомню, 75-й год!
2. Unit-тесты кода тоже появились позже вроде как.
3. Синхронизация кода была вручную, в этом и есть проблема масштабирования команды в те годы
  1. Сейчас проводится. И требует время. И требует внимание других разработчиков — то есть, снижает их производительность.
  2. Не юниттестами едиными. И есть вещи которые и не поюниттестишь. Хороший инструмент, но он не про тему разговора.
  3. Оно и сейчас вручную в случае плохо состыкованных частей разных отделов/групп, заливаемых непрерывнымпотоком в предрелизную ветку(и, нет, это не НИИ, а "стильно-модно-молодёжно-геймдев" такое учудить может, причём на каждый релиз). Автоматизация сравнивалок и VCS хорошо помогает, но далеко не со всем.
    Плюс синхронизация не только кода, но и планов/статусов/людей. Вплоть до "собрать всех участников на собрание и последовательно обсуждать по частям" — увы, тоже реальная современная практика, и тоже в стильно-модно-молодёжно случается.
Помимо указанных вами проблем, решаемых технически, всегда есть проблема координации большого количества людей. С возрастанием количества людей в коллективе число возможных коммуникаций между ними увеличивается в разы (вплоть до каждый с каждым). Какое совещание будет эффективнее, где будет 5 человек или 25?)
Человечество уже давно придумало эффективный способ управления большими коллективами — путем дробления на отдельные юниты. 5 Developers -> Team Lead -> Department Manager -> Project Manager. Есть современные средства для управления всем этим, в 75-м такого не было.

Замечательно. То есть, усилить конкретную группу людьми в таком случае нельзя, если "5 Developers" фиксированно. Речь то, напомню, про "докинуть ещё людей в неуспевающий проект".
Значит, нужно наращивать количество команд. Или депаратаментов. Или проектов.
Если численность девелоперов не фиксирована — то можно и их нарастить.
В любом случае добавляя новые синхронизационные связи и потери на них.

«5 Developers» фиксированно

С чего Вы взяли, что это фиксированно? Это число выбрано мной как примерное оптимальное число членов команды для эффективной работы, есть немало статей про это, пример — knowledge.wharton.upenn.edu/article/is-your-team-too-big-too-small-whats-the-right-number-2.

Есть компании, которые практикуют плоскую иерархию, когда тимлид подчиняется непосредственно CTO, многое зависит от проекта. Синхронизационные связи и потери на них, конечно же есть, но они не столь велики.
но они не столь велики

Проблема то в том, что они растут в геометрической прогрессии с каждым добавленным элементом. При этом добавленные элементы не привносят производительность в том же объёме.
Если к двум разработчикам добавить третьего — да, хорошие шансы успеть раньше. Если к 20 докинуть 10(на те же 50%) — нет.

Не растут. Разработчику не нужно общаться со всеми другими разработчиками.

Со всеми — нет. Со всеми с кем работа пересекается — нужно, точнее, неизбежно.


Если новички вообще по работе не пересекаются ни с кем — отлично, они возможно не сильно замедлят общую работу. Если ими заткнули неохваченное ещё направление(то есть над "вот этой обязательной к релизу задачей" ещё никто вообще не работал, и она ни одну другую команду не затрагивает совсем), например, то это может помочь. И то, возможно добавление в очередь общей интеграции; и точно затронет синхронизацию уровней выше себя.


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

«Гениально», т.е. мы не успеваем — вместо «докинуть ещё разрабов в команду» — давайте «сделаем ещё одну команду». А в терминальном случае ещё и уровней иерархии добавим.
Вам не кажется, что это шило на мыло и в общем случае не спасёт? Тем более, когда работа не может быть распараллелена? А это именно так. 2 команды не сделают один модуль быстрее в два раза быстрее, более вероятно, что они за тот же срок смогут сделать два модуль по отдельности с исходным качеством.

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

По большому счету ничего кардинально не поменялось…
Я вот прорывных методов в аналитике не вижу…
У меня просьба, а не мог бы автор или кто-то там в Райфайзенне перевести это на английский. Очень хорошо получиось!
Sign up to leave a comment.