Комментарии 22
Красиво) Видимо команда слаженная, и нету выгоревших людей, разной степени токсиков и социопатов, дизбаланса в уровне навыков, и ревностного отношения к собственному коду :D К сожалению, я видел только другой мир — кровавые кранчи в комманде гениев, где каждый человек — целый отдельный домен/отдел в больших компаниях, и такими правилами можно, разве-что, извините, "подтереться". Работу нужно делать, не пере-ссориться, спасали только тим-билдинги :)
спасали только тим-билдинги :)
А спасали раз и навсегда, либо только на какой-то время?
21 кодексо-принцип — и не упомнишь все, талмуд целый.
может стоило сократить до 7 заповедей?
может стоило сократить до 7 заповедей?
Ну оно же не на каждый день: базово, вы сначала договорились с коллегами через механику, если все идет по плану, то апеллировать к страничке и нет необходимости. Как и любой свод правил, он обеспечивается какими-то повседневными инструментами — например, с bus factor можно делиться на обсуждении задач на рабочие группы так, чтобы там был и человек с опытом в области, так и те, кто только краем уха слышал. И так по каждому пункту.
У нас в Альфа-Банке мы это назваем "стандарты разработки" и формируются они по RFC https://www.ietf.org/rfc/rfc2119.txt
А внутри команд пользуемся Agile манифестом и лично я при code review использую подходы Гугла https://google.github.io/eng-practices/review/ хотя у нас тоже есть правила code review
Спасибо, интересно! Касательно подходов к код-ревью, у нас одна из команд делилась таким чек-листом, у другой вообще своя философия. Тут, как и везде, сто цветов и фломастеры разные)
Эти "правила" работают только с правильным настроем и будут работать неправильно, если их читать с другим.
- "Мы не делаем ничего зря" — прекрасное правило для того, чтобы все начали отрицать потраченное зря время и сделанные ошибки.
- "У нас есть список обязательных знаний" — вообще прекрасное правило, если твое трактование одного из указанных принципов не совпадает с консенсусом команды, тебя могут объявить неучем и попросить самовыпилиться?
- "Мы не переписываем проекты с нуля" — неоднократно попадал в ситуацию, когда легче переписать небольшой компонент с нуля и постепенно перетащить на него всех клиентов старого. Одновременно с "мы следуем принципам и не спорим" — вообще волшебно.
- "Мы не стремимся к 100% coverage кода, но у тестируемых методов обеспечиваем 100% coverage" — никакие проценты statement coverage не говорят о качестве этого покрытия. Даже если это coverage одного метода. У меня даже картинка есть на это.
- "и не удаляем строки с мыслью “кажется, это не нужно" — порой, это единственный способ узнать, что это действительно не нужно.
- "Читаемость важнее скорости и краткости" — только до тех пор, пока скорость не важнее читаемости и краткости.
Ну и в целом какая-то мешанина принципов для разработчиков и для непонятно кого:
- "Мы не аутсорсим разработку биллинга" — счастливый заказчик попросит, и будете аутсорсить.
- "Мы не меняем приоритеты спонтанно" — счастливый заказчик попросит, и будете 10 раз в неделю менять.
В целом мысли интересные, но относиться к этому стоит как к очередной "истории успеха": вреда такое очередной команде может потенциально принести больше, чем пользы. Особенно, в долгосрочной перспективе.
Ну и в целом какая-то мешанина принципов для разработчиков и для непонятно кого
Насколько я понял из статьи — это мешанина принципов для одной конкретной команды. Отсюда специфика типа "не аутсорсим биллинг". Это команда по разработке биллинга в продуктовой конторе — откуда там возьмется "счатстивый заказчик"?
Основой посыл статьи — не трансляция принципов, которые сильно специфичны (они, кстати, под катом — я туда в первом прочтении статьи даже не смотрел). А в подходе, который таки универсален.
Выжимка из статьи: "Собираем все негласные договоренности и принципы в команде — и записываем в документ, на который можно сослаться".
Добрый день, вы правы в том, — это специфика конкретной команды в конкретной компании. Так что это скорее история про «мы тут попробовали, вот такая штука получилась, может кому-то пригодится и захочется адаптировать у себя».
Слепо копировать опыт, конечно, не стоит) Часть практик (например, про не переписывание с нуля) стала, по сути, договоренностью и передачей опыта старичкам новичкам — ну потому что как-то пробовали, но оказалось, что всем проще и выгоднее договариваться с бизнесом на выделенное время для закрытия техдолга в спринтах.
Как и любой принцип в списке, его можно поменять, вынеся свою версию на голосование и собрав 100% за. В комментариях ниже привели отличный аналог из авиации: ты не выпячиваешь свое эго, но и не обязан молчать. Если что-то не ок, не критикуешь, а предлагаешь — и если команда согласна, то вы вносите поправку. В истории этого репозитория были такие случаи.
Ни одни правила не замещают с собой коммуникацию,
Слепо копировать опыт, конечно, не стоит) Часть практик (например, про не переписывание с нуля) стала, по сути, договоренностью и передачей опыта старичкам новичкам — ну потому что как-то пробовали, но оказалось, что всем проще и выгоднее договариваться с бизнесом на выделенное время для закрытия техдолга в спринтах.
Одновременно с «мы следуем принципам и не спорим» — вообще волшебно.
Как и любой принцип в списке, его можно поменять, вынеся свою версию на голосование и собрав 100% за. В комментариях ниже привели отличный аналог из авиации: ты не выпячиваешь свое эго, но и не обязан молчать. Если что-то не ок, не критикуешь, а предлагаешь — и если команда согласна, то вы вносите поправку. В истории этого репозитория были такие случаи.
Ни одни правила не замещают с собой коммуникацию,
Мне кажется, что переносить надо не имеющуюся версию манифеста, а именно процесс его составления (в качестве базового варианта — какие-то первые версии манифеста). В текущем виде с ним согласятся, потому как он за всё хорошее против всего плохого и не соглашаться с ним некузяво, но выполнять не будут. А опыт составления группого договора бесценен.
Я бы с чисто практической точки зрения поменял первый пункт «Мы следуем принятым принципам, независимо от согласия с ними» на нечто близкое к традициям авиационных CRM (cabin resource management): «Выполняй, или объясняй». То есть если ты выполняешь принятые правила или процедуру — это по-умолчанию OK. И ты можешь отступать от утвержденной процедуры при условии (!) что можешь объяснить причину и цель такого действия. В идеале — до того, как выполнение нестандартной процедуры началось («брифинг»), но можно и после — если действие неотложное («сообщение о проблеме»). При этом, разумеется: «не успел», «не подумал», «думал, прокатит» и все в таком духе — надлежащими объяснениями не являются.
Это — с одной стороны, не лишает людей гибкости в реальных ситуациях, и дает понимание, что стандарт — не удавка, а лучшая практика. С другой стороны — заставляет давать обратную связь о ситуациях, когда стандарт оказался неприменим. И дальше можно решать — то ли это разовая ситуация, ради которой менять стандарт нет смысла (если в стандарте описать все что только можно — он будет незапоминаем, нечитаем и неприменим) — то ли ситуация частая/опасная/whatever — и ее надо пихать в стандарт, чтобы в следующий раз не экспериментировать наживую.
Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков. Они там по краю ходят — в том смысле, что можно одной простой ошибкой угробить сразу много народа. Поэтому жизнь их заставляет придумывать всякие интересные штуки для предотвращения неприятных ситуаций. Напрямую в разработку это, конечно, не перенести — иначе разработка упадет под гнетом предотвращения рисков и стоить будет о-го-го сколько! Но отдельные элементы — это прямо вот что доктор прописал. Особенно, для ответственных приложений и сервисов…
Это — с одной стороны, не лишает людей гибкости в реальных ситуациях, и дает понимание, что стандарт — не удавка, а лучшая практика. С другой стороны — заставляет давать обратную связь о ситуациях, когда стандарт оказался неприменим. И дальше можно решать — то ли это разовая ситуация, ради которой менять стандарт нет смысла (если в стандарте описать все что только можно — он будет незапоминаем, нечитаем и неприменим) — то ли ситуация частая/опасная/whatever — и ее надо пихать в стандарт, чтобы в следующий раз не экспериментировать наживую.
Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков. Они там по краю ходят — в том смысле, что можно одной простой ошибкой угробить сразу много народа. Поэтому жизнь их заставляет придумывать всякие интересные штуки для предотвращения неприятных ситуаций. Напрямую в разработку это, конечно, не перенести — иначе разработка упадет под гнетом предотвращения рисков и стоить будет о-го-го сколько! Но отдельные элементы — это прямо вот что доктор прописал. Особенно, для ответственных приложений и сервисов…
Вообще, жутко полезно хотя бы по-диагонали посмотреть номативку атомщиков и летчиков.
Спасибо за интересную наводку. А можете поделиться хорошими, на ваш взгляд, примерами, если не сложно?
Я лично с большим вниманием прочитал гайды по CRM (начать можно с видео и статей Дениса Оканя (https://denokan.livejournal.com/). Там много интересного как раз о правилах и процедурах: зачем, почему, как учить, и т.д. Плюс даются паттерны, как обсуждать проблему в условиях высоких рисков и ограниченного времени, не скатываться в борьбу характеров, и т.д.
Из авиации же — «принцип черной кабины»: нормально работающая система не должна привлекать к себе внимание или требовать постоянных проверок. Однако, любые отказы и аномалии должны быть явно и однозначно обозначены персоналу.
У атомщиков я с удовольствием стащил понятие «максимальной проектной аварии (МПА)», и принцип построения системы защиты так, чтобы в случае МПА все были живы и здоровы. Оттуда же — аварийные действия персонала по приведению системы в безопасное состояние не должны требовать сложных решений и рассудочных действий. В идеале — нажал кнопку аварийной защиты — и оно само, уже тебя ни о чем не спрашивая — сбросит, заглушит, расхолодит, и т.д. Потом в спокойной обстановке будете разбираться, что к чему было…
Моя адаптация этого принципа в работу была примерно в 2004 году — инструкция по переводу довольно большой ИТ-системы на работу в резервном режиме (другой сервер, резервная серверная примерно в 20 км). Эта инструкция содержала два пункта: первый — зайти пользователем таким-то, пароль такой-то на сервер IP такой-то. Второй — выполнить команду такую-то, переход системы в резервный режим произойдет в течение 3-5 минут автоматически. И мне было не важно, кто будет это делать — программист, администратор, или хотя бы слесарь КиП: чье тело найдут по телефону, тот и будет делать! Не важно, хочет ли он спать, пил он вчера или нет, знает ли особенности системы, и т.д. — если команда прошла, остальное от него не зависит.
P.S. Реальный переход в резервный режим был один раз примерно за 6 лет работы.
Из авиации же — «принцип черной кабины»: нормально работающая система не должна привлекать к себе внимание или требовать постоянных проверок. Однако, любые отказы и аномалии должны быть явно и однозначно обозначены персоналу.
У атомщиков я с удовольствием стащил понятие «максимальной проектной аварии (МПА)», и принцип построения системы защиты так, чтобы в случае МПА все были живы и здоровы. Оттуда же — аварийные действия персонала по приведению системы в безопасное состояние не должны требовать сложных решений и рассудочных действий. В идеале — нажал кнопку аварийной защиты — и оно само, уже тебя ни о чем не спрашивая — сбросит, заглушит, расхолодит, и т.д. Потом в спокойной обстановке будете разбираться, что к чему было…
Моя адаптация этого принципа в работу была примерно в 2004 году — инструкция по переводу довольно большой ИТ-системы на работу в резервном режиме (другой сервер, резервная серверная примерно в 20 км). Эта инструкция содержала два пункта: первый — зайти пользователем таким-то, пароль такой-то на сервер IP такой-то. Второй — выполнить команду такую-то, переход системы в резервный режим произойдет в течение 3-5 минут автоматически. И мне было не важно, кто будет это делать — программист, администратор, или хотя бы слесарь КиП: чье тело найдут по телефону, тот и будет делать! Не важно, хочет ли он спать, пил он вчера или нет, знает ли особенности системы, и т.д. — если команда прошла, остальное от него не зависит.
P.S. Реальный переход в резервный режим был один раз примерно за 6 лет работы.
Это уровень, безусловно. Чем то напомнило книгу о том, как надо общаться в IT команде, не помню какого автора, но обложка была красная. Был бы благодарен если бы кто напомнил.
В списке правил есть конфиденциальная информация? Хочется прочесть все 43 пункта в репозитории. Планируете ли сделать репозиторий с правилами публичным?
Привет!
Наверное, не до конца мы четко написали — в общем, исходно было 43 пункта, но в процессе обсуждений, приоритизации, голосований и этого всего какие-то пункты укрупнялись, какие-то отвергались. И список похудел до 27.
Тк команда им пользуется, в ней и в правилах периодически происходят изменения — даже не знаем… Но если вопрос в том, как с кем-то поделиться без обвязки остальной историей, то Лёша Катаев выкладывал на hackmd для своего доклада копию.
Хочется прочесть все 43 пункта в репозитории
Наверное, не до конца мы четко написали — в общем, исходно было 43 пункта, но в процессе обсуждений, приоритизации, голосований и этого всего какие-то пункты укрупнялись, какие-то отвергались. И список похудел до 27.
Планируете ли сделать репозиторий с правилами публичным?
Тк команда им пользуется, в ней и в правилах периодически происходят изменения — даже не знаем… Но если вопрос в том, как с кем-то поделиться без обвязки остальной историей, то Лёша Катаев выкладывал на hackmd для своего доклада копию.
Да, верно, не совсем очевидно стало, что было 43, а осталось 27, и все эти 27 представлены в статье. Спасибо за уточнение.
Спросил про публичность репозитория именно из-за того, что думал, что есть еще что-то в списке. Если же нет, то вопрос отпадет. Не знаю как другим читателям, но мне достаточно статьи и этой ссылки на hackmd. Спасибо
Напомнило классику
Как-то мы у себя тоже писали «абстрактные правила» вроде ваших. Конечно, мы попроще подошли и не работали настолько тщательно над ними. Но в итоге, мы их повесили на стену и благополучно забыли в практическом плане. По ревью кода и оформлению у нас тоже есть регламент. Но если сам ревьювер не соблюдает их при разработке… Потому что не он их принимал… В общем, правила — это конечно хорошо, но их нужно еще и соблюдать. С аутсорсингом вообще в этом отношении все плохо.
Лучше всего работают технические регламенты-инструкции вроде того, как что настроить, чтобы работало.
Лучше всего работают технические регламенты-инструкции вроде того, как что настроить, чтобы работало.
Нельзя писать абстрактные правила. Даже если для «повесить на стену» есть выжимка на листе A4 — где-то должен быть дизайн-документ с объяснениями, ради чего то, или иное правило вводится.
Крайне частая ошибка — это пытаться документом изменить практику разработки. Докладываю — практика документами не меняется! Даже, блин, в армии — начальство пишет документы про одно, в низах делается другое (хотя субординация, и «служи — по уставу!»). Очень советую почитать что-нибудь про change management: нужно, чтобы сначала появилась потребность в определенном правиле, чтобы эта потребность стала осознанной, чтобы были ресурсы для выполнения правила — и только потом можно писать правило в документ.
Обязательно проверяйте — если выполняя ваши правила можно устроить «итальянскую забастовку», значит — правила плохие (не жизненные, работать не нарушая их — невозможно) и их следует переделывать.
Крайне частая ошибка — это пытаться документом изменить практику разработки. Докладываю — практика документами не меняется! Даже, блин, в армии — начальство пишет документы про одно, в низах делается другое (хотя субординация, и «служи — по уставу!»). Очень советую почитать что-нибудь про change management: нужно, чтобы сначала появилась потребность в определенном правиле, чтобы эта потребность стала осознанной, чтобы были ресурсы для выполнения правила — и только потом можно писать правило в документ.
Обязательно проверяйте — если выполняя ваши правила можно устроить «итальянскую забастовку», значит — правила плохие (не жизненные, работать не нарушая их — невозможно) и их следует переделывать.
Самое главное чтобы правила касались всех без исключения в равной мере. Иначе будет «Друзьям — всё, врагам — закон», то есть руководство будет использовать правила чтобы спрашивать, а самим на них будет плевать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Конституция» для разработчиков: как страничка на GitHub помогает нам не ругаться уже год