принято )
Паша, Вы ж умный человек.
Делать ревью или нет, «покупать» еще 2 джуна, фиксить ли баги, рефакторить — просчитывается финансово.
Цепочка: ч/ч * на стоимость человека и так по каждому пункту.
Сравнили. Посчитали когда окупится выбранное решение. Реализовали.
Profit.
без метрик рассматривать просто нечегоУгу. Примеры метрик я приводил выше.
— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)
«какова вероятность встретить динозавра? — 50%. или встречу или нет.»
каждую на задачу обязательно должно было быть review от другого разработчика твоего ранга или вышеВот конкретный вариант. Без динозавров. Ну, разве что с «динозаврами» в виде древних кусков исходников.
Это точка зрения QA, которые тестируют методом черного ящика.Не только. Есть у меня в арсенале несколько толковых людей (реально толковых) который склонны нести подобную мысль в массы. Лучше пусть будет хоть что-то покрыто тестами, чем не будет покрыто ничего. Лучше пусть тест будет функциональным и покроет 5% функционала, но уже на эти 5% функционала можно опереться.
Без Unit не обойтись никакО, ДА! А вот если их нет и их внедрение долго и невозможно, а с первого раза еще и не получается потому что ... (о, боже, сколько тут разных вариантов) ... и нужно с чего-то начать...
Проблема в том что вы перед рефакторингом должны понять __все__ бизнес-сценарии, а не имея ни тестов, ни хорошей спеки (что как правило является проевлениями гуано-проектов), вы не сможете покрыть все сценарии.И это чистая правда! Значит вероятность подрыва растет.
Pavel Kruchina предлагал говорить не про абсолютные значени, а о процентах и тенденциях.Да нивапрос. Метрики то у всех разные )
— Какой нормальный уровень (%) соотношения «шума» и фич?1/10.
— Какой процент от затрат времени должны занимать мероприятия, направленные на поддержание скорости разработки (code-review, рефакторинг)Нет ответа. Было несколько практик. И несколько практик было успешных.
— Какой подход эффективнее и насколько: постоянный рефакторинг (каждый месяц) или рефакторинг при падении разработки на критический процент.
— Какой процент падения эффективности разработки является критическим (требует немедленно переходить к рефакторингу)Никакой! А иногда любой. Но я больше склоняюсь к варианту никакой. Сначала разбираемся в причинах падения эффективности. Да может ребятам банально в отпуск нужно. А не... тут другая причина. Просто з/п не привязана к доллару, а курс вырос и у ребят пропала мотивация. Стали медленнее работать. А у команды из
---
Дак о каких процентах и тенденциях может идти речь, если мы уже перешли на цифры, не привязав их к конкретным случаям?
PS
Как я предупреждал выше — это мнение конкретно взятого человека и оно может (и должно) отличатся от любого другого мнения любого другого конкретно взятого человека (или группы людей).©
Для рефакторинга нужно покрытие тестами, для плохого проекта это принципиально невозможно покрыть тестами все места, которые будете менять.Но есть нюанс...
Отличный комментарий! Однозначно плюс.
Сейчас попробую частично со своей колокольни «фонариком посветить».
Первое. Какой бы крутой не был код, какие бы крутые спецы не работали на проекте, как бы круто его не вылизывали/рефакторили/переписывали и.т.д. — успешность или не успешность проекта определяют клиенты. Да. Бабло! Если этого понимания нет — поздравляю, вы пилите yet another фича-в-себе. Круто вылизанную, но нафиг никому не нужную.
Но тут, как я вижу, понимание клиента во главе есть.
А значит есть и построенная цепочка клиент -> функционал -> задачи -> (yet another profit ex. refactoring).
Вот тут и подходим к вопросу эффективности.
Нужно мерять. Что мерять? Как мерять?
Дальше будет ИМХО, которое может идти в разрез с любым другим мнением. (если что — я предупредил)
Первое — меряем маркетинг(!). Посетителей, клиентов, продажи, конверсии, затраты и.т.д. Это основные показатели при принятии любого решения.
Дальше меряем производительность системы. Скорость работы скрипта/модуля, «отклик» базы данных, «отклик» API, количество обрабатываемых запросов в секунду, и.т.д.
А теперь меряем «эффективность команды».
Вот тут мерять можно от забора и до обеда.
— количество закрытых задач (для того чтобы правильно это мерять, должны быть правильные задачи, а не задача-простыня на +/-20 дней работы)
— количество баг-тикетов
— количество reopen тикетов
А что там у нас еще есть? (у каждого свое)
— среднее кол-во времени на типичную задачу
— % покрытия тестами
— стабильность тестов
— количество строчек кода (нет, не прикалываюсь. да, видел)
— количество коммитов в репу
и.т.д.
Под каждый продукт у каждой компании свои метрики.
Главное понимать что значит та или иная метрика.
Что делаем дальше? Реагируем на показатели метрик. Тех что написаны выше, или тех что написаны где-то в другом месте, или те что еще не написаны, но есть где-то в голове у руководящего состава.
Сразу говорю — реагировать нужно не на все. Но причину изменения понимать нужно.
Меньше коммитов? Ну и ладно. Просто мы избавились от микрокоммитов и пушим только готовые задачи.
Больше/меньше строчек кода? Больше баг-тикетов стало прилетать? Так мы весь месяц занимались тем, что выкатывали новый функционал и забили на поддержку.
Решаем каждое изменение метрики индивидуально.
Посему, буду краток:
Так вот, предлагаю о этих цифрах и поговорить.— 300
Как я предупреждал выше — это мнение конкретно взятого человека и оно может (и должно) отличатся от любого другого мнения любого другого конкретно взятого человека (или группы людей).
-Очень информативно и аргументированно. А главное ёмко и предельно лаконично.
требуется абсолютная культурность сотрудниковМожно потренировать их на игре в манчкина :)) Если небыло опыта этой игры — просто рекомендую для себя поиграть. Даже могу при желании пригласить поиграть в уютной домашней обстановке. Все равно все закончится «социальной неадекватностью».
Такие решения чаще всего (даже не так. читай НИКОГДА) не исходят от разработчиков, а исходят от инвесторов, владельцев бизнеса и.т.д.проведите консультации со сторонним системным архитектором и аналитикомКак это предполагается реализовывать.
И второе:
Т.е. мы сразу предполагаем, что в этой статье будет рассматриваться случай, когда все пропало?— Шеф, все пропало, все пропало! Гипс снимают, клиент уезжает!
Давайте я попробую помочь в ответах (в рамках своего опыта, разумеется, а не в рамках абстрактных идей).
Готов выслушать вопросы. Скажу какие методологии применяли и к чему это привело. (если будет что ответить) ;)
Рецепт универсальный: деньги + полномочия.
В теории, а на практикеАндерс Хейлсберг (просто оставлю это имя здесь)
Это 2 принципиально разных момента... «Неинтересно сопровождать» — это как раз проявление некомпетентности (инфантильности)В большинстве случаев — да. Согласен. Чаще всего проблема «неинтересно» на уровне квалификации разработчика. Гораздо реже — проблема на уровне квалификации менеджемнта.
Сторонний человек не будет обладать всей необходимой информацией о проекте для принятия решения.Если свои не в состоянии... Есть люди и компании, которые построили серьезный бизнес именно на такого рода консультациях. И первым этапом идет именно сбор информации.
Переписывание с нуля, как правило, просто не работает для проектов которые в продавшее уже давно.Но и контр примеры же есть: PHP (да, opensource, но было же), VOX, Magento (сейчас пилится вторая версия). Тот же facebook переписал интерфейс групп в
Везде (!) нужно смотреть конкретно по ситуации. А для того чтобы небыло
просто заипетесьможно переписывать модульно. Если вообще есть такая необходимость переписывать с нуля.
Что касается репортинга, не смотрели в сторону Vertica?
вточку!