Управление разработкой бизнес-приложений
5,6
рейтинг
6 мая 2013 в 16:09

Разработка → Программисты-оптимисты


Мы, программисты, — оптимисты. Это проявляется во всем цикле разработки ПО от оценки сроков до написания кода и внедрения. Как показывает моя практика, в разработке ПО законы Мерфи работают в 100% случаев. Несмотря на это, я раз за разом сталкиваюсь с «программистами-оптимистами».

Топ «оптимистичных» допущений:

Мы все еще можем выпустить релиз на этой неделе в пятницу в 17:48, хотя в коде есть ошибки

Нет, не можете. Кроме исправления ошибок, вам нужно:
  1. Смержить/запулить этот код (вы же не ведете разработку в ветке из которой публикуетесь в продакшн, правда?)
  2. Опубликовать код на тестовом стенде и протестировать, в том числе регрессию
  3. Проверить конфигурации, миграции БД
  4. Забекапить продакшн
  5. Опубликовать изменения
  6. Протестировать продакшн
  7. Откатиться, если что-то пошло не так

Даже если все происходит в автоматическом режиме, вам едва-ли хватит 12 минут до конца рабочего дня для того, чтоб закончить. Обычно такие выкладки производятся впопыхах и заканчиваются глупыми ляпами на продакшне, переработками по ночам и/или в выходные, откатами к предыдущему релизу и переносу выкладки, либо комбинацией этих пунктов.

Решение о релизе/выкладке можно принимать только после того, как код написан и протестирован. Точно знайте сколько времени занимает выкладка, бекап и откат к предыдущей версии в случае эпик фейла. Всегда закладывайте самый пессимистичный вариант: вы выложитесь и вам, по тем или иным причинам, придется откатиться. На текущем проекте мы автоматизировали все выкладки и бекапы. На выкладку требуется 10 минут, на восстановление из бекапа: 10 минут, на минимальное смоук-тестирование: 2 часа. Значит, для выкладки на продакшн, я закладываю 3 часа времени.

Это займет три дня. А за день сможешь? Ну, может, смогу

Не идите на поводу у менеджеров. Менеджер, даже с техническим бекграундом, не знает всей подноготной. То, что может казаться простым и быстрым менеджеру, на самом деле может занимать гораздо больше времени. Менеджер всегда оценивает только трудоемкость реализации новой фичи. Ваша задача настоять на том, что вам нужно время на рефакторинг, тестирование, выкладку. Идя на поводу у менеджмента, раз за разом вы будете откладывать технический долг, пока его не накопится столько, что вы не будете знать с какой стороны подойти к рефакторингу. Требования меняются, никто не может сразу писать идеальный код, не больше и не меньше, чем потребуется. Если вы чувствуете, что костыли в этом месте аукнутся днями и неделями в будущем, лучше потратить лишние несколько часов сейчас и сдать фичу чуть позже. Объясните это менеджеру на его языке: сейчас этот рефакторинг обойдется нам в 8 часов. А если мы вставим костыли, то через месяц наш технический долг будет стоить 56 часов. Менеджеры обычно хорошо считают, и без труда умножат количество часов на ваш рейт. Помните, что никто, кроме вас не знает код лучше, поэтому вы лучше знаете, как делать лучше с технической стороны. Подробно о прессинге менеджмента можно почитать в статье «Как две недели?!».

О, это очень глупый баг, сейчас я быстренько его поправлю и все заработает. Тест писать ни к чему

Нет, баг — это повод написать юнит-тест. Если он появился, значит, что вы пропустили это поведение и у вас дыра в «покрытии кода». Нашли баг? Добавьте юнит-тест/интеграционный тест/тест-кейс в тест-план. Это избавит от «бумерангов» — багов, возвращающихся снова и снова.

Это очень простая фича, можно даже не добавлять ее в таск-трекер. Сделаю так, требования ясны

Нет, требования, наверняка, сложнее, чем кажется на первый взгляд. Возможно, что новые требования будут конфликтовать с существующим поведением системы. Если вы не добавите таск в трекер, то в любой спорной ситуации окажитесь крайним. Самый худший вариант — устная договоренность. У людей очень короткая память. Все задачи должны ставиться только в письменном виде. Подробно об управлении требованиями я писал в статье «Specification By Example – BDD для прагматиков».

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

Нет, всегда тестируйте, в первую очередь на «целевом» окружении/железе. Любая эмуляция — лишь модель. В реальных условиях могут всплыть непредвиденные обстоятельства: другая версия ОС, другие права, другая мощность процессора, объем оперативной памяти, другие открытые порты. Все что угодно.

Эта проверка здесь ни к чему. Никому не придет в голову пользоваться программой таким образом

Лишних проверок не бывает. Именно для таких случаев придумали исключения(exceptions). Вы не поддерживаете какое-то поведение/сценарий? Выбросите NotSupportedException. Все будет предельно ясно. А вот хуже, чем NullReferenceException сложно что-то себе представить. Это не дает никакой информации человеку, поддерживающему ваш код. Он не обязан рыться в стек-трейсе и искать низкоуровневые ошибки. Всегда обрабатывайте низкоуровневые ошибки и используйте свои понятные исключения. В .NET у исключения есть свойство InnerException, которое поможет сохранить информацию о более низкоуровневой проблеме. Неплохо про exception handling в .NET написано в статье «Безопасная работа с исключениями в C#».

Эту ошибку можно обработать и сделать вид, что ничего не случилось

Пустые try-catch блоки обычно появляются, когда в требованиях к ПО появляются надежность и отказоустойчивость. Такое поведение эквивалентно заметанию мусора под ковер, чтобы никто не увидел. Если вам нужна отказоустойчивость, — предусмотрите аварийный перезапуск системы. Первое, что вы должны сделать — логировать исключение и сообщать разработчикам. Можно отправлять письма разработчикам в случае ошибок, можно использовать мессенджеры, вариантов масса. Самое худшее, что можно сделать, это проигнорировать ошибку, потому что вы не знаете к каким последствиям это приведет. Слово «исключение» выбрано не просто так. Это подчеркивает, что поведение не запланировано и не является нормальным.

Это не бага, это — фича, на тесте БД пустая, на продакшне все нормально будет

Нет и еще раз нет. Если данные обязаны быть в БД, то включите их в выкладку. Изменили конфигурацию? Добавьте трансформацию конфига. Если какой-то кейс не проверен, в 9 из 10 случаев в нем найдется ошибка. На таком стенде невозможно провести демонстрацию. «Здесь вылезает ошибка, но на боевом ее не будет» — звучит ужасно. Если по каким-то причиам невозможно настроить тестовый стенд идентично продакшну (финансовые операции, платные аккаунты, настройки безопасности и т.д.), пользуйтесь стабами (stub), эмуляторами и аналогичными тестовыми аккаунтами. Приближайте ваш тестовый стенд к продакшну настолько, насколько это возможно.

Я пофиксил/обновил, вроде работает

Никаких «вроде». Если на стенде была ошибка любого рода, проверьте, что после вашего фикса/обновления не сломалось ничего другого. Заведите минимальный чек-лист проверки работоспособности приложения после обновления, например: залогиниться, купить что-то посмотреть пару-тройку страниц. Это избавит тестировщиков и ваших коллег разработчиков от многократных обращений к вам: «слушай, в товарах эксепшн, а в новостях старая ошибка пропала, но новая появилась». Воспринимайте такую проверку как нечто само-собой разумеющееся, как элемент личной гигиены. Вы же не задумываетесь, почему чистите зубы и умываетесь каждый день.

Фиг знает в чем была проблема, я перезапустил, оно заработало

Никаких «фиг знает. Вы должны точно понимать и пресекать любые возможности падения программы. Если вы решаете проблему перезапуском, вы боритесь не с причиной, а со следствием. Эта проблема гарантированно будет повторяться в самый неподходящий момент. Вас будут будить среди ночи, чтобы вы в очередной раз перезапускали приложение, потому что оно «свалилось». Всегда решайте проблему полностью. Приложению нужен регулярный ребут? Настройте автоматический перезапуск, локализуйте проблему, добавьте таск и исправьте это. Очень хорошо о вреде «шапкозакидательства» написано в статье «Что плохого в работе на результат».

Выполнение вышеописанных рекомендаций требует самодисциплины. Соблюдать их чертовски сложно, но законы Мерфи не подводили меня ни разу. Каждый раз, когда я делаю исключение, случается что-то непредвиденное, экстраординарное и незапланированное. Каждый раз, когда не получается сдать работу качественно и в срок, я расстраиваюсь, поэтому я стараюсь никогда не отступать от этих правил. В результате, я гораздо оптимистичнее, чем раньше смотрю на разработку ПО в целом. Я знаю, что не существует «слишком сложных» задач. Существуют задачи требующие достаточно много времени для реализации. Надеюсь, что мой чек-лист будет полезен другим разработчикам.
Максим Аршинов @marshinov
карма
70,0
рейтинг 5,6
Управление разработкой бизнес-приложений
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (87)

  • +33
    Я, когда читаю такие посты, сначала проникаюсь, представляю, как люди здорово работают, как у них все налажено так, что ничто не может пробить их отказоустойчивый процесс разработки, как им легко и спокойно работается в свое удовольствие. А потом, после минутных размышлений, неизменно прихожу к выводу, что если соблюдать все эти правила, добавить ко всему TDD, и еще и какую-нибудь agile практиковать, то когда же ж работать-то?! Никак не пойму, как же продукт движется, если все время уходит на саппорт процесса разработки.
    Я вот только первые два пункта не нарушаю, остальные регулярно :(
    • +11
      Я так тоже думал.
      1. Автоматизация: выкладок, бекапов, всего, что имеет смысл. Сначала кажется, что долго, а потом выясняется, что пара человеко-дней. Если над проектом работает пара десятков разработчиков, это экономит здесь час, там час, набегают дни и недели. Кроме этого, заваленные выкладки задерживают не только разработчика, но и тестировщиков и менеджеров.
      2. Если сложить это время, выясняется, что как раз на хот-пачти и и уходит все время. Обычно, принято считать, что полезна работа — это новые фичи, а не багфиксы и хотпатчи.
      3. Прерывания. Нет ничего хуже, чем когда «дергают». На то, чтобы вернуться обратно «в поток» тоже нужно время.

      Вы тратие на один час больше своего времени в краткосрочной перспективе. В долгосрочной экономите человеко-дни другим сотрудникам и себе (вас не дергают).
      • +4
        После одного из факапов я собрал всех и задвинул тезис «всё, что может быть автоматизировано, должно быть автоматизировано». Помогло.
        Правда, пришлось скрипты самому писать.
      • +4
        >пара человеко-дней

        Вот вы и сами демонстрируете заголовок вашей статьи
        • 0
          Я оценивал автоматизацию сборки и выкладки «абстрактного проекта в вакууме». Для больших и сложных систем это конечно займет больше времени. Я настраивал CI с нуля на четырех проектах, поэтому у меня уже есть некоторый опыт, чтобы говорить о таких сроках. Если тема настройки CI интересна, я могу написать tutorial на эту тему.
          • 0
            А в каком окружении?
            • 0
              TFS, TeamCity, .NET, ASP.NET MVC, Windows Services
    • +2
      У меня всегда такие же мысли. Увы, реалии зачастую такие, что всю работу нужно было сделать еще вчера, поэтому писать тесты, чекать и т.п. и т.д. тупо некогда. И зависит это не всегда от разработчика, ибо его ставят тупо перед фактом необходимости сдать все через час-два.
      • +2
        Поверьте, это у вас в голове. Не надо писать тесты на краткосрочных проектах. Это не рентабельно. Если ваше приложение будет работать достаточно долго, вы просто сами выроете себе могилу «сделай за час-два». Потом все-равно кому-то придется переписывать приложение с нуля, потому что ни один здравомыслящий подрядчик не возьмется разгребать такой код. Современный IT-рынок — рынок соискателя, а не работодателя. Вы в праве и должны организовывать эффективный процесс разработки.
        • +2
          Точно так же не рентабельно делать все красиво и правильно на тысячу, когда бюджета выделили сто рублей (а под «сделать за час-два» подразумевается обычно именно это).

          Я не спорю с тем, что Вы правы в целом, безусловно. Просто ситуации бывают разные и люди бывают разные. На это и хотел обратить внимание )
          • 0
            Существует множество клиентов, готовых выделить много тысяч за качественный продукт
      • +6
        Разработчику в наше время не так уж и тяжело поменять работу. Если менеджер/заказчик лезет в разработку, и рассказывает вам как делать Вашу работу — это очень плохо.
        • +3
          Так я и поменял ^.^
        • 0
          Как то выгнали из фирмы, потому что запрещал это делать.
    • +1
      Хм. Ну вообще-то на работу как раз больше времени остается. Все agile практики вообще-то направлены на минимальный уровень бюрократии и деланье того что нужно СЕЙЧАС. Если надо сейчас править баги то и правиш прямо сейчас (замечательное правило что баги со скрамборда всегда берутся первыми). Если нужен рефакторинг — рефакториш сейчас (а это из TDD). А вот запуски приложения и smoke-тестирование (это как раз и прогон минимально осмыслленого сценария на задеплоеном приложение) спасает огромное количество времени и вам и другим членам команды. По личному опыту — при процессе построенном по agile методологиям код реализующий нужную функциональность пишется куда быстрее.
    • 0
      Да, если всё это собрать вместе, то при изменении одного фрагмента кода, нужно будет подготавливать весь проект к этому как минимум три дня. Хотя… может это и не так много против того, что можно неделями ошибки выгребать потом.
  • +14
    >> никогда не отступать от этих правил.

    а вот это зло.
    Простейший пример, недавно(в начале весны) в воскресенье америка время двигала, а в РФ время уже не переводится. У нас и попадали сервера с фейсбуком связанные. Это было толи ночь толи утро нерабочего дня. Узнали об этом программисты благодаря экстренному смс уведомлению о проблемах на серверах. И фиксили прямо на продакшене. И пофиксили. Менеджмент и тестеры и вообще все остальные узнали о результатах в понедельник. Да это форс мажор, да это не часто происходит. Но, блин, на достаточно больших проектах разнесённых по многим странам такое бывает. И когда сервис лежит, хуже уже не сделаешь. И в этот момент нет никаких правил. Мотивированные люди сами знают что они могут делать всё для решения проблемы и решают её. Поэтому никогда не говори никогда. Я к тому что используя наборы правил, а этот набор достаточно хорош, надо знать и границы их применения и в определённые моменты отбросить и погрузиться в ничем не ограниченный цифровой драйв, который позволит в кратчайшие сроки делать то что обычно кажется невозможным.
    • +9
      Это правила «мирного времени». Если продакшн лежит — это другое. Естественно, что в этом случае нужно поднимать продакшн.
      • +8
        Вот, а в статье про это не написали. Именно правила мирного времени. И это надо помнить.
        • +4
          Я не знаю ни одного человека, который сказал бы «наши корпоративные стандарты запрещают поднимать приложение». По крайней мере, я бы не стал работать с таким человеком. А вот примеров «хоп-хоп, ща сделаю» у меня целый вагон.
        • +3
          Соблюдение правил «мирного времени» — позволяет избежать военного. Грубо говоря — чем больше кода у вас реально проверяется на тестовом стенде, чем ближе тестовая среда к «боевой» (и так далее по тексту) — тем меньше вероятность что на продакшене что-то пойдёт не так.
          • 0
            На тестовом надо не забывать еще тестировать все под нагрузкой. Гнать ботов на тестовый стенд и проверять все.
    • +9
      И когда сервис лежит, хуже уже не сделаешь

      Можно случайно стереть всю БД из-за неправильного запроса))
      • 0
        Можно. И можно сделать бюрократию на доступ к боевым серверам. Можно слить конфиг на тестовый и работать на нём. Меньше риска меньше скорость. Это выбор который мы делаем. Есть бекапы и репликация. Это выбор в, в данном случае, того кто фиксит. На его усмотрение. И чем меньше стоит между ним и сервером тем лучше, а он уж в праве выбирать путь. Опять же это работает только в случае высоко профессионального и мотивированного персонала.
  • +21
    Я вот раньше думал — какие все вокруг замечательные профессионалы! И тесты пишут на каждый чих и в проблемы вдумываются и всегда в график попадают и не забывают нас, нубов, научить. Когда же я научусь так?

    А потом уже сам поработал и повыпускал. Cвоими глазами увидел исходники многих знаменитых и коммерчески успешных продуктов, всех этих гениев клавиатуры… Когда б вы знали из какого сора растут стихи не ведая стыда :)

    В общем, не нужно принимать все близко к сердцу. Идеальная разработка — это сны о чем-то бОльшем и не более того :)
  • +13
    Я когда такие статьи читаю, мне идеальная разработка представляется как этакая религия. Есть заповеди, есть библии, есть апостолы и толкователи, попы и священники, есть церковь, при этом от верующего требуется «самодисциплина» и «самовоздержание» взамен на обещание райской загробной жизни; и смертные грехи, за которые попадаешь в ад, который кстати тоже есть.

    И, так же как с религиями, даже самые святые попы не без греха, а люди, которые не отягощают себя излишней божественной моралью, достигают большего в жизни

    Так что имейте веру и кайтесь ибо день суда релиз близок, либо идите пишите код, @#$%ь

    Аминь
    • 0
      Самодисциплина — да, религия — нет. Воздержание — вообще нет. Я писал не о процессе разработки, а о личной ответственности, мотивации разработчика и об уважении к другим членам команды. Какие чувства вы испытываете, если после апдейта из VCS проект не собирается или даже не стартует? А если коллега говорит, что исправил баг, вы заходите на главную страницу и видите там Exception?
  • НЛО прилетело и опубликовало эту надпись здесь
  • +17
    > Значит, для выкладки на продакшн, я закладываю 3 часа времени.

    Нет, значит выкладку на продакшн вы переносите на понедельник :) Никогда не планируйте релизов на пятницу, даже на утро.
    • +2
      Мне тоже больше нравится выкладываться по понедельникам.
    • +3
      И упаси вас Бог релизиться в конце года, числа эдак 28-29 декабря… :)
      • +7
        Зато российские пользователи до 11го ничего не заметят:)
      • 0
        А у некоторых как раз 1го и 2го января самые рабочие дни.
    • +4
      Нет, значит выкладку на продакшн вы переносите на понедельник :) Никогда не планируйте релизов на пятницу, даже на утро.

      А в понедельник пара тысяч сотрудников приходят на работу, а у них ничего не работает начиная от электронных пропусков и заканчивая 42-координатными сверхсовременными станками.

      Далеко не все можно релизить тогда, когда хочется девелоперам и менеджерам девелоперов. Иногда бывает совершенно наоборот и релизы допустимы, например, только в 18-00 пятницы, чтобы в случае форс мажора было 2 дня на откат и/или восстановление системы и вытекает такой график политики релизов из решаемых системой бизнес-задач.
      • +2
        > А в понедельник пара тысяч сотрудников приходят на работу, а у них ничего не работает начиная от электронных пропусков и заканчивая 42-координатными сверхсовременными станками.

        Альтернатива — все выходные ничего не работает, и разработчики все выходные матерясь откатывают релиз и разбирают что же случилось.
        А тестирование и стенд вам для чего? :)

        > чтобы в случае форс мажора было 2 дня на откат и/или восстановление системы

        Не исключаю и такое, если в выходные продакшн совсем никому не нужен, и можно спокойно накатить и потестить на продакшне.
        • +2
          А тестирование и стенд вам для чего? :)

          А тестовый стенд всегда меньше боевой системы. По этому я склонен верить Законам Мерфи, согласно которым всегда может найтись баг, который не проявляется на тестовой системе, но расцветает во всей красе на боевой. :)

          Альтернатива — все выходные ничего не работает, и разработчики все выходные матерясь откатывают релиз и разбирают что же случилось.

          Альтернатива — это наличие политики выкатывания релизов, которая вытекает из решаемых бизнес-требований. Правда такая политика должна быть не только технической, но и организационно-правовой, ибо переработки оплачиваются по двойному тарифу и прочие сопутствующие вещи типа организации допуска в офис в выходные и т.д. тоже должны быть отработаны.
    • +1
      У нас это правило прописано в регламенте, так же прекращается релиз новых версий за две недели до нового года.
    • 0
      Лучше выкладывать в четверг, тогда будет день реальной работы и два выходных на исправление страшных ошибок. Или два выходных для обкатки заказчиком.
      • +2
        От сервиса зависит еще. У некоторых наоборот, наибольшая активность в выходные — т.е. нужно чтобы в выходные все работало 100% стабильно и без разрывов.
        Вообще, нужно смотреть когда минимальное использование идет — тогда и планировать деплой апгрейдов, пусть хоть это будет в 2 часа ночи в субботу.
  • +1
    Многие случаи, это не оптимизм, а халатность скорее. Встречается регулярно, если с таким поведением не бороться — это становится нормой и укореняется. Я может поспорил бы только о юнит-тестировании каждого чиха. Но это вопрос скорее философский. :)
  • +1
    Я вот все никак не возьму в толк (уже не в первом топике), о каком-таком «откате» структуры БД (и уж тем более — о каком восстановлении БД из бэкапа) после релиза идет речь? Объясните, пожалуйста, как это все возможно, если данные пишутся в базу постоянно, машин много, а сайт нельзя останавливать даже на 10 секунд.

    Если изменился только код — то ради бога, можно откатывать-накатывать хоть до ночи. Но релиз — не релиз, если в нем не меняется база. Мне за 15 лет ни разу не приходилось сталкиваться с необходимостью что-то «откатывать» на продакшене. Как это бывает у других? Каков процесс? Почему вообще возникает необходимость откатывать базу и что под этим подразумевается? Почему вначале не протестировать, успешно ли накатывается база, на тестовом кластере со свежезалитой копией всех данных продакшена (или хотя бы с частью данных, достаточно однородной)?
    • 0
      У нас база бекаптися просто мейнтененс-планом + бекапы инстансов амазона. Необходимости откатывать БД на демо-стенде не было, но в случае чего есть 2 варианта отката. Откат удобен в случае неудачного обновления дев/тест-окружения. На них актуальность данных не так важна, а вероятность накатить фигню существует. Существуют системы, в которых запись производится гораздо реже, чем раз в 10 секунд. Зависит от приложения.
    • 0
      Например, новая версия приложения требует альтера на базу (ну или еще какого изменения структуры/данных).
      Проальтерили, обновили приложение — не взлетело. А старая версия кода с новой структурой БД не работает.
      Вот и приходится «откатывать» структуру, т.е. применять обратный альтер.
      • +2
        Был недавно на яндекс-субботнике, рассказывали про яндекс-диск. Так они там не структуру откатывают, а пишут патчи к старому коду, чтобы он поддерживал новую версию БД.
        • 0
          А если точек входа\платформ работающих со структурой 10? Ко всем патчи делать!
          • +2
            Сделать доступ к базе через апишечки! ^^
            • –1
              Ага, обернуть все в процедурки, дергать интерфейсы и получить дикий геморрой с поддержкой и версионированием :) Плавали уже, чуть не захлебнулись.
        • 0
          в патче к старому коду тоже ошибиться можно)
        • 0
          Вы не знаете, есть ли эта инфомрация в сети? Интересно было бы узнать, как в Яндексе это делают. Плохо себе представляю, как можно поддерживать столь сложные патчи.
  • +2
    Я что ли один тут пессимист? Мне всегда кажется что мы ничего не успеем, всё делаем медленно, большую часть времени закладываю на написание тестов, отладку и ввод в эксплуатацию. Пессимизм видимо начинает резко проявлятся, когда начинаешь отвечать за других программистов-оптимистов, не иначе.
  • –5
    Вы же не задумываетесь, почему чистите зубы и умываетесь каждый день.

    … вы серъёзно? Не чищу зубы несколько лет.
    • +1
      > Не чищу зубы несколько лет.

      И как, помогает?
    • +3
      Не чищу зубы несколько лет.

      Нету что чистить?
    • +1
      Ник надо оправдывать, а не позоритьтся на людях
    • +1
      Жирновато!
      image
  • –1
    Гы. Комикс по нашей с другом цитате. Ностальгичненько.
  • +1
    Забавная презентация почти в тему: Optimistic Developers vs Pessimistic Testers
  • 0
    Еще полезно вводить мораторий на релизы, мержи (и любые другие изменения в продакшене) в определенные дни. Скажем по пятницам, последние дни месяца, за 2 дня до праздников и так далее. Избавляет от геммороя в выходные дни.
    • +2
      На прошлой YAC был доклад от Google «Тестирование 2.0». Доклад ни о чем, зато слайды смешные.
      Докладчик: «В чем корень всех зол и багов?».
      Перелистывает слайд: «Fridays».
      Перелистывает слайд «Friday 17:00»
      Докладчик: «Серьезно, может вообще запретить комиты по пятницам? Как это происходит? Вы уже спишите к друзьям, девушке. Думаете о чем угодно, но не коде»
  • 0
    К сожалению, очень часто сопутствующими чертами оптимизма являются полное отсутствие критики и самокритики.
    Поэтому все радастна идут ногавно
    гу со временем.
    
  • 0
    Ох (: хочется высказаться по поводу сроков.

    Это, конечно, хорошо отстаивать сроки, но практика показывает, что если вы что-то делаете неделю — это не значит, что вы не можете сделать это быстрее. Поэтому прежде чем тупо упираться в свои представления сроков, хорошенько подумайте и оцените как условия, так и возможности.
    • +1
      Речь идет о зафиксированном объеме работ. Вы правы, что любая задача может иметь «full-banana» и «limited» реализацию. Например, «необходимо отображать на сайте документы для скачивания». Можно начать городить API, забирать эти ссылки через API от источников этих документов, поддерживать авто-обновление и еще много чего, а можно просто собрать необходимый список, положить эти документы на сервер со статикой и дать ссылки. Для конечного пользователя результат одинаков.

      Всегда существует объем технического долга. Вопрос в том, на сколько этот технических долг критичен. Недопустимо мириться с костылями в «ядре» системы и core-функционале. Я работал с несколькими проектами, в которых основная бизнес-логика была написана «на костылях». Такой подход приводит к чудовищному перерасходу средств и такому-же чудовищному качеству продукта в среднесрочной и долгосрочной перспективах. Я сталкивался и продолжаю сталкиваться с менеджерами, которые убеждают меня, что поменять какое-то бизнес-правило, лежащее в основе приложения, — дело пяти минут.

      Функционал, который делается для ограниченного количества пользователей, не является основным, и, возможно, в будущем, вообще не понадобится — совершенно другая история. Такой функционал я всегда предлагаю реализовывать «limited»-вариантом.
      • +1
        С вами согласен.

        Но хочется поделиться личным опытом: участвовал я в проекте, в котором на «каждый функционал» отдавалось столько времени, сколько нужно разработчикам. В итоге всё равно получилась система с костылями (тут в тему будет картинка «Уж в этот раз я всё сделаю правильно»).

        Зная о таком положении дел, менеджеру очень трудно согласиться дать больше времени. Этому надо учиться (:

        p.s. Спасибо за статью!
        • 0
          Тим-лид должен со своей стороны тоже должен ограничивать разработчиков. У тим-лида больше опыта. Он и должен предотвращать синдром второй системы.
  • +6
    Мне подобные статьи напоминают советы в женских журналах, которые иногда читает моя жена, цитируя мне некоторые ради «чисто поржать». Суть в том, что там в КАЖДОМ номере рассказывают, какие надо делать упражнения, косметические процедуры ну и остальное чего там женщины делают. И всё это нужно делать обязательно, каждый день. Понимает ли журнал, что если женщина будет делать каждый день всё то, что написано хотя бы в 5-ти номерах подряд, то это будет занимать примерно 40-50 часов в сутки? А если взять журналы за пару лет — то и все 500 часов в день. А журналам пофиг на реальность — они рекомендуют «делать правильно». Так и вот эта статья — всё круто, если бы время было безразмерно, а понятия дедлайнов не существовало в принципе. А так — фантастика да и только.
    • +1
      А можно более подробно, что из вышеописанного займет у вас 40-50 часов в сутки? Может быть вы пользуетесь инструментами, которые вам не подходят и работают слишком долго?
      Вы же призываете писать тесты: habrahabr.ru/company/infopulse/blog/177581/ и пишите о том, как отстаивать сроки: habrahabr.ru/company/infopulse/blog/170777/. Я не понимаю, в чем наши позиции расходятся.
      • +1
        Они схожи даже более, чем Вы указали. Я, к примеру, еще год назад писал об оптимизме программистов. Разница вот в этом:
        «поэтому я стараюсь никогда не отступать от этих правил»

        и
        «Я знаю, что не существует «слишком сложных» задач»

        Говорить «никогда» — это всегда резко, поспешно и, как любое общее и категоричное утверждение — неверно. И сложные задачи — тоже существуют. И они порой заставляют идти против своих же правил. В общем, у Вас хорошие и правильные мысли, я согласен со многими из них (в той же мере как читательницы женских журналов согласны с их советами), просто следовать им всегда и на 100% — слишком накладно и не приносит того профита, как «следовать на 80% и быть гибким в оставшихся 20%».
        • +2
          Опытный разработчик сам знает, где он пойдет на компромисс, но это все-таки исключения, вроде уже подмеченного «упавшего продакшна». К сожалению, слишком много людей с которыми я работал «гибки» на 90%. Отсюда и категоричность.

          Мне нравится одна фраза, которая описывает, как разные люди видят definition of done:
          Я думаю, что «помыть посуду» — это включить воду и вымыть все, что есть в раковине. Моя жена думает, что «помыть посуду» — это убрать грязные тарелки со стола, протереть стол, помыть посуду, протереть, поставить в сушилку, ложки убрать шкафчик.

          В разработке тоже самое. Я за то чтобы ломать меня делать работу полностью.
          • +1
            проблема в том, что 90% разработчиков считают себя опытными (а значит и вправе делать отступление от правил).
            • 0
              Поэтому такие решения должен принимать тимлид или лид. Если даже они не знают, чем отличается абстрактный класс от интерфейса©, то не поможет уже ничего.
              • –1
                Ну-ну. Для меня этот вопрос (отличие абстрактного класса от интерфейса) просто таки повод для смеха :). Потому что в последний раз мне его задавали при приёме на работу, где (как оказалось) всё было написано на друпал 6 (кто не вкурсе — фреймворк на функциях). А в другом месте «тимлид» решил выпендриться «в чем отличия версий ...» (принципиально не отвечаю на такие вопросы) — и сам же запутался.

                Так что, приходится признать, что и многие тимлиды входят в те 90%…
  • +1
    Как человек, очень часто задающий программистам вопрос «сколько на это времени нужно», могу сказать, что я куда спокойнее отнесусь к ситуации «обещал за 5, сделал за 2», чем «обещал за 2, а возится уже 5». Другими словами — единственный момент, когда программист может может выбрать положительную стратегию (всегда успевать) — это на этапе согласования сроков. В этот момент программист может возражать — и эти возражения будут услышаны. Всё последующее будет срыв сроков, «возиться» и «всё ещё не готово».
    • 0
      что, и никогда не задаёте вопросов «Сколько?! А чего так долго, там же только кнопку прикрутить?».

      Как показывает практика, если программист знает, что втрое завысил сроки — он работает… Ну как бы это сказать — с ленцой («да там работы на 2 дня, а ещё неделя впереди»).
      • +1
        Программисты бывают разные (с).
        • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Да, задаю. И программист должен объяснить где я ошибаюсь, потому что если у нас различается понимание состояния проекта, то это различие будет только нарастать.

        Считать, что программисты всегда работают в поте лица своего — неправильно. Бывает — халтурят. Бывает — ленятся. Бывает, вообще пишут не то, что нужно, потому что не хотят вчитываться в мотивационную часть техзаания.

        • 0
          А вам не кажется, что учёт рисков — это отнюдь не задача программиста? Т.е., да, программист может обьяснить, почему вот это — 2 попугая, а вот это 7. Но вот почему эти 2 попугая делались 3 недели…
          • 0
            Частично — программиста. Оценивая задачу, нужно думать не сколько займет времени сделать такую фичу в вакууме, но еще и
            1. Как эту фичу задеплоить
            2. Как внедрить ее в текущий функционал, нет ли сложностей
            3. Что потребуется менять во внутренней архитектуре, чтобы не оставлять тех. долг
            4. Можно ли сделать фичу быстрее, с учетом, что потом будет время на рефакторинг
            5. Какие есть внешние зависимости (например, внешние API), как быстро написать стабы на эти зависимости, если они не будут готовы в срок

            С такой оценкой менеджеру будет гораздо проще управлять рисками.
            • 0
              Собственно это и будет оценка сложности задачи. (кроме последнего, т.к. сдавать задачу без проверки на реальных API — бессмысленно). Оценка же времени выполнения не должна лежать на программисте. Потому что кроме перечисленного Вами существует ещё:
              1. Вероятность ухода программиста в отпуск/на больничный/увольнения
              2. Вероятности появления срочных задач
              3. Затраты времени на получение данных (от сторонних специалистов)
              4. Общий отвлекающий «шум» (совещания, дни рождения, уровень шума в офисе)

              Я уж молчу о том, что оценка будет зависить от настроения программиста.
              В тоже время, большинство проблем повторяются постоянно (опять забыли, что нужно расширять функционал, полезла верстка, кто-то ушёл в отпуск, вылезли баги, устроили микрорефакторинг), и статистически неплохо ловятся. Поэтому я и считаю, что менеджеру проще оценить реальное время на написание задачи (если конечно он ведёт статистику, а не гоняется за программистом в последнюю минуту с криком «Сколько делать будешь?!»)
          • +1
            Если программист не может (а точнее, не хочет) объяснить причины, то это нарушенное взаимодействие в команде и такой проект будет постоянно буксовать на мелочах. Обратная связь очень важна.

            (из своего опыта)
            Одну мелочь (которую я считал мелочью) программист начал делать. И делал, и делал, и делал. На вопрос «когда» отвечал «три часа осталось». На третью неделю я его растряс, выяснилось, что он пытается решить задачу невероятной сложности, практически не решаемую нашими силами, реализовать безумную логику, которая неявно вытекала из-за глупости в ТЗ, плюс изначальный подход к решению был выбран с небольшим запасом и этот «небольшой запас» кратно усложнил задачу.

            После часа совместного изучения проблем ТЗ было переписано с нуля, значительно упрощено и выкинут нафиг весь запас по развитию архитектуры (потому что я знал, что никакого «развития» в этом месте не планируется).

            Итог: программист дурак, что не сказал «это сложно сделать» и не сказал «упс, а тут, оказывается, сложно» вовремя.
            Я дурак, потому что а) поверил программисту на этапе «на три часа осталось» б) тянул три недели а не полез разбираться в причинах после первых симптомов отставания.

            Мораль: программист не просто должен, а обязан объяснять product owner'у и команде о возникающих у него проблемах и причинах, почему то или иное изменение на самом деле очень тяжёлое. Знание о цене реализации во-первых может вовремя поднять вопрос о рефакторинге кода, а во-вторых может вообще поменять стратегию реализации (например, «вместо фичи А будем делать Б»).
            • 0
              Ещё раз — программист может обьяснить сложность задачи, а не время на её исполнение. В вашем случае Ваша ошибка именно в том, что Вы слушали сколько времени осталось, а не забили тревогу, как только время на задачу весом в 2 попугая превысило среднестатистическое.

              Так что дурак Вы в данном случае, и только Вы.
              • 0
                Что значит «объяснить время на её исполнение»?

                Вы же понимаете, что я не могу над каждым программистом над его душой сидеть без устали. Более того, у меня есть вполне себе обратный пример — программист часто к концу спринта говорит «я всё закончил, что дальше»? (то есть берёт резерв спринта).

                Если человек для проблемы недельного размера говорит «три часа осталось» — это нормально? На что я должен ориентироваться при оценке сложности и времени решения задачи?
                • +2
                  Так а зачем над душой стоять — у вас таск трекера нет? У меня в команде всё было очень просто — к концу дня смотрим на выгорание задач. И если задача, которая находится в активном статусе (в процессе) долго не хочет выгорать — начинаем разговор с разработчиком.

                  Более того, такой подход позволяет довольно быстро ловить проблемы. Если сегодня задача оценена в 2 попугая, и на завтра — она всё также осталась в сложности 2 попугая — значит либо программист ничего не делал, или его отвлекают постоянно (вполне реальная ситуация), или мы ошиблись с оценкой.
  • +2
    Я — пессимистичный разработчик. Всякий раз, когда менеджмент что-то обсуждает, я указываю, где именно и почему у нас будут проколы по срокам, фичам, стабильности и т.п. Очень часто я таким образом порчу радужную картину в верхах и нарушаю всеобщуюу идиллию и эйфорию в компании. Несмотря на то, что все мои замечания в конце концов оказываются верными, меня все равно не любят.
    • 0
      А мне говорили, что я желчный и нарушаю атмосферу в команде :)

      шутки шутками, но на самом деле половина наших придирок реально только мешают. Часто на моей практике мои замечания оказывались вполне верными, но низковероятными, и мы тратили на обсуждение и реализацию низковероятностных вещей больше времени чем на высокоприоритетные. Так что для себя сейчас взял правило — если вероятность появления некой ситуации ниже некого порога и не может нарушить работоспособность системы в целом — забили, решим на уровне тех-поддержки.
    • 0
      Меня за это вообще уволили. Я даже сроки не обсуждал, просто указывал, что такая-то хотелка выходит за рамки современной компьютерной науки.
  • +1
    Не идите на поводу у менеджеров

    Распечатать и в рамку.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.