Как известно, есть бизнес-задачи а есть задачи технические.
Бизнес хочет скорейшего решения и оценивает работу по количеству сделанных бизнес задач. Но тут есть нюанс — что можно худо-бедно решить эти задачи быстрее за счет понижения качества кода, как бы оставить на потом.
И как обычно назревает — что эти оставленные косяки начинают тормозить процесс вплоть до полной его остановки.
Представим что вы вошли в проект и там много таких "оставленных на потом" вещей, которые не позволяют повысить качество. К примеру, для серверных ошибок нет типизации и в каждом месте стоит своя лесенка из условий, чтобы понять что произошло (или вообще некорректное поведение, основанное на том, какие ошибки наиболее часто возникают, а не на всех возможных вариантах — без проверки реальной ситуации). Или нет юнит-тестов как таковых и архитектура не сильно заточена под их простое добавление. Вы говорите — давайте все это в одно место вынесем и приведем в порядок — а вам — та не, сейчас не время — потом этим займемся, когда зарелизим.
И тут как-то понимаешь, что работа в бардаке вряд ли поможет быстрее сделать релиз.
Вроде да — вот прямо сейчас быстрее эту задачу сделать, не работая над системой классификации исключений — оставить как есть. Но будет работать лишь для части случаев. Потом тебе дают баг — вот для этого случая не корректно отработало — и опять нужно вернуться с тому, что откладывалось или добавить очередную лесенку именно для этого случая.
Что вы делаете в таких случаях? Идете на поводу или упираетесь и приводите сначала в порядок базу?
С одной стороны если начать приводить в порядок базу — то тебе предьявят что ты вместо решения бизнес-задач фигней страдаешь.
С другой стороны если базу не привести в порядок — то предьявят что ты все делаешь медленно, все ломается, все не стабильно работает.
если отвалят премию и отпуска еще пару недель, ну .. можно обсудить. если нет, то понятно что интереса ковырять говно нет никакого, надо все переделывать. в говне ковырять, есть полно готовых на то людей. может даже с опытом ассенизаторским.
а так через дорогу норм проекты всегда есть, где нырять никто не просит.
Здравствуйте, Shmj, Вы писали:
S>Как вы поступаете?
Делать все в комплексе:
— Закладывать техдолг в оценки времени фич (не обязательно детально проговаривать с бизнесом, если не понимает)
— Уменьшать техдолг при исправлении багов (также закладывать время)
— Показывать бизнесу возможность снижения time-to-market за счет снижения техдолга. Обычно бизнес готов сотрудничать, если видит профит. Так можно протолкнуть более масштабные изменения
Здравствуйте, Gt_, Вы писали:
Gt_>а так через дорогу норм проекты всегда есть, где нырять никто не просит.
У него особый талант выбирать работу где опять приходится нырять.
Этож не первый раз такое.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Во что ты опять влип?
Везде где я работал абсолютно нормально относились с избавлению от тех долга: я мог сам поручить себе такую задачу и заниматься этим неделю-другую, бизнес сам мне поручал задачи по тех долгу, было даже так что бизнес выделял отдельную команду на полгода для таких задач.
Здравствуйте, Shmj, Вы писали:
S>Как известно, есть бизнес-задачи а есть задачи технические.
S>Бизнес хочет скорейшего решения и оценивает работу по количеству сделанных бизнес задач. Но тут есть нюанс — что можно худо-бедно решить эти задачи быстрее за счет понижения качества кода, как бы оставить на потом.
Потом ты выполнил и перевыполнил плани уволился, и хоть трава не расти. Пусть следующие поколения разгребают.
S>С одной стороны если начать приводить в порядок базу — то тебе предьявят что ты вместо решения бизнес-задач фигней страдаешь.
А очередное поколение разработчиков столкнётся с тем, что они все дураки и всё сломали. Вот до них же раньше хорошо было.
S>Как вы поступаете?
Если в проекте постоянно сбегают разработчики, то вряд ли ты станешь исключением.
Здравствуйте, Shmj, Вы писали:
S>Что вы делаете в таких случаях? Идете на поводу или упираетесь и приводите сначала в порядок базу?
S>С одной стороны если начать приводить в порядок базу — то тебе предьявят что ты вместо решения бизнес-задач фигней страдаешь.
S>С другой стороны если базу не привести в порядок — то предьявят что ты все делаешь медленно, все ломается, все не стабильно работает.
S>Как вы поступаете?
Если принять, что порядок — есть функция от требований, то то, что сегодня порядок — завтра бардак. При изменяющихся требованиях. А значит, наводить порядок просто для того, что бы был порядок — задача для прокрастинации.
Условно, сегодня, наводя порядок, я прикручиваю кодогенерацию, а завтра ее выпиливаю, т.к. при переходе на новый фреймворк она перестала работать детерминированно и хороших решений по ее сохранению нет.
Потому, лучше оставить как есть, если конкретный бардак не мешает двигаться вперед.
Но, лучше проложиться и написать тест, который при выходе из области действия работоспособности текущего бардака предупредит, что текущий бардак далее устраивать не будет.
Кто вы? В зависимости от моей роли — мои действия могут варьироваться: Как синьор, я делаю что мне сказано и фикшу по минимуму за то время что мне дали...;
Как лид, я анализирую текущее положение проекта и иду говорить с бизнесами, обьясняя им (обычно это лишее) суть фраз "возросшие риски" и "избыточная стоимость поддержки";
Как CTO я выделяю цели и квоты на техдолг, разрабатываю независимый процесс аудита качества разработки (судя по твоему рассказу у вас в конторе об этом не слышали);
CC>У него особый талант выбирать работу где опять приходится нырять.
Ой ладно уж. Такой код почти везде, где нет очень строгого техлида, фанатично следящего за качеством кода, документации, тестов и прочего. Может также встречаться в open source, типа linux kernel. Но в любом внутреннем продукте я готов гарантировать полные штаны этого самого го... тьфу, технического долга.
