Как поменять минус на плюс, или Давайте сделаем это интересным

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

Команда в унынии, люди активно смотрят по сторонам и примерно половина решительно настроена уходить. Адресат вопроса (терпила) — новый менеджер, которому досталась эта прелесть. Суть вопроса — что делать?

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

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

Итак, для начала можно попробовать понять в чем проблема. Как себе представляю себе я — все напряги появляются из-за того, что пользователи находят ошибки. Тогда сразу первый вопрос — а почему так? Вот если бы сделать, чтобы баги находились и исправлялись ДО заказчика? Таким образом можно понизить уровень стресса в команде — заказчик доволен, и беспокоиться нечего. Появляется решение — разобраться с разработчиками и QA, почему баги пропускаются и доходят до заказчиков.

Это уже похоже на решение проблемы. Однако можно пойти еще дальше.

Какой-то умный исследователь человеческого мозга сказал, что этот самый мозг склонен к однозадачности, и требует для полноценного переключения внимания на другую задачу до 15 минут. И если вам ВНЕЗАПНО сообщают, что есть новая бага и нужно стремительно ее начинать фиксить, то придется потратить какое-то время, чтобы на ней сфокусироваться. Кроме этого, может понадобиться воспроизвести ее окружение: достать нужную версию из VCS (при этом как-то сохранив код, над которым идет работа), может что-то пересобрать, приатачить отладчик, проклацать пару форм, повводить туда тестовые данные, и в итоге узнать, что точка прерывания стоит слишком поздно :)

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

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

Тестировщикам тоже стоит задуматься об автоматизации. Где не хватит своих сил — всегда можно попросить разработчиков помочь. Постепенно доля багфиксинга будет уменьшаться и в результате станет бесконечно малым :)

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

А у вас есть элемент неинтересности в работе?

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

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



Найкращі коментарі пропустити

Написать модульные тесты на готовое приложение, которое не было спроектировано с учетом этого самого модульного тестирования — это жуткая кара для разработчиков и менеджера. Будет очень много, нет, ОЧЕНЬ МНОГО рефакторинга, который без модульных тестов, как известно — источник еще большего количества багов, даже если дизайн у приложения более-менее. В описываемом же случае в системе наверняка довольно много не самого хорошего кода, с ним еще сложнее.

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

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

Между тем, писать тесты в таких клинических случаях как раз и нужно. Только наверно начать стоит с интеграционных, которые бы тестировали целые фичи приложения (сервисы, UI) + пытаться автоматизировать функциональное тестирование QA. На данном этапе это наверно самое реальное, что можно сделать, т.к. это не потребует серьезного рефакторинга.

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

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

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

Не знаю — не знаю, если переработки я бы уволился в любом случае.

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

122 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Дааааа покрытие тестами легаси кода так увлекательно. Особенно если он писался так что для покрытия двух методов надо замочить 42 сервиса и написать огромный конфиг для dbUnit

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

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

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

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

ну а откуда видеть поддержку людей если обычно это просто еще один геморой на больную голову?
Проект писаный не по TDD магически обрастает кучей чертовски неудобных в тестировании мелочей, которые прекрасно превращают эту работу в ад.Чесно говоря единственный путь — писать тесты на новые фичи и по возможности на баги... Вообще не помню у кого либо успехов на почве ’лихо покрыть тестами 50К строчек олдового фекалокода’

есть фреймворки, которые помогают покрыть тестами легаси код, например, approval tests (blog.approvaltests.com)

Хочешь быть трабл мейкером в команде? Ок) Задача ввести White box тестирование в существующий проект — это гиблое дело. А если написано уже более 2 000 000 строк кода... Нет, я все уже понял и осознал ошибки. Есть отличная книга «Не мешай мне работать», когда я пришел на этот проект у меня были какието идеи каким образом вдохнуть новую жизнь в проект, но вскоре я понял что это «очередной геморой» и отказался от этой идеи. Все что нужно — это развиватся самому, читать литературу, изучать то что есть хорошего в проекте и валить в другую компанию на более адекватный проект.

А представте что все получилось. Собрались все (руководство, манагеры, програмеры) и придумали нечто и нет больше багов, скажем через пол года.
Кому это надо? Нет роботы, нет купюр ...
А програмерам с такого проекта валить надо
Менеджменту новых искать
кллиент платит, робота кипит, новые практику проходять.

Сплошное развитие

такие проекты в 90% случаев результаты деятельности «сделай то не знаю что». некоторые еще эджайлом это называют.

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

Немного проясню ситуацию. Описанный кейс со мной на самом деле не происходил. Однажды в разговоре с умными людьми эти самые люди его рассказали и поинтересовались моим мнением. А мнение мое разрослось до статьи :). У меня на проектах до такого пока не доходило (хотя было когда-то, но я тогда не был менеджером, и кстати, быстренько с такого проекта свалил) , чему я даже и рад.

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

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

В догонку несколько ехидных комментариев

Уйти с такого проекта — это просто, но не всегда дальновидно.

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

попробовать решить проблему, можно как минимум получить опыт,

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

развиться дальше в своей компании

Практика показывает, что оптимальное развитие по деньгам и по навыкам дает работа на одном месте не более, чем год — два. Два даже много, учитывая динамичность рынка труда. По сему, никакого смысла в развитии «в своей компании» нет. Гораздо быстрее поучиться и перейти туда, где лучше

,

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

Что именно подразумевается под «решить проблему»? Выйти на минимум багов? Сделать проект интересным для «активных» инженеров («пассивным» это не надо)? Полностью удовлетворить клиента и успешно завершить проект? Уломать клиента сделать новую версию «с нуля»?

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

«Решить проблему» — сделать так, чтобы она пропала :)
Если у всех участников разные цели, то скорее всего, успеха не будет. Надо ли напоминать про лебедя, рака и щуку? Хорошее решение — win-win для всех.

В жизни все еще страшней. :)
С моей точки зрения главная проблема в этом кейсе — это проблема менеджмента, главная ответственность которого состоит в:
1. Управление человеческими ресурсами.
2. Управление процессом разработки, позволяющему выпускать ПО приемлемого уровня качества.
Сам кейс изначально подразумевает неадекватно поставленный процесс, который в свою очередь постепенно привел к данной ситуации.
Не знаю как сейчас, но в былые времена были такие группы строителей, назывались «шабашниками», работающие по принципу «замесить и нарубить», а после меня хоть потоп.
В общем в ИТ такие компании тоже есть.
Есть еще один принцип, нарушение которого, как правило приводит к подобной ситуации. Я называю его
3. «я — есть дешевая продажная шлюха, за пару баксов сверху выполню любое твое желание».
Это ситуация в которой компания разработчик имея и без того не совершенный процесс разработки за пару баксов сверху становится в определенную позу разрушая свой и без того несовершенный процесс в угоду прихотям клиента.
Подведем итоги:
Проблема не носит технический характер, а является сугубо «организационной», поэтому попытки решить ее привлекая программистов лишь отдаляют стагнацию продукта, но не меняют ситуацию кардинально, потому как, ни менеджмент компании разработчика, ни сам клиент ничего делать скорей всего не собираются. Убедится в этом так же легко.
Достаточно сделать пару предложений по улучшению процесса разработки, как такового, без привязки к конкретному клиенту/продукту.

Если спустили «на тормозах», — менеджмент компании все устраивает, и он не собирается ничего менять. Из своего опыта могу сказать, что продукт в таком состоянии может находится годами. :)

Удачи. Книга в помощь: “Object-Oriented Reengineering Patterns” scg.unibe.ch/download/oorp.

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

итого:

1. увеличить затраты на QA

2. снизить частоту релизов, выпускать только тщательно оттестированные

рефакторинг, автотесты — можно пробовать продать клиенту, но ИМХО, маловероятно

1) Однозначно. Что также включает большее вовлечение девелоперов в QA процесс, о чем автор и пишет.

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

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

проблема не в «несопроводимом коде». проблема в том, что баги доходят до пользователей. смотрите глазами заказчика, а не разработчика.

я предлагаю улучшить процесс тестирования и выявлять брак до выпуска продукта из производства.

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

а увеличение затрат на QA и снижение частоты релизов, чтобы дольше и тщательнее тестировать — это легче обосновать.

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

продавать нужно идею «версии 2.0» с новыми фичами и новой архитектурой. либо же доп. затраты на QA

Неправда ваша.

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

Другой важный вопрос: совпадает ли у вас видение текущей ситуации с заказчиком? Быть может он уже привык к жалобам разработчиков и считает это обычным перфекционистическим нытьем? Быть может в секретных лабораториях уже разрабатывается «мы наш мы новый мир построим 2.0™®©» , и нафиг никому изменения в этой отстое 1.0 не нужны, ну краме самых критичных? Не нужны, пока через три года, не обнаружится что 2.0 приносит все еще 1/10 дохода, намного менее стабильна, и все еще не поддерживает всего функционала 1.0. Ну да это другая история.

Продажа рефакторинга. Конечно если так с наскоку «а давайте мы вам все тут порефакторим. ну или даже лучше с нуля напишем» — то нормальный заказчик пошлет куда подальше. Но если есть уже общее понимание (см. выше), то можно начинать разговор об уменьшении tech debt. Продавать отдельностоящий рефакторинг как задачу действительно сложно, но зачастую и не нужно — opportunistic refactoring (martinfowler.com/...efactoring.html) это лучший способ постепенного улучшения ситуации без больших затрат up front. Ну а когда заказчик начинает замечать положительный эффект (иначе смысла не было затевать) и более открыт к диалогу — можно обсуждать и cross-module, cross-component, etc. большие рефакторинги если надо.

Главное — не предлагать написать с нуля. Хуже будет если согласится :)

не понял, нам как легче нужно, или как лучше?

Да, интересный кейс. Мне кажеться надо продумывать честный план либо по переходу проекта в какое-то более веселое состояние (рефакторинг + среда интеграционных тестов) либо в переводе его на анабиоз (заморозить добавление функциональности, для нового — новые модули) и согласовать с командой и заказчиком. Ну и разобраться почему QA ошибки не находят.

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

покрывать тестами — занятие сомнительной приятности, хоть и полезное.
а овертаймы оплачиваются? если нет, сделайте их оплачиваемыми и добровольными. Или добавляйте к отпуску.

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

Дык тим лид занят. Даже нам не отвечает. Виртуал.

И если вам ВНЕЗАПНО сообщают, что есть новая бага и нужно стремительно ее начинать фиксить, то придется

...послать сообщившего в пешее эротическое, пока не закончится текущее. Так и только так.

достать нужную версию из VCS (при этом как-то сохранив код, над которым идет работа),

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

А о какой VCS идет речь? Если SVN/TFS/Perforce — придётся переключиться на другую ветку, текущий под положить в какой-нибудь shelve. Если это git/hg, процесс похожий с той разницей, что можно изменения не шелвить, а закомитить в локальную веточку или просто в текущую, а потом вернуться. В любом случае это и есть «сохранив код над которым идет работа», уверен автор в курсе всех этих подходов, но неуверен, что ваша ирония уместна.

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

1) Полный чекаут — может занять длительное время, правда только в первый раз.

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

3) Два чекаута в централизированных системах могут легко стать проблемой, если возникнет потребность перенести изменения из одной рабочей копии в другую минуя центральный сервер.

В общем, в случае DVCS я вообще не вижу смысла в таком подходе в описанном контексте, в случае CVCS я бы предпочёл shelving, т.к. это избавляет от всех трёх пунктов. Мой котёнок забился в угол и зашипел, когда я предложил ему сделать две рабочии копии.

1) Полный чекаут — может занять длительное время, правда только в первый раз.

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

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

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

3) Два чекаута в централизированных системах могут легко стать проблемой, если возникнет потребность перенести изменения из одной рабочей копии в другую минуя центральный сервер.

Я что-то пропустил или изготовить патч даже между несколькими ревизиями с последующим применением в другой копии стало вдруг тяжкой, непосильной задачей? Каким образом постоянное переключение туда-сюда в рамках одной рабочей копии (котеночка жалко) экономит время? И это не считая того, что обычно конфиги надо менять (вручную, да), и не дай Бог используется база данных со слегка несовместимой схемой: украл, выпил — в тюрьму замотал в дамп, размотал, запустил! Романтика!

две рабочии копии.

«две рабочих копии».

Все равно вы время ото времени чаи гоняете на работе. Не ви...

Пожалуй сознательно пропущу это.

Кроме того, если известно, что есть N веток софта, в которые по желанию левой пятки или по факту инцидента надо коммититься, то разумно загодя держать по working copy каждой поддерживаемой ветки.

Для меня разумнее иметь систему контроля версий, которая позволяет дёшево переключаться между ветками и легко мёрджиться (привет git, hg). Избавляя о лишних заботах о настройке конфигураций и их поддержке.

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

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

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

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

Я что-то пропустил или изготовить патч даже между несколькими ревизиями с последующим применением в другой копии стало вдруг тяжкой, непосильной задачей?

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

Думаю это всё уводит беседу не туда.

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

«две рабочих копии».

почему? я думаю «две рабочие копии» правильно.

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

Ага, так и записываем. С проектами, которые имеют одинаковые по названию и разные по содержанию конфиги, дела не имели. С проектами, которые в различных поддерживаемых ветках работают с несовместимыми базами данных, дела не имели.

Думаю автор статьи в курсе этого, а факт того, что «нужно как-то сохранить текущую работу» остаётся фактом.

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

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

почему? я думаю «две рабочие копии» правильно.
сделать кого-л./что-л. — винительный падеж. Проверяем:

сделать (кого/что) две (каких) рабочих (кого/чего) копии.

Ага, так и записываем. С проектами, которые имеют одинаковые по названию и разные по содержанию конфиги, дела не имели. С проектами, которые в различных поддерживаемых ветках работают с несовместимыми базами данных, дела не имели.

Сомнительные выводы.

сделать кого-л./что-л. — винительный падеж. Проверяем:

сделать (кого/что) две (каких) рабочих (кого/чего) копии.

нашёл правило nekin.narod.ru/...th/numerals.htm, читать с «И без того сложные», вобщем я был прав, сложная штука русский язык

1. ну хоть один-то раз все равно по-любому это сделать нужно. А потом cp -R.
2. no comments.
3. почему? любая более менее адекватная IDE и сорц контрол поможет сделать патч и применить к другой ветке. Или через сервер пойти (кратко-живущий бранч).

Множественные рабочии копии часто полезны, иногда очень. Поработайте в IntelliJ IDEA с более-менее крупным java проекте и постоянным переключением между production/staging/trunk и переподсасыванием их зависимостей.

1. да
2. ?

3. угу, но это не безболезненный путь, тем более через сервер и коротко-живущий бранч.

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

Могу лишь сказать «не часто полезны, но иногда очень». У всех разный опыт, конечно когда-то полезны, когда-то нет. Спасибо, но на java не хочу работать =), я прекрасно работаю в проекте с переключением между production, qa-staging, pre-staging, dev, just-ci и ещё куче веток, DVCS мать его так и нормально написанные миграции для DB. Это раз уж мы начали рассматривать частные случаи, вместо оригинального топика.

Почему-то автор не учавствует в обсуждении своего топика.

Я верно понимаю, что разработчики уставшие перебирать тонны унылого legacy кода с миллионом баг бросятся на «очень занимательный challenge» покрытия всего этого чуда тестами? Сверхоптимтистично... Это занятие будет даже скучнее багфикса

Блин,как знакомо. Как вариант-относиться к этому философски, расслабиться,и получить удовольствие

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

Два совета на выбор: «Работает — не трогай» или «Лошадь сдохла — слезай!» («Riding a Dead Horse») www.tysknews.com/..._dead_horse.htm.

Так где решение следующего?

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

это все ещё в силе касательно тестов и всего. Решение не предложено.

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

P.S.: «с разработчиками и QA» — из контекста больше похоже что имелось ввиду «с разработчиками и тестировщиками». Просто интересно стало, вы знаете разницу между QA и тестировщиками?

... Решение не предложено.

Так решением было предложение при правке багфиксов в добавок покрывать код тестами. Или я как то не так прочел? =\

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

Решение:

Что делать? Надо как-то ловко сделать так, чтобы ошибки находились тогда, когда разработчик еще в контексте проблемы. ...

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

Просто интересно стало, вы знаете разницу между QA и тестировщиками?

Скорее всего догадываюсь, что она есть, а википедию открывать неохота :). На практике видел и работал только с тестировщиками, которых все называют QA engineer. Больше чем в одной компании (да и, пожалуй, стране).

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

Ба-дум-тссссс.....

ИМХО успех проекта. Счастливые HR-ы берут счастливых девелоперов на очередной багфикс.

проходят годы .....

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

Бред какой-то.

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

Serhiy Kalinets преобретает статус баг-киллера номер один. Все солидные фирмы уже давно доводят до ума проекты в Украине. Serhiy Kalinets выбирает, каким стартапам давать ту самую разросшуюся и отмасштабированную команду во главе с Serhiy Kalinets.
....
Бред какой-то.
Очень хорошо, что автор комментария сам себе и ответил :)
Напомнило этот анекдот:

sniff-tales.livejournal.com/26981.html

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

Напомнило этот анекдот:

Неудивительно, это же я его придумал )

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

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

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

Вывод, надо забить на качество и искать лохов. Лохи! Лохи! И только лохи спасут Украинский ИТ!

Интересный пост, но неожиданный вопрос в конце.

Если работа не интересная, то в наше время найти новую — очень просто. Если не хочется искать новую — значит работа интересная.

Теперь по существу.

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

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

Все это приправлено постоянными стрессами — фиксы непростые и нужны на вчера.

Надо пересмотреть что-то в менеджменте проекта, это ошибка менеджмента или первоначального договора с заказчиком.

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

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

Команда в унынии, люди активно смотрят по сторонам и примерно половина решительно настроена уходить.

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

Суть вопроса — что делать

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

Однако, из области советов «со стороны».

1. Наймите _опытного_ QA менеджера, которому приходилось разгребать такие завалы. Если не можете взять на работу — просто воспользуйтесь услугами консультанта (см. ветку dou.ua/...ums/topic/5208 . У нас есть опытные специалисты, начавшие свой бизнес и они часто не прочь подработать себе на очередной стартап. Заставьте HR отдел хорошо поработать — если они звонят и предлагают им работу тестера раз в 3 дня, то пусть попробуют смотреть несколько шире.

2.

И если вам ВНЕЗАПНО сообщают, что есть новая бага и нужно стремительно ее начинать фиксить, то придется потратить какое-то время, чтобы на ней сфокусироваться.

это путь в никуда. Пусть клиент хоть бомбу покупает, но менеджер — на то и менеджер, чтобы дать людям нормально работать. Срывать с одной задачи на другую — это признак, простите, бардака в разработке. Если клиент, по вашим словам, большой, то команда — никак не 1.5 человека. А значит мы можем позволить 20-30% команды делать не самые актуальные задачи просто потому, что хотим сохранить хорошую мину при плохой игре — а в результате, _дать людям нормально работать_. Кто осободился — делает горячую задачу.

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

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

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

В отличии от автора статьи, у нас шла инициатива снизу.. а не сверху (от менеджмента). Менеджмент был прав в том, что не мешал.

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

Еще,

Не знаю — не знаю, если переработки я бы уволился в любом случае.

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

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

В отличии от автора статьи

Тут скорее «от ситуации, описанной автором статьи». В моих проектах такого не было еще. Везет наверное :)

Напоминает ситуацию из «Влюблен по собственному желанию» с Янковским, когда он перед токарным станком убеждал себя, что он властелин металла, и не вытачивает болт, а покоряет стихию :)

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

Тем самым будет удовлетворена потребность енд-юзером в бастром фиксиньи багов и парарлельно система будет рефакторится с целью приблизить количесвто багов максимально к нулю.

Это означает просто удвоить персонал. Кто будет «успокаивать» «вчерашние» требования?

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

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

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

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

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

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

Зарплата не может мотивировать, даже если она большая, но может демотивировать, если она маленькая...

Дело в том, что есть люди, которые знают, чего они хотят. Часть из них хочет денег. На таких здесь и расчет :)

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

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

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

Можно, но это бессмысленно. Платить нужно не тем, кто больше кричит, а тем, кто лучше работает. Это мотивирует и тех кто хорошо работает, и тех, кто захочет работать лучше.

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

Наконец, провести брейнсторм и root cause анализ. Из информации в статье складывается впечатление, что неверно выделены и проблема, и пути её решения... но информации о проекте маловато, чтобы утверждать это с уверенностью.

Ну и что, как там ваш солюшен, заработал? или это пока ещё только идея?

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

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

На самом деле это ж кейс :) Мне задали вопрос «на подумать», ну а я изложил свои мысли по этому поводу. В моих проектах как-то все проще.

Написать модульные тесты на готовое приложение, которое не было спроектировано с учетом этого самого модульного тестирования — это жуткая кара для разработчиков и менеджера. Будет очень много, нет, ОЧЕНЬ МНОГО рефакторинга, который без модульных тестов, как известно — источник еще большего количества багов, даже если дизайн у приложения более-менее. В описываемом же случае в системе наверняка довольно много не самого хорошего кода, с ним еще сложнее.

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

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

Между тем, писать тесты в таких клинических случаях как раз и нужно. Только наверно начать стоит с интеграционных, которые бы тестировали целые фичи приложения (сервисы, UI) + пытаться автоматизировать функциональное тестирование QA. На данном этапе это наверно самое реальное, что можно сделать, т.к. это не потребует серьезного рефакторинга.

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

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

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

Мені чомусь зразу подумалось, що деви не зрозуміють challeng-а і тести будуть писатись по такому принципу: s.developers.org.ua/...eca87970b_r.jpg

А ще, мені здається, цей топік прекрасно ілюструє підхід «стартаперів» з сусідньої теми про аджайл (хоча вона і про аджайл, але багато там сказано і про тести). Наговнокодити побільше і пошвидше, «знайти свою нішу» ©пижжено_у_антона, а потім фіксити цю рухлядь все життя і дивуватись чому девелопери довше ніж пів року не затримуються :)

Сделать быстрее != наговнокодить :) Так что я бы не обобщал. Можно выбросить неважные фичи и хорошо сделать лишь то, что нужно. Можно сделать прототип быстро и плохо, чтобы проверить идею, а потом переписать с нуля.

Важно просто понимать концепцию технического долга и чем он чреват для приложения и проекта в целом.

Сделать быстрее != наговнокодить :) Так что я бы не обобщал. Можно выбросить неважные фичи и хорошо сделать лишь то, что нужно. Можно сделать прототип быстро и плохо, чтобы проверить идею, а потом переписать с нуля.

Повністю згідний, але:
1) щоб викинути неважливі фічі потрібно посидіти і скласти список важливих фіч
2) розписати пріоритети для важливих фіч
3) подумати як же писати ці важливі фічі, щоб потім не опинитись у вище описаній ситуації
А це вже який-неякий процес :) Якщо перечитати коментарі у «аджайл» темі, то стає ясно, що «фаундерам» будь-який процес здається чимось надлишковим і таким, що шкодить «пошуку ніші».
Тепер якщо подумати, що проект — це > 200 тис. строк коду на початку + швидкий розвиток у разі успіху, то коли це все переписувати? Ніякий управлінець у здоровому глузді не буде «різати по живому» заради міфічних «покриття тестами та правильної архітектури» (з чим я абсолютно згідний, до речі).

Прототип — це з іншої опери. Прототипи пишуть, щоб показати потенційним інвесторам і першій аудиторії (тітка/дядько/сусідка_галя). А якщо прототип містить всі фічі і працює з живими користувачами в режимі 24*7, то який тоді він прототип?

* про 200 тис. строк коду: 1) це буде справедливо не для всіх, це я суджу по останніх проектах і тільки на .NET . Для якоїсь CMS на Python ситуація може бути кардинально іншою. 2) сюди входит все що пишеться по проекту, навіть NAnt скрипти

Було б цікаво почути якусь статистику з досвіду учасників дискусії

на .NET теж е CMS

Так щё у загали? Як буты топикастеру по вашому?

CMS просто для прикладу, сприймайте це як placeholder для будь-якого підходящого по змісту слова :)
Взагалі, мені здається, що потрібно прислухатись до цієї поради: dou.ua/...esnym-2/#175615

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

Та порада не враховуе видсутнисть простиру для манёвра. Це однаково як наняты ще одну команду.

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

В минулій компанії підхід «правильна архітектура + гуано_код» показав доволі непоганий результат. З часом ми переписали всі вузькі місця і збільшили test coverage до того рівня, коли більшість серйозних багів відловлювались на етапі коміту. Тут головне не розводити бардак в новому коді тільки тому що «нічого страшного не станеться, ми це потім перепишемо».

До речі, у нас від загального часу розробки виділяли 15-20% на покращення існуючого коду. Це теж відіграло свою роль.

«фаундерам» будь-який процес здається чимось надлишковим

Це виключно ваші особисті фантазії.

А про вас тут ніхто і не згадував, але раз ви обізвались... Покажіть мені, будь-ласка, в тій темі де саме ви виступаєте на стороні «за процеси в стартапі». Наприклад, ось цей ваш коментар dou.ua/...rything/#173439 говорить про підтримку топікстартера, який, між іншим, проти :) Чи ви уже настільки «записались», що і самі не згадаєте за що виступаєте?

Для чого мені витрачати час, якщо ти не хочеш нічому навчитись, а виключно довести що ти правий?

Ти правий, заспокойся. Наскільки саме правий — дізнаєшся коли вкладеш власні гроші в свій стартап.

Доповню.. hint: «процес в стартапі» буває не тільки процесом написання коду.

Шановний модератор, раз ви так ряно відноситесь до своїх обовязків і слудкуєте за «чистотою», то прошу вас видалити 1) ось цей коментар dou.ua/...esnym-2/#175639 як такий, що порушує п.1 і п.3 ваших правил, а також 2) dou.ua/...esnym-2/#175631 як такий, що порушує п.3

Звичайно ж, якщо ви не сповідуєте принцип «всі люди рівні, але деякі ’рівніші’ за інших»

ИМХО, мысли очень интересные... Явно видится желание выйти из непростой ситуации, зарекомендовать себя... то есть мотивация у менеджера есть. Только мне кажется, что эти мысли похожи на метания между одной хорошей мысли к другой. А решают ли они проблему? Проблема:

унылый багфиксинг

. Решение — сделать бакфиксинг не унылым. Правильно, народ нужно мотивировать. Вопрос — как? Сделав работу еще более сложной и добавив смежных задач? Вряд ли. Так они Вас еще больше мотивируют... Мне кажется самая распространенная проблема в подобных проектах — человек не видит результат своего труда. Баг пофикшен — ура, но всегда найдется еще 3 и так далее... Если о простых решениях — распределение работы и делегирование ответственности. Пусть каждый отвечает за свой участок работы, за свой модуль, программу, плагин, часть прагина — не важно. Чтобы человек видел, что его часть работы может быть лучше и постепенно он к этому продвигается. И мысли появятся как это сделать, и мотивация должна наклюнуться.

Еще более простой/гораздо сложнее путь — пресловутый Agile, если захочется, даже с прекладными технологиями. Если не захочется, то хотя бы — www.slideshare.net/...gile-management .

и как

унылый багфиксинг

перенести в Agile ? где и как тут будут спринты, демо, ретроспективы, относительно к багам?

Я же ссылку привел в пример. Я там не видел ни спринтов, ни демо, ни ретроспектив. Я про эджайл менеджмент, а не про прикладные технологии.

перенести в Agile ? где и как тут будут спринты, демо, ретроспективы, относительно к багам?
Від аджайла сам процес понурого багфіксінгу менш понурим не стане.

Замініть «фіксити баги» на «їсти гівно».

Так от, можна це робити спринтами зі щоденними літучками на тему, хто як їв учора й як збирається їсти сьогодні, а можна скласти детальний план і меню наперед на рік, а можна забити на процес і просто вкалувати від рання до ночі.

Результат буде один: всі наїдяться гівна. Зовсім не факт, що його поменшає.

Який же вихід з цієї ситуації(понурого багфіксінгу) пропонуєте Ви?

Звісно, можна й без аджайла, аджайл — це не панацея.

Як зробити багфіксінг менш понурим?

Не поверите, но я сейчас работаю на таком проекте :)
Весело, ггыы

Правильно, народ нужно мотивировать

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

а

человек не видит результат своего труда

на унылую физиономию влияет редко

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

Согласен на все 100%. Это обязательно нужно делать. Только результаты нужно уметь интерпритировать... Ведь что, как правило, в такой беседе люди говорят? Что «проект не интересный. Много багов... Я переделываю чужую работу, вот бы с чистого листа!» Ну если не про деньги. Но мы не можем лишить их багов или сказать писать с чистого листа... Человек долден видеть цель труда. Не хотите делить ответственность — определите другие цели... Не многим нравится работать просто потому что работаю и что-то зачем-то делаю...

В общем и целом это работает, пока тесты не стали обычной повседневной вещью для команды. Это забавно, ново и интересно. Когда написание тестов — это такая же обычная вещь, как и написание кода, ничего не меняется. Это всё такой же неинтересный багфикс.

Также я не понял поинт про уменьшение кол-ва багов, кот. находят пользователи за счёт написания юнит тестов. Нет я понимаю, что потратив большее время на анализ/рефакторинг кода и покрытие его тестами, вероятность _нахождения_ багов увеличивается, но в абсолютных понятиях проблему это решить не может, т.к. баги могут быть разного рода: юзабилити, неверное решение (т.е. вам кажется, что он оверное, а оказалось нет). Т.е. сокращение кол-ва багов за счёт большего времени потраченного на работу и анализ кода это разумный аргумент, но тесты лишь средство и даст именно _сокращение_, может это и имелось в виду, но just to be clear.

Challange сомнительный, несомненно это именно челендж, но интересно ли копаться в чужом коде? Приводить его в порядок, да ещё и в продукте, которые не ты развивал, не начинал и не видишь дальнейшего светлого будущего (добавления фич и т.п.) Вот что я думаю по поводу чтения плохого кода: twitter.com/...5620737/photo/1

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

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

1. Что такое «чужой код»?

2. Удовольствие и challenge — это немного разные вещи.

1. Забавно, «чужой код» — код который написан не мной (чужим, отсюда и название).

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

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

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

И я о том. Код не бывает чужим на проекте.

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

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

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

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

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

В том, что это скучно, и в том, что не в деньгах счастье.

Зато чудестно прокачивает перки «терпение», «внимательность», «сначала-думай-потом-говори-да» и словарь обесцененной лексики :)

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

Угу, именно это я и написал выше =)

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

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

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

вам, напевно, не попадався справжній говнокод, писаний азіатами (хоча і штатівські деви тим часом грішать), які заявляють «об’єктний підхід вдарить по перфоменсу» і ваяють неструктурований не розбитий на модулі код з таблицями в базі, в яких по 100-200 полів. а, і коменти в кожній стрічці типу «ініціалізуєм об’єкт» (наступна стрічка — ініціалізація об’єкта) «видаляєм об’єкт» (видалення об’єкта) і т.п.

намалювати особистісні портрети таких розробників — 1 день, і не побачити нічого цікавого: сидить собі, «патерни, інкапсуляція, код конвеншин, бест практайс — нє, нє слишал» (при чому я не вірю в те, що треба однозначно гнатись за всіма цими поняттями — просто людина хоч якось має розвиватись, не обов’язково все застосовуючи), клепає задачі як бачить і так десятки років на одному і тому ж рівні.

Маєте рацію, мені набагато частіше траплявся гівнокод, написаний любителями цікавих проектів. Їм вже нецікаво, а воно ще не працює. Або решето в плані безпеки.

Однак думаю, що навіть азіаткод, якщо він працює, можна ітеративно рефакторити. Це, щоправда, обійдеться недешево.

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

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

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

Як правило, розчищати наївний копіпаст на порядки простіше, ніж ad-hoc оптимізації, в яких кожен рядок гівнокоду невідомим чином впливає на решту програми, використовує недокументовані фічі й баги рантайму — там дійсно чорт ногу зламає. Але на такі оптимізації команда описаних вами мавпочок просто не здатна.

Детективы люблю читать. Мне легко придумать, что могло бы быть более интересным.

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

Именно. Стиль программирования с «паттернами» — влияние на неокрепшую чуть-пост-джуниорную психику разрушительное.

не хочу, но повторю мой ответ ниже — вы пишете глупости, никак не вяжущиеся с «sr. software engineer в ...»! Юнит, интеграционные, регресионные тесты ВСЕГДА уменьшают кол-во новых и старых багов реализации (грубо говоря кода) при добавлении нового функционала или рефакторинге. Запомните это как прописную истину! Утверждать другое, это как подписываться под словами «мне писать тесты было всегда влом, поэтому я отвергаю их полезность/надобность».

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

Т.е. сокращение кол-ва багов за счёт большего времени потраченного на работу и анализ кода это разумный аргумент, но тесты лишь средство

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

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

Давайте я лучше немного расскажу о себе, я с первого года работы проникся идеей юнит тестирования, усиленно вводил эту практику на первой работе, затем на второй и вот сейчас на третьей, около 4-х лет я пишу юнит и интеграционные тесты в каждом проекте в котором работаю, и не просто пишу, а тренирую людей это делать. Читаю по этому поводу лекции (restuta.net/...elopers-slides ). Некоторое время работал на Typemock, куда был принят после собеседования с Roy Oscherove (минутки тщеславия).

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

Суть того, что я написал в том абзаце было — уточнение, того, что написал автор в топике. Я забочусь, чтобы читатели правильно понимали применение этого инструмента. Т.е. уменьшить количество багов в коде покрытом тестами удастся, но никак не других типов багов. Часто создаётся ложная иллюзия того, что когда команда пишет тесты, то багов у них в проекте быть не должно или «тесты не работают», я слишком часто слышал такие фидбеки от менеджеров и других людей, которые ещё не поняли предназначения юнит тестов. Также мой опыт показвыает, что баги которые пользователи находят в приложении это (очень субъективно) 90% UI сторона, нежели server side. (которую тоже можно покрыть тестами, но уже не юнит, разве что сложныйе Javascript скрипты покрыть тестами на JavaScript тест-фреймворке, остальное это удел автоматизированных тестов).

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

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

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

Я не буду комментировать остальные участки вашего сообщения, т.к. надеюсь мы друг друга поняли и нашли корень miss communicatioin.

<offtop> Антон, ссылка не работает

Вот правильная ссылка:
restuta.net/...elopers-slides

(в предыдущем комменте был глюк парсера)

но тесты лишь средство

Що ніяк не означає, що ними користуватись не треба.

Навіщо вибирати хороші викрутки, якщо можна шурупи викручувати кухонним ножем? Це всього лише інструмент!

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

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

Писати тести для наявного проекту невимовно весело, якщо старий код просто не передбачав, що його будуть викликати з тесту, і якась функція, що на перший погляд всього лише повертає boolean, міняє стейт десяти об’єктів...

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

Веселуха мабуть дуже підходяще слово. А враховуючи, що писати модульні тести ДО чи ПІД ЧАС розробки коду досить непроста задача, то написання таких тестів для системи, що розроблялася роками буде:
1. вимагати відповідних знань та навичок, відмінних від тих, які треба для написання просто модульних тестів;
2. банально, часу, при чому часу набагато більше, ніж на написання звичайних модульних тестів

3. скільки займе часу покриття тестів величезної системи до рівня, коли баги перестануть доходити до кінцевих користувачів?

Со всем согласен, а на пункт 3 ответ «нисколько», юнит тесты не позволяют решить проблему наличия багов в приложении.

серьезно? вроде в подписи Senior SE, а такие глупости говорите...

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

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

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

Задача менеджера, во всяком случае в данном проекте, объяснить заказчику полезность рефакторинга и бесполезность багофикса. Это тотально. Говорить нужно языком заказчика (в том числе, но не исключительно, языком денег).

В целом кейс годный. Вот только legacy code бывает разный. Иной покрывать тестами, так переписать проще. И это не шапкозакидательство, а банальный опыт.

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

Согласен насчет риска, но в кейса речь идет о том, что затраты на «латание дыр» уже давно и прочно превысили все разумные пределы. И здесь экономически целесообразнее все-таки начать искать критические участки и устранять причины.
А просить прощения лучше не всегда, вопрос только в том, чтобы обосновать бизнесу необходимость технологических работ, в 80% случае грамотное объяснение способно решить 90% проблем проекта, просто объяснять никто не хочет/не умеет

Не знаю — не знаю, если переработки я бы уволился в любом случае.

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

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