Один из аспектов профессии разработчика — посвящение профанов в особенности процесса разработки ПО.
С. Макконнелл, Совершенный код
Цель этой публикации — поделиться опытом работы над проектом со сложной историей и тяжёлым наследием. После ухода из очередного т.н. «стартапа», я решил что хочу попробовать новых ощущений: enterprise, legacy, etc. Для этого взялся за работу над корпоративным приложением для транснационального концерна. Разработка на тот момент шла уже третий год, приложение пережило несколько поколений разработчиков, но стабильного релиза так и не было.
Полагаю публикация будет полезной:
- разработчикам принимающим аналогичное решение, чтобы взвесить за и против
- менеджерам «непростых» проектов, чтобы лучше понять причины и следствия технических проблем
- и, конечно, просто любопытствующим
Затрагиваемые в статье вопросы:
- Низкая компетенция разработчиков, и что с этим можно поделать?
- Какие аргументы убедительны в глазах заказчика для нефункциональных изменений в проекте?
- Почему работа аналитиков и QA очень важна с точки зрения разработки в частности и для проекта в целом?
Input
Что на входе? На собеседовании первого этапа я был заинтригован следующими подробностями:
- Используемая версия фреймворка за годы разработки успела устареть
- Релиза стабильной версии продукта за два года не состоялось
- Бизнес-сложность системы порой зашкаливает
На собеседовании второго этапа, с участием проектного менеджера и ведущего разработчика, я получил следующую порцию нюансов:
- У текущей команды разработки низкий уровень компетенции в используемых фреймворке, языке, тестировании, IoC, объектно-ориентированном дизайне, шаблонах проектирования и архитектуре
- Предметная область действительно непроста
- Заказчик убеждён что проблем нет
К моменту принятия положительного решения об участии в проекте, я не видел ни одного хорошего или надёжного места в нём: абсолютно всё, что мне удалось узнать, являлось признаками проблем. Именно это и подтолкнуло меня к положительному ответу =)
Резюмируя положение дел на старте, можно выделить следующие балластные категории, которые представляли риск для успеха дальнейшей разработки:
- Низкая компетенция разработчиков
- Низкое качество кода (вытекает из предыдущего пункта), большой технический долг
- Отсутствие налаженной инфраструктуры
- Отсутствие автоматизированного тестирования
- Отсутствие культуры приёмочного тестирования
- Отсутствие культуры версионирования, внесения изменений, деплоя
- Требования не стандартизованы
- Менеджерский долг перед заказчиком — сокрытие имеющихся на стороне команды исполнителя проблем, преувеличение успехов, новые обещания к старым долгам
Общий посыл, который бы я рекомендовал разработчикам, претендующим на роль «спасателя» (в должности сеньора, ведущего разработчика, техлида и т.п.): не врать и не бояться. Если вы застали проект в плачевном состоянии, это не значит, что люди, работавшие в нём до вас, считают так же. Во-первых: текущее состояние проекта во многом плод их усилий, людям психологически сложно воспринимать критику результата своего труда. Во-вторых: скорее всего, уровень команды, допустившей имеющиеся проблемы, не позволяет их разглядеть — для них объективно проблем не существует. В описываемом случае, банальные толстые контроллеры — содержащие всю бизнес-логику — считались приемлемыми. Отсутствие юнит-тестов — не воспринимается как что-то ужасное, если человек просто не знаком с модульным тестированием.
В подобной ситуации вам неизбежно придётся насаждать свои, лучшие практики в команде. Для этого есть два пути: эволюционный — обучить (в первую очередь собственным примером) имеющиеся кадры. Революционный — искать более компетентных исполнителей, а значит планомерно заменять команду.
Начинаем с тестов
Одним из первых моих мероприятий было подключение тестового фреймворка, помощь коллегам в запуске и написании тестов. Эволюция, конечно более гуманный вариант — не надо никого «сливать», тратить время и деньги на подбор более опытных (и вероятно — дорогих) специалистов. И кармически это гораздо полезней — делиться знанием. Но этот долгий путь. Если разработчик, достаточно зрелый, чтобы считать себя готовым к разработке корпоративных приложений за деньги, не освоил тестирование, что-то в его кривой профессионального роста пошло не так. Драма в том, что скорее всего, не выдержав новых требований, многие предпочтут найти новое место работы. Человеку свойственно идти по пути наименьшего сопротивления. В этом случае попытка обучить — пустая трата своего и чужого времени.
Если у вас нет в запасе лишнего человека-года, что более чем вероятно, для коммерческой разработки, то шансов плавно эволюционировать у малоопытной команды мало. Лучше сразу готовиться формировать новую команду, предъявляя к соискателям требования выше, чем было до этого. Да, увеличивая таким образом бюджет. И это не раздувание бюджета, это компенсация долга, созданного в прошлом менеджером: может в попытке сэкомить, может из-за недостатка опыта.
Перечисление технологических изменений, которые предстояло произвести, я начал с модульных тестов. Модульные тесты одновременно самая дешёвая во внедрении и сопровождении возможность для поддержания вашего проекта в порядке. И в то же время одна из самых фундаментальных. Начинать с тестов — хорошая привычка. С тестов можно начинать кодирование, использование незнакомой библиотеки или языка, постановку задачи, проверку реализации чего бы-то ни было. Тесты — это способ мышления, при котором вы, прежде чем сделать что-то, формально описываете результат. Если отточить этот навык до должного уровня, то получение любого результата не будет у вас вызывать затруднений, вы забудете про страх белого листа. И это касается не только программирования.
SVN -> Hg -> Git
Исторически на проекте использовался SVN. Мержи были делом сложным и ответственным, сопровождавшимся сакраментальным «не пуште пока в транк, сегодня деплоим». Коллеги по департаменту в других проектах использовали Mercurial. Около месяца мы пробовали эту систему контроля версий, но в итоге предпочли переход на хорошо знакомый и популярный Git. Как и ожидалось, большинство соискателей, при формировании новой команды, чаще оказывались знакомы с Git, нежели с двумя другими СКВ. Чем не повод для перехода?
CI & CD
Windows Server -> Ubuntu
Remote Desktop + manual update -> delpoy.sh -> Unix + Docker + TeamCity
Копии приложения для демонстраций и тестирования находились на Windows Server. Управление сервером и обновление приложений осуществлялось вручную, путём подключения к удалённому рабочему столу. Примерно пол-года мне понадобилось на убеждение менеджера, и, через него, заказчика, что обязательным предусловием выпуска в продакшн, должен стать перевод инфраструктуры на Unix. Параллельно с этим формальным обоснованием, в процессе поиска второго бэкенд-разработчика, я смотрел в сторону кандидатов владеющих администрированием LAMP стека. К счастью, нам удалось найти специалиста с хорошими навыками в Bash и Unix: в итоге он стал в команде на 50% разработчиком и на 50% билд- и интеграционным инженером. К выходу в продакшн у нас был полноценный CI и CD. Привет Rottenwood!
Это мероприятие, как прочие, не чисто техническое решение. Методологии и концепции разработки влияют на другие процессы, не забывайте об этом. Если менеджер привык руководить командой, для которой подготовка релиза сводится к «**як-**як и в продакшн!», недостаточно настроить агент в TeamCity. Вам придётся донести до менеджера осознание того, что «нельзя просто взять и «пофиксить» это за пять минут на проде до демо». Да, это будет на первых порах доставлять дискомфорт. Менеджеру понадобится месяц или больше, чтобы привыкнуть что деплой теперь происходит не по пинку, мгновенно, вместе с падением рабочего продакшена. Теперь это осознанная процедура, которая пусть занимает 10 минут, но гарантировано ничего не уронит, и даст предсказуемый результат на любом из серверов, сколько бы их у вас не было.
Для заказчика аргументами необходимости выделение на это ресурсов и времени послужили:
- Снижение простоя в экстренных случаях — благодаря Docker мы можем оперативно развернуться на любой виртуальной машине в любом датацентре.
- Мы можем поставить приложение вместе с образом и оно может быть запущено на любой машине (такой кейс тоже рассматривался) без участия со стороны команды разработки.
- Безопасность — изолированность контейнера с приложением от хост-машины, простота и надёжность Unix для сервера. Часть пунктов при прохождении приложением корпоративного security-аудита автоматически закрывалась.
- Родная среда для используемого приложением стека, шире набор применимых технологий для потенциальных фич. Большая лояльность разработчиков.
- Ощутимый прирост производительности без дополнительной конфигурации.
Eclipse / NetBeans / Trial WebStorm / Brackets -> PhpStorm
Другим важным мероприятием стала организация приобретения для команды лицензии на PhpStorm и настройка единого стиля форматирования в соответствии с PSR. Я считаю любая организация может (и должна) обеспечить работников нормальными орудиями труда. PhpStorm и WebStorm сейчас лидирующие, на мой взгляд, IDE на рынке по поддержке PHP / JavaScript / TypeScript. Хорошая IDE существенно способна повысить как личную эффективность программиста, так и команды в целом — легко внедрить посредством настроек единый code style и разные полезные «примочки» для работы над проектом.
Devprom + Excel + *.jpg-> Jira
Этот переход, пожалуй оказался самым эпичным и долгожданным для нас. Исторически, использовался Devprom. Если в двух словах: никому не рекомендую эту систему. Для меня было откровением, что платное ПО может быть настолько низкого качества! Случайным образом система могла зависать, падать, содержала откровенные уязвимости. Каждый апдейт, помимо патча нескольких SQL-инъекций (и добавления новых, судя по частоте обновлений) привносил новшества в расположение элементов GUI, так что привычные уже сценарии использования приходилось осваивать заново.
Поскольку система управления проектом — краеугольный камень процесса планирования и разработки, использование «забагованного» и нестабильного решения сказывалось на всех остальных процессах: люди ленились заводить баги в трекере (это было сложно и долго), при планировании наполнение бэклога итерации превращалось в пытку на целый день, задачи терялись, инструменты аналитики и оценки было проще не использовать, менеджеры стремились при любой возможности протолкнуть в работу что-то в обход трекера. Таким образом используемый инструмент явно наносил вред нашим процессам, согласитесь это ужасно.
Благодаря Девпрому и изобретательности привычных к нему менеджеров, я наблюдал некоторые альтернативные способы управления:
- Работа по картинкам — после тестирования на выходе имеем папку со скриншотами, названными в соответствии с приоритетами. Разработчики весело хватают понравившиеся картинки и «фиксят» их, перекладывая картинки в папочку Done. За попытку создать на каждую картинку задачу в трекере можно было получить по рукам.
- Email-driven managment: в рассылке между членами команды на протяжении от нескольких дней до недели ходит письмо в таблицей высокоуровневых «фичей». Инициатива использовать доску трекера для оперативного управления разработкой — наказуема.
- Excel planning — составление бэклога и оценка при помощи легендарного табличного процессора.
Трекер задач — не менее важен в разработке чем IDE. Это краеугольный камень процесса разработки: в нём должна начинаться и заканчиваться любая активность в проекте. Нет задачи — нет кода. Jira, возможно лучшее из решений для коммерческих организаций на рынке.
PM-level
Если разработчик осуществляет оперативное управление в команде, от его решений может зависеть многое. Его выбор определяет успех или провал реализации отдельных частей продукта. Конечно, это наиболее актуально для небольших команд: 2-4 разработчика, тестировщик, аналитик. Пропорционально увеличению количества разных специалистов — вводим архитекторов, администраторов, QA-отдел — надо полагать, степень персональной ответственности отдельного участника процесса снижается.
Но не забывайте, что есть как минимум два фактора, которые вы, будучи техническим специалистом, на которые у вас нет прямого влияния. При этом от них прямо зависит сама возможность успеха проекта:
- Общий бюджет проекта и, соответственно, штатное расписание. Нельзя написать конкурентно-способный аналог приложения, если у вас в штате на порядок меньше специалистов. Дальше прототипа, на энтузиазме ваш «стартап» не улетит.
- Деятельность стоящих перед вами в пищевой цепочке — заказчика и бизнес-аналитика.
Если менеджер проекта на вашей стороне и может выбивать у вышестоящего руководства (или заказчика, в зависимости от структуры вашей организации) дополнительные расходы, если менеджер способен отстоять перед заказчиком важность необходимых нефункциональных изменений в проекте и процессе — у вас есть шансы на успех. Остальное зависит от вашего совершенства.
Если менеджмент не готов прислушиваться к команде разработки, шансов на восстановление — нет. Вы не можете прямо влиять на решение вышестоящего, или сменить руководство проекта. Но вы должны сделать всё возможное чтобы вас услышали, если не хотите отвечать за чужие ошибки.
Dev-level
Если ваш опыт разработчика подсказывает что у проекта есть проблемы, например банальный технический долг, вы можете кинуться грудью на амбразуру рефакторинга… И погибнуть, поскольку остальная команда будет успевать «говнокодить» из своего пулемёта большее количество строк в минуту, чем вы сможете физически отрефакторить и покрыть тестами. Абстрагируйтесь от самой разработки, посмотрите на процесс с высоты птичьего полёта: обзоры кода, защищённые ветки и пул-реквесты, инструменты статистического анализа кода в вашем CI — есть множество инструментов позволяющих предотвратить распространение проблемы. Гораздо важнее устранить причину проблемы, устранение симптомов — дело вторичное. И не факт что у вас хватит времени на второе, с большинством legacy придётся жить ещё долго. Главное предотвратить метастазы.
Иногда ошибка действительно в генах. Тогда лучший способ — отсечь некачественный генотип от вашей популяции и заменить его свежим образцом с необходимыми доминирующими признаками.
После года рефакторинга, мне кажется, что порой стоит оценивать разработчиков не по большому количеству принесённой пользы (функциональности + соответствующей кодовой базы), а по минимуму оставляемого вреда, в виде технического долга и неподдерживаемого, или не тестируемого кода. Конечно у вашего менеджера будет альтернативный взгляд на реальность. Но реальность разработки такова, что «запилить фичу» практически любой сложности для среднего разработчика не составляет труда. Гораздо важнее в средне- и долгосрочной перспективе чтобы это добавление не ухудшало архитектуру, сопровождалось не хрупкими и понятными тестами, было спроектировано с оглядкой на принципы SOLID. В этом отношении, я предпочту одно senior'a двум middle'ам и двух middle'ов четырём junior'ам. Чем длиннее дистанция, которую предстоит пройти вам и вашему продукту, тем важнее данный тезис.
Увы, собрать достаточно сильную команду в приемлемые сроки почти никогда не удаётся, даже обладая необходимым бюджетом. Квалифицированных специалистов даже в самых распространённых технологиях и фреймворках катастрофически не хватает. Построение процесса разработки на промышленном уровне поможет вам компенсировать это. Используйте возможные утилиты и техники для анализа и контроля качества кода. Поставив за отлаженный конвейер среднего или начинающего разработчика вы получите более предсказуемый результат и планомерное развитие, чем дав волю «коммитить» в мастер энтузиасту с горящими глазами. Ваша задача должна состоять в организации стабильного процесса и облегчении встраивания в него участников, а не героической ликвидации последствий не менее героических лихих кустарных решений.
Analytics
Если вы видите, что бизнес-аналитик скидывает в разработку сырые требования — не включайте фантазию и не начинайте кодирование. Составьте список вопросов и всех конфликтных мест и отправьте ему письмом. Или обсудите вместе над распечаткой все сомнительные моменты. Кодирование же стоит начинать тогда, когда у вас на руках есть настолько определённые требования, в утверждённом аналитиком файле, что задачу по их кодированию можно делегировать любому разработчику. Я считаю что идеально поставленная задача по разработке, кроме ссылки на релевантные требования, не должна содержать никакой «бизнес-логики», в крайнем случае высокоуровневое описание используемых шаблонов проектирования, если назначаемый разработчик ещё не знаком детально с компонентами системы, где предполагается внесение изменений.
Банальная истина, которой мы ежедневно забываем: люди склонны полагать свои мысли очевидными. Несмотря на средний высокий IQ в нашей отрасли, телепаты, увы, всегда в отпуске. Если вы войдёте в режим телепата и сделаете за аналитика его работу, то вы окажетесь виноваты в следующих грехах:
- С вероятностью близкой к единице, задача отнимет у вас времени больше, чем вы планировали. Ведь давая оценку, разработчик всегда озвучивает время на кодирование. Наиболее опытные из нас могут заложить риски отладки, тестирования, сопровождения документации и т.п. Но я сомневаюсь что даже лучшие из разработчиков способны точно прогнозировать время необходимое им на работу в качестве бизнес-аналитика. Аналитик не будет за вас программировать. А за превышенные сроки отвечать вам.
- Вы будете ответственны за все ваши фантазии, поскольку попадая в реализацию, они остаются не описанными в требованиях и не согласованными с заказчиком. Потом вам придётся долго убеждать всех, что это «не баг а фича», и в конечном итоге переписать этот код, с появлением реальных требований. Хорошо если вы же. Гораздо хуже наткнуться на недокументированное поведение и загадочный код с инициалами, владельца которых никто на проекте не помнит.
- Вы лишаете хорошего парня-аналитика возможности профессионального роста.
- Вы увеличиваете энтропию Вселенной, нивелируя выгоду от разделения труда.
Результаты устных обсуждений и переписки должны фиксироваться в конечных файлах с требованиями. Разработайте пакет документов, необходимых для адекватного планирования разработки и планомерного кодирования. Определите, какие форматы нужны для описания той или иной части системы. К примеру — для каждой экранной формы — может быть востребован следующий набор документов:
- Файл Visio с описанием функциональности, блок-схемами зависимостей между полями
- Файл Excel с правилами валидации и описанием типов данных для каждого поля
- Файл PSD для верстальщика, сопутствующие исходники (шрифты, иконки)
Такой пакет будет востребован не только на этапе разработки но и на следующих: приёмочное тестирование и разработка пользовательской документации.
Идеально было бы версионировать эти файлы параллельно с исходным кодом, чтобы понимать актуальное и требуемое состояние системы. К сожалению, с большинством сложных офисным форматов версионирование по аналогии с исходными кодами в Git не применимо.
Бизнес-анализ — это процесс, который важно формализовать и отладить не меньше чем саму разработку. И поскольку в отношениях разработчик-аналитик вы являетесь своего рода потребителем, ваш долг помочь выстроить эти отношения к обоюдному удовольствию.
Estimate it
Если менеджер вынуждает вас давать оценку задачу, по которой не был проведён анализ, ставьте верхнюю из возможных. Я, например, для таких задач использую значения Фибоначчи 13, либо 21, в то время как для нормально спланированных задач максимальное значение 5. Таким образом вы явно отражаете сложность, которая на данном этапе не может быть оценена точнее.
Другая крайность: установите минимальную оценку. Я использую 1, хотя многие оптимисты склонны давать обещания вроде «это можно сделать за 5 / 10 /15 минут». Да, безусловно есть правки, внесение которых займёт считанные минуты — не считая накладные расходы на взаимодействие с трекером, СКВ, документаций, тестами. Чтобы не огорчать менеджера тем, что «маленький» фикс занимает целый инженерный час, могу порекомендовать связанные мелкие правки объединять в одну задачу.
QA
Если вы получаете баг-репорт в виде «Починить форму на странице M» или одного скриншота с большим жирным знаком вопроса на безобидной, всем привычной странице, у вас вряд ли получиться исправить проблему. Формализуйте формат баг-репорта в соответствии с особенностями вашего приложения. Покажите и расскажите всем причастным к тестированию продукта как получить отладочную информацию необходимую для исправления, как формулировать. Не пытайтесь воспроизвести невоспроизводимое.
Другой нюанс: если в команде нет культуры тестирования, менеджер может полагать что ручное тестирование продукта — дело разработчиков. Ваша миссия показать ему простую арифметику: час разработчика как правило в N-раз дороже часа «ручного» тестировщика. За несколько полных дней тестирования имеющимися в команде разработчиками, легко сжигается зарплата зарплата выделенного тестера. Не забываем о простое разработки.
Тестирование — это процесс, который должен проходить планомерно и на регулярной основе, а не мероприятие вроде апрельского субботника. Если у вас в организации ещё нет QA, но вы знаете что это такое — приближайте его появление всеми доступными средствами. Пока нет квалифицированного приёмочного тестирования, команда разработки будет оказываться крайней во всех обнаруженных багах. Если тестирование носит нерегулярный характер, то баги будут находиться редко, зато много и не те. Это значит, что лавина аврально обнаруженных багов будет отравлять вам жизнь, и серьёзно вредить всему процессу разработки. В упомянутом проекте, выбивание штатной единицы для QA-специалиста и поиск подходящего кандидата у меня заняло около полутора лет.
Какие риски несёт нерегулярное и плохо организованное тестирование:
- Если тестирование проводится редко, будет казаться что версия ужасно «забагована», кровь-кишки-чума, а-а-а всё пропало, всё бросаем, все бежим на пожар!!1 — это срывает запланированную разработку, порой полностью парализуя её. Риск сорвать следующий дедлайн.
- Единовременное обнаружение большого количества багов, субъективно будет восприниматься, как то что их критически много в (казалось бы) готовой версии, что подрывает ваш авторитет разработчика.
- В случае с ручным, эпизодическим, слабо организованным тестированием баг-репорты будут низкого качества — а значит трудно-воспроизводимы, неактуальны, дублированы. Разработчики будут тратить дополнительные усилия и время на попытки их воспроизведение. По моему опыту могу сказать, что, зачастую, воспроизведение бага занимает времени не меньше чем исправление. И вдвойне обидно за потраченное время, если воспроизвести не удалось.
- Время на исправление большого количества багов сложнее оценить, по сравнению с регулярным ежедневным включением их в план. Если процесс отлажен, то, располагая метриками производительности тестирования и разработки, можно закладывать оценку исправлений в долгосрочный план, параллельно с остальной разработкой.
- Шансов «пофиксить» все ставшие известными за день до релиза баги в срок будет очень хотеться и менеджеру и молодым разработчикам. Но нет, так не бывает. Релиз будет либо ненадлежащего качества, либо сорван.
- Специалисты, выполняющие тестирование от случая к случаю (приходящие стажёры, проектные менеджеры, аналитики, сами разработчики (упаси бог!), кофе-леди, бухгалтера и сантехники) по определению: а). низко-эффективны в этой роли, поскольку она для них эпизодическая б). вряд ли будут действовать согласовано по какому-либо плану или сценариям в). дадут гарантировано некачественные отчёты
Помочь организовать здоровое тестирование — в собственных интересах разработчика.
Лучшее — главный враг хорошего!
Если вам повезёт и вы отладите разработку до идеального состояния, это не значит что менеджмент и заказчик автоматически станут счастливы. Во-первых, если PM, например, хронически прогибается под заказчика, беря без ведома команды обязательства по разработке больше чем физически можно успеть, то по мере роста стабильности и производительности разработки, будут расти и обязательства. Во-вторых, всегда найдутся не озвученные раньше проблемы, которые за не имением прочих получат самый высокий приоритет. Здесь схема такая: если раньше команда «факапила» стабильность и новую функциональность, то теперь заказчик может посчитать что приложение медленное и записать это как «эпичный факап», хотя изначально никаких требований относительно этого не существовало. Или вспомнить некую Pet-feature, ломающую всю имеющуюся логику и выставить её как must-have, а любые контр-аргументы посчитать непрофессионализмом и саботажем. Тут уже всё от адекватности заказчика и вашей менеджерской прослойки зависит. В таких ситуация остаётся только последовательно аргументировать, взывать к логике или искать более благодарную организацию.
Ещё один нюанс, о котором стоит помнить: по мере роста продукта, стоимость внесения изменений неизбежно растёт. Всегда. Все лучшие практики и прочие примочки, о которых написано выше, лишь уменьшают коэффициент роста этой стоимости. Таким образом, если человек не имел продолжительного опыта работы с командами, которые имеют хорошо поставленные процессы, и плохо эти процессы понимающий, он может сделать следующий вывод:
— было: никакого формализма, **як и в прод, пацаны быстро делали всё.
— стало: куча формализма, CI/QA-какой-то мешает быстро «релизить», пацаны медленно стали кодить…
При этом, не имея личного опыта работы в проектах различных размеров и командах, от него ускользает, что между «было» и «стало» находятся:
- большой временной период
- большой срез функциональности реализованной за это время
- не выплаченные долги из того что «было»
Поэтому, для таких персонажей важно не столько само наведение порядка — для не-разработчика, любые изменения, кроме функциональных, будут эфемерными и необязательными. Важно аргументированное обоснование с наглядными примерами: что, как и почему. Тот самый аспект профессии разработчика, о котором упоминает Макконнелл.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (76)
Temirkhan
06.09.2016 00:03+2Не знаю… Мне нравится следить за тем, что и где в логах «падает» и переписывать легаси во что-то поприятнее)
А потом приходит заказчик и говорит «надо сделать вот это», на что я отвечаю «мы делали нечто подобное в прошлый раз костылем. может сделаем нормально?», на что мне отвечают «нет, давай костылем. потом поправим»… *плачет*
Avenger911
06.09.2016 00:38+3Мы на проекте для себя решили, что в оценку задач по умолчанию закладывается устранение техдолга в затронутом коде. Это позволяет постепенно дорабатывать напильником проблемные места. К счастью до менеджмента удалось донести необходимость этого. "А почему так долго?" "Так техдолг рефакторингом красен." Могут правда снять задачу со спринта, если время не устраивает, и подсунуть какую-нибудь другую :-)
Temirkhan
06.09.2016 12:48Объем техдолга в проекте превышает объем задачи от трех до восьми раз… До внедрения скрам системы я пользовался Вашим подходом(
aknew
08.09.2016 20:42Мне еще попадались великолепные вводные от заказчика в стиле «будем использовать АААА, оно кривое и не очень подходит, но оно наше! А великолепно подходящее ББББ не наше».
samizdam
08.09.2016 21:29Если речь об используемом стеке или инструментах, то это как бы не его совсем компетенции, а Ваши.
aknew
08.09.2016 23:32Речь о стеке, формально — да, вы правы. Фактически же тебе просто говорят «у нас есть мега библиотека и ее надо прикрутить» т.е. задача изначально ставится не «реализовать такую-то функциональность», а «прикрутить такую-то библиотеку». Безусловно, это просчет менеджмента что такую задачу вообще поставили, но инженерам от этого не легче (доказывать что падает все именно из-за этой библиотеки пришлось долго и упорно, но в релизную версию мы ее таки не пустили). Более того, я сталкивался и с проектами, построенными по принципу «проект дело десятое, но глючное поделие заказчика должно быть в его основе», хотя это уже обычно демки разной степени сложности, а не боевые проекты (а вот «прикрутить библиотеку» было в боевом)
samizdam
08.09.2016 23:59Ну, выходит заказчик заказывает не функциональность а интеграцию с имеющимися решениями? Может у него бизнес на этом построен. Если так, то как говориться, кто деньги платит, тот девушку и ужинает.
aknew
09.09.2016 12:36+2Бывает и желание усидеть на двух стульях, когда в принципе у заказчика есть несколько формально независимых групп, но результат работы одних групп навязываются другим именно по принципу «наше», хотя этот навязываемый компонент ни является ни бизнесообразующим для заказчика, ни лучшим решением в своем сегменте. Важно чтобы заказчик не перескакивал грань между «давайте соптимизируем и будем использовать наш компонент т.к. мы полностью контролируем его и всегда можем уточнить у разработчиков» и «плевать на все, используем наше!!! Корпоративный дух!!!!»
А по поводу денег — согласен полностью, но я потому и отвечал не на саму статью, а на коммент в стиле «хотел сделать все как надо — начальство запретило». Статья-то как раз очень понравилась и совершенно по делу, жаль только не всегда это выполнимо из-за административных проблем (но этот момент ИМХО и не входил в рамки данной статьи, а то бы монография получилась)
Vestild
06.09.2016 00:07+3Чёрт! Вы описали почти идеальный план построения хорошей продуктовой команды из ничего!
terrier
06.09.2016 01:38+3Спасибо, отличная статья, очень удачно суммирует опыт «борьбы» с legacy и организационным бардаком. Особенно импонирует позиция автора, который при виде проекта с явными проблемами не плачет и не вешается, а берет и наводит порядок.
Zoberg
06.09.2016 11:04+1Хорошо, что у автора были какие-никакие рычаги влияния и к его мнению прислушивались. Ситуация была не совсем безнадежной =)
vanxant
06.09.2016 02:40+1Вот насчёт последней части, где про докапывающихся до фигни заказчиков.
Это совсем уже не компетенция разработчика. Ну, есть такие люди, и их много, которые всегда пытаются продавить скидку, хапнуть чуть больше нахалявку и т.д. И тут все вопросы к сейлзам — за что они вообще хлеб едят?
Хочет заказчик поиметь нахалявку производительность х2? Сейлзы должны тут же сказать «обязательно, всенепременно!» и выкатить допик с мотивированной сметой, которая увеличивает стоимость х2 и сроки х3. Но не доводить до абсурда, разумеется. Если заказчик увидел реально полезную штуку, которая почти ничего не стоит в смысле реализации (пресловутые 15 минут) — её можно и подарить, абсолютно бесплатно, за подписание актов, например)
Но, ещё раз, это совсем не инженерные вопросы. И на попытки сейлзов свалить ещё и это на программистов нужно отвечать предельно жестко в рамках допустимого.samizdam
06.09.2016 10:23+1Согласен. Именно это я имел в виду. С той разницей что в моём случае вместо продажников продуктовые менеджеры и аналитики берут на себя коммуникацию с заказчиком.
… если PM, например, хронически прогибается под заказчика, беря без ведома команды обязательства…
Rottenwood
06.09.2016 17:35+1Согласен с вами. Важно чтобы решение о цене реализации, в описанной ситуации, принималось не продажником и не заказчиком.
arodygin
06.09.2016 03:19+1Огромное спасибо за статью — плюсую и преклоняюсь перед вашей несгибаемостью. Сам в похожей ситуации, но уже опустил руки. У нас большой enterprise-проект на ASP.MVC (C#). Уровень легаси зашкаливает:
- SVN (на Git не переходим, т.к. генеральному нужно редактировать в репозитории некоторые input-файлы, а он не программист, кривая его обучения гиту — большая; на распил репозитория на «код» и «input»-файлы пока не соглашаются).
- Deploy ручной на AWS Windows-сервера через RDP.
- Низкая компетенция разработчиков — все пришли из мира desktop-разработки, никто не в курсе как работает HTTP в принципе, JavaScript пишется с трудом и в виде ужасных «спагетти».
- Бизнес логика в огромных контроллерах (есть экшены по 500 строк и больше).
- Генерация HTML местами жестко зашита в бизнес-логике.
- Само приложение реализовано stateful (например, entity, выбранный на предыдущей странице, сохраняется в сессии и на следующей странице выбирается оттуда, вместо передачи его ID через URL).
- ну и много чего еще...
Есть конечно и плюсы, и даже телодвижения в сторону улучшения и борьбы с legacy, но говнокод растет быстрее, т.к. (лучше и не скажешь):
вы можете кинутся грудью на амбразуру рефакторинга… И погибнуть, поскольку остальная команда будет успевать «говнокодить»
samizdam
06.09.2016 10:28+1Сочувствую.
Я так полагаю, что скупой платит дважды: рано или поздно игнорирование текущих проблем ударит по проекту и компании, и накапавшие по долгам проценты могут убить даже успешный продукт.
А проблемы с качеством кода, которые вы описали, на мой взгляд можно решить тремя способами: тесты, тесты и тесты. Без тестов не будет ни рефакторинга, ни SOLID и прочих прелестей, с которыми приятно иметь дело.
nkochnev
06.09.2016 07:09+3Эта одна из немногих статей за последнее время, которую захотелось прочитать полностью, спасибо автору!
Столкнулся с похожими проблемами на моей текущей работе около полутора лет назад, с того времени внедрил несколько подходов и технологий: git, IoC, централизованное логирование в elasticsearch, новый трекер задач. Несколько задач решил через микросервисы.
Кстати, на мой взгляд автор не сказал про важную часть — логирование.
Я долго убеждал в необходимости писать логи в одно хранилище с последующем оповещением ответственных лиц о произошедших событиях.samizdam
06.09.2016 10:34Да, логирование важно, безусловно.
Изначально в описываемом проекте логирования настроено не было, и проблем соответственно с его кривой политикой. А фреймворк в этом плане не мешает: при необходимости можно расставить точки где угодно и начать писать что угодно в любой момент.
igor_suhorukov
06.09.2016 14:26+1Плюсую поднятую тему!
Кроме логирования важен сбор метрик приложений при тестировании и в продакшен. Иначе все NFR, под которыми подписываетесь бессмысленны. Так же как и быстрое определение а что именно «тормозит» и не работает.
Для JVM решений описывал возможную реализацию в статьях:
- «DevOps: отправляем метрики и спим спокойно»;
- «Публикация логов в Elasticsearch — жизнь без регулярных выражений и без logstash».
sens_boston
06.09.2016 07:28+1Статья интересная, но непонятно, какова была ваша роль и насколько велики были данные вам полномочия? По моему опыту (пусть, возможно, и меньшего solution — не знаю, что вы имели ввиду конкретно под enterprise — так, скромный американский стартап до сотни человек, solution, приносящий в год единицы миллионов прибыли, и тайная главная цель, состоящая в продаже этого стартапа), для этого нужен как минимум уровень CTO (в случае стартапа), ну, или не знаю кого в вашем случае. В общем так, чтобы chairman компании, в порыве откровенности, сказал: "Слушай, даю тебе все полномочия, увольняй, нанимай кого хочешь (бюджет в таких-то рамках обеспечу), но мы должны зарелизиться в начале декабря! Даю тебе лично годовую зарплату в качестве бонуса" :)
Имея такие возможности, и соответствующие такой позиции знания, как надо: думаю, при наличии определенной доли удачи можно задачу решить. Если же речь идет о позиции с намного меньшими полномочиями, то сто процентов возникнут трудности и проблемы. Что поделать, если релиз менеджер знает лишь юникс-шелл, и его шансы (а главное желание) освоить MSBuild равны 0? Но при этом — он очень хороший парень, пришел задолго до вас, друг CEO, и работает уже в третьем стартапе с chairman-ом? Уволить (или даже критиковать) вам его просто-напросто не дадут — это конфликт в коллективе, и, вероятнее всего, расстанутся с вами. Или вы обнаружили, что уровень QA ниже плинтуса, они пропускают реально тяжелые showstoppers, но вместо это порождают кучу false reports? Но разогнать отдел — не ваших полномочиях. И так далее, и тому подобное.
Я полностью согласен с тем, что вы написали (и даже добавил бы еще) — например, обязательную тренировку разработчиков на code review и требование творческого и серьезного подхода к этому вопросу (просто ужас, что творится с code review — процедура теряет весь смысл). Ну и много еще чего можно добавить. Но применить это в реальной жизни можно лишь имея большие полномочия, твердые знания, умение убеждать начальство, а также твердый характер (вы решили уволить мать-одиночку, которую непонятным образом повысили в QA из рядового тестера-«кнопконажимальщика» до инженера).samizdam
06.09.2016 10:49+2Пришёл просто разработчиком. Проект по размерам средний, основные проблемы не в размере, а сложности предметной области и наследии. Начал по пунктам налаживать разработку: тесты, git, deploy. Предыдущий ведущий разработчик вскоре покинул команду. В итоге получилось что стал исполнять роль тим лида: проектирование, техническая постановка задач.
Полномочий, как таковых, увы кот на плакал — вся разработка и я формально в аутсорсе, весь менеджмент внутри компании, заказчик вообще в другой стране и департаменте корпорации. Поэтому решения о найме / увольнении достаточно оперативно и прямо принимать я не имею никакой возможности. Только последовательно отстаивая свою линии: повторять месяц, другой, третий:
— мало фронтенда надо усилить, засыпемся на новых фичах, бла-бла-бла…
— нужен выделенный QA, засыпемся багами с релизом, бла-бла-бла…
Глядишь, через пол-года корпоративная махина начинает тебя слышать и пытаться искать человека. И в таком духе. В общем долго и тяжело.
До того участвовал в стартапе, где мне был дан карт-бланш: набирай сколько надо людей, плати сколько надо чтобы работали. Конечно при таком раскладе эффективность построения команды на порядок отличается.
little
07.09.2016 14:51Не очень понял, почему вы взялись за эту работу, не имея на тот момент никаких полномочий?
Как вы собирались всё исправить при «живом» тимлиде, который этого не сделал, будучи просто разработчиком? Или же вам прямо на собеседовании ПМ и тимлид сказали, что готовы и хотят улучшений, что вы для этого и нужны, и что они, в свою очередь, будут вас в этом поддерживать?samizdam
07.09.2016 14:59На тот момент основной мотивацией взяться за проект было получить в резюме строчку с именем крупной компании и стабильное (в сравнении с чередой стартапов) место работы. Ну и применить на практике, теоритические, по большей части, знания о рефакторинге.
О том насколько сильно будет затронут весь процесс речи не шло.
Как мне представляется, никто из занятых в проекте на тот момент не представлял себе масштаб предстоящих мероприятий =)samizdam
07.09.2016 15:01Поддержка со стороны ПМ, в целом была, когда проектный график это позволял, за что ему спасибо.
Kioju
06.09.2016 10:36+1Спасибо. Залип в статью, оторвался только что б ссылку скинуть коллегам.
От себя хотелось бы добавить, что в нескольких местах где работал бизнес-аналитики занимаются максимум распределением задач по разработчикам и подготовкой версий в редмайне. Без бизнес-анализа =( В итоге приходится общаться напрямую с разработчиками сервисов, которые мы у себя юзаем вместо того, что бы запереть в комнате двух БА и добиться от них прописанной логики взаимодействия и описания параметров запросов =(((.samizdam
06.09.2016 10:51Да, сталкиваюсь с аналогичными проблемами. Аналитики пытаются излагать то как они видят реализацию, а не требования, при этом, зачастую скидывая анализ сырых требований на разработчиков. Ну и пытаются менеджерить, не обладая ни знанием, ни опытом.
Я это называю «работа не на своём уровне абстракций» =)
dipsy
06.09.2016 10:36Трекер задач — не менее важен в разработке чем IDE. Это краеугольный камень процесса разработки: в нём должна начинаться и заканчиваться любая активность в проекте. Нет задачи — нет кода.
При всём уважении и практически полном согласии с остальным текстом статьи вынужден констатировать, что там, где я работаю, и у меня лично в частности, трекеры задач как таковые не приживаются почему-то, ну никак. И я лично для себя полезности в них не нахожу, только лишние затраты времени, может потому что проекты не очень большие, 1-3 человека над одним трудится, может потому что нет конкретно «кодеров», а есть программист, который сам себе задачу ставит из очень размытых требований, сам с заказчиком общается и т.п.
А вот про тесты и квалификацию это прям в тему, как раз один коллега, высокооплачиваемый ведущий специалист, увольняется, оставив в наследство после себя горукода(ладно, пусть) кода, с которым явно придется повозиться, тестов 0 и все прочие прелести, вплоть до магик-намберз. Старайтесь сразу держаться от таких подальше, чтоб самому потом не вляпаться.samizdam
06.09.2016 10:59Если программист 1, конечно жиру поднимать, пожалуй излишне.
Если двое, то, в принципе они и экселем могут обойтись.
Но по мере увеличения разработчиков и потока задач, важно уметь найти след всех изменений продукта: кто, что, когда и почему. В идеале не должно вноситься ни единой строчки кода без соответствующей задачи в трекере.
Трекер инструмент управления командной разработкой, чем больше команда, тем этот инструмент становиться более необходим.
Насчёт высокооплачиваемого спеца без тестов — наблюдал аналогичное не так давно.
Опытнейший спец, любимец менеджеров по причине циничного отношения ко всему: надо — запилим. За день, хорошо, за день. За чес? Говно-вопрос. Ничто не вечно, конечно он в итоге ушёл. И бедный его коллега: оставшийся с наследством без тестов, на костылях и палках работающим.
Мы же пишем код не для того чтобы писать, а читать его =)ivanko
06.09.2016 11:40Мне кажется, что дело не только в количестве разработчиков, а в соотношении количества незакрытых запросов на человека за итерацию. Причем если число разработчиков растет, то и предел при котором нужен трекер тоже понижается.
DmitryMry
06.09.2016 11:59Не согласен здесь с вами по поводу трекера. Использую джиру и другие трекеры/системы, даже если работаю один. Во-первых, если у человека нет чёткого плана, то в большинстве случаев работа будет выполняться медленнее. Во-вторых, бывает полезно отслеживать затраченное на задачи время — от простого улучшения планирования, до, например, внеплановых отчётов на внезапные «а чем ты занимался весь месяц?». В-третьих, имея перед собой список задач, гораздо проще расставить их приоритеты. В-четвёртых, если есть список задач, то не будет «боязни чистого листа» — создаётся тикет, содержащий «общее» описание задачи, затем связанные тикеты, содержащие уже более точно выделенные вещи, затем тикеты, содержащие более детальные задачи и т.д., до тех пор, пока что-то абстрактное и непонятное не будет представлено в виде простейших задач, с которыми не возникнет никаких проблем. Я это говорю не просто как что-то гипотетическое — всё в полной мере «выстрадано» на собственном опыте. Конечно, бывает и такое, что заказы простейшие, на день или несколько дней работы — тут план вполне может в голове держаться (если область хорошо известна и задачи абсолютно никаких вопросов не вызывают — в общем, рутина). Но любой хоть сколько-нибудь серьёзный проект ощутимо выигрывает от использования трекеров/инструментов планирования и т.п.
P.S. Закончили ли вы уже тот проект? Сколько времени заняли все эти изменения и сколько всего времени проект разрабатывался?samizdam
06.09.2016 13:40Участие ещё не закончил, я в нём ~ год и восемь месяцев. Описанные мероприятия охватывают примерное первые полтора года.
Разработка проекта же велась с 2013 года, и будет продолжаться, эксплуатация формально началась с конца 2015, но по факту активное использование ещё не началось — по сути тянется фаза приёмки, чендж реквесты постоянно появляются.
svboobnov
06.09.2016 22:09Трекер задач нужен даже для одного разработчика.
Я вот 1Сник, работал в торговой компании (т.е. не софтверная компания, а отдел поддержки и разработки приложений из 3 человек + 2 сисадмина);
И что хочу сказать: мне в трекере ставились задачи (и на разработку и на правку багов), я оные задачи выполнял, и в конце недели вполне обоснованно мог сказать начальству: я потратил столько-то времени на это и столько-то на вот это, а вот эту критическую фичу я вообще сверхурочно реализовал, она хрупкая, и сейчас я поставил себе же задачу «причесать» эту фичу. Все довольны: управленцы видят сроки работ, пользователи видят, когда к их запросу приступят, QA видят, когда надо начать тест той или иной фичи.
dskozin
06.09.2016 11:28+1Отличная статья, спасибо!
Меня заинтересовало, как стало возможным повернуть эту громадину и сколько времени на это ушло?
Как боролись с сопротивлением коллектива?
У меня тоже наполеоновские планы были все сделать правильно, однако одно заинтересованное лицо считает что знает процессы разработки ПО лучше, и приходилось ему «сдаваться». В итоге технический долг вырос примерно до 4-5 программисто-месяцев, а я предпочел искать новую работу вместо дальнейшего увеличения этой кучи. Ибо не могу…samizdam
06.09.2016 13:50Коллектив разработчиков, по сути полностью поменялся в течении первого года на более адекватный. Не идеальный, но более соответствующий новым требованиям. Насколько я могу судить, если повысить планку, то люди склонные развиваться остаются и развиваются, те кто не может уходят сами. Это процесс не долгий, сопротивление скорее пассивное. Но коллектив, как частный случай социума склонен адаптироваться к изменяющимся условиях, порой и методом естественного отбора. Про время ответил выше.
В целом, я на многие вопросы связанные с инертностью большой организации стал реагировать более спокойно, чем раньше. Главное сигнализировать как можно раньше, регулярно и достаточно настойчиво. Время расставит всё на свои места, порой надо помнить что твоя ответственность ограничена тем, чтобы только указать на проблему, при этом возможности решить её в оперативном режиме нет из-за инертности / недостатка полномочий.
Shamov
06.09.2016 12:09Ничего не сказано о том, что делать с самой главной проблемой энтерпрайза. Всё время речь идёт о том, как повысить эффективность людей. Это имеет смысл, когда работы много, а людей мало. Тогда и разделение труда даст заметный эффект. И всё прочее более-менее релевантно. Но это совсем другая история. В энтерпрайзе же существует ровно обратная проблема. Как понизить эффективность людей таким образом, чтобы они были заняты всё время, выполняя небольшой объём работы? Важно, чтобы никто из тех, кто хорошо разбирается в каком-то отдельном фрагменте этой огромной системы, не ушёл из компании. Теоретически, компания даже готова платить им полноценную зарплату за просмотр смешных картинок из интернета, лишь бы они оставались на своём месте и были готовы немножко поработать при необходимости. Но ведь официально такое объявить невозможно. Это будет как-то не комильфо. Соответственно, нужно как-то занять разработчиков работой. Понятно, что с низкоквалифицированными дело обстоит проще. Их не требуется замедлять. Они и так работают достаточно медленно. Но что делать с высококвалифицированными, чтобы они не заскучали?
samizdam
06.09.2016 13:55Энтерпрайз энтерпрайзу рознь, видимо.
Мне скучать не приходилось, и всем работы хватало. Но, спасибо менеджменту, и с эффективностью особо никто мозг не насиловал.
Касательно автобусного фактора, есть хорошо известные методики: code review, ping pong, соглашения по кодированию, требования к внутренней документации, workshops. Если есть буфер на смешные картинки, то уж лучше имхо использовать его на указанные мероприятия.Shamov
06.09.2016 14:38Для себя я определяю энтерпрайз следующим образом. Это не просто разработка и поддержка большой системы, а такой процесс разработки, при котором компания получает деньги не столько за внедрение новых фич, сколько за то, чтобы всё работало как раньше. Новые фичи приходится делать очень редко. Гораздо чаще нужно просто фиксить баги. При этом под «гораздо чаще» имеется в виду то, что в среднем раз в две недели обнаруживается баг, который можно пофиксить за час. Так что, наверное, всё-таки нет. Не энтерпрайз энтерпрайзу рознь. Описанная мной проблема присуща энтерпрайзу в принципе. Это его дистинктивное свойство. Если такой проблемы нет, то тогда это просто не энтерпрайз в моём понимании, а всего лишь разжиревший стартап.
С автобусным фактором не всё так просто. Такие простые техники, как code review и прочее, помогают снизить риски незначительно. Люди, занятые в разработке, ценны не тем, что хорошо ориентируются в кодовой базе. Это скорее приятный бонус. Основную ценность образует их опыт работы в специфической предметной области. Например, кто-то в течение шести последних лет занимался реализацией взаимодействия системы с РЖД. Он может легко ответить на любой вопрос о том, как что работает в РЖД. Задокументировать все его знания невозможно. Кто-то другой пять лет разрабатывал модуль для взаимодействия, к примеру, с Почтой России. С ним то же самое. Без него нельзя не то что исправить баг… Нельзя даже понять, где баг, а где широко известная в узких кругах особенность поведения, которая на первый взгляд выглядит странно, но на самом деле была выстрадана годами опыта практической эксплуатации.
superyateam
06.09.2016 12:48+1Спасибо за статью! Отлично от А до Я все расписано. Такое ощущение, что в своей новой команде вы навели полный порядок.
Вопрос назасыпку: что посоветуете вместо связки Confluence + Jira + Bitbucket для небольшой команды (4-6 человек)? Перевели код на github, но баги там вести неудобно. Есть сторонние сервисы, типа Waffle.io или HuBoard, которые превращают GitHub issues в некое подобие Jira, но этого мало. Ну и плюс ко всему нет вообще никакой альтернативы Confluence. Jira/Confluence — отличные продукты до того момента, пока ты не начинаешь заниматься их администрированием и вот там начинается самый ад. Atlassian видимо не особо парится проблемами своих кастомеров… :(samizdam
06.09.2016 13:59Сам я эти продукты не администрировал, не слышал об особых проблемах с ними.
Кроме Jira работал в паре мест с Redmine, пожалуй его можно рассматривать как более легковесную альтернативу. Но, опять так по наслышке, сам не администрировал, проблемы с администрированием там не исключены.
Меня Attlasian, как пользователя вполне устраивает.
igor_suhorukov
06.09.2016 14:36Redmine когда я с ним работал отлично заменял и confluence и jira, но явно не подходил для доступа к вашему проекту внешнего заказчика. Авторизация и доступ были как мед — либо есть, либо его сразу нет. Решалось подобное заведением отдельного проекта для заказчика и переноса комментариев «из и в» в наиболее честный и полный трекер для разработчиков.
К тому же его раньше можно было упаковать с jruby и деплоить в java веб контейнеры, чтобы не разводить зоопарк с веб серверами и рантаймами.
DmitryMironov
06.09.2016 17:35Вместо Jira можно использовать TargetProcess, Trello
Вместо Confluence — нужно смотреть как именно вы сейсам ее используете, тогда можно будет что-то порекомендовать.superyateam
06.09.2016 21:18Используем Confluence для проектной документации. Много документов с иерархической структурой. Перекрестные ссылки друг на друга.
abbath0767
06.09.2016 17:35Мне понравилась в свое время YouTrack от JetBrains. На мой взгляд для маленьких команд — самое то
G-M-A-X
06.09.2016 14:09Вы молодец! :)
П.С.
О менеджерах:
Иногда приходит такой менеджер без пяти шесть и говорит:
— Заливай на прод, нету времени объяснять.
:)samizdam
06.09.2016 17:46+1Не проблема. Легким нажатием кнопки (за пять минут до шести можно успеть это сделать) в тимсити запускаем билд, в который входят установки зависимостей, сборка, юнит тесты, приёмочные тесты, тестовый прогон миграций на дампе базы с прода, автобекап перед выкатом на сервере…
Когда билд закончится (пол седьмого), я уже буду подъезжать к дому. Если не закончиться успешно — ничего страшного, просто упал билд, ну бывает.
В совсем крайнем случае бэкап предыдущей версии создан, процедура отката отрепетирована.
Утром всё можно на свежую голову поправить.
vyatsek
06.09.2016 14:55+1Примерно в таком же г довелось участвовать. Могу сказать что неправильные пчелы, делают неправильный мед. Процессы лишь слегка улушат ситуацию, ситуация изменила тренд, когда на проекте появились комптетентные люди.
У людей как и у меня не проходит желание «переписать все нафиг», но это не целесообрзно, по этому методично и планово как только сталкиваемся с проблемным кодом, его переделываем.samizdam
06.09.2016 22:16В том и профит процессов, что они могут помогать даже неправильным пчёлам делать правильный мёд. И привлечь компетентных людей, либо вырастить таких, проще имея отлаженные процессы.
git + docker — нельзя пофиксить что-то по горячему на проде — очередной билд затрёт
CI + автотесты — нельзя в продакшен выкатить нерабочую сборку
сбор метрик, CRAP, цикломатической сложности — можно автоматом заворачивать пул реквесты без должного покрытия или откровенный овногод и т.д.vyatsek
08.09.2016 14:04Они не помогают, они ограничивают залепить г-но :)
Это все равно что на слив поставить фильтр крупных фракций, да кусков больше не будет, но малопригодная жижа остается.samizdam
09.09.2016 00:05Я как идеалист и романтик, склонен полагать, что при достаточном количестве и качестве фильтров (продолжая вашу аналогию), а ещё и дистилляции (в виде код-ревью и парного программирования например) можно получить пригодную для питья воду из чего угодно =) Чем водококанал, насколько я знаю, успешно и занимается.
ivanych
06.09.2016 16:10+2Читал и завидовал. Либо у автора невероятный талант убеждения, либо автору невероятно повезло с руководством:)
Обычно такое провернуть просто невозможно — нет спроса и согласия сверху.
Мой «любимый» диалог в подобной ситуации выглядит примерно так:
Разработчики: Давайте наладим тестирование, это повышает качество.
Руководство: А вы пишите качественнее, вам и так платят кучу денег, ещё на тестировщиков тратить не хватало!samizdam
06.09.2016 17:52Конечно, многие вещи удалось завершить не без известного лимита доверия со стороны PM и периодов относительного затишья в графике проекта. Но, до идеала, как всегда далеко.
igor_suhorukov
06.09.2016 18:06В сложном технологическом проекте, придметная область которого близка команде, вполне можно покрыть почти все юнит и интеграционными тестами своими силами. А если QA как манна небесная окажется в команде, то ему достанутся высокоуровневые вещи: тест-планы и приемочные тесты для конкретных потребителей проекта, ближе к специфике их бизнеса.
ivanych
06.09.2016 18:15Суть проблемы не в то, что команда не может это сделать, а в том, что команде не дают это сделать:(
«Нет, не до тестов сейчас. Занимайтесь бизнес-задачами».igor_suhorukov
06.09.2016 18:31А вам за что деньги платят: за послушание или за эффективную работу?) Можно найти какой-либо баланс между работой над бизнес-задачами и улучшением QA автоматизации втихоря?
Один неявный плюс автоматизации про который часто забывает менеджмент — не разбегутся из проекта профессионалы от регулярного демотивирующего manual monkey testing.ivanych
06.09.2016 18:40+2> А вам за что деньги платят: за послушание или за эффективную работу?
За послушание.
> улучшением QA автоматизации втихоря?
Я как-раз об этом и говорю — в большинстве случаев спроса на качество нет. Разработчики извиваются ужом, чтобы пропихнуть качество в проект. Собственно, вся обсуждаемая статья как-раз об этом — об инициативе снизу. Хорошо, если эта инициатива находит понимание. Чаще — не находит.samizdam
09.09.2016 00:15+1Да, проблема качества почти везде актуальна, на QA многие экономят.
Но вот чтобы начать использовать TDD / unit testing не вижу возможных объективных организационных проблем (кроме отсутствия компетенции у самих разработчиков), было бы желание. Это чисто внутренний вопрос разработки, а на качество влияет очень хорошо. Начальство и знать не обязано, пишут разработчики тесты или нет.
TheGodfather
06.09.2016 17:35Ваша миссия показать ему простую арифметику: час разработчика как правило в N-раз дороже часа «ручного» тестировщика. За несколько полных дней тестирования имеющимися в команде разработчиками, легко сжигается зарплата зарплата выделенного тестера. Не забываем о простое разработки.
Позволю себе не согласиться с этим утверждением — хороший тестировщик должен иметь зарплату сравнимую с зарплатой разработчика, да, быть может, немного меньше, но уж никак не «в N раз». Ибо вклад в итоговое качество продукта вносят и те и другие, причем далеко не всегда можно утверждать, что разработчик — намного больше. Возможно, вместо того, чтобы нанимать мануальщика-«обезьянку» за копейки, лучше стоит взять сеньора, но быть уверенным, что он так же горит энтузиазмом, как и вы — и с обеих сторон (QA и девелопмент) качество будет непрерывно расти.samizdam
06.09.2016 17:53Смысл приведённого мной расчёта в том, что предполагается тестирование руками отнюдь не «хороших» тестировщиков, а наоборот, людей немотивированных этим заниматься.
А за автоматизацию QA — я обеими руками.igor_suhorukov
06.09.2016 18:09Веб автоматизируется selenium тестами на CI, может есть смысл делать больше приемочных тестов? Мануальщик может стать автоматизатором…
sumanai
06.09.2016 19:36Как я вас понимаю!
В текущем проекте (на php) на FTP каждый второй каталог или файл имеет старые копии с названиями типа %имя_файла%1, %имя_файла%2, %имя_файла%44, %имя_файла%.old, %имя_файла%_, %имя_файла%__…
Потихоньку разгребаю, переношу историю правок одного популярного движка в Mercurial (благо разработкой занимаюсь один, можно использовать более удобный мне инструмент, а не более популярный) но времени на это у меня мало((
vkushni
07.09.2016 17:57+2Согласен со всем с автором кроме того что касается unit-testing. Если код низкого качества то обычно методы с бизнес логикой по 100+ строк в которых делается все и вся. Писать юнит тесты на такие методы не имеет смысла потому что вы банально не можете предсказать состояние системы после его выполнения: данных слишком много или результаты слишком разнообразны. Другая причина — вы банально не сможете покрыть все кейсы использования этого метода. Даже хороший код, который пишется на основе существующего кода низкого качества не получится сделать лучше в силу обстоятельств. Поэтому мой список действий по улучшению продукта:
-) terminology (Терминология должна быть общей для того чтоб избежать недопомниманий на любых этапах разработки, + документирование например на wiki. Терминология может отличаться от сервиса к сервису но должна иметь описание по которому можно было связать два разных сервиса)
-) naming conventions (название классов и методов должны дублировать общепринятую терминологию, пардон, java specific: а так же package naming)
-) database (практика показывает что качество data access layer в первую очередь зависит от структуры субд. Новые обьекты СУБД ссылаются на уже существующие и не позволяют сделать новые фичи — «хорошо», изменение существующей схемы можно делать кардинально или итеративно, желательно «per feature»)
-) presentation layer (PL) > business logic layer (BLL) > data access layer (DAL) (выделение 3х слоев в серверном приложении это один из важных шагов на пути к качественному коду: single responsibility. Написание качественного DAL невозможно без улучшения схемы СУБД, BLL без DAL, PL без BLL)
Только по коду:
-) code formatter (в идеале должен лежать в git вместе с кодом и подхватыватся IDE)
-) static code analysis (в идеале должен быть интегрирован в IDE. Developer должен думать о качестве кода во время разработки, что позволяет приобрести полезную привычку вместо надоедливых e-mail от CI&CD )
Заметка манагерам:
-) програмеры часто концентрируют все внимание на решении одной задачи (что является прямой противоположностью с менеджерской работой), поэтому им не только лень переключать внимание на что-то другое а еще и тяжелее (уровень концентрации выше), поэтому нужно сделать так чтоб они не тратили свое внимание и концентрацию на что-то другое. Девелоперы лажают с билдами? — Выделите время на автоматизацию процеса. Девелоперы лажают с деплойментом? Упростите процесс, сделайте билды более тонкими а деплойменты более частыми. Девелоперы плохо тестят фичи, баги? Выделите время на написание чего-то что поможет упроситить тестирование как для девелопера так и для qa
sergeyns
07.09.2016 17:58У меня ощущение, что автор описывает не свой реальный опыт работы, а фантазии на тему как должно быть. Почему? В одном из постов выше есть правильный вопрос по полномочия «автора». Чтобы все это сделать, и нагнуть остальных сотрудников компании… полномочий хватит только у директора… или владельца (выбить бюджеты но новый софт, более грамотных сотрудников, лишать премий особо упорытых и увольнять особо сопротивляющихся и саботажников… еще много чего)
Rottenwood
07.09.2016 20:57+1Автор описывает свой реальный опыт работы. Описанные им фантазии удалось воплотить в жизнь. Менеджмент смотрит на результат, и если он достигается то кредит доверия к разработке растет, а затем может быть направлен на лоббирование управленческих решений.
sumanai
07.09.2016 21:49Всё это заняло более полутора лет, плюс ещё не закончилось. Так что всё может быть.
n43jl
Это хорошо, когда вы имеете возможность разгребать бардак, который творится. Столкнулся с ситуацией, что устроился в маленькую команду Java разработчиков (4 человека). Все 3 разработчика старше меня на 12 лет, опытные, но культура разработки не сходится с моей чуть больше чем совсем. Вообщем у нас 0 тестов (тестирование ручное), ручной деплой, смесь языков в виде Java в jsp. css — файлы и js файлы тоже JSP с вставками Java переменных. Вместе они работают около 20 лет, и ничего они слушать не хотят про deploy одной кнопкой или про тестирование — им это не нужно, и так все работает. Вообщем ищу работу :)
Singaporian
А им и не надо слушать это. Любое программирование — от бизнеса. Идите к тем, кто в этой команде считает деньги. И внятно и четко распишите плюсы и минусы. Кроме карт-бланша вы заработаете и авторитет — а на нем можно выехать очень далеко. А если вы не сможете расписать плюсы, то тогда обратный вопрос: а с чего вы взяли, что порядок и бэст практис лучше для бизнеса, чем то УГ, что есть?