Comments 31
Так-то оно так, но в целом советы в духе: "Хорошо быть богатым и здоровым, а быть бедным и больным - плохо".
Проблемы возникают не потому, что программистам и менеджерам только дай волю лишнюю работу поделать. Нет, проблема в том, что чаще всего определить что является важным, а что нет крайне сложно. А еще бывает так, что сегодня что-то важно, а уже завтра нет и наоборот.
Сложно конечно, но даже если примерно прикинуть, уже можно получить выгоду в скорости. На практике очень редко люди хотя бы на минуту задумываются о важности/нужности/будущем
Не могу говорить о тех местах, где вы работаете, но почти везде где работал я - существовал процесс постановки и обсуждения задач, смысл которого для разработчика и заключается в том, чтобы узнать все, что необходимо о задаче. Чем выше уровень разработчика, тем важнее для него вопрос: "Зачем эта задача бизнесу". Я, как тимлид и технический директор нередко сталкивался с тем, что более простое и дешевое решение задачи лежит вообще не в плоскости разработки.
В современных командах вопросы "зачем", "что", "почему" и "как" решаются, как правило между продакт-менеджером и руководителем разработки. Это что касается небольших команд.
Что касается enterprise-разработки, я надеюсь, не нужно объяснять, почему Code-Review должно проходить каждый раз, почему нужно докапываться до мелочей и вкусовщины, почему нужно документировать даже очевидные узлы и так далее.
Как раз таки нужно объяснять, особенно в enterprise разработке.
По той же причине, почему в каждом макдональдсе должны быть одинаковые граммовки, форма и бизнес-процессы. Это называется стандарты. Когда любая группа людей вырастает до определенного масштаба стандарты просто необходимы. Типичный enterprise-проект - банковская система. Ядро написано на Java в 2004 году. Какие-то части переписали на новые версии языка, какие-то нет, сама система обросла дополнительными сервисами на PHP, потом появились сервисы на NodeJS, появились консумеры АПИ, находящиеся вне компании. Система становится все сложнее и сложнее и вот ее поддерживает уже 400 программистов. Если в таких системах начинаешь отходить от стандартов хоть на шаг, то все неизбежно и очень быстро приходит в хаос. Сегодня вам всем дружно очевидно "что и как делает эта штука", а через 5 лет команда сменилась целиком уже несколько раз. А документации нет. А ведь было очевидно. И вот вы тратите кучу времени и денег просто чтобы понять что это вообще такое. Да и каждый член команды тот же час начнет трактовать почти все случаи как "это не супер важно" или "это же очевидно", "да я тут только одну строчку поменял, ревью можно не делать". Единственное исключение - когда вы пишите стандарт на то, в каких случаях можно и нужно отходить от стандартов. И то каждый будет интерпретировать все по-своему.
Это обычная проблема в любых проектах на которых работает много людей, не только программирование. Одно дело построить дачу и совершенно другое строить Бурдж-Халифа.
Да, иногда при причесывании всех под одну гребенку бывает так, что самым умным приходится отрезать голову, но в случае с кровавым enterprise важнее скорее стабильное качество и прогнозируемость релизов, нежели некая нерегулярная краткосрочная "скорость" за счет технического долга.
Добавлю, что большинство упавших продов в моей жизни начиналось именно с да я тут только одну строчку поменял, ревью можно не делать
даже большие корпорации сейчас стараются идти в девопс методологию и улучшать time-to-market, выделяя автономные команды и сокращая бессмысленные согласования.
SRE практики - туда же, когда у тебя есть бюджет на ошибки.
Всякие канареечные релизы (тест на проде), автотесты препрода и т.д. снижают риски
Вы пытаетесь опровергнуть мой тезис о том, что тесты и документации в крупной корпорации должны быть везде словами:
> Всякие канареечные релизы (тест на проде), автотесты препрода и т.д. снижают риски
ТАК Я ЖЕ ОБ ЭТОМ И ГОВОРЮ!! Снижают риски вводя девопс подход, при котором НЕЛЬЗЯ мержить ветку без код ревью. Снижают риски написанием тестов и не только модульных, а еще и функциональных, интеграционных и всяких других) Корпорации не снижат количество стандартов и бюрократии, а как раз таки повышают. Даже по вашим же словам комментом выше)
В девопс методологию прийти довольно сложно, потому что это не "методология". Пардон за занудство, но если рассказывать про управление разработкой, то желательно термины не путать. Где-то рядом мелькала статья, в которой в очередной раз предлагалось выбрать между методологиями Lean, Agile, Waterfall, так что болевые ощущения возникли мгновенно.
Практики DevOps говорят об устранении согласований в смысле передачи ответственности от Change Approval Board (нечастых заседаний по одобрению возможных изменений с участниками, которые вообще не про разработку) самим командам, но под командами в общем случае имеют ввиду Empowered Team, где уже есть в составе продакт и/или проджект, есть бэклог и приоритезация, есть ревью и тестирование. То есть передача ответственности за одобрение изменения ближе к делу, ближе к контексту и повышение оперативности принятия этих решений.
За TTM рассуждать в районе дискуссии про то, пишем ли мы тесты и делаем ли ревью, дело тоже не особо благодарное, т.к. TTM сильно шире времени исполнения откуда-то взявшейся задачки. LeadTime сократить можно, но поставлять на прод невероятно быстро вместо хот-фиксов хот-баги - это про странные соревнования, победителя которых потом могут и ногами побить. Вместо тестов и ревью говорить, - "да я точно знаю!" - такое себе. Не знает, узнает только на проде.
Что везде нужен разумный подход - да, тут сложно не согласиться.
Клепаете MVP или говноутилиту местного значения на выброс в отдельном репозитории-помойке - фигачьте себе прямо в master, на ходу додумывая концепцию решения. Развиваете энтерпрайз-легаси-монстра - вы через неделю уже понять, что происходит не сможете при таком подходе. Вон, в соседней статье рассуждают про то, как по-крутому можно три месяца искать в легаси-проекте одну строчку, в которой ошибка и этим сломать все дурацкие KPI про коммиты (которые никто в качестве KPI принимать, к слову, не предлагал), продемонстрировав, тем не менее, невероятную эффективность и полезность. Что в итоге смог разобраться - молодец. Три месяца было потрачено, потому что когда-то давно вместо тестов, документации и ревью разрабы рассуждали про то, о чем не спрашивали, и выдали якобы невероятный "тайм-то-маркет" (который, очевидно, мерять и сравнивать никто даже не пытался). А потом штука под названием технический долг настигла их наследников и "тайм-ту-маркет" внезапно стал чудовищным.
Является ли эффективной такая организация разработки, при которой у нас сначала все происходит невероятно быстро, а потом все медленнее и медленнее? Рассуждения о достижении эффективности обычно именно такую ситуацию, такие подходы используют как точку отсчета, как призказку в духе "в стародавние времена все думали, что клепать как попало это очень здорово", чтобы потом через пугающий график роста стоимости внесения изменений рассмотреть наборы практик, которые позволяют прийти к другой ситуации, когда стоимость внесения изменений экспоненциально не растет. Но там честно показывается, что начало в таких подходах медленнее, чем в тяп-ляп и в продакшен. Зато потом нет никакой загнанной лошади, которую проще пристрелить.
В целом, общая мысль статьи - про разумное, но некоторые формулировки кажутся не самыми удачными.
тесты на функциональность, которая меняться никогда не будет
Так для того и пишут тест, чтобы он свалился, если вдруг поведение почему-то изменилось, хотя не должно.
до стилистических мелочей и вкусовщины
Лучше докопаться как можно раньше и выработать принципы, код-стайл. Внедрить форматтер и линтер, статический анализ кода. Иначе потом в это месиво никто добровольно лезть не захочет.
не тратить времени на планирование, если нет дедлайна
А цели есть? Приоритеты? Если имелось ввиду календарное планирование, то понять можно, если планирование в целом, то больше похоже на цитату из сборника с вредными советами. Так не добраться из пункта А в пункт Б, если не брать в руки карту и не прокладывать маршрут, не подгонять отстающих и не возвращать уклонившихся от курса.
Короче, делай хорошо важное, не делай плохо не важное.
Не ...
...
Не ...
Технический долг. Нет, не слышал.
Технический долг - это когда знаешь, что сделал слишком тупо, но пришлось. Это про другое
Да, это слишком тупо - не писать документацию, не делать ревью кода, не гонять тесты, ...
Нет. Вот есть сервис. Его считали "маленьким и неважным". Допустим, он получал прогноз погоды(придумайте другой пример, это неважно), чтобы показать его в кабинете клиента. Вот вы сделали компонент и забыли. И все работало 2 года. Документацию вы решили не писать, тестами решили не покрывать, да и вообще на все забили, сделали "чтобы работало".
И вот сейчас оно сломалось.
Отсутствие тестов и документации определенно стало техническим долгом, который теперь имеет свое воплощение во времени работы программистов и деньгах компании.
Технический долг это про "снизить стоимость сейчас" и "заплатить потом". Это он и есть.
Ок, выстрелил риск. Но еще в 20 "погод" не выстрелил. В итоге на сэкономленное время можно компонент доделать. Допилить тесиы, зарефачить чутка и т.д.
Вот с годами развития IT-индустрии, выяснилось, что в проектах с большой историей и большим количеством разработчиков эти "риски" выстреливают часто. По этой причине и придуманы все эти практики вроде document first, TDD, CI\CD, code review и прочее. Неужели так сложна мысль о том, что все это придумали не потому что работы было маловато, а как раз наоборот?)
Хороший код способен заменить документацию. Было у меня 2 особенных случая. Первый случай - проект с прекрасной документацией и даже уроками и с очень непонятным кодом. Второй случай - проект с прекрасным, понятным кодом и ... я даже не знаю, есть там докуменатция или нет :)
PS: я не против документации, она нужна бывает очень даже. Сам пользуюсь. Просто бывают разные интересные случаи.
Хороший код способен заменить документацию.
Это заблуждение. Хорший код может заменить ЧАСТЬ документации. Тольку ту, которая предназначена непосредственно для разработчиков. А это далеко не ВСЯ документация. Не говоря уж о том, что лазить по условному файлу routes.php вместо того, чтобы открыть привычный Swagger - такое себе удовольствие. А это пример именно разработческой документации, которую по вашему может заменить код. Может. И из буханки хлеба трамвай можно сделать, да, но зачем?
Спустя два года...
И да: относительно примерно половины погромистов (да и не только их), когда-либо работавших под моим чутким надзором, у меня есть сильное ощущение — если бы они хотя бы задумывались, что написанное ими вообще-то надо бы и тестировать, и документировать, и всё остальное, их код уже бы выглядел сильно иначе.
Это не значит, что нужно всё документировать.
Но что надо каждую минуту спрашивать себя «не херню ли я делаю?» — значит.
Экономия времени: к сожалению время очень подлая штука. Подлость заключается в том, что вроде оно одинаковое. Секунды, минуты, часы, .... Но нет. В проекте время бежит по разному. И важно экономить не абстрактное время, а то что реально дорого. К примеру, для сокращения длительности проекта надо в первую очередь изучить те задачи, которые лежат на критическом пути проекта, так как именно они и определяют длительность. Также надо понимать, что время == деньги. И часто деньги измеряются совсем по другому. Один вариант - почасовка, ккогда ты платишь за часы спеца на проекте. И тогда конечно он делает только важное/срочное, а там поглядим. Но на большом проекте таким никто не занимается, так как работы дофига и ее бы банально успеть. Плюс качать туда сюда человека банально неэффективно. Поэтому всем проще, и как ни странно эффективнее, "продать" человека на 100% в проект. А при таком подходе всегда есть период, когда человек менее загружен, поэтому он может подтянуть хвосты, и в частности написать тесты на второстепенный функционал. Поэтому для средних и больших проектов совет аккуратно печатаем, делаем самолетик и пускаем в открытое окно
Тщательно проработать аспекты, собрать встречу ... когда-то я был архитектором на проекте внедрения Интернет Банкинга с нуля. До 10 команд разработки, часто за бабки, часть вообще из-за бугра. Куча мала заказчиков и примазавшихся. Я был архитектор + ИТ менеджер (впихивая невпихуемое, если оно похоже на ИТ). Так вот, у меня за первую половину дня могло быть 50+ звонков. В день 10+ встреч, и часто посещение 2-3 офисов (так получилось, народ сидел по разным местам). Поэтому совет собрать и хорошенько продумать выглядить либо тонким стебом, либо отсутствием опыта крупных проектов. Тут собирать всех - теплоход нанять надо :) А уж все проговорить - можно месяцы потратить. В общем, летит второй самолетик вслед первому
Дизайн - да мне если често вообще по фиг какой. Главное пусть согласованный и главный спонсор одобрит. А то получается, что у всех свое мнение, дизайнер перерисовывает по 5му кругу, а потом большой босс говорит "а мне тут надо кружочки" :) Проще сделать работчий, чтобы дизайн соответствовал модели и был непротиворечив, а потом если что - переделаем во втором релизе. И да, дизайнеры часто именно те, кто на почасовке, поэтому их то точно второстепенными экранами для админа грузить не будет. Т.е. совет хорошо, но выглядит как "чтобы повернуть направо - крутите руль направо, а чтобы налево - то налево". Так он и само по себе происходит :)
Доку вообще можно не писать :) Вопрос в том, кто принимает работу. Условно если большой Enterprise, а ты отдаешь систему в поддержку - с команды внедрения 7 шкур снимут, пока акт подпишут. Тут не команда разработки решает. В коммерческой на "заказчика" тоже все просто. Он платит деньги и решает, что и как описывать. Иногда тут можно поспорить, но это больше контрактинг, чем "тут пишем, тут не пишем". В любом случае главное - дока обычно предмет sign off, поэтому как и что часто просто задано по умолачанию, и отпетлять от лишней работы можно в мелочах. А так как доку писать никто не любит, то оно выходит автоматом.
Выделять бизнес-слои ... на последнем проекте красивая картинка архитектуры заняла А4 в альбомном раскладе. И это только от входных S3 бакетов до целевой базы данных. А тут такой совет. Слои выделять :) А в реале там этих слоев ... а если разрисовать с разных сторон. Прикладная декомпозиция, инфраструктурная, сетевая, безопасность - там такая матрешка будет. И не потому что хочется выпендриться, а потому что так выходит
Тщательно планировать работы перед дедлайном ... дедлайн вообще самое веселое время. Сколько не планируй, всегда время будет бежать быстрее чем у черной дыры, в сутках часов будет 30, а то и все 36. Не бывает так. Почти никогда. Всегда тебя выжимают по срокам. По скоупу. Во всем. Никто не даст (кроме откровенно распильных и гос. проектов) времени больше, чем успеть на ленточке. Всегда что-то пойдет не так. Конечно, если проект небольшой - то все бывает. Но, архитектору не везет. Обычно его привлекают туда, где много-много всего :) Хотя все делаешь. Чек-листы, ежедневные сверки, тесты - все равно шары нет
функциональность, которая [...] в будущем будет меняться с большой вероятностью.
функциональность, которая меняться никогда не будет
в небольшой эффективной программе, которая не будет особо меняться в будущем.
Тут всегда вопрос: а кто будет угадывать будущее, и насколько качественно он это делает?
"делать то, что нужно, но лишнего не делать"
По этому принципу современные игры делают. Смену на работе отсидел, а как оно работает, кто то другой проверит.
функциональность, которая меняться никогда не будет
Любая функциональность может и будет меняться. По-моему, это азбучная истина, которую надо постичь уже к уровню джун+. От "тимлида" такое читать вообще дико. Причем иногда пустяковая с твоей точки зрения функциональность на практике является любимой фичей кастомера - и он внезапно хочет ее развивать. Так что в этот колодец плевать не стоит.
Ключ к эффективности разработки: делать то, что нужно, но лишнего не делать