Технический долг убивает мотивацию, тормозит разработку, вызывает конфликты — исследование Статьи редакции
«Хвост» из старых задач для разработчиков мешает заняться новыми. В Hacker Noon рассказывают, что в командах думают об этой проблеме.
Команда SaaS-сервиса Stepsize опросила более 200 разработчиков о том, как на их процессы влияет технический долг — очередь из отложенных задач или проблем в коде. Вот какие результаты она получила.
52% опрошенных считают, что технический долг понижает командный дух
По их словам, это чуть ли не главное, что мешает им продуктивно работать. Часто разработчики отдают приоритет новым функциям — хотя решение старых проблем могло бы улучшить пользовательский опыт и скорость продукта.
Программисты тратят семь часов в неделю на долг
В среднем у разработчика на работу с устаревшим ПО и техобслуживание уходит треть времени. Из него более 50% — на технический долг. Если автоматизировать этот процесс, разработка ускорится, считают авторы отчёта.
В основном технический долг скапливается в бэкенде
Более 60% опрошенных уверены: из-за долга появляется множество новых багов и сбоев. В основном это связано с проблемами с серверной частью продукта, из-за чего вся остальная структура — приложение или сайт — работает хуже.
Выпуск продуктов ускорился бы на 100%, если бы не очередь из задач
Половина респондентов говорит, что их компании не справляются с техническим долгом. Из-за этого часто возникают конфликты между руководством и разработчиками. Последние убеждены: долг — главное, что снижает производительность, однако его нельзя сделать приоритетной задачей, так как нужно работать над новыми функциями.
15% опрошенных заявляют, что их продуктивность вырастет на 200%, если решить проблемы со старыми задачами. Лишь 2% считают, что это не повлияет на скорость работы команды.
Непрерывно занимаются техобслуживанием в основном крупные компании — у кого больше ста разработчиков в команде
70% крупного бизнеса проводит технические работы еженедельно или ежедневно, 20% — ежемесячно, и менее 10% — ежегодно. Тогда как средний и малый бизнес решает эти проблемы в проектном формате.
54% программистов корпоративных компаний утверждают, что занимаются техобслуживанием регулярно, а в стартапах — лишь 42%.
Какие инструменты используют команды
В отчёте отмечают, что в корпорациях и стартапах над техническим долгом работают примерно одинаково: используют Jira или другое ПО для отслеживания задач и проектов.
целое исследование чтобы узнать про то что люди предпочли бы делать что-то тяп-ляп не прикладывая должных усилий? а контроль убивает мотивацию, замедляет работу и вызывает конфликты, потрясающе!
Комментарий недоступен
Целиком исследование можно скачать вот тут: https://www.stepsize.com/report
А ещё когда начинает тимлид задрачивать за чистоту кода, потому что у каждого великовозрастного ребенка прогера - восприятия частоты особенное своё. А ещё есть QA -QAA QAS QACVB и другие страшные люди которые вместо того чтобы искать баги по наводке CSS CSM, исправляют фитчи которые сделаны по запросу members. 😄🤣 И вот тут, Ты понимаешь, что ты совсем не командный человек и некогда им не был и быть не хотел.
Вообще, относительно чистоты кода, существуют общепринятые практики, которые должны быть закреплены конвенциями к проекту следование которым обязательно. И если вы выходите за установленные рамки, то не должны только радоваться тому, что вас в них возвращают. Другое дело, что есть иноверцы, которые силой навязывают что-то своё. Вот с такими просто не стоит работать, нервы должны быть дороже.
что за практики?
С одной стороны, это совокупность семантических правил - общих для всех ЯП (правила относящиеся к синтаксическим конструкциям - читайте книгу чистый код), уникальных для конкретного ЯП и исключительно проектных (кавычки, табы, отступы). С другой стороны, это линтеры, преттеры и конфигурации для idea.
Слова не джунчика, но мидла 💪
Если серьезно, то никакой линтер ни на что не влияет. Если команда называет переменные как попадётся и лепит код куда вздумается, то проблемы продукта сильно глубже и хуже, чем какой-то там техдолг.
Вы, наверное, хотели сказать что-то про SOLID и стандартные архитектурные паттерны (cqrs, feature modules etc), но это всё довольно субъективно и в любом случае требует уточнения под каждый конкретный проект.
А «замените if-else на тернарку потому у вас так линтер настроен» - я вас умоляю.
Я так понял, что мидлом вы себя назвали? Чистота, это про то, о чем я написал. Название переменных туда как раз подползает. Солид, это про дизайн кода. Мидлы уже должны понимать разницу между дизайном и архитектурой.
И если вы не заметили, то я не про тех долг, о котором написано в заголовке. Я о чистоте кода, о котором написано в комментарии.
В PHP это - PSR, например.
Всего-то достаточно ставить хороший прототип и ТЗ, и не менять его в процессе разработки, но чаще всего в голове продумать алгоритм с нуля до конца могут только люди которые и программируют и делают UX, но их программистов воспринимают как людей не шарящих, что нужно пользователю, поэтому к ТЗ их не допускают, а допускают абсолютных гуманитариев. Просто когда скачут с одной идеи на другую, тяжело переключиться на новое и потом возвращаться к старому коду, когда видишь всё что нужно сделать от начала до конца, то и код пишется без ошибок к которым потом надо возвращаться. Моё мнение как программиста умеющего делать полноценные рабочие прототипы в AxureRP
Если программист пишет продукт не для программистов, то в большинстве случаев это будет рабочий кусок Г, который не продать нормальному пользователю.
Это спорно, куча стартапов сделанных непрограммистами и живущие только на инвесторские бабки, т.е. покрывают не лучший сервис всякими бонусами для пользователей, также есть примеры успешных стартапов от программистов, короче это не аксиома. Да и я писал о смеси программиста и UX, программист понимает как это работает внутри, UX как сделать так, чтобы это ещё и было удобно другим.
О, свидетели неменяющегося ТЗ появились. Я буду рад увидеть хотя бы один пример такого.
я когда заказываю для себя разработку, делаю не меняющееся. Долго делаю, но делаю и только потом заказываю. А сам почти таких ТЗ не получал, чаще всего меняется, тут я не спорю.
Комментарий недоступен
Комментарий недоступен
вы сферического коня в вакууме описываете, должна быть гибкость в разработке, которая позволяет закрывать технический долг без ущерба продукту.
А если долги еще и со второй работы висят, то вообще труба
https://vc.ru/hr/283787-sotrudniki-na-udalenke-sovmeshchayut-dve-raboty-vtayne-ot-nachalstva-i-poluchayut-ot-200-tysyach-do-600-tysyach-v-god
Забавно, если эти две работы еще пересекаются и в первой компании ты ждешь когда криворукие разрабы из второй компании допилят REST... И это тоже ты :D
Воистину это так! Самый лучший способ определять особый день посвященный только решению тех долга.
Все правильно. А кто и зачем придумал SCRUM, сами поищите.
вот тут здорово расписано еще про умышленный и неумышленный техдолг и стратегии по его обслуживанию и устранению https://vc.ru/dev/242768
Информационная безопасность и отсутствие уязвимостей в коде - это тоже тех долг. Предлагаю тоже на неё забить (нет)!
Это не техдолг (сюрприз)
и что же это по твоему?)
За написание тестов заплатите
Комментарий недоступен