loading...
Привет коллеги. У меня к вам серьёзный вопрос без КПДВ. Как у вас в компаниях регулируется политика применения всяких хороших практик при разработке?
Может у вас есть какой–то большой талмуд, где написано “покрывай код тестами минимум на 70%” и “не разрабатывай проект без CI” и обещается грозная кара за их невыполнение? Или каждый ПМ сам определяет такой набор правил и их внедряет (и кстати что делать если ПМ без девелоперского бэкграунда?). Или вы просто берёте на работу людей которые сразу искаропки всё делают хорошо и правильно? Или просто уговариваете каждого прислушаться к голосу разума и быть паинькой?
Если вы работаете на аутсорсе, как вы уговариваете заказчиков в необходимости выделения человеко–часов на обеспечение правильного процесса и практик?
Приходится насаждать полезное, доброе и вечное. Хорошо, что это делается по указке сверху и даже самым тупым индивидам приходится соответствовать – иначе остаются без бонусов (естественно, это все усложняется дурацкими метриками, понятными даже (read: только) менеджерам – например, Maturity Level).
: Собственно нам уже понятно что надо насаждать, но мы всё ещё не понимаем как это правильно делать. Многие вещи хорошо работают в отдельных командах или проектах (заслуга ПМов и девелоперов), но я не понимаю как это вытащить на уровень компании.
: начальству далёкому от программирования доказывать вечное и доброе всегда тяжко – тут нужен индивидуальный подход и работа на уровне понятных примеров. Например, твой главный босс увлекается формулой один. Расскажи ему как грамотно устроены питы у команд и проведи аналогию с программированием.
Вобщем, как-то так.
С мотивацией начальства проблем нет, интересует именно механизм внедрения этого всего.
: имеет смысл сделать в виде скрама – внедрять какую-то одну фичу в команду, смотреть как она работает, если нравится оставлять, не нравится – менять на что-то другое. проблема в том, что без имеющейся CI инфраструктуры и как минимум аджайл стиля разработки очень сложно оценить эффект от любого нововведения.
скрам нам тоже “внедрили” сверху, причем даже там где не надо. типа пусть будет везде, где не пригодится – уберем. один тим быстро перешел на канбан, потому что им спринты в ресерче не нужны.
в общем путь один – пробовать.
Блин, вот и так зло и сяк зло. Так можно и до исползования дизайн паттернов в хелоу-ворлд приложениях дойти.
: в общем, я считаю, что даже “самую лучшую” практику нельзя бездумно насаживать сверху.
: потому беркус и пишет: в общем путь один — пробовать.
Я сегодня в своём куске кода, который когда-то старался-пытался в сторону быстродействия закручивать, нашёл чужую вставку. Там в цикле по не хилому количеству записей идёт запрос к полу-ебанистически огромной таблице. при этом другие поля той же таблицы заполняются несколькими строчками выше в один запрос, то есть ещё одно поле там выше дописать ума не хватило.
А директор ИТ, руководитель отдела в 50 рыл, про всю эту ебалду заявил “да наверное ок”.
Вот, блядь, и как с такими внедрять информационную систему управления предприятием, а? Они, блядь, про юнит-тесты наверное даже не слышали. Соглашение по кодированию больше года лобирую. Хотя бы минимальное, чтобы выравнивание хоть какое-нибудь было.
: задай им жару, пиши все ок. а потом удаляй все переносы строк и комить!
: да, у меня была мысль ввести категории проектов от “прототип-однодневка” до “ентерпрайзная хрень на 100500 человеко-месяцев” и разные требования к ним.
: у нас все за до самого верху, по крайней мере на словах. Вопрос наверное наполовину организационный: как именно это всё внедрить так чтобы не получилось “бездумно и сверху” с закономерным сопротивлением снизу?
: Внедряй снизу же!
: Сегодня один мобильный девелопер в моей комнате ругался что тестеры не юзают test flight. Другой порывается наконец взвести CI для мобильных проектов и изучает git. Влияю я так на них штоле своим присутствием? (вот только два дня как переехали и я с ними сижу).
: Распечатай свой портрет в полный рост и повешай в каждый кабинет напротив входа.
У нас была такая ситуация. Был проект, который делал один мегамозг, сам себе PM и архитектор, который клал болт на все возможные практики. Он вертел на нём принципы ООП, считая инкапсуляцию недоразумением. Тащил в продакшн код какие-то нелепые беты JBoss-а, только потому, что там поддерживался EJB3.1, а потом сам вручную латал в нём дыры, отсылая патчи разработчикам JBoss-а (байка, наверное, но за что купил, за то и продаю). У него в подчинении были два программиста, которые не рисковали особо с ним спорить. Надо ли говорить, что спустя 7-8 месяцев разработки проект провалил все сроки, жутко глючил, и конца и края этому было не видно. Мегамозга выгнали ссаными тряпками, большую часть написанного кода пришлось выкинуть.
Босс, видимо, схватился за голову, долго думал и, в конечном итоге, решил дать шанс правильным, прогрессивным подходам и практикам. На смену мегамозгу пришёл толковый чел из Интела, который на собственной шкуре, будучи сначала тимлидом, а потом PM-ом, прекрасно прочувствовал полезность eXtreme Programming-а при разработке и Scrum-а при планировании и управлении процессом разработки.
Я пришёл к самому началу второй попытки. С тех пор уже прошло 7 месяцев, и могу сказать, что более эффективного процесса я за свою практику не встречал. При том, что мы делаем довольно сложную штуку, багрейт у нас низкий. В этом есть прямая заслуга процесса:
– Используется TDD, есть ещё набор интеграционных тестов, а все юзкейсы покрываются функциональными тестами, которые прогоняются на каждый коммит.
– Программисты работают в парах, нет разделения людей по модулям или фичам. Collective code ownership в действии.
– Рефакторинг не откладывается на “когда-нибудь после релиза”. Если надо улучшить код, это делается прямо сразу, без дальнейших отлагательств. Если учесть, что он покрыт тестами, делать это не так уж и страшно
Помимо налаживания процессов, заслуга человека из Интела в том, что он помог подобрать правильных программистов, а именно тех, для кого заветы из книжки Clean code – не пустой звук, тех, кто может объяснить, в чём заключаются принципы SOLID, и как их применить.
Короче, тут сочетанное влияние факторов, но результатом я, как участник команды, очень доволен.
: если бездумно, то любую идею можно изосрать, на мой же взгляд, лучше попробовать, чем не попробовать.
: я аж прослезился. хорошая история такая, душевная 🙂
: да! А нормальный рефакторинг… Господи, я ебал начальство на эту тему три ёбаных года. А потом рестарт и дождался! Я просто счастлив!
: Конечно низкий багрейт, ведь в скраме багов нету. Он у вас вообще должен быть нулевым, сдается мне, вы что-то не по скраму делаете, колись!
: наверное от холода глаза заслезились?
Начальник отдела разработки для этого и создан, чтоб внедрять новое и развивать свой отдел. Если у вас возникает такой вопрос, то вам или надо нанять такого чела, или поменять текущего. А он уже найдет подход. Взваливать подобные обязанности на ПМ опасно :), обязанности ПМа лежат в другой области. А рзрабы сами не организуются, как показывает практика.