Комментарии 31
Ещё никто не написал что знание алгоритмов или шаблонов проектирования практически ни чего не даёт, если вы не знакомы с действительно Успешной практикой их применения. Потому что оченьчасто всё это богатство вводится в код не для решения насущных проблем, а для того чтобы можно было ссылаться на красивую терминологию.
Правильно замечено: "кодовая база без реального владения со временем деградирует". Сколько людей, столько мнений. И даже, если все профессионалы высокого класса, нужен координатор, чтобы привести к единому соглашению и следить, чтобы все придерживались единой линии.
Сейчас стараюсь четко определить владельца кода или сам станавлюсь им. Тогда можно говорить о каком-то порядке или возможности придерживаться плана и поставки в срок.
Именно поэтому в ядре Linux (как и в любом уважающем себя open source проекте) в корне лежит файл MAINTAINERS, где вказаны владельцы всех подсистем, драйверов и других частей ядра. Вообще всех. Если у кода нет владельца - он скорее всего будет убран из ядра. И именно владелец решает нужно ли принимать вот этот конкретный патч и в каком виде.
Да, в "Делай как в Гугл" об этом написано. Вся кодовая база делится на всех разработчиков. Каждый модуль принадлежит только одному. Владелец может переделывать и рефакторить как пожелает.
Это приводит к тому, что разработчик в своих модулях стремится наводить порядок, чтобы ему самому было удобно дебажить и исправлять ошибки, также и развивать. Нет опасения, что тебя отматерят по поводу, что ты отформатировал чей-то код. Написанный тобой говнокод будешь поддерживать ты, ты будешь искать в нем ошибки, дебажить и исправлять. Также и уменьшается или просто ликвидируется проблемы слияния изменений в гите. Работникам не приходится изучать всю кодовую базу проекта в памяти, они становятся экспертами в своих частях продукта.
Мне нравится эта идея, но на практике задачи бросаются кому попало, кто свободен в настоящий момент. Затраты непроизводительного труда на изучение чужого кода просто катастрофические.
... Владелец может переделывать и рефакторить как пожелает.
Это приводит к тому, что разработчик в своих модулях стремится наводить порядок, чтобы ему самому было удобно дебажить и исправлять ошибки, также и развивать.
еще это ведет к тому что те модули которые используют этот модуль могут в один прекрасный момент столкнутся с тем что их взаимодействие с этим выбранным модулем приводит к ексепшенам, в лучшем случае, а в худшем что их модули просто перестали компилироваться. Удобно самому не значит что удобно клиентам к сожалению.
Таким образом, очевидно, что наличие владельцев для всех модулей кодовой базы не решает проблему поддержки стабильности-надежности при развитии системы. Нужно еще как-то решать проблемы взаимодействия модулей при изменениях.
Ну, проблема взаимодействия разных модулей есть в любом случае. Если коммуникация нормально налажена, то какие-то измененения апи модуля будут обговариваться заранее с пользователями этого модуля.Это никак не противоречит идее, что у каждого модуля должны быть свои владельцы.
Если коммуникация нормально налажена, то какие-то измененения апи модуля будут обговариваться заранее с пользователями этого модуля.
вот именно! Какие-то будут, а какие-то не будут. Если например поменять порядок вызовов функций некоторого АПИ, то есть, для примера, что функция А должна теперь вызываться обязательно только после того как была вызвана функция Б, хотя раньше это было не важно, то есть большая вероятность, что такое изменение АПИ не будет даже идентифицировано как изменение АПИ...
Это действительно
никак не противоречит идее, что у каждого модуля должны быть свои владельцы.
Эта проблема существует не зависимо от наличия или отсутствия владельцев.
что функция А должна теперь вызываться обязательно только после того как была вызвана функция Б, хотя раньше это было не важно, то есть большая вероятность, что такое изменение АПИ не будет даже идентифицировано как изменение АПИ...
Грустная правда.
Этому даже название придумали: sequential coupling (also known as temporal coupling).
Согласовывать это сложно. Неплохой вариант это добавить новое, а потом попросить мигрировать.
Тут помогает разделение кода и API. Например физически через контракты. Владение кодом и владение публичным API - это две разных позиции. Они требуют разных навыков и знаний.
По моим наблюдениям, не все разработчики понимают, что они владеют еще и публичным API и поэтому делают странные вещи.
Владение кодом и владение публичным API - это две разных позиции.
Вообще мысль интересная, но если попробовать проанализировать практику применения каких-то удачных публичных АПИ, например ДиректХ, то мы выясним что концепция владения к ним не очень подходит.
Сама публичность противоречит концепции владения, то что сделано публичным уже не принадлежит тому кто это что-то изначально создал, а принадлежит всем. Поскольку договорится сразу со всеми и в разумные сроки представляется не возможным, вряд ли можно говорить о владении, об авторстве - пожалуйста, но не о владении которое подразумевает возможность распоряжаться.
Как раз эта невозможность единоличного владения приводит к выбору того что вы упомянули в виде:
Неплохой вариант это добавить новое, а потом попросить мигрировать.
в принципе это единственно возможный вариант когда интерфейс стал публичным и во всю используется. Нужно выпустить или новую версию этого интерфейса или даже принципиально новый ДРУГОЙ интерфейс который решает те же задачи но другим способом. И не обязательно что этот новый интерфейс будет в любых условиях лучше, они могут существовать и использоваться одновременно в разных применениях, и оказывается что иногда придется писать логику выбора подходящего интерфейса, и оказывается что это расширение кодовой базы более оправдано чем применение единственного оригинального интерфейса который проявляет свою абсолютную неэффективность в определенных условиях.
Как то так.
Сама публичность противоречит концепции владения, то что сделано публичным уже не принадлежит тому кто это что-то изначально создал, а принадлежит всем.
Под владением обычно понимается принятие решений. В случае API это тот, кто принимает решения об изменении / добавлении / удалении. Публичное АПИ накладывает много ограничений, но всё равно оно меняется.
как вы себе представляете решение об, для строгости, удалении хотя бы одной функции из интерфейса который стал публичным и который используется скажем в десятках проектов? (изменение в общем-то равно удалению в некотором смысле, даже простое изменение типа одного из параметров!)
Типа давайте выпиливайте все вызовы удаленной функции все дружно? Как посмотрят пользователи такого интерфейса на такого владельца этого интерфейса, то есть куда они его пошлют? я думаю не трудно догадаться.
Я думаю такой владелец надолго потеряет возможность создавать публичные интерфейсы.
как вы себе представляете решение об, для строгости, удалении хотя бы одной функции из интерфейса который стал публичным и который используется скажем в десятках проектов?
Не удалять - это тоже решение. В публичном API владелец будет больше уделять время обратной совместимости.
Если вы думете что всё понимают, что такое публичное API и что в нем можно делать и что нельзя, то я вас разочарую. Если не будет человека который предупредит о последствиях и запретит изменения, то будут проблемы с совместимостью.
Может в гугле и есть у всякого кода владелец, который 24/7 его обслуживает, но в реальности у программиста всегда есть какие то новые задачи в каких то более других модулях или проектах. Сделать его ответсвенным за какой то код который написан 5 лет назад и ожидать что он его будет пожизненно суппортить - это чушь. За годы работы у него накопятся миллион таких модулей, и на новые задачи просто не останется времени. Да и никто не будет платить такому программисту который занят не разработкой новых фич, а чисто суппортом того что и так как то работает. А еще среднестатистический программист просто забьет на такой суппорт, оно ж и так работает, а работает - не трогай.
Вообще мне больше нравится определение технического долга как разницы между сложностью проекта и экспертизой команды. Сложность проекта растет всегда, экспертиза растет медленнее и регулярно падает вследствии изменений в составе команды. Так что технический долг и экспертизу можно условно отобразить на графиках, показать менеджерам и попросить бабла на рефакторинг. Они такое понимают когда графики.
Правильно замечено: "кодовая база без реального владения со временем деградирует". Сколько людей, столько мнений. И даже, если все профессионалы высокого класса, нужен координатор, чтобы привести к единому соглашению и следить, чтобы все придерживались единой линии.
По-моему, вы всё поняли с точностью до наоборот ))
У кодовой базы всегда ЕСТЬ реальный (безо всяких оговорок) владелец. Это контора, которая наняла программистов. Проблема в том, что такое владение обезличено и неэффективно. Владельцы компании могут вообще не разбираться в коде, а нанятые кодеры рассуждают по формуле «Оно моё? Меня е..т?». Вот к этому и сводится проблема «кодовая база без реального владения со временем деградирует». То есть, не хватает не супервладельца кодовой базы, а владельцев отдельных частей, которые будут приглядывать за ними. Как говорил Ленин, «хозяйчиков».
Чтобы её решить, можно сделать программистов квази-владельцами: ты не можешь продать свой код, но можешь писать его как посчитаешь нужным, неся за свои решения всю полноту ответственности (ограниченную трудовым договором). А далее всё зависит от качества нанятых людей. Если они не дураки, то будут тащить и внедрять у себя хорошие практики и инновации (а дураков делать квази-владельцами себе дороже).
Но чтобы это квази-владение работало, к нему нужно относится всерьёз. Какое же это владение, если к тебе пришёл какой-то, извиняюсь за выражение, координатор, который, в отличие от тебя, не смотрит 12 часов в день на код твоего модуля, и не разбирается во всех нюансах, и начал тебя приводить к единой линии? Это уже не владение, а чайка-менеджмент: прилетел, поорал чаечкой, насрал и улетел в туман.
Чтобы её решить, можно сделать программистов квази-владельцами: ты не можешь продать свой код, но можешь писать его как посчитаешь нужным, неся за свои решения всю полноту ответственности (ограниченную трудовым договором). А далее всё зависит от качества нанятых людей. Если они не дураки, то будут тащить и внедрять у себя хорошие практики и инновации (а дураков делать квази-владельцами себе дороже).
Все с точностью наоборот: если программисты - дураки, то они дадут навесить на себя эту дополнительную ответственность за так (про деньги я тут не увидел) и будут тратить дополнительное время и силы, чтобы сделать лучше код, который принадлежит не им, а предпринимателю. А если не дураки, то вспомнят старую советскую присказку "гудит, как улей, родной завод, а мне-то..." (далее непечатно) и будут работать, как работали - в формальном соответсвии с принятыми на предприятим стандартами ( по простому - "на отъевяжись"). Все равно, ведь, если смотреть в корень - деньги-то программисты по факту получают за потраченное время и силы. И если из-за плохого существующего кода потребуется потратить дополнительное время, чтобы добавить новую функцию, то программисты ничего не теряют: им за это потраченное время заплатить должны сполна.
Вне IT есть на это хорошая аналогия: материальная ответсвенность. Если где-то требуется, чтобы с материальными ценностями не случилось то, что с титановыми шариками из анекдота ("один - сломал, другой - потерял"),то там с работниками заключают договор на условиях полной материальной ответсвенности. За что платят работникам больше денег.
Вот и здесь - ответственность за качество кода должна компенсироваться компенсацией. Как именно - это, однако, вопрос сложный, с матценностями-то проще. Но, по-любому, брать на себя ответсвенность за качество кода забесплатно - это IMHO признак дурачины.
Статья лишний раз подтверждает, что "играть" в разработку надо только в долгую и компании, и команды разработки должны совместно совершенствовать продукт
Компания получает надёжный продукт и сильную команду. Команда получает сильную компанию, в которой реально расти и развиваться годами
Компания получает надёжный продукт и сильную команду. Команда получает сильную компанию, в которой реально расти и развиваться годами
"Команда" обычно ничего не получает. По той простой причине, что обычно команда объективно (т.е. как группа людей с общими материальными интересами) не существует. А существует обычно группа наемных работников, каждый их которых получает оплату по своему индивидуальному трудовому договору. При этом сумма договора, в среднем, определяется не отношением компании, а балансом спроса-предложения на рынке труда. То есть работники - ни каждый индивилуально, ни группа в целом - ничего материального не получают. Моральное удовлетворение - возможно получают, но стоит ли работать за "спасибо" (вопрос риторический)?
Получать команда может только если она действительно существует объективно: например, если команда - это артель, которая подряжается выполнять определенную работу за определенные деньги. И при этом - сама решает вопросы, кого в артель брать, кому сколько из общей доли платить, и кого попросить покинуть артель. Вот тогда команда получает эту самую сильную компанию, как клиента. Но обычно такой тип отношений работников и работодателей не принят.
PS Кстати, метод манипуляции, когда группу людей, никакими интерсами не связнную объявляют "командой" и хотят, чтобы они совместно действовали в интересах манипулатора - этот метод используется не только в трудовых отношениях, а много где - в социальной психологии имеет даже специальное название: "техника гранфаллуна". Происхождение термина (тем, кто с боконизмом не знаком и не знает, что гранфаллун - это каррас, обращающийся вокруг ложного вампитера) и описание метода можно найти, к примеру, в известной монографии Чалдини (в разных изданиях она называется "Психология влияния" или "Влияние").
Все так, но в реалиях сегодняшнего рынка такого все меньше. Знаю лично несколько прецедентов, когда команда разработки всем составом куда-то уходила или наоборот приходила в компанию и так из раза в раз. А там где компания понимает, что такое настоящая долгосрочная мотивация (в том числе и денежная) такие команды задерживаются надолго
Достаточно узнать кто поддерживает какие-то наиболее важные участки крупных и важных систем. Очень часто это будет либо старая команда, либо команда, где основной костяк "старички". Невидимая рука рынка диктует условия, все больше компаний вкладываются в свои ИТ команды на долгосрок
Невидимая рука рынка диктует условия, все больше компаний вкладываются в свои ИТ команды на долгосрок
Повторяю: команды не существует. И вообще, есть примета: когда начальник говорит "Мы - команда", то это означет, что он хочет наеобмануть работников. А существуют отдельные работники, зарплата каждому из которых платится отдельно.
И да, обман наемных работников обходится компаниям дешевле, чем честно и без всякой лапши на уши платить работникам зарплату побольше - то, ради чего они, собственно, и работают. А потому неведимая рука рынка и толкает компании в эту сторону. То есть, это не владельцы и их управляющие такие, а жизнь такая.
Технический долг может накопиться даже если процессы разработки были корректные.
Но есть устаревание технологий и платформ.
Есть ситуации с лицензиями или тем, что какие-то технологии или платформы вообще пропадают, и надо мигрировать.
И это может привести к тому, что технический долг появляется из-за внешних факторов.
Причем изменения могут быть таковы, что архитектура продукта становится неидеальная для новых условий, нужен рефакторинг, переосмысление.
Если мы делаем автомобиль, а потом делаем новые фичи, фонарь, АКП, подушки безопасности, центральный замок, а потом еще и кондиционер. И оказывается для грамотного внедрения кондиционера просверлить пару дырок не очень хорошо. А для климат-контроля нужно вообще переосмыслить салон, что уже приличная переработка.
А потом захочется бензин поменять на батарею. И тут вообще с нуля все переосмыслить надо.
Примерно так и разработка - бизнес накидывает новые фичи, и когда проходит определенное время под весом множества новых фич понимаешь, что было бы неплохо переписать часть продукта с нуля, чтобы было проще это все внедрять.
В общем я не согласен, что дело все в плохо организованных процессах. Дело исключительно в том, что архитектор с девелоперами должны иметь бюджет и ресурсы на технические задачи, и бизнес должен это осознавать, выделяя эти ресурсы и бюджет.
На хабре уже была статья на эту тему - "О важности владения кодом" - https://habr.com/ru/post/710166/
В ней очень подробно разбирался этот вопрос. Рекомендую к прочтению всем интересующимся данной темой.
Та статья начинается с неверного утверждения
Владеет кодом тот, кто его регулярно поддерживает.
Неверное оно потому, что кодом владеет тот, кто владеет авторскими правами на него. А наемный работник обчыно передает владельцу предприятия авторские права весь на создаваемый им по поручению нанимателя код. А в наиболее запущенных случаях (хотя в Богоспасаемой такие случаи - редкость) - вообще на весь код, написанный им в период работы на этого нанимателя.
Наниматель же может, по согласованию с наемным работником и за оговоренную компенсацию, передать этому работнику ответственность за этот код. Но ответственность - это не владение, право распоряжения кодом при ней весьма ограничено.
А потому та статья IMHO вряд ли заслуживает внимания.
Деградация кода — это результат неправильной организации процессов