Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Экстремальное программирование: «ковбойский багфикс на продакшне»

Пару слов о себе: мой опыт в веб-разработке — 12 лет. Я отвечаю за техническую составляющую IT-компании; в команде со мной работают 4 сотрудника.

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

Постановка задачи

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

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

Согласовав сроки и приоритеты, мы обсуждаем допустимые отклонения функционала. То есть выкидываем то, чем можно пожертвовать для более оптимальной реализации. И тут же намечаем 2-3 варианта реализации: быстрый (который мы выбираем в 99%), традиционный нормальный и усложненный «с забеганием вперед».

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

Кодинг

Принимаясь за работу, я всегда делаю упор на получение 80% результата за 20% времени. Остальные 20% результата зачастую можно изменить так, чтоб они не занимали 80% времени, или вообще отложить.

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

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

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

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

Разработчики в компании универсальны и взаимозаменяемы. По крайней мере, мы к этому всегда стремимся. Каждый девелопер может продолжить работу другого, если тот вдруг заболел, к примеру. Такая универсальность помогает не только работать над одной задаче вместе, но и отвлекает от рутины.

Тестирование

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

Таким образом, мы передаем продакту и тестерам функционал, который, как правило, уже готов на 100%. Олег и тестировщики делают финальную формальную проверку функционала.

Релиз

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

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

Пример

Вот реальный пример экстремального программирования в действии.

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

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

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

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

Вывод

Почему такой подход работает:
— Имеем быстрый ощутимый результат;
— Тратим время эффективно.

Делайте только то, что нужно реально сейчас и не тратьте время на разработку функционала, который не нужен. Делайте code reviews регулярно и стремитесь к нулю багов в коде.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

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



79 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

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

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

Про тестирование вроде сказано что тестируется все и достаточно подробно. Вся практика XP строиться на фундаментальном тестировании. И в статье автор однозначно об этом написал

А я бы хотел поддержать автора данной публикации потому, что сами исповедуем принципы минимализма, да и сам подход XP. Т е всегда стараемся просчитать тот минимальный функционал который требуется, для того чтобы заказчик был доволен, и далее доводим его до совершенства от релиза к релизу. Естественно что данный подход не имеет смысла в тех проектах, где релизы не могут быть слишком частыми или если есть возможность сразу получить конечные требования (обычно это невозможно или слишком затратно).

Поддерживаю поддержавшего! ))

Коллеги, еще раз спасибо за конструктивные комментарии.
Добавлю: мы — продуктовая компания; у нас есть «костяк» девелоперов.

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

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

Мы работаем с XP подходами с момента когда появился сайт extremeprogramming.org (лет 15 назад?) и в дальнейшем читали литературу на эту тему. Могу порекомендовать классику www.amazon.com/...ace-Edition/dp/0321278658 и www.amazon.com/...ywords=user story mapping

В дополнении к классике XP конечно применяем все практики что понравились, например Lean. Советую посмотреть вот это видео: «Конкуренция на основе скорости разработки» www.youtube.com/watch?v=U_HgMduuE5s

На что стоит обратить внимание в применении Аджайла и XP:

1) Самое важное — автоматизированное тестирование — одна из самых важных техник. Т е тесты должны быть разные, и их должно быть достаточно, чтобы быть уверенным в том, что быстрый фикс не поломает половину логики. У нас на проектах тесты обычно трёх типов — unit тесты на чистой базе с заданными моделями, и тесты на staging базе с реальными данными. Третий тип тестов — интеграционные, или функциональные. Для Web разработки это обычно Selenium тест который учитывает и логику UI

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

3) Ведение лога работы и документация. Это важно для всех. И для PM чтобы потом если возникнет вопрос кто что делал было ясно, и для программиста т к лог описывает детали изменений других членов команды. Учитывая то что принято т.е. «коллективное владение кодом» — т.е. кто угодно может изменить любой участок кода проекта — это надо делать во первых с пониманием, во вторых все должны это видеть. Есть такое понятие «прозрачности» изменений. В данном случае прозрачность означает следующее — любой commit жёстко привязан к таску, и любой таск привязан к совершенно конкретной задача. В дальшейшем это снимает все возможные вопросы, причём решается всё оперативно, если таковые возникают. Примеры «а зачем мы добавили кнопку X на странице Y» должны решаться в течении нескольких минут — открыл код, нашёл кнопку, связанные коммит и таск по которому она была добавлена, из него сразу ясно или ссылка на бизнес требования. Документирование — важно чтобы было не избыточное. Т е документируются сложные части интерфейсов API, алгоритмов. Если это банальное изменение на добавление поля — никакой отдельной документации вести не следует — сама система task management со ссылкой на бизнес требование — достаточная документация в большинстве случаев, за исключением конечно какого нибудь public api

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

5) По поводу костылей и технического долга. Это никак не связано с методологией по моему. Технический долг неизбежно накапливается на всех проектах, где отсутствует опытный тех. лид. Наблюдал эту картину и на waterflow проектах, и даже у нас в копмпании где проект ведут слабые программисты. Обычно ситуация такая что «продавить» на кривое решение можно только неопытного, слабого программиста. Если нет лида, решение продавливается и в дальнейшем эти костыли приходиться как то поддерживать. Есть даже исследование по поводу технического долга и срока жизни проекта (www.sig.eu/...hnical-debt-and-interest) , которым я махаю перед носом у заказчика когда вижу очередной костыль где то в коде. Но! Меня умиляют некоторые комментарии людей типа Дмитрий Говоров

и как итог, аутсорсер теряет клиента. Это просто неизбежно
. А вот как бы не так. По моему опыту, даже проект сплошных костылях существует положенные ему 7-10 лет и никто не дёргается его переделывать. Мало того — закачик доволен! Вопрос лишь в том, что в «конце пути» работа на таком проекте становиться скучной, тянущейся резиной, где каждый чих и мелкое изменение ломает всю логику. Потому рецепт простой — держите нормального тех. лида на все ваших проектах, и не давайте продавливать кривые решения.

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

Далее уже критика критикующих поименно:

Дмитрий Говоров

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

Быввает навеное и так как Вы описали. Но чаще всего вопрос стоит таким образом, что пользователям или нужна фича, при этом ну суть важно как это будет выглядеть, или не нужна, совсем, и узнать это до момента её релиза невозможно или слишком затратно. Вот потому и делаем мы часто вот такие «фичи-исследования рынка» — с 80% функционалом, который гарантированно устроит пользователя если это ему реально нужно. А с остальными деталями определимся в процессе и по комментариям пользователя. Главное тут то, что мы не «угоняемся» в исследования деталей и тонкостей интерфейсов до тех пор, пока не окончательно ясно что фича реально востребована. Мы же не делаем продукты типа телефона, где неправильно расположенная кнопка серьёзно повлияет на всё, мы делаем легко изменяемый продукт, и изменить детали в наших силах, вопрос в том что мы не решаем всё за пользователя заранее, и идём по его фибеку и расширяем фичу только в ту сторону, которая реально востребована.

В целом согласен, есть некоторые замечания.

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

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

Тут есть проблема — клиент должен принять (и подписать бумагу, и принять сам для себя без возражений), что такой быстрый функционал должен будет потом генерализоваться, что приведёт к ещё 1-2-3 изменениям UI в его фиче. А ещё — что, когда он платит за такую фичу, он платит для всех, а не только для себя, и она станет доступна всем.

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

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

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

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

В моей практике из такого разбора получались результаты разного уровня, начиная от «все действия делать в терминале под screen, а не из входного шелла» до создания полноценного конфигуратора-апгрейдера, который способен справляться с большинством случаев скрещивания хитрых локальных модификаций с изменениями, поступающими от новых версий (там применялась, afair, даже алгебра изменений в стиле darcs).

И всё равно, чем больше действий может быть автоматизировано на уровне apt-get upgrade, тем лучше :)

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

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

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

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

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

Знаю организации с сотнями клиентов, которые в таком стиле работают уже много лет — и это не какие-то навязанные законодательно лавки, а честно конкурирующие на мировом рынке. «Доктор, что я не так делаю?» (tm)

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

И текучки кадров нет, люди работают по 15 лет.

Вспомните недавний инцидент с кинопоиском.

Я вижу, что за счёт того, что слово «кинопоиск» очень на слуху, его теперь втыкают как обоснование чему угодно — от вращения Луны до топологических аксиом.
bash.im/quote/436160

Работаем в стиле XP уже лет 12, и есть клиенты, которые примерно столько лет с нами. Что мы делаем не так? Почему они не разбежались? Вы видимо мало работали в таком стиле, и суждение немного постороннее. Я как адепт могу сказать другое — да блин большинство клиентов двумя руками ЗА говноподходы типа «.як..як..и в прод». И тут действительно важно не дать заказчику возможности сделать все как попало, нужен трезвый анализ и умение сказать «НЕТ» когда это требуется.

Согласен что есть вероятность того, что можно запороть фичу, реализовав её как попало. С другой стороны это дело заказчика (или отдела бизнес аналитики по новомодному) — определить какой именно ф-л является первостепенным, какой второстепенным, т е расставить приоритеты. А выгода всё таки явная — берём 5 фич, допустим соотношение востребованных/невостребованных 3/2. Потрачено на начальном этапе по Паретто — 5*20=100ед, на дополнительном — 80*3. Итого: 100+240+340. В предлагаемом Вами варианте — 500. Выгоднее делать только то, что востребовано.

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

Подход работает, но при следующих ограничениях:
1. Комманда монолитная, техлид не менялся и обладает всей полнотой знаний и контроля («сам делаю код ревью за всеми членами команды»)
2. Рост не экстенсивный и бизнес процессы задаете вы (нет ситуаций появления трех крупных клиентов со своими хотелками, чаще всего рост принудительно сдерживается руководством).
3. Проект один и на одном хосте (есть одна версия в разработке и сопровождении)

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

Для корпоратива, версионных продуктов или растущей комманды не подойдет.

1. Комманда монолитная, техлид не менялся и обладает всей полнотой знаний и контроля («сам делаю код ревью за всеми членами команды»)

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

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

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

3. Проект один и на одном хосте (есть одна версия в разработке и сопровождении)

Нет. Несколько проектов, сотни клиентов, тысячи хостов.

Для корпоратива, версионных продуктов или растущей комманды не подойдет.

Работает в случае «консультационного ПО» (в терминал Joel Spolsky). Версионность есть, есть планомерное развитие, часто даже в новомодном стиле по графику с фиксированными интервалами (как Firefox). Команда медленно растёт. Взрывной рост, да, не применяется, как и массовые сокращения.

Новый крупный клиент с очень специфическими хотелками — обычное явление.
А три и одновременно, а через неделю, ещё три? ;)
Про сдерживание не зря поправка была. Чаще всего сдерживают бюджетом на клиента :)
А три и одновременно, а через неделю, ещё три? ;)

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

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

Прошу расшифровать обе реплики, я не понял их смысл.

Денисе,
— Цікаво, наскільки комфортно в таких умовах почуваються ваші колеги?
Ревью та тестування допомогають, але рано чи пізно помилки прослизнуть в робоче оточення.
— Як ви відстежуєте що зламалося?

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

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

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

Как все однообразно комментируют:) Отвечу и я однообразно: есть живые случаи с планомерным развитием по 15-20 лет. Поэтому рекомендую пересмотреть свои вводные.

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

Первый раз оставляю комментарий здесь. Но больше терпеть нет сил))))
Ваш вывод ошибочен.

Делайте только то, что нужно реально сейчас и не тратьте время на разработку функционала, который не нужен.

это частично так, но ваша разработка должна быть нормально и качественно спроектирована, чтобы дальнейшая поддержка и расширение были возможны с минимальными\ адекватными затратами на така званый рефакторинг. Также возможна разработка с использованием Моков или так званых Стабов, но и этот подход требует проектирования!

Вообще сейчас модно стало говно кодить а потом решать проблемы говно кода в виде технических сторей «редизайн или рефакторинг».

Как я понимаю что ваша компания

Sovtes
не ИТ-шная так как занимается логистикой а вы пилите ее внутренний продукт.

Я повидал много разных подходав, но ваш явно в 5-терке худших.
Тестировщики должны не только

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

А вообще делайте что хотите)) ваше дело чем и как заниматься, но не агитируйте за вещи которые не являються правильными!

Коллеги, спасибо всем за отзывы. Примерно этого и ждали :)

Экстремальное Программирование назвали так не от того, что его практикующие ведут себя как ужаленные (aka «ковбойский багфикс на продакшне»), а потому, что техники из которых эта практика состоит в известном смысле доведены до крайности:

— программирование в паре может быть полезным — давайте делать это постоянно (Pair programming);
— модульное тестирование доказало свою эффективность — давайте писать тесты до кода и в больших кол-вах (TDD);
— частые релизы нравятся клиентам и способствуют выявлению проблем интеграции — давайте интегрироваться постоянно (CI).

Ого скільки писателів ідеального коду в коменти набігло)))

не так уже и много)) есть более интересные темы) просто зачем это было постить непонятно?

Дякую що написали назву компанії — тепер буду знати кого обходити під час можливого пошуку роботи.
А Вам бажаю все-таки передивитися поточну методологію розробки (якщо звичайно описане можна так назвати...)

Дякую що написали назву компанії — тепер буду знати кого обходити під час можливого пошуку роботи.

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

Я так понимаю что писем от кастомера типа «WTF is going on? Do you guys have anybody responcible for Change Managent process in your organisation?» автор еще не получал. Ничего, получит.
Ну а про всякие мелочи типа SSAE16 и т.п. и разговора очевидно нет...

А у QA не подгорает,
какой куа?
а на стейджинге нету
какой стейджинг?
черри-пикают
а гит тут при чем?

Не нужно додумывать то, чего нет )

Подозреваю, что

Олег и тестировщики
- это что-то типа Product Owner и подопытные пользователи

Допускаючи реліз через staging-сервер, наявність системи контролю версій і QA, варто допустити що й QA команда під час релізу виконує тести саме на staging-сервері.
Якщо це не можливо з технічних причин, то я би допустив що QA тестують саме staged стан продукту. Якщо deploy-процедури передбачають можливість виконання hotfix, то й QA мають підтримувати такий режим. А така комбінація дає надзвичайно гнучкі інструменти для деплою та оперативного латання дірок.

Зовсім інша ситуація, якщо ні deploy-інфраструктури, ні процедур, ані моніторингу не має і зміни і правда здійснюються прямо під навантаженням і без SCM. Але це знову ж таки сильно залежить від навантаження на продукт і від вміння команди і менеджменту вчитися і адаптуватися до росту і нових проблем.

Думаю, этот метод будет работать до первого серьезного залета.

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

At first I was like 😠
But then I 😂

Позвольте, а где же про «экстремальное программирование». Вы подменили понятие.
По тексту видно, что вы даже эту тему не читали.
citforum.ck.ua/.../project/programing.shtml
www.skipy.ru/philosophy/xp.html
compress.ru/article.aspx?id=11721

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

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

P.S. И вообще после такой статьи могут быть проблемы с дальнейшим трудоустройством :)

И в чем мессадж? Вы круты?

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

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

Менеджеры, которые соглашаются и продавливают подход «х**к х**к и в продакшн» — это редкостные сволочи, которых нужно вечером встречать у парковки и проводить беседу на тему best practices in project management.
А инженеры, которые дают себя продавить — ..., впрочем, они сами себя уже наказали.

Почему такой подход работает:
Этот подход не работает на серьезных проектах. И вот почему.

К менеджеру приходит продакт и говорит — у нас есть о**ительная идея фичи, которая нужна очень важному клиенту.
Есть 2 варианта:
1) Ad-hoc решение, что займет 1 час
2) Собрать полностью требования, сделать нормальный дизайн, нормальную реализацию (50 часов)

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

Как только мы делаем фичу в ковбойском стиле (захардкорить чей-то ID-шник в коде, 2 раза в день выполнять ad-hoc запрос на продакшн базе, отключить входную валидацию чтоб пропустить какой-то высокоприоритетный запрос, тысячи их), мы берем на себя технический долг, по которому должны платить проценты каждый день рабочим временем инженеров.

Сегодня захардкордили ID-шник одного клиента.
Завтра скажут что нужно запустить еще одного клиента.
Когда через неделю скажут запустить 11-го клиента, кто-то спросит, какого фига, ему ответят — вы смогли запустить 10 клиентов, значи 11-го тоже запустите без редизайна системы.
И инженер будет добавлять 11-й ID-шник в код и деплоить на продакшн.

Поскольку фича со стороны выглядит «complete», отказаться онбоардить 50-го клиента будет намного сложнее, чем отказаться онбоардить первого, так как на эту фичу уже рассчитывает бизнес, клиенты, уже есть план по ее использованию.

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

Наши инженеры теперь постоянно совершают какие-то операционные действия для поддержания этой фичи и мы теряем velocity.

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

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

После этого один из инженеров говорит fuck this shit и уходит из команды, унося с собой часть уникальных знаний о том, как все это было сделано.
Берется новый инженер, которого начинают вводить в курс. Когда он задает вопрос «какого хрена это сделано через жопу», тогда и произносится та самая фраза — мы так делаем последние полгода, просто смирись.

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

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

================================================

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

Артем, в целом соглашусь. Прошу обратить внимание на абзац статьи: «Но как же технический долг? Как только становится ясно, что исходная быстрая схема устарела для данной конкретной задачи или ее нового этапа, то мы перестраиваем модель, рефакторим и подстраиваем под текущие новые требования, но, опять-таки, только в пределах текущих требований, без делания „на перед“.»

Сори, но это сродни «Я не пристегиваюсь, потому что ситуация на дороге безопасная, когда станет опасной, я пристегнусь», или «Я кольнусь несколько раз чтоб попробовать, в любой момент могу соскочить». Можете соскочить, а можете и не соскочить.

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

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

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

Я кольнусь несколько раз чтоб попробовать, в любой момент могу соскочить
А зачем соскакивать? И так ведь ясно, что там хорошо.
После этого один из инженеров говорит fuck this shit и уходит из команды, унося с собой часть уникальных знаний о том, как все это было сделано.
Ага! А потом находятся хитрые чуваки вроде недавно нашумевшего Sun Trust Bank кот-е в условиях увольнения прописывают бесплатные консультации в течении 2-х лет после увольнения...
www.computerworld.com/...s-cooperation-clause.html

Если там при увольнении не дают бонус в размере 5-годовой зарплаты, я бы ничего не подписывал, собрал вещи и свалил, а если Sun Trust Bank после этого сильно понадобилась бы моя консультация, я бы без проблем ее предоставил в любое время суток за $500/hour

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

К менеджеру приходит продакт и говорит — у нас есть о**ительная идея фичи, которая нужна очень важному клиенту.
Есть 2 варианта:
1) Ad-hoc решение, что займет 1 час
2) Собрать полностью требования, сделать нормальный дизайн, нормальную реализацию (50 часов)
Если менеджер в этот момент выбирает первый вариант, он запускает процес, который очень медленно, но неотвратимо приведет к неотвратимому плохому концу.

А вот представим себе ситуацию, что после Ad-hoc решения эта фича «не пошла» и в итоге оказалась никому не нужной....

При этом суммарные затраты будут 1час + возможно 1 час на удаление. А для «классического» waterflow подхода будет потрачено 50 часов на разработку никому ни нужной фичи, и потом ещё часов 10 на её удаление. Да, я понимаю что возможно в процессе самого этапа бизнес анализа станет ясно что фича ничего не стоит, и делать её не надо, но имея опыт работы с весьма убеждёнными в ценности своих идей заказчиками могу сказать что в реальной жизни проще один раз показать несостоятельность идеи быстро, чем пытаться доказать на словах.

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

И инженер будет добавлять 11-й ID-шник в код и деплоить на продакшн.

Это проявление крайности. Да, мягкий и безответственный разработчик так и поступит, а в нормальной ситуации за проектом следит человек с опытом побольше, который сумеет вовремя среагировать и изменить архитектуру данного решения на более адекватную. Всё таки есть отличие XP vs

«х**к х**к и в продакшн

А я приведу контр-пример. Я часто вижу как раз обратную ситуацию, когда в крупных корпорациях уходят недели и месяцы обсуждений на то, куда добавить кнопку, тратяться («пиляться») бюджеты, работают отделы BA и QA, а в результате работы на 1 день, и кнопка эта по факту никому не нужна. Если бы сразу поставили и замерили реакцию пользователей, было бы намного результативнее. Черезчур формальный процесс сильно замедляет разработку.

Добавлю от себя — мы в целом пользуемся XP как подходом. И конечно релизнуть фичу можно по ускореннйо процедуре, но обычно всё равно потребуется полная прогонка тестов и приёмка данной фичи через code review.

А вот представим себе ситуацию, что после Ad-hoc решения эта фича «не пошла» и в итоге оказалась никому не нужной....
При этом суммарные затраты будут 1час + возможно 1 час на удаление.
В идеальном мире будет 1 час на удаление. В реальном мире проект по выпиливанию фичи может по своему размаху переплюнуть несколько проектов по созданию аналогичной фичи и заблокировать работу нескольких команд на недели, в особо клинических случаях фичу выпилить будет даже невозможно, ничего при этом не сломав.

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

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

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

Если проект простой, то ваш подход возможно имеет смысл для существования. Но в крупных проектах ваш подход не будет работать. Я к сожалению работал в таких проектах в которых использовался ваш подход. Как только доходит дело до расширения проекта, заказчик начинает хотеть чуть больше, ты понимаешь что ту эрунду которую написала вся команда до этого можно просто выбросить. И обычно в таких случаях время на рефакторинг не выделяется. Бывают даже случаи когда проще переписать проект заново чем пытаться сопровождать монстра который состоит из сплошных «костылей» и «велосипедов».

Александр, согласен. У нас на рефакторинг выделяется время, когда этот рефакторинг оправдан, т.е. когда «костыль» становиться слишком дорогой.

Значит вам реально очень везет что на рефакторинг выделяют время. Обычно все бывает в точности наоборот. Заказчик не хочет зачастую платить деньги за рефакторинг, а объяснить почему например предыдущие N-задач подобного плана решались например за 2 часа, а следующая задача такого же плана займет 20 часов. То у заказчика возникнет резонный вопрос: «Почему 20 часов, если на предыдущие задачи были по 2 часа.» И приходится тратить время чтобы объяснить, что эти 20 часов необходимость для проекта, потому что старое ad-hoc решение не работает уже.

если ваш ПМ/Лид не умеет продавать заказчику рефакторинг, то это не проблемы подхода, а проблемы тех кто его не правильно использует. это как пистолет обвинять в убийстве

Рассмотрим 2 ситуации

1) Цукерберг приходит к вам и говорит — «Я придумал запилить кнопку dislike, это нужно сделать до завтра, хоть как, главное чтоб работало». Нужно убедить его отложить запуск этой фичи на 2 недели, так как «хоть как» выйдет боком, нужно нормально задизайнить эту фичу.
2) Фича сделана «хоть как», запущена 2 недели назад в продакшене, но оказалось, работает тоже «хоть как». Теперь вам нужно пойти к Цукербергу и убедить его в том, что кнопку нужно отключить (теперь уже на 4 недели), заново задизайнить и переписать функционал, а также мигрировать все дизлайки из старой системы в новую.

В первом случае он скажет «Блин ну как так, у меня уже джва года просят эту игру кнопку»
Во втором случае он скажет — «Вы опять конопли обкурились? Если мы сейчас отключим эту кнопку, то об этом напишут даже в NYT и акции компании упадут?»

В каком случае продажа будет более успешной?

а никто не говорит что на такую ересь как во втором варианте надо вестись, никто не опускал БА анализ

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

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

Я думаю просто что те ПМ/Лиды с которыми я работал просто, умели сразу нормально оценить сложность проекта и сколько на него будет потрачено человеко часов. Не вижу смысла что-то пробовать донести до человека который считает программирование и разработку через ad-hoc решения нормальной практикой. Меня больше удивляет как ваш ПМ/Лид умудряется продавать постоянно «костыльные» решения и с вами до сих пор кто-то сотрудничает.

ПМ/Лид умудряется продавать постоянно «костыльные» решения
вам никто не говорил про постояно. суть в том, что не стоит забывать, какая цель вашей работы
это как пистолет обвинять в убийстве
Нет это как чистить пистолет пренебрегая инструкциями безопасности как раз здесь
это не проблемы подхода, а проблемы тех кто его не правильно использует
«неправильно» кстати слитно.
Короче, продать рефактор,чтобы кастомер ничего не понял — тот еще скилл.

Всё проще. Фактически продаётся не продукт, а работа целевой системы. Главным компонентом является поддержка, которая в себя включает и рефакторинг (открыто говорится, что все введённые наскоро фичи должны быть обобщены и нормализованы), и поступление точно таких же фич, заказанных кем-то ещё. Понятно, что от профиля работы «мы вам сделали код по всем правилам, а дальше что хотите, не наша проблема» это отличается чуть менее, чем полностью.

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

Я бы так не сгущал. Они же работают 12 лет так. Иногда ничего не нужно продавать. У них могут быть просто доверительные отношения и этого достаточно, чтобы сказать, что делаем вот это, потому что это нужно потому-то потому. Если заказчик не бронелобый, он понимает важность стабильности системы.
Кастомеры очень редко понимают, что что-то на костылях. Подозрения и недовольство — когда система не стабильная, это не всегда обусловлено костылями.

Есть кастомеры, которые именно тесты и аутсорсят)

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

Читал про компании которые раз в два месяца выделяют неделю чисто на рефакторинг, а не когда уже некуда деваться

Я вот вижу обратную ситуацию — люди часто угоняются пишут огромные тех задания а потом получается пшик. Иногда всё таки проще идти небольшими шагами, особенно если цель не сильно понятна сразу. И вообще автор пишет о том, что делать всё надо вовремя, иногда и быстрый фикс на продакшне покатит, чаще начинать надо с минимума, но и ситуации в которых строится полная модель и данная реализация тоже ведь возможны? Одно другого не отрицает. Согласен только с тем, что построить серьёзные проект на костылях не выйдет. А вот сделать многое быстрее и понять что в результате нужно — можно.

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

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