Как стать автором
Поиск
Написать публикацию
Обновить

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

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

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

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

А 4й — это боль… Сам пару раз натыкался на такие ТЗ, что хотелось плакать. Правда, к счастью, не пришлось по ним работать.
Всего голосов 3: ↑3 и ↓0+3
А вот я часто слышу «Сделай пока хоть как-нибудь».
А вижу так
Всего голосов 2: ↑2 и ↓0+2
Фото отлично подходит, IMHO.

А ТЗ и макет, видимо, потому будут.
Всего голосов 1: ↑1 и ↓0+1
Это не (анти)паттерны, а отмазки.
Всего голосов 5: ↑4 и ↓1+3
Таки не все. Пройдёмся ка по части «отмазок».

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

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

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

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

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


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

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

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

PS: это что же получается… большинство начинает работу до того, как известны макеты и ТЗ?
Всего голосов 3: ↑3 и ↓0+3
Ты пока начинай выпускать календарь, а макет с картинками как-нибудь подтянем, оукей? ;)
Всего голосов 7: ↑7 и ↓0+7
Еще вспомнил один явный антипатерн одного типа-очень-крутого архитектора, который так испоганил всю систему за полтора года работы в нашем проекте, что потом группа годами залечивала раны от следов его славной деятельности.
Антипатерн звучал так: «да, ваше решение формально правильное и работает, но оно не гибкое! А вдруг в будущем понадобиться что-то другое?? Поэтому давайте сделаем так....» И далее шло предложение по супер-пупер-гибкому решению, которое было в 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();

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

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

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr