Немного креатива — календарь с антипаттернами

    Всем привет!

    Пост повышенной несерьёзности, ибо пятница.
    Хочу рассказать про антипаттерны, которые выкристаллизовались в нашей компании. Just For Fun.

    Каждый раз, когда разработчики/монтажники/схемотехники применяли повторяющуюся отмазу, её фиксировали и заносили в список. Когда список вырос и в нём появилось почти 12 отмазок, нам пришла в голову идея сделать свой календарь с антипаттернами (поскольку отмазки иллюстрируют то, как не стоит думать и делать, приравниваем их к антипаттернам). Для этого нам предстояло осилить вёрстку календаря и к каждому анти-паттерну «родить» соответствующую картинку. Вёрстку делали в LaTex'е, а картинки — в inkscape, в svg-формате. В-общем, получилось вполне open-source'но. Но пост всё-таки больше не о технической реализации, а о самих анти-паттернах. Кому интересно, добро пожаловать.

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

    Сразу хочу сказать, что сами анти-паттерны и картинки к ним — это просто шутка, мы не стремились никого обидеть.

    Поехали!

    Номер один: «У задачи был низкий приоритет»

    Отмаза возникла, когда начали активно внедрять scrum. Казалось, что никакую задачу не стоит решать, если она имеет более низкий приоритет, чем те, которые взяли в работу на этот спринт. Иногда получалось смешно, т.к. задача с низким приоритетом была на самом деле важна и мешала более приоритетным задачам. Project owner'а при этом в известность не ставили, а в конце спринта получалось вот такое:



    Номер два: «у нас не было инструмента!»

    Это любимая отмаза монтажников. Что удивительно, наличие карт-бланша на покупку практически любых инструментов не решало проблему. Картинка получилась жестокая.



    Номер три: «скажут сделать — сделаем!»

    Вот сидит человек и ждёт, что ему скажут, что это надо сделать. А ты-то уверен, что это очевидно и надо просто начинать это делать. Немного пересекается с антипаттерном «не было команды это делать». Но звучал всегда именно в такой форме.



    Номер четыре: «мы работаем».

    Жуткая фраза, которую приходилось слышать от руководителя на вопросы, касающиеся оптимальности и рациональности происходящего на его участке. Пришлось записать…



    Номер пять (мой любимый антипаттерн): «Всё готово, но надо смёржить».

    До сих пор часто приходится слышать и даже иногда произносить. Когда от транка понаделано куча бренчей и из этих кирпичиков налажена работающая система. И кажется, что уже всё готово и хоть сразу — в production, но нет — надо сначала смёржить. Комичность ситуации в том, что смёржить — не всегда такой уж простой и быстрый процесс, за которым снова следует тестирование и т.д.



    Номер шесть: «Мы всегда так делали»

    Делали криво и будем делать криво, потому что всегда так делали. Доколе?



    Номер семь: «Сделано ровно то, о чём просили»

    Некоторые очень любят выключать мозг в момент выполнения какой-то задачи. Им посвящён этот анти-паттерн. А другие некоторые считают, что остальные думают также как они сами. Вот и получается…



    Номер восемь: «Не было команды это делать»

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



    Номер девять: «Это надо запланировать»

    Думаю, многие замечали, что есть мелочи, которые проще сделать сразу, чем запланировать, потому что они мелочи. А когда нам говорят, что эти мелочи надо запланировать (ага, записать в бэклог, поставить приоритет, и поехали) — мы записываем это как анти-паттерн. Картинку к этому антипаттерну мы так и не придумали. Получилось вот что:



    Номер десять: «Это надо разрабатывать»

    Свеженький анти-паттерн. Мы заметили за собой, что часто говорим, что «это надо делать». Так надо брать и делать, а не говорить. Картинка получилась соответствующая.



    Номер одиннадцать: «Ничего не знаю — письма не было»

    Употребляется при общении в реале после длительных корпоративных переписок. Очень удобно — ведь довольно трудно доказать, что письмо действительно было:



    Когда картинки закончили, сверстали календарь в LaTex'е и выпустили небольшой тираж для раздачи внутри компании и подарков.

    Исходный код календаря выложен в github. Для успешной сборки потребуется пакет Tikz, поскольку сам календарь (даты, числа и т.к.) делается с помощью него. С небольшими усилиями из этого календаря можно сделать любой другой, you are welcome! Там же, в каталоге pdfs есть собранные версии — см. README.

    Всем хороших выходных!

    PS: А какие антипаттерны наблюдаются в ваших компаниях?
    НТЦ Метротек
    Разработка и производство Ethernet устройств etc.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

    Комментарии 37

      +15
      Может к «Это надо запланировать» что-нибудь вроде этого?

      P.S. Содержание креатива в предложении — 0 % (ибо откровенно стырено)
        +3
        Это не моя задача — и картинка как двое друг на друга показывают. Обыкновенно когда кто-то считает, что какая либо промежуточная работа должна выполняться кем-то другим.
          +2
          о, кстати, да, встречал пару раз ;)
            +19
            image
            +24
            Ты пока делай, а макеты и тз я тебе потом дам
              +17
              «Так сложилось исторически.»
                +1
                Огромный плюс. Я сам эту фразу говорю в ответ на каждый, наверное, третий вопрос, который мне задают про дизайн проектов, в которых я участвую. Не всегда это означает, что всё плохо, но почти всегда означает, что, раз новому человеку непонятно, почему сделано именно так, то и самому стоит призадуматься — а стоит ли дальше так жить.
                  +1
                  Ага, нам часто задают вопрос — почему Altera, а не Xilinx (это производители FPGA). И ответ получается именно «сложилось исторически», потому что много лет назад одного из нас этому научили в институте и так оно и по сей день.

                  В принипе, ничего плохого действительно нет, но задуматься заставляет.
                  +4
                  1. Этого не было в ТЗ.
                  2. А мне никто не говорил, что надо еще и второе ТЗ прочитать.
                  3. Нам ТЗ некогда было внимательно читать.
                  4. В этом ТЗ вообще ничего не понятно, но мы поняли это только потом.
                    +3
                    Интересно, а пункт 3 вообще может прокатить? Это же вообще нонсенс какой-то

                    А 4й — это боль… Сам пару раз натыкался на такие ТЗ, что хотелось плакать. Правда, к счастью, не пришлось по ним работать.
                    +2
                    А вот я часто слышу «Сделай пока хоть как-нибудь».
                    А вижу так
                    +3
                    Это не (анти)паттерны, а отмазки.
                      +8
                      Таки не все. Пройдёмся ка по части «отмазок».

                      «У задачи был низкий приоритет» — так для того приоритеты и придумали? Сначала делается то, что имеет высокий приоритет, потом по нисходящей. Вопрос к тому, кто приоритеты выставляет. Исполнитель же может напомнить, мол, давно висит задача с низким приоритетом, может пора подвинуть? Нет? Оукэй.

                      «Скажут сделать — сделаем!» и «Сделано ровно то, о чём просили» — нормальный ответ человека, который долго работал по принципу «инициатива — наказуема». Или если он и сейчас так работает.

                      «Это надо разрабатывать» — в дословном виде не встречал, но бывает подобный ответ — «это нельзя просто сконфигурировать/быстро пропатчить, функционал нужно именно разрабатывать [в рамках отдельной задачи]». Сказать, что это требует разработки, а значит больше времени — отмазка?

                      «Всё готово, но надо смёржить» — 'это попадает под антипаттерн, потому что мердж действительно порой бывает… нетривиальным :-) У нас например «фича готова к деплою» означает «фича готова, протестирована и слита с боевой веткой».

                      «Ничего не знаю — письма не было» — Может быть как отмазкой от безрадостной задачи, так и вполне реальной ситуацией, когда человек думает, что обсудил с тобой что-то, а на самом деле нет. Замотался, не передал задачу, а теперь права качает.
                        +2
                        «фича готова к деплою» — взял на вооружение, спасибо
                          0
                          «Это требует разработки» — скорее всего, другими словами стесняются сказать «это неизвестно, сколько займёт времени, но намного больше ожидаемого».
                        +5
                        «C бекендом всё отлично — остался фронтенд». (Затем реализация фронтенда вскрывает баги бекенда, потому что, по сути, его нельзя было проверить.)
                          0
                          «C бекендом всё отлично — остался фронтенд»


                          Ой, как я люблю так говорить!
                          мимобэкенд-разработчик
                          +2
                          Мне запомнилась такая фраза начальства: «наша система должна быть прежде всего надежной и не содержать ошибок, поэтому...» — и дальше шел какой-нибудь бред, который делал систему именно с ошибками и ненадежной. Открыто спорить никто не решался, но все тихо клали на такое «ценное» правило или принцип разработки и делали по-своему, фактически занимаясь саботажем.
                          • НЛО прилетело и опубликовало эту надпись здесь
                              +1
                              «этого не может быть», «а у меня все работает» — нежелание девелопера искать проблему, которая случается у клиента/тестера. жутко бесит
                                +1
                                Зачастую это не нежелание искать проблему, а отсутствие возможности ее найти. Порой скриншот и логи программы приходится вытягивать из пользователя клещами, а уж список шагов для устойчивого воспроизведения — совсем уж фантастика.
                                  +1
                                  Пользователь не может быть идеален, он может не понимать что и как нужно сообщать. Программа должна обладать хоть какими-то навыками самоотладки/отправки отчётов о падении. Многие пользователи вообще обходят проблему, не сообщая разработчику. Нужно быть благодарным хотя бы за обратную связь.
                                    –1
                                    Практически полностью согласен с JIghtuse, плюсую
                                    0
                                    Еще круче, когда подходишь к тестировщику и у него внезано все начинает работать как надо :D
                                  +3
                                  Антипаттерн «ничего не исправилось» — возникает, когда пользователь снова и снова сообщает об одной и той же проблеме, отказываясь устанавливать высылаемое в ответ разработчиками обновление.
                                    +1
                                    Мой любимый — «это не мой код». Это когда разработчику надо поработать с чужим кодом и вместо того, чтобы разобраться в нём и интегрировать туда своё решение, сооружается «пристройка» где-то сбоку в виде страшного костыля. Аргументация при этом звучит так: «это не мой код, зачем мне в него лезть?»
                                      –2
                                      Еще порция антипаттернов — devanswers.ru.
                                        0
                                        Жаль что без картинок там
                                        +3
                                        Коллеги, позвольте подытожить предложенные анти-паттерны.

                                        Получается (с учётом рейтинга комментов, по ниспадающей) следующее:
                                        (21) Ты пока делай, а макеты и ТЗ я тебе потом дам
                                        (14) Так сложилось исторически
                                        (4) нам ТЗ некогда было внимательно читать (выбрал из четырёх предложенных именно этот)
                                        (4) С бэкендом всё отлично — остался фронтенд
                                        (3) Это не моя задача
                                        (3) Ничего не исправилось (звучит от имени пользователей)
                                        (2) Сделай пока хоть как-нибудь
                                        (1) Этого не может быть — у меня всё работает
                                        (1) Это не мой код

                                        Итого 9 штук, то есть с января по сентябрь включительно! Осталось ещё три месяца и картинки соответствующие придумать, и можно будет запустить в печать календарь с анти-паттернами от Хабра-пользователей на 2015 год.

                                        PS: это что же получается… большинство начинает работу до того, как известны макеты и ТЗ?
                                          +7
                                          Ты пока начинай выпускать календарь, а макет с картинками как-нибудь подтянем, оукей? ;)
                                          +4
                                          Еще вспомнил один явный антипатерн одного типа-очень-крутого архитектора, который так испоганил всю систему за полтора года работы в нашем проекте, что потом группа годами залечивала раны от следов его славной деятельности.
                                          Антипатерн звучал так: «да, ваше решение формально правильное и работает, но оно не гибкое! А вдруг в будущем понадобиться что-то другое?? Поэтому давайте сделаем так....» И далее шло предложение по супер-пупер-гибкому решению, которое было в 10 раз сложнее реализовать и в 100 раз сложнее использовать. Но! Оно было ну очень гибким, просто изгибалось влегкую во все стороны. И как-то опускался вопрос, что эта гибкость и на фиг никому не нужна.

                                          Маленький, но яркий пример: в проекте надо было использовать один глобальный объект. Типичное решение: синглтон. Обычно выгядит как:

                                          MyClass.GetInstance().DoSomething();

                                          или даже MyClass::s_instance.DoSomething();
                                          или MyClass::DoSomething(); // неявный синглтон

                                          если не надо нам ничего там динамически инициализировать.

                                          Так вот, было сказало, что это ни хрена не гибко, но гораздо гибче будет так:

                                          MyClass.GetInstance(«default»).DoSomething();

                                          Зачем имя инстаса? А для гибкости! Вдруг у нас будут разные кофигурации? Конфигурации чего? А хрен его знает — когда будут, тогда и будем разбираться. Но все равно еще не достаточно гибко! Гораздо гибче так:

                                          MyClass.getInstance(ConfigurationManager.GetInstance().GetConfigurationName()).DoSomething();

                                          Тогда, типа, мы можем задавать имя инстаса без перекомпиляции. А сам ConfigurationManager будет читать свои параметры из некого файла кофигурации. Но главное, что в этом проекте никаких конфигурации не было за всю историю его существования и никаких конфигураций не намечалось в ближайшие 10 лет. Но чтобы написать простейший вызов метода, все были вынуждены писать каждый раз через задницу:

                                          MyClass.GetInstance(ConfigurationManager.GetInstance().GetConfigurationName(«default»)).DoSomething();

                                          Если заметили, в последнем варианте добавилось еще одно звено «гибкости» — имя имени конфигурации, то есть, некий мэппинг между ключом-строкой и реальным именем конфигурации. Зачем? А чтобы было гибче, гибше, гибчее!
                                            +1
                                            У такого подхода есть еще одна проблема, кроме распухания кода: правильная работа программы становится возможна только при особым образом написанных конфигурационных файлах. В итоге появляется часть конфига, которая не должна меняться пользователем ни при каких обстоятельствах (наподобие знаменитого # DO NOT EDIT - THIS FILE IS AUTOMATICALLY GENERATED BY MAGIC). Фактически, такой конфиг должен писаться разработчиком — и ставиться вместе с программой.

                                            Но в конфиге есть и изменяемая пользователем часть, которая в итоге неизбежно будет затираться при обновлениях программы.
                                              0
                                              Согласен, но я не столько про излишнее использование конфигурационных файлов (это частность), сколько вообще про излишнее усложнение проекта/дизайна/решения в угоду некой абстрактной, плавающей в неопределенном будущем гибкости, которая оборачивается реальным кошмаром в настоящем.
                                              +1
                                              Прошу прощения за «Ь» в «А вдруг в будущем понадобиться что-то другое». Видимо, в мозгу была фраза «может понадобиться», но пока думал, написал другое. :)
                                                +1
                                                Похожая ситуация была, но в другой стезе… У нас один товарищ (я тогда был юниором) с умным видом сказал, что юзать просто $.ajax в JQuery библиотеке не гибко, а самое главное слишком увеличивает код проекта… сделал обвязку бедной функции с кучей дефолта и настрочил документацию-комментарий. Потом появились уникальные вещи которые «товарищ» не учел и функция расширилась до кальки полноценной $.ajax. Уже через полгода я её выпилил из проекта.

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

                                              Самое читаемое