Не любая техническая правка простая. Например, если есть задача заменить запрос в цикле более сложным, но одним запросом с измененной логикой обработки — то мы считаем эту задачу техническим долгом и пробуем решить со стажерами. Многие такие задачи даже как технический долг не признают и не правят такие вещи.
Постараюсь объяснить логику работы. У нас большая стажерская программа и к нам приходит ощутимое количество начинающих разработчиков. Как мы решили выстроить работы с начинающими. Вместо изучения теории ребята анализируют замечания системы статического анализа кода. Система группирует однотипные ошибки по одной или нескольким конфигурациям и показывает пример исправления. Лидер команды проверяет исправление на одном примере, и ребята точечно вносят правки во все места в коде. В результате все довольны. Сильных разработчиков мы на эти правки не отвлекаем, а ребята привыкают к работе в нашей инфраструктуре, правилам разработке, адаптируются к командной работе. Если в команду приходят опытные разработчики, то конечно, к этой активности мы их не подключаем. Но все видят свой технический долг, и мы регулярно проговариваем, какие замечания надо поправить.
Мы анализируем все ошибки: и по журналу регистрации, и по технологическому журналу. Не все эти ошибки могут видеть пользователи в системе, и тем более не по всем из них могут сообщить поддержке.
Может помните ещё такие языки программирования как Pascal или ранние версии Delphi. Вот там точно приходилось самой реализовывать))
Конечно! Видите, так давно не пользовалась этим термином, что допустила ошибку))
Не любая техническая правка простая. Например, если есть задача заменить запрос в цикле более сложным, но одним запросом с измененной логикой обработки — то мы считаем эту задачу техническим долгом и пробуем решить со стажерами. Многие такие задачи даже как технический долг не признают и не правят такие вещи.
Постараюсь объяснить логику работы. У нас большая стажерская программа и к нам приходит ощутимое количество начинающих разработчиков.
Как мы решили выстроить работы с начинающими. Вместо изучения теории ребята анализируют замечания системы статического анализа кода. Система группирует однотипные ошибки по одной или нескольким конфигурациям и показывает пример исправления. Лидер команды проверяет исправление на одном примере, и ребята точечно вносят правки во все места в коде.
В результате все довольны. Сильных разработчиков мы на эти правки не отвлекаем, а ребята привыкают к работе в нашей инфраструктуре, правилам разработке, адаптируются к командной работе.
Если в команду приходят опытные разработчики, то конечно, к этой активности мы их не подключаем. Но все видят свой технический долг, и мы регулярно проговариваем, какие замечания надо поправить.
Мы анализируем все ошибки: и по журналу регистрации, и по технологическому журналу. Не все эти ошибки могут видеть пользователи в системе, и тем более не по всем из них могут сообщить поддержке.