Владение кодом VS владение проблемой
Jun. 23rd, 2023 09:30 pmЯ вот тут понял одну интереснейшую вещь. Эти два понятия невероятно различаются.
Для начала про "владение". "Владение" тут используется в особом смысле - человек знает, и ему не всё равно. Если оно не решает проблему, то это не "пишите задачу в джиру", это "я пишу задачу в джиру, что нужно починить". Если всплывает неконсистентность, то это не "они идиоты", а "надо понять между чем и чем и найти решение".
Так вот:
Есть владение продуктом (product owner). Я эту штуку пропускаю, важно, но вне фокуса этого поста.
А ещё есть владение проблемой и владение кодом.
Владение проблемой, это когда человек о конкретной проблеме "всё знает" (или стремится всё знать). Ух ты, у этой проблемы есть аспект, о котором никто не думал - надо разобраться. Такой человек - финальный авторитет в вопросах проблемы. Может быть их несколько, но тогда проблема чаще всего рассыпается на несколько подпроблем и каждый закапывается в свой аспект.
А есть владение кодом, который (эту) проблему решает. Если в коде оказывается особый случай, который, хоть и вырожденный, ведёт к кубической сложности - это важно. Если теоретически решение unsound, это важно. Структура классов/модулей/etc - это важно. Выбраная парадигма при написании коннекторов - это важно.
Так вот, часто бывает, что владение проблемой и владение кодом, который решает проблему, это одно и то же. Человек хорошо знает проблему печати стикеров в формате IEE809.32a, у него есть код, который их печатает, и он всё знает про непечатные стикеры.
Это идеальный вариант, потому что с этого человека и спрос. Когда что-то не так, он либо выяснит, что есть ещё один нюанс в печати стикеров и уточнит задачу (у себя в голове в первую очередь), и код допишет, и за кривое срезание углов в пул-реквесте будет ругаться.
Но в общем случае это могут быть разные люди! Например, человек может всё ещё владеть проблемой, но уже не владеть кодом, потому что его дальше пишут другие люди. То есть он всё ещё может в него смотреть, но у него нет ощущения полного понимания. Кому-то что-то там надо было поменять, ну окей.
А может быть случай, когда человек когда-то владел проблемой, но теперь владеет только кодом, потому что его утащили с "передовой" и он мирно что-то там в либе ковыряет. Он владеет либой, но вот применение этой либы - уже не зона его ответственности, и если задача плавно оморфировала, то он не рвётся выяснять что и почему и нафига.
Из этого можно сделать интересное токсичное наблюдение: может быть так, что ни у проблемы, ни у кода больше нет владельца. Люди могут приходить и что-то приносить, но в целом, никого не волнует ни консистентность, ни абстрактные проблемы. "оно же и так работает", хотя только что в код принесли слой перепутанных спагетти, которые гарантировано угробят код в перспективе 3-5 лет.
Отсутствие владельца у кода ведёт к ветшанию кода. Отсутствие владельца у проблемы ведёт к неполному или неудобному решению проблемы. Отсутствие владельца у того и другого складывается в ветшающий код, решающий не ту проблему.
(тут должен быть плавный финал, но я уже сказал всё, что надумалось, а воду лить не хочу).
Для начала про "владение". "Владение" тут используется в особом смысле - человек знает, и ему не всё равно. Если оно не решает проблему, то это не "пишите задачу в джиру", это "я пишу задачу в джиру, что нужно починить". Если всплывает неконсистентность, то это не "они идиоты", а "надо понять между чем и чем и найти решение".
Так вот:
Есть владение продуктом (product owner). Я эту штуку пропускаю, важно, но вне фокуса этого поста.
А ещё есть владение проблемой и владение кодом.
Владение проблемой, это когда человек о конкретной проблеме "всё знает" (или стремится всё знать). Ух ты, у этой проблемы есть аспект, о котором никто не думал - надо разобраться. Такой человек - финальный авторитет в вопросах проблемы. Может быть их несколько, но тогда проблема чаще всего рассыпается на несколько подпроблем и каждый закапывается в свой аспект.
А есть владение кодом, который (эту) проблему решает. Если в коде оказывается особый случай, который, хоть и вырожденный, ведёт к кубической сложности - это важно. Если теоретически решение unsound, это важно. Структура классов/модулей/etc - это важно. Выбраная парадигма при написании коннекторов - это важно.
Так вот, часто бывает, что владение проблемой и владение кодом, который решает проблему, это одно и то же. Человек хорошо знает проблему печати стикеров в формате IEE809.32a, у него есть код, который их печатает, и он всё знает про непечатные стикеры.
Это идеальный вариант, потому что с этого человека и спрос. Когда что-то не так, он либо выяснит, что есть ещё один нюанс в печати стикеров и уточнит задачу (у себя в голове в первую очередь), и код допишет, и за кривое срезание углов в пул-реквесте будет ругаться.
Но в общем случае это могут быть разные люди! Например, человек может всё ещё владеть проблемой, но уже не владеть кодом, потому что его дальше пишут другие люди. То есть он всё ещё может в него смотреть, но у него нет ощущения полного понимания. Кому-то что-то там надо было поменять, ну окей.
А может быть случай, когда человек когда-то владел проблемой, но теперь владеет только кодом, потому что его утащили с "передовой" и он мирно что-то там в либе ковыряет. Он владеет либой, но вот применение этой либы - уже не зона его ответственности, и если задача плавно оморфировала, то он не рвётся выяснять что и почему и нафига.
Из этого можно сделать интересное токсичное наблюдение: может быть так, что ни у проблемы, ни у кода больше нет владельца. Люди могут приходить и что-то приносить, но в целом, никого не волнует ни консистентность, ни абстрактные проблемы. "оно же и так работает", хотя только что в код принесли слой перепутанных спагетти, которые гарантировано угробят код в перспективе 3-5 лет.
Отсутствие владельца у кода ведёт к ветшанию кода. Отсутствие владельца у проблемы ведёт к неполному или неудобному решению проблемы. Отсутствие владельца у того и другого складывается в ветшающий код, решающий не ту проблему.
(тут должен быть плавный финал, но я уже сказал всё, что надумалось, а воду лить не хочу).