Highload fwdays — спікери зі Stackoverflow, Netflix, Google, AWS, Rovio | Київ, 5 жовтня
×Закрыть

Как вы относитесь к «dirty code to production» разработке? Или не зажрались ли вы ребята?

Предыстория.
Клиент (web middleware) нанял маленькою команду спецов в одной из outstaff компаний. Новая команда состояла всего лишь из UIX, бекэнд, фронтенд (спустя 2 мес) и iOS разработчика.
Хотя клиентской компании уже без малого 5 лет, проекты, которые они запустили, используют технологии и медодики 6-ти летней давности.

Всё бы ничего, казалось бы, что ребята решили серьезно занятся парком своих приложений и улучшить их (команда годная). Но, была поставлена задача делать быстро, AFAP, «dirty way» и использовать как можно больше copy-paste для ускорения процесса.

Не могу судить о дизайнерских или мобильных решениях и возможностях их переиспользования, но PHP бэкэнд выглядел весьма печально. IDE пестрил deprecated уведомлениями, а MVC с ООП совершенно не пахло. «Фреймворк» собственной разработки, который рекомендовали использовать, совершенно не походил на таковой: 6 функций преобразования данных таблиц в массивы с пресловутым or die(mysql_error()). Все пути по папкам со своими точками входа ({module}/index.php - помните?). В общем не приложение, а скрипты.

Чтобы начать разрабатывать c таким подходом, нужно было не просто убрать нотисы в IDE, но и добавить к собственным скилам ещё экстрасенсорику для угадывания что этот код делает и спиритизм для обращения к духам умерших методик за знаниями.
Но, чего тут ныть? Делать нужно.
Два проекта (CMS и веб-сайт), которые были запланированы не нужно было переделывать, но создавть почти с нуля (БД уже имелась). CMS планировалось как платформа для управления контентом всего парка middleware сайтов, но для начала только одним.
Исходя из этого, использование старого подхода новый разработчик отбросил сразу, поскольку копошение в трясине пахло некорректными эстимейтами. Оценили по самым оптимистичным меркам, выкинули всё неважное — чтобы вписатся в дедлайн.
Взяли набор готовых решений и либ. Чуть подкрутили, упростили. Но всё равно не вписывались. За 2 месяца без вменяемого ТЗ на одних только хотелках (user stories) поднять полностью рабочий сайт и CMS со своими бизнесс-заморочками для крохотной команды малость сложновато. Да и фронтенд пришел только под конец — за 3 недели до ДЛ.

В итоге, по наступлению ДЛ — клиент уволил двоих сотрудников (UIX, backend) из-за оверинжиниринга и срыва сроков. Хотя, проекты уже на финишной прямой.

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

Как быть разработчикам? Как себя вести в подобной ситуации? Не братся за такие проекты? Не строить из себя «золотого», а закатывать рукава и делать, как говорят — типа если спец, то и маслом нарисуешь, на кой тебе Фотошоп?

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

Спасибо. За внимание.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1. Не работать с мудаками. Себе дороже
2. Использование хард кода неизбежно приведет к удорожанию стоимости проекта в целом, ведь далее потребуется тотальный рефакторинг (если проект планируется развивать дальше)
3. Если клиент не понимает п.2 — смотри п.1

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

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

Правильный подход — ставить правильные эстимейты. Подход «поставим максимально оптимистичные эстимейты» как раз и заканчивается

по наступлению ДЛ — клиент уволил двоих сотрудников
. Если клиент неадекватен, брызгает соплями и слюнями и рассказывает, как ему 2 студента сделают в 3 раза быстрее — рекомендовать ему пойти нах и нанять этих 2-х студентов. Если же клиент адекватен — спокойно обосновать реалистичные эстимейты, рассчитать риски (в том числе и отсутствие вменяемого ТЗ), объяснить риски и спокойно работать к обоюдному удовлетворению.

Клиент дважды оспаривал эстимейты. Во второй раз разработчик согласился писать «dirty way», но это не сильно повлияло на результат, поскольку user stories остались прежними.
В целом согласен. Разработчику не нужно было позволять клиенту влиять на эстимейты. И, возможно, в споре выяснилось бы какой именно подход клиенту нужен и что разработчик ему не подходит по требованиям к проекту.

Вопрос не в dirty way. Хочет так — не вопрос, пусть будет так. Растолковать риски, объяснить, что при таком подходе разработчик не может ручаться за качество кода, что вполне возможны баги, которые из-за ограничений такого подхода будут решаться неделями, а их фикс будет вызывать тонны новых багов (например, баги кривой архитектуры, требующие полного переписания архитектуры проекта). Если он с этим согласен — не вопрос, его предупредили, он берёт эту ответственность на себя. При таком подходе только T&M, никакого fixed price, либо фаза багфикса только за дополнительные деньги, считающиеся 100% по T&M, иначе для разработчика есть риск попасть на бесконечный багфикс за свой счёт.
Оспаривать эстимейты — легко. Диалог вести в стиле — окей, мэн, мы оценили эту задачу в 2 недели, у тебя есть 3 дня. Отлично, вот тебе тот scope, который мы можем выкатить за 3 дня, остальное выносим в отдельные задачи и ты сам решаешь, что тебе важно, а что нет. Подписываться выполнить задачу, требующую 2 недели за 3 дня — тупо, всё равно не справитесь, если эстимейты корректные, упираться рогами в заказчика с воплями — да тут не меньше 3-х недель — тоже тупо, хотя и лучше, чем вариант 1. Но приведёт к неудовлетворённости заказчика.

Ситуация банальна и повсеместна. Отослать мылом заказчику.

Мені здається, що між «Якісно» і «Швидко» не має бути перетину.

Если брать сплоченную команду с опытом за большие деньги, то вполне реально и качественно и быстро, но очень дорого, потому-что, слаженность процесса должна быть высокого уровня :)

По крайней мере таких тяжело найти.

Ну так вы пронаблюдали процесс поиска. Изнутри.

Как быть разработчикам?

Вы хотели/хотите уметь работать с такими технологиями? Нет? Забыть и двигаться дальше. Да? Учиться работать с такими технологиями. Но у вас вроде чёткий ответ «нет».
Большой плюс для обоих сторон — определяться с ответом как можно раньше.

Не строить из себя «золотого», а закатывать рукава и делать, как говорят

Не надо строить, надо уметь обосновать свою позицию.
В том числе перед суровой объективной реальностью.
«Копошение в трясине пахло некорректными эстимейтами (...) Взяли набор (...) но всё равно не вписались».
Есть решение A, есть решение B, разработчик уверен что нужно делать B поскольку A не впишется в сроки.
Reality check, бам, B не вписывается в сроки. Занавес.

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

Не бывает такой ситуации, чтобы требования функциональные + нефункциональные были четко сформулированы, а программисты отказывались их делать или саботировали. Как правило есть формулировка «Сделать заебись!» (цитата).

Наняли студентов, что ж вы хотели, скупой платит дважды.

Не студентов, но присмотр PM’a не помешал бы. Оказалось, что программист не всегда может донести масштабы факапа до клиента, который сфокусирован не на процессе, а на результате. Фильтр какой-то работает с обеих сторон и реальная картина оказывается между строк.

Интересно, а экскаваторщик или крановщик могут донести масштаб факапа до клиента?

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

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

Давайте будете чесно писати — “не було в моєму досвіді”?

Да, в моем опыте такого не было. А в вашем опыте было, когда программисты видя полную спеку саботировали проект ?

Когда вы поняли, что не вписываетесь в дедлайн? Клиент об этом знал?

Сначала ДЛ как такового не было. Было «желательно до». Затем, когда не вписались в «желательно до», поставили дедлайн с оговоркой — посмотрим что получится. Ну и когда пришло время — дедлайн оказался очень строгим и реальным фейлом.
Суть не в дедлайнах даже. Судя по-всему, заказчику нужна была не такая разработка. Банальный скриптинг, а не приложение. Даже MVC для них казалось чем-то слишком сложным поэтому они пытались контролировать выбор фреймворка с оглядкой на те, которые они когда-то щупали или слышали (здесь был выбран устаревший slim 2.x). Но скриптинг всё равно считался лучшим решением и пиарился постоянно.
Как-то так.

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

Как быть клиенту, которому нужно быстро, по-старинке, минимальным количеством людей?
Давно известно что из «быстро», «качественно», «недорого» клиент может выбрать только 2 пункта. Нужно быстро и минимальным количеством людей (зачем?) — нанимает несколько супер-синьоров, платит им дохрена работу 20 часов в сутки и они сделают как скажет: хочет «по-старинке» (зачем?) — специально сделают много копипаста. «Клиент всегда прав» — поэтому «любой каприз за ваши деньги». Если предложить большие деньги — то и синьоры не откажутся «замарать ручки».
Как быть разработчикам? Как себя вести в подобной ситуации? Не братся за такие проекты? Не строить из себя «золотого», а закатывать рукава и делать, как говорят — типа если спец, то и маслом нарисуешь, на кой тебе Фотошоп?
Как обычно: называть свою цену. Спец сможет и маслом — если в 10 раз больше заплатят. А если джун и ничего лучше нет — то да, нечего «строить золотого», делай как говорят иначе уволят.
Это рынок: спрос и предложение. На фрилансе всегда можно найти кто согласится делать халтуру очень дешево и быстро (если не наши то индусы или китайцы).
«быстро», «качественно», «недорого»
Только быстро, качественно, дорого.

Судя по-всему, клиент хотел только «быстро». Но команда оказалась не готова к такому повороту событий.
И да, это был аутстаф — не аутсорс.

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

За 250 баксов в час.
И это правильно! Деньги — это обычно тот аргумент, который клиент всегда понимает (в отличии от технологий). Хочет что бы кто-то поддерживал его 15 летний сайт на VB6 ? Без проблем — плати от 250 баксов в час за поддержку! А согласен переписать — тогда за 30 баксов в час все переделаем. Что выбираешь?

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