Pull to refresh

Comments 103

А если в коде встречается выражение такого плана:
$a=date(«Ymd»)-getenv(«REQUEST_URI»)
то это к какому паттерну относится? :)
Причем REQUEST_URI не число вообще никак :)
Вера в то, что вдруг в строке запроса окажется не "/blogs/", а число? :))
Затрудняюсь точно классифицировать такое :) Я бы назвал это pure fucking magic и заставил бы переписать :)
Это называется PHP, как ни крути :)
Вы на PHP только так и пишете? :)
Вообще это бред на самом деле :)
Это просто ошибка в ДНК программиста)
Я думал, чувство юмора никто не отменял. Разве в языках со строгой типизацией такое возможно? Разве такие языки позволяют число разделить на ложь и правду возвести в квадрат?
Кажется ето «кодобред»
Человеку, который выдаёт такой код, нужно наполировать зад пряжкой от ремня и отправить назад в школу изучать какой-нибудь компилируемый язык программирования. Можно начать с Pascal. И через пару лет ему можно будет доверить интерпретатор.
Скорее всего, артефакт, оставшийся от копипасты.
Может еще чего дельного почитать предложите для лечения всего этого, а?
не для лечения, а избежание этого надо прочитать книгу: «Рефакторинг. Улучшение существующего кода»
Мартин Фаулер
Рефакторинг это уже не избежание, а лечение. Книга хорошая, да :)
И для избежания тоже. Если заранее знать, что именно придётся переписывать, это можно изначально написать правильно.
А книга действительно замечательная.
Это как детям сказка про бабу Ягу?
Или как вредные советы Остера?

Увы, собственный опыт переделок, кранчей и дедлайнов не сопоставимо ценней, нежели просмотр возможных последствий соблюдения анти-паттернов.
Это потому что на своих ошибках учиться эффективнее? ;)
Именно, сказки про Бабу Ягу актуальны в детстве, когда мы еще познаём мир и вся входящая информация для ребёнка — как данное.
Потом мы открываем для себя «ложь» и в конце концов фильтр становится всё сильнее и плотнее.

Просматривая всяческие социальные (в частности) предостережения мы думаем «Это не про меня».

А когда подписан контракт с заказчиком, когда корявый менеждмент и низкий скил исполнителей приводят к кранчам, суткам непрерывной работы, питанию фастфудами… Не в сказке сказать, ни пером описать ;)
Главное не зацикливаться на этом, надо в меру предполагать что сразу написать правильно, как бы всё равно многое придется переписывать. Как бы Фаулер и пишет, что не надо излишне планировать, ведь можно воспользоваться рефакторингом.
Ну лечение — это как-то не хорошо звучит. Рефакторинг ведь часть текущей работы, причем нужная и обязательная часть, избавляющая от большого количества проблем в будущем. Никто не безупречен и никто сможет написать всё правильно сейчас, чтобы это было правильно и в будущем.
Зачем избегать? Для того и придумали рефакторинг чтобы не париться на эту тему. Пиши тесты — реализуй костылями — рефакторь. Так проще и быстрее.
В данном случае доступны 2 методологии лечения — до и после. Так вот лечение до, то есть предохранение от анти-паттернов, является более предпочтительным. В таком случае посоветую читать книги Рихтера, Страуструпа — они учат как писать. В случае же лечения после — советую читать книги о рефакторинге, коих не мало.
забавная фамилия, СтраусТруп )))
Для вас она новая? А что вы тогда делаете на Хабре? :)
я так понял те что минусуют над ней свое уже отсмеялись )
О том, как создавать программы, лучше читать www.htdp.org/. Страуструп дает слишком однобокий взгляд на вещи.
Эти книги читать нужно, как азбуку.

Но, пока не наступишь на грабли, не поймешь как это больно. И никакие доводы Страуструпа вместе с Фаулером не помогут. Это как… ну я не знаю… «сыночек, не, упадешь!». Пока не будет куча кровищи, или нога поломанная ниче сыночек не поймет :)

Надеюсь, аллегории поняты.

Программист — не сапер. Можно и поошибаться… в начале карьеры, само собой.

Зато как же надолго запоминаешь «антипаттерн», над которым проплакал с недельку, исправляя или изменяя.
Книги нужно читать, но еще очень полезно смотреть реально работающий код, причем написанный профессионалами.
Например, разнообразные популярные open-source фреймворки и т.д.
И в популярных open-source фреймворках встречаются некоторые пёрлы. Всем свойственно ошибаться, даже профессионалам. Имхо к книгам следует добавить подробные code review кода с «использованием» различных анти-паттернов.
Полностью согласен. Но если говорить о PHP, то считаю что вполне достойна изучения symfony и уж тем более Zend.
Тоже с вами соглашусь, в крупных популярных проектах анти-паттерны обычно долго не задерживаются.
M.Feathers: Working Effectively with Legacy Code. («Эффективная работа с унаследованным кодом»). Если надо, пишите в личку мыло, вышлю chm.
Надо просто читать хорошие книжки для начинающих программистов, такие как SICP или упомянутый выше HtDP.
народ, помогаем человеку, поднимем карму для переноса в тематический блог.
dotcomrade не против?
Помню один замечательный антипаттерн «Паблик Морозов»
Этот «замечательный» паттерн относиться к ООП :) Когда класс-потомок выдает абсолютно все данные класса-предка, что нарушает принцип скрытия информации, на котором базируется не только ООП, но и модульное программирование.

В википедии, например, этот анти-паттерн находится в секции шуточных, хотя такая ошибка может довольно широко встречаться у начинающих ООП-разработчиков. Видимо из-за каламубрного названия :)
Спасибо за статью. Может я и ошибаюсь, но ваш список антипаттернов напоминает этот: insidecpp.ru/antipatterns/ :)
Свой список я старался строить на неких «взаимосвязях» анти-паттернов. В принципе, все они тесно связаны, но всё же некоторые могут вызывать или даже содержать друг друга. Спасибо за ссылку, почитаем-с :)
Сделал выводы. Буду следить за собой.
Сейчас работаем над одним проектом, который достался от пакистанцев.
Там есть все мыслимые и немыслимые анти-паттерны.
Теперь с благоговением вспоминаю Фаулера и рефакторю, рефакторю…
Думаю, такое есть в любом крупном проекте. Если количество такого кода существенно — то есть смысл подумать о полном переписании с использованием существующих наработок.
Классика.

Напишите мне программу, не применяя copy-paste. Да что далеко ходить — данный топик написан этим методом! :-)
Главное — головы не терять. И находить в себе силы разбираться, если не работает.
А самое главное — уметь ограничивать себя и не искать слишком уж универсальных решений там, где вполне сойдёт одно простое.
Беда в том, что даже если называть анти-паттерны классикой — случаи их «использования» не исчезнут, и жаль, что они становятся классикой :( А про copy-paste — если вы про анти-паттерн, а не про собственно действие, то без него можно и нужно писать программы.
Если задействуется copy-paste — значит копируем код. Раз копируем код, значит плохо все спроектировали.
Не задействовали всю силу ООП)
принцип DRY — don`t repeat yourself
копировать код можно с другого проекта )
Я думаю вы не совсем поняли о чём говорится. Имеется в виду, что если в коде есть повторяющиеся куски, которые выполняют похожую работу, то это не верно, и нужно рефакторить.

p.s. Сам не безгрешен в этом плане… :)
вот, блин отвечал — 2 часа… Когда начал писать, предыдущих коментариев не было… :D
Хм… а с чего бы «удалённая работа отдельных программистов» является причиной «Спагетти-кода»?
Это ж очевидно зависит от профессионализма этих самых программистов и уровня организации процесса.
Да. Сам работаю удаленно. Возможно, имелось в виду, что если удаленный, лишний раз не спросишь, не обсудишь, даже если есть skype.
За собой такое замечал, так что в принципе правда)
Да, именно это имелось ввиду. Когда взаимодействие разработчиков «хромает», то может и образоваться спагетти-код, так как разработчик может не использовать решения, найденного другим разработчиком. Мало того, в таком случае рядом возникает и изобретение велосипеда, иногда одноколёсного, что вдвойне опасно.
для исключения этого есть замечательный keyword — fixme, когда кто-нибудь поставит, он начинает мозолить глаза, обсудишь и поправишь ))
В продолжение актуальной нынче темы пинариков ?)
думаю это много лучше ) как я понял в пинариках сам себя оцениваешь, а тут тебя еще и оценивают другие, fixme + svn blame замечательный способ контроля кода, тем более когда в команде есть «гуру». кстати может свой пинарик делать доступными и для других участников? так оценка эффективности дня будет точнее?
Пинарик сугубо для себя.
А вот при публичном ревью косяков уже срабатывают совсем другие рычаги влияния на мотивацию

«Shame on you, lazy bone!» — косым взглядом на фиксера-должника заставит его покраснеть авторитетный гуру на дейли митинге ;)
Это, конечно, радикально, но работает исправно. И
Да. Тоже считаю, что от профессионализма зависит, но никак не от удаленности.
Зависит еще и как. Может повлиять, стать подводным камнем, поводом и причиной
НО не предопределяется — тут я согласен.
Есть пара моментов.
Первый, скажем так, это один из факторов, ухудшающих взаимодействие. И результат, при прочих равных, будет (образно) «хуже».

И, во-вторых, так уж получилось исторически, что удаленка — достаточно доступная вещь и таким образом работают много некомпетентных спецов. Но от этого нельзя ставить в «зависимость» спагетти-код. Ибо те же самые разработчики, даже при определенном контроле, при работе в офисе, наваяют тот же «спагетти-код».
Резюмируя:
Collocated team — не спасает от Спагетти кода, если кто-то в команде к нему предрасполагает.
Distributed team — не повод для Спагетти кода, но может послужить бонусом, при условии низкого уровня организованности.

Согласен также, что распределённость команды косвенный повод для любого из анти-паттернов. Но не вижу проблемы указать его для примера ;)
Ну для примера то и я не против :)

Резюме хорошее)
Спасибо, рад что сошлись мнением ;)
Парное программирование + Review Кода, могут в некотором роде спасти от появления антипаттернов.
Review может заменить парное программирование, когда оно не возможно, но не всегда.
Полагаю, указывались возможные причины. Как одно, так и второе может стать причиной. А вместе с ними и множество других ;)
С другой стороны, уровень (само)организации может выходить из распределённой команды.
«Банальная нехватка времени и спешка сейчас запросто могут вылиться в огромные проблемы и неработоспособность системы в будущем.»

Подписываюсь под каждым словом. Как по мне — лучше не делать ничего сейчас, чем сделать кое-как, а потом с этим париться. Это только видимость выгоды исполнителя от такой работы. Стратегически решения в стиле «нужно быстренько, чтобы работало уже завтра, поэтому пока никаких паттернов, юнит-тестов и прочих вещей, требующих времени» потом стоят очень дорого в обслуживании. И это при том, что и времени то реально не сэкономили — заказчик в итоге так и получил систему с большим опозданием, время потрачено на дебаг, доработку и внедрение дополнительных фич, которые добавляются очень сложно из за, к примеру, спагетти-кода.
Главное, чтобы это понимал управленец :) Это очень хорошо продумано в такой agile практике, как scrum — если в к майлстону что-либо неготово, то оно полностью переносится на слеующий спринт. В итоге, если сравнить время для реализации «костыля» и фикса его в будущем, и нормальную реализацию потом, то видим выигрыш второго варианта — как по времени, так и по качеству.
Совершенно верно, Scrum вообще хорошо подходит для следования концепциям, ведущим и к получению результата, и к качественному коду.
Эх… цитирую директора: «Ценность наших решений в том, что мы можем уже на следующий день дать заказчику что-нибудь готовое. А докрутим и дофиксим потом»
И вот что с этим делать? ( это, можно сказать, философия нашей компании.
Наверное, основать конкурирующую компанию, которая будет применять исключительно кошерные методы и завоевать с её помощью мир, на зависть вашему директору.
Очень интересная статья.
Поймал себя на частом употреблении паттерна «Программирование перебором». Постараюсь искоренить эту привычку :)
У меня данный метод ассоциируется с паскалем, с него я начинал и ой как «любил» перебор.
Метод научного тыка ;)
По опыту моей работы, товарищи из далёкой Индии очень любят паттерн «Спагетти-код»
Позанудствую:

>С этим надо бороться — для каждой задачи имеется не одно, а несколько, красивых и оптимальных решений

Несколько решений не могут быть оптимальными — оптимальное решение всегда одно. Другое дело, если вы не можете четко выделить систему критериев и параметры функции определения оптимальности решения, тогда конечно несколько наиболее красивых решений можно назвать оптимальными. К примеру — что важнее, увеличение скорости работы алгоритма в 2.7 раза или уменьшение объема занимаемой объектом памяти в 1.45 раза? Если вы точно сможете в таких цифрах описать все составляющие вашей системы оценки качества кода для конкретного программного продукта на конкретном этапе его жизненного цикла, то, сравнив все возможные решения, найдете среди них то, что называется оптимальным. А после этого вас ждет сюрприз — пока вы оценивали варианты решений, индусы используя все перечисленные вами паттерны написали работоспособный код, который продали вашему заказчику в два раза дешевле %)
Два разных SQL запроса являются одинаково оптимальными если для них генерируется одинаковый план запроса :)
самый главный антипаттерн — тупое следование всем рекомендациям «как надо программировать, и как не надо».

Головой думать надо — вот главнейший паттерн.
Ага! Плюс опыт многого писАния.
UFO just landed and posted this here
Поддерживаю целиком и полностью. Очень хочется работать правильно, чтобы не стыдно было потом за продукт и его код. А для этого надо, чтобы и начальство понимало, как это, «правильно». На голом энтузиазме ведь не будешь работать…
У меня с Паттернами довольно интерестная история. ООП я начал изучать после того, как вдоль и поперек изучил функциональное программирование.

ООП паттерны я использовать стал, даже не подозревая, что это паттерны и они как-то так называются. :)

В общем, можно сказать, что у меня происходит обратная реакция, чем описанная «Золотой молоток» :). Опыт не пропьёшь.
У копипаста есть и обратная сторона: например на сайте 2 раздела: новости и статьи, при чём тз на статьи заказчиком ставилось так: «сделай, как новости». Дабы не копипастить делаешь одну систему (модели виды может даже контролы и таблицу дб с полем kind enum(news,articles) ) и разделяешь например параметром или значением свойства класса. На первый взгляд дёшево и сердито, но потом заказчик даёт корректировки на статьи типа: убери в списке статей картинку, сделай возможность добавлять несколько картинок в текст статьи, сделай другой фон у статьей… и приходится городить костыли, пока не приходит корректировка «сделай 3 уровня вложенности у статей» и тогда приходится таки разделять на две системы (вспоминая при этом заказчика не злым тихим словом :) )

или более распространённый пример: используешь html layout, т к «все страницы как первая», а потом заказчик присылает креатив своего дизайнера, где не то, что дизайн разный, а ширина шаблонов разная…

я не говорю, что копипаст хорошо, его минусы все знают, я о том, что при проектировании проекта нужно постараться предугадать его развитие, и потом решать, что копипастить, а что нет.
прям чувствуется печальный опыт в вашем «например» =)
да, с заказчиками оно очень часто так. Поэтому лично я стараюсь делать по возможности более расширяемо, в пределах отведенного времени на таск. Побочный эффект ненужной сложности ни разу не возникал еще, т.к. времени всегда в обрез )
Ну в данном случае нужно выделить основные особенности обеих систем в отдельный класс, а уже потом создать наследников для новостей и статей. Причём почти сразу понятно, что нужно сделать именно так.
Кстати да, в _грамотном_ копипасте _отлаженного_ кода нет ничего плохого.
Все перечисленные анти-паттерны — атрибуты любого прототипа.

Если такой код написан не вами, скажите спасибо человеку написавшему этот код, вам осталось только отрефакторить, все ошибки перед вами, функциональные требования уже в коде.

Если же он написан вами, вам не позавидуешь, скорее всего вы не высыпаетесь уже неделю, проект нужно было сдать ещё на прошлой, а вам нужна ещё хотя бы одна. Вашему проекту натурально не хватает человеко-часов.
Я бы добавил сюда лень как самый главный анти-паттерн
Лень — двигатель прогресса :)
SELECT a,b
FROM table_1 t1
WHERE EXISTS (SELECT '42' FROM ....)

Чем плохо 42? :)
Можно добавить анти-паттерн «Бездумное комментирование».
Работаю с кодом где полно комментариев вида
«end if here»
«end code here»
«added by Ahmed»
" — MAIN CODE START HERE -----------"
Есть комментарии построенные в форме в вопросительной форме.
Никакой полезной информации они не несут, но претендуют на комментированный код.
Лучше писать код понятно, чем объяснять, что же ты написал.
10 слов «рефактори....» в статье, одно в названии блога и одно в тэгах. ОМГ.
Статья понравилась. Только вот последняя фраза все убила.
«Программист не должен писать код так, чтобы его потом пришлось рефакторить, помните это ;)»

Это кто так может? Пусть первым поставит мне минус. Рефакторинг — это естейственный процесс.
Почитайте «Рефакторинг. Улучшение существующего кода» Мартин Фаулер
Там в каждой главе написано, что избежать рефакторинга неудается никому.
Рефакторинг — действительно улучшение существующего кода. Но если программист пишет код и понимает, что его обязательно придётся рефакторить/переделывать ибо решение неоптимизированное, или даже ошибочное — значит что-то пошло не так.
«Преждевременная оптимизация — зло», — говорили отцы-основатели.
Отбрасывая преждевременную оптимизацию не надо писать так «абы работало», особенно в крупных проектах. Проще не совершать грубых ошибок, чем потом их исправлять. Но сразу не совершать — не может никто, это со временем приходит.
UFO just landed and posted this here
«Мой любимый паттерн проектирования — GodObject»
MVC классический пример паттерна Золотой молоток (Golden hammer) :)
Sign up to leave a comment.

Articles