Каждый год платформа Stack Overflow проводит опрос программистов и разработчиков со всего мира, а затем обнародует результаты. Из них можно узнать много интересного:
- какие ИТ-направления оплачиваются лучше других;
- какие языки программирования используются чаще;
- какое образование преобладает среди айтишников;
- кто как предпочитает учиться;
- сколько среди ответивших самоучек и так далее.
В 2024 году в опросе приняли участие более 65 тысяч респондентов, так что выборка большая и показательная. Нас особенно заинтересовали ответы на вопрос о том, что расстраивает программистов и разработчиков в их работе. Получились такие результаты, а мы попробуем их проанализировать:
На случай если вы не знаете английский язык, приведём перевод ответов:
- 62,4% — объём технического долга.
- 32,9% — сложность технологического стека для сборки.
- 32,3% — сложность технологического стека для разработки.
- 31,6% — надёжность инструментов и систем, используемых в работе.
- 27,1% — отслеживание работы.
- 25,1% — исправление и обновление основных компонентов.
- 22,8% — количество используемых программных инструментов.
- 19,6% — показ вклада.
- 18,6% — поддержка безопасности создаваемого кода.
- 15,4% — поддержка безопасности систем и платформ, используемых в работе.
- 8,7% — ничего из перечисленного.
Объём технического долга
Технический долг — это метафора для описания дополнительных усилий, которые придётся потратить в будущем из-за каких-то решений ради более быстрой разработки. Технический долг возникает, когда код пишут быстро, но не оптимально — без тестирования или составления документации, из-за чего впоследствии код требует доработки и исправлений.
Простой пример: компания разрабатывает новое приложение и ради соблюдения сроков пренебрегает тестами и аккуратностью архитектуры. Приложение выходит вовремя, но в будущем его поддержка и развитие становятся всё сложнее и требуют всё больше времени и ресурсов. Так проявляется то, что можно назвать погашением технического долга.
Технический долг накапливается со временем, и это нельзя остановить, ведь он образуется как побочный эффект создания нового ПО. Погасить технический долг можно так:
- Провести аудит кода и определить области с техническим долгом. Составить список, где и в каком объёме есть долги, какие у них причины, последствия и приоритеты.
- Расставить приоритеты по техническому долгу в зависимости от срочности и важности. Какие-то долги могут ждать, а другие лучше погасить как можно скорее. Например, если служба поддержки тонет в обращениях и это дорого обходится компании.
- Придумать, какие быстрые и более долгосрочные меры можно применить, чтобы уменьшить или устранить технический долг.
- Включить задачи по этим мерам в обычный процесс разработки и постепенно исправлять код, тестировать его и документировать.
Звучит просто, а на практике оказывается нелегко, иначе у большинства компаний отсутствовал бы технический долг. Но по-другому с ним не справиться, и, если наличие технического долга расстраивает команду, нужно искать возможности его устранить. А вот как можно уменьшить будущий технический долг:
- Тестировать и улучшать код при разработке новых продуктов.
- Использовать инструменты для анализа кода, чтобы выявлять слабые места.
- Обучать команду писать качественный код и развивать культуру разработки.
- Объяснить руководству и заказчикам, почему важно управлять техническим долгом, чтобы получить от них поддержку и ресурсы.
Сложность технологического стека для сборки
Большинство современных программных продуктов разрабатываются большими командами. Разные исполнители могут использовать разные инструменты, фреймворки и библиотеки — тот самый технологический стек. И когда наступает время, чтобы собрать вместе результаты работы всех участников, это оказывается сложным и трудоёмким процессом.
Из-за сложности стека замедляется время сборки. Разнообразие инструментов может привести к конфликтам версий и проблемам с совместимостью. Чем больше технологий используется, тем сложнее поддерживать и обновлять проект.
Вот как можно избежать сложностей технологического стека для сборки:
- Использовать минимально необходимый набор инструментов и выбирать только те, что действительно необходимы для проекта. Например, если предполагается разработка под разные платформы, не получится обойтись без специальных языков программирования вроде Swift для iOS.
- Делать выбор в пользу стандартных инструментов, которые хорошо задокументированы и поддерживаются. Ещё лучше, если эти инструменты многофункциональные и могут заменить несколько.
- Договориться со всеми, кто работает над проектом, о том, какие инструменты использовать.
Сложность технологического стека для разработки
Наряду с тем, что технический стек бывает сложным для проекта в целом, он может быть сложным и для конкретного специалиста, который работает над своей частью. Если приходится одновременно использовать много различных технологий, инструментов, фреймворков и библиотек, работать так действительно тяжело. Особенно сложно новым членам команды, от которых требуется изучить все используемые технологии.
Проблема усугубляется тем, что при сложном технологическом стеке недостаточно уметь этим всем пользоваться. Нужно ещё и постоянно управлять версиями и обновлениями. В ИТ есть понятие «ад зависимостей» — это когда небольшие изменения в одной части вызывают цепочку проблем в других. Например, одна библиотека может зависеть от версии другой, и если вторая обновляется, вместе они перестают работать.
Но со сложным технологическим стеком всё же можно бороться:
- Использовать только те инструменты, которые действительно необходимы для выполнения задач проекта. Проще говоря, не плодить сущности.
- Отдавать предпочтение проверенным и совместимым инструментам, которые хорошо интегрируются друг с другом и поддерживаются.
- Разделять проект на модули или микросервисы, которые можно разрабатывать, тестировать и поддерживать независимо друг от друга.
- Регулярно пересматривать используемый стек, удалять устаревшие или избыточные инструменты и менять их на более эффективные.
- Вести документацию и описывать в ней лучшие практики работы с используемым стеком.
Надёжность инструментов и систем, используемых в работе
Как и в любой другой области, в ИТ нет ничего абсолютно надёжного. Это нормально, потому что программные продукты и оборудование создаются обычными людьми, а нам всем свойственно ошибаться. Что-то устаревает или больше не поддерживается, где-то обнаруживаются новые уязвимости, у чего-то появляются более продвинутые аналоги.
Как пользователи, мы не можем отвечать за то, как работают программы или железо. Например, никто не мог предвидеть и не был готов к тому, что в июле 2024 года по всему миру начнутся сбои в работе операционной системы Windows. В итоге много компаний и обычных людей понесли ущерб, и, хотя виновные были найдены и проблема была устранена, репутация Windows серьёзно пострадала. Как говорится, осадочек остался.
Если приходится работать с ненадёжным инструментом, справиться с расстройством из-за этого можно только с помощью терпения и прощения людям их недостатков (или создать собственный такой инструмент, но это точно путь не для всех). Ещё можно делать так:
- Регулярно создавать резервные копии кода, данных и конфигураций, чтобы можно было быстро всё восстановить, если что-то выйдет из строя или даст сбой.
- Изучать альтернативные инструменты и технологии, которыми можно заменить то, что ненадёжно.
- Следить за выходом новых версий и патчей и регулярно устанавливать обновления.
- Сообщать о найденных ошибках и проблемах в службу поддержки инструмента или системы.
- Общаться с сообществом, которое тоже использует инструмент или систему, делиться с ним выявленными ошибками и советоваться по возникающим проблемам.
Отслеживание работы
Если программист или разработчик работает не в одиночку над собственным проектом, он всегда будет частью какого-то процесса, который связан с работой других. От этого возникает необходимость координировать общие действия, а это требует понимать, кто что делает в данный момент, каков прогресс и сроки. Даже если программист или разработчик выполняет всю работу сам, заказчика будет интересовать, как идут дела: работает ли исполнитель над задачей, на какой всё стадии, когда будет готово.
Когда работу отслеживают, это может расстраивать и вызывать чувство давления. Но нужно понять, почему и зачем так происходит. Например, если программист или разработчик регулярно не сдаёт работу вовремя, это может вынудить руководство контролировать процесс со стороны, чтобы избежать проблем. В таком случае есть только одно решение — стать более надёжным сотрудником и завоевать доверие, чтобы контроль не был нужен.
Но если всё хорошо и делается в срок, надо копать глубже. Например, есть очень недоверчивые люди, которым нужно контролировать всё вокруг. А может, всё объясняется просто: в компании в принципе отслеживается работа всех сотрудников, чтобы руководство могло в любой момент узнать, что происходит, и удостовериться, что всё в порядке.
Если вас расстраивает, что вашу работу отслеживают, можно попробовать такие подходы:
- Узнать, почему так тщательно отслеживают работу. Может, это горящая задача, от сроков выполнения которой зависят большие деньги и доверие клиента.
- Если постоянный контроль вызывает дискомфорт, нужно поговорить с руководством или командой, объяснить, как это влияет на вашу мотивацию и продуктивность, и постараться найти компромисс.
- Постараться выстроить доверительные отношения с руководством и командой. Если показывать хорошие результаты работы в срок, можно добиться большей автономии.
Исправление и обновление основных компонентов
Жизненный цикл любого программного продукта продолжается до тех пор, пока проект не закроют и поддержку не прекратят. Когда программа готова и вышла на рынок, это ещё не окончание работы над ней. Даже если провести очень много тестов и постараться предусмотреть как можно больше, может оказаться, что где-то всё-таки остались ошибки. И получается, что работа над проектом продолжается. Это может быть неинтересно и отнимать время, которое можно было бы потратить на новые проекты.
Если это расстраивает, могут помочь такие стратегии:
- Понять, что исправление и обновление кода — неотъемлемая часть процесса разработки даже после выхода продукта и может предотвратить большие проблемы в будущем.
- Сосредоточиться на результате и на том, что исправление и обновление сделают продукт лучше для его пользователей.
- Если возможно, делегировать часть задач коллегам или более младшим разработчикам — это поможет им развиваться.
- Попросить руководство или команду дать вам возможность участвовать в новых проектах, чтобы не застревать на однообразных задачах.
Количество используемых программных инструментов
Если в работе приходится использовать множество инструментов, это может утомлять, даже если они несложные. Вот как можно с этим справиться:
- Проанализировать используемые инструменты и определить, какие из них действительно необходимы, а от каких можно отказаться.
- Стандартизировать набор инструментов для команды и проекта, чтобы уменьшить их количество.
- Автоматизировать рутинные задачи при помощи скриптов и макросов.
- Найти способы интеграции разных инструментов между собой.
Показ вклада
Многих программистов и разработчиков расстраивает, что им приходится показывать свой вклад в работу. Это может быть связано с разными причинами, например с чувством давления, боязнью критики или ощущением, что работа недооценивается. Здесь может помочь такое:
- Осознать, что демонстрация вклада — это не просто формальность, а возможность помочь команде и руководству оценить прогресс, распределять задачи и улучшать процессы.
- Понять, что люди в принципе так устроены, что сосредоточены в основном на себе и могут не замечать происходящего с другими. И чтобы они увидели чужой вклад в работу, нужно им о нём рассказать.
- Подойти к демонстрации своего вклада как к возможности получить не только критику, но и похвалу, которая мотивирует на дальнейшую работу (впрочем, критика тоже не страшна — она задаёт направление для развития).
Поддержка безопасности создаваемого кода и поддержка безопасности систем и платформ, используемых в работе
Не все ошибки в коде сказываются на работоспособности. Бывают такие, при которых программа отлично работает, но содержит уязвимости, и это может привести к серьёзным последствиям, например к утечке данных.
Безопасность кода добавляет сложность и объём работы. При этом та же безопасность может противоречить другим целям, например удобству использования или скорости разработки. Чтобы обеспечить безопасность кода, от программиста или разработчика требуются глубокие знания и высокая ответственность. А поскольку технологии и методы атак постоянно развиваются, нужно быть в курсе последних уязвимостей и защитных мер.
Всё это может серьёзно расстраивать. Мы как-то разбирали мем о том, как один парень захотел узнать всё, что известно об информационной безопасности, и что из этого вышло.
Советовать тут что-то конкретное сложно. Самый простой и работающий выход — поговорить со своими безопасниками в компании и узнать, что они думают про решения, которые вы предлагаете. Если решений у вас нет — спросите совета, они ребята умные, что-то точно подскажут.
А если безопасник в компании это вы — штош. Сочувствуем, но такова жизнь безопасников: смотреть на код, грустить, вздыхать, а потом придумывать классные решения. В том, что вы его придумаете, мы не сомневаемся, потому что верим в вас.
Вы — классные. Обнимаем.
