GD Star Rating
loading...

Привет коллеги. У меня к вам серьёзный вопрос без КПДВ. Как у вас в компаниях регулируется политика применения всяких хороших практик при разработке?

Может у вас есть какой–то большой талмуд, где написано “покрывай код тестами минимум на 70%” и “не разрабатывай проект без CI” и обещается грозная кара за их невыполнение? Или каждый ПМ сам определяет такой набор правил и их внедряет (и кстати что делать если ПМ без девелоперского бэкграунда?). Или вы просто берёте на работу людей которые сразу искаропки всё делают хорошо и правильно? Или просто уговариваете каждого прислушаться к голосу разума и быть паинькой?

Если вы работаете на аутсорсе, как вы уговариваете заказчиков в необходимости выделения человеко–часов на обеспечение правильного процесса и практик?

Админы и сочувствующие посетители hardblog.net посчитали злободневным:вечные ссылки и продвижение сайтов

22 Responses to Привет коллеги.

  1. Sukon:

    Приходится насаждать полезное, доброе и вечное. Хорошо, что это делается по указке сверху и даже самым тупым индивидам приходится соответствовать – иначе остаются без бонусов (естественно, это все усложняется дурацкими метриками, понятными даже (read: только) менеджерам – например, Maturity Level).

  2. Lagapp:

    : Собственно нам уже понятно что надо насаждать, но мы всё ещё не понимаем как это правильно делать. Многие вещи хорошо работают в отдельных командах или проектах (заслуга ПМов и девелоперов), но я не понимаю как это вытащить на уровень компании.

  3. Xuaapp:

    : начальству далёкому от программирования доказывать вечное и доброе всегда тяжко – тут нужен индивидуальный подход и работа на уровне понятных примеров. Например, твой главный босс увлекается формулой один. Расскажи ему как грамотно устроены питы у команд и проведи аналогию с программированием.

    Вобщем, как-то так.

  4. Lagapp:

    С мотивацией начальства проблем нет, интересует именно механизм внедрения этого всего.

  5. Sukon:

    : имеет смысл сделать в виде скрама – внедрять какую-то одну фичу в команду, смотреть как она работает, если нравится оставлять, не нравится – менять на что-то другое. проблема в том, что без имеющейся CI инфраструктуры и как минимум аджайл стиля разработки очень сложно оценить эффект от любого нововведения.

    скрам нам тоже “внедрили” сверху, причем даже там где не надо. типа пусть будет везде, где не пригодится – уберем. один тим быстро перешел на канбан, потому что им спринты в ресерче не нужны.

    в общем путь один – пробовать.

  6. Nasgreen:

    Блин, вот и так зло и сяк зло. Так можно и до исползования дизайн паттернов в хелоу-ворлд приложениях дойти.

  7. Nasgreen:

    : в общем, я считаю, что даже “самую лучшую” практику нельзя бездумно насаживать сверху.

  8. Xuaapp:

    : потому беркус и пишет: в общем путь один — пробовать.

  9. Fiaer:

    Я сегодня в своём куске кода, который когда-то старался-пытался в сторону быстродействия закручивать, нашёл чужую вставку. Там в цикле по не хилому количеству записей идёт запрос к полу-ебанистически огромной таблице. при этом другие поля той же таблицы заполняются несколькими строчками выше в один запрос, то есть ещё одно поле там выше дописать ума не хватило.
    А директор ИТ, руководитель отдела в 50 рыл, про всю эту ебалду заявил “да наверное ок”.
    Вот, блядь, и как с такими внедрять информационную систему управления предприятием, а? Они, блядь, про юнит-тесты наверное даже не слышали. Соглашение по кодированию больше года лобирую. Хотя бы минимальное, чтобы выравнивание хоть какое-нибудь было.

  10. Nasgreen:

    : задай им жару, пиши все ок. а потом удаляй все переносы строк и комить!

  11. Lagapp:

    : да, у меня была мысль ввести категории проектов от “прототип-однодневка” до “ентерпрайзная хрень на 100500 человеко-месяцев” и разные требования к ним.

  12. Lagapp:

    : у нас все за до самого верху, по крайней мере на словах. Вопрос наверное наполовину организационный: как именно это всё внедрить так чтобы не получилось “бездумно и сверху” с закономерным сопротивлением снизу?

  13. Sukon:

    : Внедряй снизу же!

  14. Lagapp:

    : Сегодня один мобильный девелопер в моей комнате ругался что тестеры не юзают test flight. Другой порывается наконец взвести CI для мобильных проектов и изучает git. Влияю я так на них штоле своим присутствием? (вот только два дня как переехали и я с ними сижу).

  15. Sukon:

    : Распечатай свой портрет в полный рост и повешай в каждый кабинет напротив входа.

  16. XawSport:

    У нас была такая ситуация. Был проект, который делал один мегамозг, сам себе PM и архитектор, который клал болт на все возможные практики. Он вертел на нём принципы ООП, считая инкапсуляцию недоразумением. Тащил в продакшн код какие-то нелепые беты JBoss-а, только потому, что там поддерживался EJB3.1, а потом сам вручную латал в нём дыры, отсылая патчи разработчикам JBoss-а (байка, наверное, но за что купил, за то и продаю). У него в подчинении были два программиста, которые не рисковали особо с ним спорить. Надо ли говорить, что спустя 7-8 месяцев разработки проект провалил все сроки, жутко глючил, и конца и края этому было не видно. Мегамозга выгнали ссаными тряпками, большую часть написанного кода пришлось выкинуть.

    Босс, видимо, схватился за голову, долго думал и, в конечном итоге, решил дать шанс правильным, прогрессивным подходам и практикам. На смену мегамозгу пришёл толковый чел из Интела, который на собственной шкуре, будучи сначала тимлидом, а потом PM-ом, прекрасно прочувствовал полезность eXtreme Programming-а при разработке и Scrum-а при планировании и управлении процессом разработки.

    Я пришёл к самому началу второй попытки. С тех пор уже прошло 7 месяцев, и могу сказать, что более эффективного процесса я за свою практику не встречал. При том, что мы делаем довольно сложную штуку, багрейт у нас низкий. В этом есть прямая заслуга процесса:
    – Используется TDD, есть ещё набор интеграционных тестов, а все юзкейсы покрываются функциональными тестами, которые прогоняются на каждый коммит.
    – Программисты работают в парах, нет разделения людей по модулям или фичам. Collective code ownership в действии.
    – Рефакторинг не откладывается на “когда-нибудь после релиза”. Если надо улучшить код, это делается прямо сразу, без дальнейших отлагательств. Если учесть, что он покрыт тестами, делать это не так уж и страшно

    Помимо налаживания процессов, заслуга человека из Интела в том, что он помог подобрать правильных программистов, а именно тех, для кого заветы из книжки Clean code – не пустой звук, тех, кто может объяснить, в чём заключаются принципы SOLID, и как их применить.

    Короче, тут сочетанное влияние факторов, но результатом я, как участник команды, очень доволен.

  17. XawSport:

    : если бездумно, то любую идею можно изосрать, на мой же взгляд, лучше попробовать, чем не попробовать.

  18. EnoLt:

    : я аж прослезился. хорошая история такая, душевная 🙂

  19. Xuaapp:

    : да! А нормальный рефакторинг… Господи, я ебал начальство на эту тему три ёбаных года. А потом рестарт и дождался! Я просто счастлив!

  20. Sukon:

    : Конечно низкий багрейт, ведь в скраме багов нету. Он у вас вообще должен быть нулевым, сдается мне, вы что-то не по скраму делаете, колись!

  21. Nexhlam:

    : наверное от холода глаза заслезились?

  22. Rotko:

    Начальник отдела разработки для этого и создан, чтоб внедрять новое и развивать свой отдел. Если у вас возникает такой вопрос, то вам или надо нанять такого чела, или поменять текущего. А он уже найдет подход. Взваливать подобные обязанности на ПМ опасно :), обязанности ПМа лежат в другой области. А рзрабы сами не организуются, как показывает практика.

Добавить комментарий