Pull to refresh
12
0
Александр Лебедев @alexanderlebedev

Фронтенд разработчик, тимлид

Send message
Зависит от того, в какой фазе жизненного цикла находится продукт. Если планируется активное развитие с новым фичами — будет и новый код, и рефакторинг, и бюджет времени на это.

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

Если нас интересует компактность образа именно в проде, то вижу возможность для оптимизации. node-gyp и инструменты сборки нативного кода, как правило, нужны на этапе установки но не нужны после этого. Если использовать multi-stage build, то можно убрать эти зависимости из финального образа. Недавно удалось выиграть за счет multistage более 300MB размера образа (~1.6GB -> ~1.25GB)
*Upd* Общее количество мини-исследований до 2-3 часов должно быть незначительным и не влиять на темп запланированных работ. Если их становится много, тоже стоит планировать. При нарушении этого принципа снижается прозрачность происходящего для менеджмента и может возникнуть ситуация, идентичная «рефакторингу в тайне от менеджера»
Знакомые соображения, перекликаются с моим опытом.

1. В каждом проекте есть свой пороговый размер задачи, до которого быстрее сделать без планирования. У нас это 2-3 часа. Если есть какая-то идея по улучшению, которая вписывается в это время, можно пробовать без заведения задачи. Главное — вовремя остановиться, если понял, что быстро закончить не получается. Если какой-то эксперимент выглядит дороже этих 2-3 часов, то (в среднем) быстрее добавить его в план и дождаться его очереди, чем ждать, пока откроется окно нужных размеров для экспериментов.

2. Любые задачи с непредсказуемым итогом мы стараемся записывать в формулировке, очень приближенной к тому, что вы предлагаете. «Попробовать ускорить время старта (лимит времени 1 день)». «Разобраться, почему тесты показали ухудшение производительности в предыдущем спринте и попробовать починить (лимит 4 часа)».

3. Для любых изменений, которые войдут в стабильную ветку продукта, должна существовать задача и коммит должен на неё ссылаться. Даже когда задача на 5 минут. Может показаться, что это лишняя бюрократия, но на длинных интервалах отсутствие такого правила обходится дороже.
Через демонстрацию цепочки эффектов на те показатели, которые данный конкретный бизнес считает для себя важными. Попробую привести несколько примеров:

Качество. Устранение технического долга в важном модуле позволит повысить качество и снизить шанс возникновения регрессионных дефектов при внесении модификаций. Наличие плохо спроектированного/реализованного кода, напротив, гарантирует высокий шанс регрессий. При этом никакой QA-процесс не гарантирует 100% обнаружения дефектов. Значит, появление критичных дефектов, которые могут испортить репутацию компании в глазах широкой публики или ключевого клиента — вопрос времени.

Скорость разработки. Разработка быстрее всего идёт при использовании современных библиотек, правильных абстракций и т.п. Устранение технического долга в модуле, где планируется добавление новой функциональности, частично или полностью окупится при последующей разработке. Кроме того, доведение функциональности до требуемого уровня качества займет тем меньше времени, чем меньше дефектов и чем ниже риск регрессий при их исправлении.

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

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

1. Необходимость смотреть полную историю изменений файла вместо blame/annotate — тут надо выбирать между простой историей изменений и согласованным стилем кода в проекте. Способа получить и то и другое одновременно я не вижу. ИМХО, польза от согласованного стиля более весома, поэтому мы делаем стилистические правки. В других проектах ситуация может отличаться.

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

3. Риск регресса важен, и именно он часто является ограничителем для такого рода улучшений кода. Если зона затронутой функциональности увеличивается, нужно одобрение на такое изменение от всей команды, включая QA и Владельца продукта.
Мы также столкнулись с тем, что замена ng-annotate-loader на angularjs-annotate необходима, чтобы начала работать поддержка ES2017 синтаксиса в babel-loader
ИМХО, для существующих проектов бонусов от миграции webpack 1 -> webpack 2 не так много, чтобы срочно переходить. Там где webpack'а ещё нет, стоит использовать последнюю версию.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity