Comments 17
Знания можно передать, мудрость только нажить. Бесхозный код это жалкое зрелище. Но назначение хозяина - ещё не решение. Номинальное владение кодом даётся гораздо проще, чем овладение навыками его понимать и сопровождать.
Код эволюционирует вместе с его авторами. Вы меняете код, код меняет вас. Нужно прямо физически отрастить себе что-то в могзах, чтобы в решении появился паттерн, кодогкнератор, фреймворк, принцип и т.п. Комбинаций тьма и они довольно уникальны. У новых хозяев этого не будет (но за то будет что-то своё и они непременно воспользуются шансом для самореализации). Что-то успеют поменять, что-то нет. Через несколько итераций смены собственников код превращается в такое же лоскутное одеяло, как если бы у него ни каких хозяев вовсе не было.
Решение как мне кажется находится не в плоскости ownership, а в выращивании людей в той же среде. Прямо вместе с этим же кодом, годами. Junior, middle, senior и т.п. (а не 2 недели на KT и оно всё твое).
Согласна с мыслью, про выращивание людей в той же среде. Только ещё и выращивать должен кто-то, кто давно в проекте и сам его хорошо знает. А то назначают ментором человека, который сам ещё меньше года в компании - он сам-то не всё знает и джунам всего не покажет. Ну и дальше повторится содержание статьи.
Аха, всё верно на счёт формального владения. В статье как раз говорится о том, как владение в полном смысле этого слова вырождается в формальное и приводит к печальным последствиям.
Для меня интересным и близким к моей реальности тут было то, что показан процесс деградации ответственности и озвучены причины. Как говорится "предупреждён, значит вооружён". )
Моя боль сейчас сосредоточена именно на максимальном возможном упрощении передачи знаний и устранения единоличного владения внутренними проектами компании.
Разработчик начинает совершенно новый проект с продуманной архитектурой и чистым, структурированным кодом.
Всегда же так? Да? Ведь правда?
Да, друг мой. Надеюсь что всегда 😢😢😢😢
Да. А потом ты идешь на работу)
В домашних проектах, где ты и вся команда разработки, и devops, и product owner, и менеджер, и CTO & CEO, и даже клиент, все в одном лице - конечно всегда. А вот в коммерческих проектах такой идеализм как правило выживает не больше пары недель со старта проекта...
Статья в самое сердечко. Часто встречаю огромные куски кода или целые модули и сервисы, которые писались при царе горохе. И дальше этот код продолжает подпираться костылями, вместо нормального рефакторинга, потому что его или страшно трогать или задача горящая и нужно вклинить ее здесь и сейчас, а не переписывать старое.
Прочесть такой код - та ещё задача(
Почему бы не покрыть код тестами, чтобы не бояться трогать его?
Потому что тестам тоже нужно доверять. Это не панацея. Вы уверены, что понимаете все кейсы которые вы покрыли? Вы уверены, что покрыли все кейсы? Была у меня ситуация. Нужно поменять некоторую логику в одном модуле. Тесты есть. Меняю. Тесты проходят. Через неделю оказывается, что в базе были хранимые процедуры (для тригеров) которые перестали работать как надо. В итоге модуль который я правил работал как надо, а данные которые обновлялись тригерами были некорректными, в следствии чего другой модуль перестал корректно работать. Да тут можно сколько угодно говорить про архитектуру и связанность кода, но факт есть факт - тесты были, но не помогли.
Так причина боязни "трогания" не в отсутствие тестов, а в отсутствие понимания как это все работает.
Грубо говоря тесты даже если и есть, но ты не понимаешь как оно работает внутри, то и решения будут приниматься соответствующие: тяп-ляп сбоку или дублирующая функциональность или "нам срочно только тут". В итоге и тесты есть и код работает, а все вместе начинает пованивать (code smell) со временем все больше и больше.
Владение в данном случае призвано блюсти чистоту и своевременную передачу знаний касательно кода, что бы с ним было удобно и приятно работать.
Эх, сколько чепухи понаписано насчёт проблемы, которая в машиностроении, например, не имеет места быть.
В машиностроении любой узел, любой агрегат имеет своё кб, отдел и бюро, которое его ведёт, поддерживает и развивает. В любом техбюро отделе каждый конструктор и технолог ответственен за свой набор деталей и узлов. Когда возникает вопрос по детали или техпроцессу, всегда известно, кто ответственнен за данную деталь.
Другие просто не имеют права ничего менять в чужой документации.
В ит почему-то полный бардак. Огромная статья посвящена проблеме, которая в принципе решается элементарно - закрепление каждого класса за определённым разработчиком.
Так ведь бизнес хочет экономить здесь и сейчас. Придумали же самодокуметирующийся код чтобы не писать документацию или забивают на её актуализацию, ибо "потом как нибудь".
Справедливости ради могу представить, что куча кода улетает в никуда и выбрасывается и вроде как бизнесу кажется, что не стоит усилий такой код как-то вменяемо делать поддерживаемым и всё такое.
Но вообще угнетает эта атмосфера пофигизма, разгильдяйства, "после спринта хоть потоп"
У меня вот на текущей работе эта самая атмосфера. И знаете, когда все привыкли к подходу - "давайте сейчас напишем хрень, потому что быстро надо, а потом исправим (нет)", то и сам начинаешь по этому принципу работать. И даже оправдание себе находишь - "если всем похер, то почему мне должно быть дело?".
Обычно в таких системах кто-то должен стать первым и запустить процесс =ъ
Само собой, магическим образом, оно никогда не начнётся. Вообще формулировки про "если всем..., по почему мне..." способствуют именно тому положению дел, которое так всех раздражает. Да и странная это "команда" получается. Поэтому что бы разорвать эту порочную связь лучше думать на тему "а что я могу сделать, что бы...". И не всегда это могут быть прямые действия в один ход.
Например для начала можно:
общаться в команде на тему качества кода, создавая общий вектор
выделять и фиксировать самые раздражающие места и доносить до всех
договариваться и фиксировать планы по рефакторингу
регулярно подсвечивать проблему качества кода на ретро и общих встречах с управлением и при планировании
время от времени самом вносить минорные правки по качеству
О важности владения кодом