Comments 12
Спасибо. Ценно то, что описание получилось компактным и структурным. Его можно брать за основу при формировании регламента.
Оставлять код чище, чем он был до тебя
Вот с этим есть сомнения. Например переворматирование прекрасно рушит annotate и потом не найдешь (по крайней мере без больших усилий) кто и зачем написал эту строку. Таск другой и как узнать бизнес логику оригинального таска? А уж смена названий переменных это потенциалльно конфликт у разработчиков (было пару раз на моей памяти).
Опять же QA могут быть сильно против ибо регресс. При 100% покрытии тестами еще так сяк, но зазеленить упавшее может потребовать долгого времени.
Спасибо за комментарий. Все перечисленные сложности актуальны, но есть способы их обойти
1. Необходимость смотреть полную историю изменений файла вместо blame/annotate — тут надо выбирать между простой историей изменений и согласованным стилем кода в проекте. Способа получить и то и другое одновременно я не вижу. ИМХО, польза от согласованного стиля более весома, поэтому мы делаем стилистические правки. В других проектах ситуация может отличаться.
2. Споры между разработчиками при смене названий переменных — симптом отсутствия общих соглашений о стиле кода, в которые входят и принципы именования. Такие соглашения нужно вырабатывать так или иначе, это залог эффективной работы команды. Как именно — вопрос сложный, можно ещё одну статью написать в поисках ответа ) В нашей практике, разногласия именования решаются на этапе ревью кода и это, как правило, не занимаем много времени.
3. Риск регресса важен, и именно он часто является ограничителем для такого рода улучшений кода. Если зона затронутой функциональности увеличивается, нужно одобрение на такое изменение от всей команды, включая QA и Владельца продукта.
1. Необходимость смотреть полную историю изменений файла вместо blame/annotate — тут надо выбирать между простой историей изменений и согласованным стилем кода в проекте. Способа получить и то и другое одновременно я не вижу. ИМХО, польза от согласованного стиля более весома, поэтому мы делаем стилистические правки. В других проектах ситуация может отличаться.
2. Споры между разработчиками при смене названий переменных — симптом отсутствия общих соглашений о стиле кода, в которые входят и принципы именования. Такие соглашения нужно вырабатывать так или иначе, это залог эффективной работы команды. Как именно — вопрос сложный, можно ещё одну статью написать в поисках ответа ) В нашей практике, разногласия именования решаются на этапе ревью кода и это, как правило, не занимаем много времени.
3. Риск регресса важен, и именно он часто является ограничителем для такого рода улучшений кода. Если зона затронутой функциональности увеличивается, нужно одобрение на такое изменение от всей команды, включая QA и Владельца продукта.
Бизнес-логику оригинального таска надо узнать из документа requirements, ссылку на который разработчик разместил в комментариях к коду, нет?
При опытной эксплуатации убедился, что разработка ПО в России «для госнужд» всё так же на стадии «тяп-ляп да побыстрее», главное хайп.
После ОЭ остался с резко негативным впечатлением… будем надеяться, что хоть когда нибудь ситуация изменится.
После ОЭ остался с резко негативным впечатлением… будем надеяться, что хоть когда нибудь ситуация изменится.
Пользу от устранения технического долга стоит формулировать в ключе пользы для бизнеса, иначе есть риск того, что задачи по созданию новой функциональности всегда будут считаться более важными.
КАК?
Через демонстрацию цепочки эффектов на те показатели, которые данный конкретный бизнес считает для себя важными. Попробую привести несколько примеров:
Качество. Устранение технического долга в важном модуле позволит повысить качество и снизить шанс возникновения регрессионных дефектов при внесении модификаций. Наличие плохо спроектированного/реализованного кода, напротив, гарантирует высокий шанс регрессий. При этом никакой QA-процесс не гарантирует 100% обнаружения дефектов. Значит, появление критичных дефектов, которые могут испортить репутацию компании в глазах широкой публики или ключевого клиента — вопрос времени.
Скорость разработки. Разработка быстрее всего идёт при использовании современных библиотек, правильных абстракций и т.п. Устранение технического долга в модуле, где планируется добавление новой функциональности, частично или полностью окупится при последующей разработке. Кроме того, доведение функциональности до требуемого уровня качества займет тем меньше времени, чем меньше дефектов и чем ниже риск регрессий при их исправлении.
Мотивация команды. Хорошие разработчики дорого стоят и их приходится долго искать. Если ситуация с техническим долгом плохая и нет тенденций к улучшению, мотивация разработчиков страдает. Для выполнения той же работы потребуется увеличение размера команды, а это дополнительные затраты на зарплаты и дополнительное время на ожидание найма.
Качество. Устранение технического долга в важном модуле позволит повысить качество и снизить шанс возникновения регрессионных дефектов при внесении модификаций. Наличие плохо спроектированного/реализованного кода, напротив, гарантирует высокий шанс регрессий. При этом никакой QA-процесс не гарантирует 100% обнаружения дефектов. Значит, появление критичных дефектов, которые могут испортить репутацию компании в глазах широкой публики или ключевого клиента — вопрос времени.
Скорость разработки. Разработка быстрее всего идёт при использовании современных библиотек, правильных абстракций и т.п. Устранение технического долга в модуле, где планируется добавление новой функциональности, частично или полностью окупится при последующей разработке. Кроме того, доведение функциональности до требуемого уровня качества займет тем меньше времени, чем меньше дефектов и чем ниже риск регрессий при их исправлении.
Мотивация команды. Хорошие разработчики дорого стоят и их приходится долго искать. Если ситуация с техническим долгом плохая и нет тенденций к улучшению, мотивация разработчиков страдает. Для выполнения той же работы потребуется увеличение размера команды, а это дополнительные затраты на зарплаты и дополнительное время на ожидание найма.
Есть соблазны отрефакторить без заведения тасков.
1) Я не уверен, что вытяну рефакторинг до конца. Т.е. попробовал сменить алгоритм — одно потянуло другое, входные данные по-другому надо генерить, и вот я уже 4 часа сижу переписываю всё на новый формат данных, и конца этому нет (а думал, что за час успею). Т.е. придётся переписать пусть не всю систему, но подсистему. И тут надо остановиться, откатить все изменения и дать проблеме побродить в голове. Через месяц может будет озарение, что надо заходить с другой стороны.
2) Есть некоторые идеи, которые не гарантируют улучшение. Например, заменить структуру в памяти с RB-дерева на B-дерево. То есть, думаешь, что выиграешь из-за улучшения локальности данных, а проигрываешь из-за большей O-константы в алгоритмах.
Т.е. таск надо писать в виде: «я попробую потратить часа 4, а если не пойдёт, то отложить на пару месяцев?»
1) Я не уверен, что вытяну рефакторинг до конца. Т.е. попробовал сменить алгоритм — одно потянуло другое, входные данные по-другому надо генерить, и вот я уже 4 часа сижу переписываю всё на новый формат данных, и конца этому нет (а думал, что за час успею). Т.е. придётся переписать пусть не всю систему, но подсистему. И тут надо остановиться, откатить все изменения и дать проблеме побродить в голове. Через месяц может будет озарение, что надо заходить с другой стороны.
2) Есть некоторые идеи, которые не гарантируют улучшение. Например, заменить структуру в памяти с RB-дерева на B-дерево. То есть, думаешь, что выиграешь из-за улучшения локальности данных, а проигрываешь из-за большей O-константы в алгоритмах.
Т.е. таск надо писать в виде: «я попробую потратить часа 4, а если не пойдёт, то отложить на пару месяцев?»
Знакомые соображения, перекликаются с моим опытом.
1. В каждом проекте есть свой пороговый размер задачи, до которого быстрее сделать без планирования. У нас это 2-3 часа. Если есть какая-то идея по улучшению, которая вписывается в это время, можно пробовать без заведения задачи. Главное — вовремя остановиться, если понял, что быстро закончить не получается. Если какой-то эксперимент выглядит дороже этих 2-3 часов, то (в среднем) быстрее добавить его в план и дождаться его очереди, чем ждать, пока откроется окно нужных размеров для экспериментов.
2. Любые задачи с непредсказуемым итогом мы стараемся записывать в формулировке, очень приближенной к тому, что вы предлагаете. «Попробовать ускорить время старта (лимит времени 1 день)». «Разобраться, почему тесты показали ухудшение производительности в предыдущем спринте и попробовать починить (лимит 4 часа)».
3. Для любых изменений, которые войдут в стабильную ветку продукта, должна существовать задача и коммит должен на неё ссылаться. Даже когда задача на 5 минут. Может показаться, что это лишняя бюрократия, но на длинных интервалах отсутствие такого правила обходится дороже.
1. В каждом проекте есть свой пороговый размер задачи, до которого быстрее сделать без планирования. У нас это 2-3 часа. Если есть какая-то идея по улучшению, которая вписывается в это время, можно пробовать без заведения задачи. Главное — вовремя остановиться, если понял, что быстро закончить не получается. Если какой-то эксперимент выглядит дороже этих 2-3 часов, то (в среднем) быстрее добавить его в план и дождаться его очереди, чем ждать, пока откроется окно нужных размеров для экспериментов.
2. Любые задачи с непредсказуемым итогом мы стараемся записывать в формулировке, очень приближенной к тому, что вы предлагаете. «Попробовать ускорить время старта (лимит времени 1 день)». «Разобраться, почему тесты показали ухудшение производительности в предыдущем спринте и попробовать починить (лимит 4 часа)».
3. Для любых изменений, которые войдут в стабильную ветку продукта, должна существовать задача и коммит должен на неё ссылаться. Даже когда задача на 5 минут. Может показаться, что это лишняя бюрократия, но на длинных интервалах отсутствие такого правила обходится дороже.
*Upd* Общее количество мини-исследований до 2-3 часов должно быть незначительным и не влиять на темп запланированных работ. Если их становится много, тоже стоит планировать. При нарушении этого принципа снижается прозрачность происходящего для менеджмента и может возникнуть ситуация, идентичная «рефакторингу в тайне от менеджера»
Sign up to leave a comment.
Ланнистеры всегда платят свои долги! (и технические тоже)