Комментарии 103
А если в коде встречается выражение такого плана:
$a=date(«Ymd»)-getenv(«REQUEST_URI»)
то это к какому паттерну относится? :)
Причем REQUEST_URI не число вообще никак :)
$a=date(«Ymd»)-getenv(«REQUEST_URI»)
то это к какому паттерну относится? :)
Причем REQUEST_URI не число вообще никак :)
Blind faith
Затрудняюсь точно классифицировать такое :) Я бы назвал это pure fucking magic и заставил бы переписать :)
Это называется PHP, как ни крути :)
Кажется ето «кодобред»
Человеку, который выдаёт такой код, нужно наполировать зад пряжкой от ремня и отправить назад в школу изучать какой-нибудь компилируемый язык программирования. Можно начать с Pascal. И через пару лет ему можно будет доверить интерпретатор.
Скорее всего, артефакт, оставшийся от копипасты.
Может еще чего дельного почитать предложите для лечения всего этого, а?
не для лечения, а избежание этого надо прочитать книгу: «Рефакторинг. Улучшение существующего кода»
Мартин Фаулер
Мартин Фаулер
Спасибо, попробую.
Рефакторинг это уже не избежание, а лечение. Книга хорошая, да :)
И для избежания тоже. Если заранее знать, что именно придётся переписывать, это можно изначально написать правильно.
А книга действительно замечательная.
А книга действительно замечательная.
Это как детям сказка про бабу Ягу?
Или как вредные советы Остера?
Увы, собственный опыт переделок, кранчей и дедлайнов не сопоставимо ценней, нежели просмотр возможных последствий соблюдения анти-паттернов.
Или как вредные советы Остера?
Увы, собственный опыт переделок, кранчей и дедлайнов не сопоставимо ценней, нежели просмотр возможных последствий соблюдения анти-паттернов.
Это потому что на своих ошибках учиться эффективнее? ;)
Именно, сказки про Бабу Ягу актуальны в детстве, когда мы еще познаём мир и вся входящая информация для ребёнка — как данное.
Потом мы открываем для себя «ложь» и в конце концов фильтр становится всё сильнее и плотнее.
Просматривая всяческие социальные (в частности) предостережения мы думаем «Это не про меня».
А когда подписан контракт с заказчиком, когда корявый менеждмент и низкий скил исполнителей приводят к кранчам, суткам непрерывной работы, питанию фастфудами… Не в сказке сказать, ни пером описать ;)
Потом мы открываем для себя «ложь» и в конце концов фильтр становится всё сильнее и плотнее.
Просматривая всяческие социальные (в частности) предостережения мы думаем «Это не про меня».
А когда подписан контракт с заказчиком, когда корявый менеждмент и низкий скил исполнителей приводят к кранчам, суткам непрерывной работы, питанию фастфудами… Не в сказке сказать, ни пером описать ;)
Главное не зацикливаться на этом, надо в меру предполагать что сразу написать правильно, как бы всё равно многое придется переписывать. Как бы Фаулер и пишет, что не надо излишне планировать, ведь можно воспользоваться рефакторингом.
Ну лечение — это как-то не хорошо звучит. Рефакторинг ведь часть текущей работы, причем нужная и обязательная часть, избавляющая от большого количества проблем в будущем. Никто не безупречен и никто сможет написать всё правильно сейчас, чтобы это было правильно и в будущем.
Зачем избегать? Для того и придумали рефакторинг чтобы не париться на эту тему. Пиши тесты — реализуй костылями — рефакторь. Так проще и быстрее.
В данном случае доступны 2 методологии лечения — до и после. Так вот лечение до, то есть предохранение от анти-паттернов, является более предпочтительным. В таком случае посоветую читать книги Рихтера, Страуструпа — они учат как писать. В случае же лечения после — советую читать книги о рефакторинге, коих не мало.
забавная фамилия, СтраусТруп )))
О том, как создавать программы, лучше читать www.htdp.org/. Страуструп дает слишком однобокий взгляд на вещи.
Эти книги читать нужно, как азбуку.
Но, пока не наступишь на грабли, не поймешь как это больно. И никакие доводы Страуструпа вместе с Фаулером не помогут. Это как… ну я не знаю… «сыночек, не, упадешь!». Пока не будет куча кровищи, или нога поломанная ниче сыночек не поймет :)
Надеюсь, аллегории поняты.
Программист — не сапер. Можно и поошибаться… в начале карьеры, само собой.
Зато как же надолго запоминаешь «антипаттерн», над которым проплакал с недельку, исправляя или изменяя.
Но, пока не наступишь на грабли, не поймешь как это больно. И никакие доводы Страуструпа вместе с Фаулером не помогут. Это как… ну я не знаю… «сыночек, не, упадешь!». Пока не будет куча кровищи, или нога поломанная ниче сыночек не поймет :)
Надеюсь, аллегории поняты.
Программист — не сапер. Можно и поошибаться… в начале карьеры, само собой.
Зато как же надолго запоминаешь «антипаттерн», над которым проплакал с недельку, исправляя или изменяя.
Книги нужно читать, но еще очень полезно смотреть реально работающий код, причем написанный профессионалами.
Например, разнообразные популярные open-source фреймворки и т.д.
Например, разнообразные популярные open-source фреймворки и т.д.
M.Feathers: Working Effectively with Legacy Code. («Эффективная работа с унаследованным кодом»). Если надо, пишите в личку мыло, вышлю chm.
народ, помогаем человеку, поднимем карму для переноса в тематический блог.
dotcomrade не против?
dotcomrade не против?
Помню один замечательный антипаттерн «Паблик Морозов»
Этот «замечательный» паттерн относиться к ООП :) Когда класс-потомок выдает абсолютно все данные класса-предка, что нарушает принцип скрытия информации, на котором базируется не только ООП, но и модульное программирование.
В википедии, например, этот анти-паттерн находится в секции шуточных, хотя такая ошибка может довольно широко встречаться у начинающих ООП-разработчиков. Видимо из-за каламубрного названия :)
В википедии, например, этот анти-паттерн находится в секции шуточных, хотя такая ошибка может довольно широко встречаться у начинающих ООП-разработчиков. Видимо из-за каламубрного названия :)
Вот полный список: Resign Patterns
Спасибо за статью. Может я и ошибаюсь, но ваш список антипаттернов напоминает этот: insidecpp.ru/antipatterns/ :)
Сделал выводы. Буду следить за собой.
Сейчас работаем над одним проектом, который достался от пакистанцев.
Там есть все мыслимые и немыслимые анти-паттерны.
Теперь с благоговением вспоминаю Фаулера и рефакторю, рефакторю…
Там есть все мыслимые и немыслимые анти-паттерны.
Теперь с благоговением вспоминаю Фаулера и рефакторю, рефакторю…
Классика.
Напишите мне программу, не применяя copy-paste. Да что далеко ходить — данный топик написан этим методом! :-)
Главное — головы не терять. И находить в себе силы разбираться, если не работает.
А самое главное — уметь ограничивать себя и не искать слишком уж универсальных решений там, где вполне сойдёт одно простое.
Напишите мне программу, не применяя copy-paste. Да что далеко ходить — данный топик написан этим методом! :-)
Главное — головы не терять. И находить в себе силы разбираться, если не работает.
А самое главное — уметь ограничивать себя и не искать слишком уж универсальных решений там, где вполне сойдёт одно простое.
Беда в том, что даже если называть анти-паттерны классикой — случаи их «использования» не исчезнут, и жаль, что они становятся классикой :( А про copy-paste — если вы про анти-паттерн, а не про собственно действие, то без него можно и нужно писать программы.
Я думаю вы не совсем поняли о чём говорится. Имеется в виду, что если в коде есть повторяющиеся куски, которые выполняют похожую работу, то это не верно, и нужно рефакторить.
p.s. Сам не безгрешен в этом плане… :)
p.s. Сам не безгрешен в этом плане… :)
Хм… а с чего бы «удалённая работа отдельных программистов» является причиной «Спагетти-кода»?
Это ж очевидно зависит от профессионализма этих самых программистов и уровня организации процесса.
Это ж очевидно зависит от профессионализма этих самых программистов и уровня организации процесса.
Да. Сам работаю удаленно. Возможно, имелось в виду, что если удаленный, лишний раз не спросишь, не обсудишь, даже если есть skype.
За собой такое замечал, так что в принципе правда)
За собой такое замечал, так что в принципе правда)
Да, именно это имелось ввиду. Когда взаимодействие разработчиков «хромает», то может и образоваться спагетти-код, так как разработчик может не использовать решения, найденного другим разработчиком. Мало того, в таком случае рядом возникает и изобретение велосипеда, иногда одноколёсного, что вдвойне опасно.
для исключения этого есть замечательный keyword — fixme, когда кто-нибудь поставит, он начинает мозолить глаза, обсудишь и поправишь ))
В продолжение актуальной нынче темы пинариков ?)
думаю это много лучше ) как я понял в пинариках сам себя оцениваешь, а тут тебя еще и оценивают другие, fixme + svn blame замечательный способ контроля кода, тем более когда в команде есть «гуру». кстати может свой пинарик делать доступными и для других участников? так оценка эффективности дня будет точнее?
Да. Тоже считаю, что от профессионализма зависит, но никак не от удаленности.
Зависит еще и как. Может повлиять, стать подводным камнем, поводом и причиной
НО не предопределяется — тут я согласен.
НО не предопределяется — тут я согласен.
Есть пара моментов.
Первый, скажем так, это один из факторов, ухудшающих взаимодействие. И результат, при прочих равных, будет (образно) «хуже».
И, во-вторых, так уж получилось исторически, что удаленка — достаточно доступная вещь и таким образом работают много некомпетентных спецов. Но от этого нельзя ставить в «зависимость» спагетти-код. Ибо те же самые разработчики, даже при определенном контроле, при работе в офисе, наваяют тот же «спагетти-код».
Первый, скажем так, это один из факторов, ухудшающих взаимодействие. И результат, при прочих равных, будет (образно) «хуже».
И, во-вторых, так уж получилось исторически, что удаленка — достаточно доступная вещь и таким образом работают много некомпетентных спецов. Но от этого нельзя ставить в «зависимость» спагетти-код. Ибо те же самые разработчики, даже при определенном контроле, при работе в офисе, наваяют тот же «спагетти-код».
Резюмируя:
Collocated team — не спасает от Спагетти кода, если кто-то в команде к нему предрасполагает.
Distributed team — не повод для Спагетти кода, но может послужить бонусом, при условии низкого уровня организованности.
Согласен также, что распределённость команды косвенный повод для любого из анти-паттернов. Но не вижу проблемы указать его для примера ;)
Collocated team — не спасает от Спагетти кода, если кто-то в команде к нему предрасполагает.
Distributed team — не повод для Спагетти кода, но может послужить бонусом, при условии низкого уровня организованности.
Согласен также, что распределённость команды косвенный повод для любого из анти-паттернов. Но не вижу проблемы указать его для примера ;)
Полагаю, указывались возможные причины. Как одно, так и второе может стать причиной. А вместе с ними и множество других ;)
С другой стороны, уровень (само)организации может выходить из распределённой команды.
С другой стороны, уровень (само)организации может выходить из распределённой команды.
«Банальная нехватка времени и спешка сейчас запросто могут вылиться в огромные проблемы и неработоспособность системы в будущем.»
Подписываюсь под каждым словом. Как по мне — лучше не делать ничего сейчас, чем сделать кое-как, а потом с этим париться. Это только видимость выгоды исполнителя от такой работы. Стратегически решения в стиле «нужно быстренько, чтобы работало уже завтра, поэтому пока никаких паттернов, юнит-тестов и прочих вещей, требующих времени» потом стоят очень дорого в обслуживании. И это при том, что и времени то реально не сэкономили — заказчик в итоге так и получил систему с большим опозданием, время потрачено на дебаг, доработку и внедрение дополнительных фич, которые добавляются очень сложно из за, к примеру, спагетти-кода.
Подписываюсь под каждым словом. Как по мне — лучше не делать ничего сейчас, чем сделать кое-как, а потом с этим париться. Это только видимость выгоды исполнителя от такой работы. Стратегически решения в стиле «нужно быстренько, чтобы работало уже завтра, поэтому пока никаких паттернов, юнит-тестов и прочих вещей, требующих времени» потом стоят очень дорого в обслуживании. И это при том, что и времени то реально не сэкономили — заказчик в итоге так и получил систему с большим опозданием, время потрачено на дебаг, доработку и внедрение дополнительных фич, которые добавляются очень сложно из за, к примеру, спагетти-кода.
Главное, чтобы это понимал управленец :) Это очень хорошо продумано в такой agile практике, как scrum — если в к майлстону что-либо неготово, то оно полностью переносится на слеующий спринт. В итоге, если сравнить время для реализации «костыля» и фикса его в будущем, и нормальную реализацию потом, то видим выигрыш второго варианта — как по времени, так и по качеству.
Совершенно верно, Scrum вообще хорошо подходит для следования концепциям, ведущим и к получению результата, и к качественному коду.
Эх… цитирую директора: «Ценность наших решений в том, что мы можем уже на следующий день дать заказчику что-нибудь готовое. А докрутим и дофиксим потом»
И вот что с этим делать? ( это, можно сказать, философия нашей компании.
И вот что с этим делать? ( это, можно сказать, философия нашей компании.
Очень интересная статья.
Поймал себя на частом употреблении паттерна «Программирование перебором». Постараюсь искоренить эту привычку :)
Поймал себя на частом употреблении паттерна «Программирование перебором». Постараюсь искоренить эту привычку :)
По опыту моей работы, товарищи из далёкой Индии очень любят паттерн «Спагетти-код»
Позанудствую:
>С этим надо бороться — для каждой задачи имеется не одно, а несколько, красивых и оптимальных решений
Несколько решений не могут быть оптимальными — оптимальное решение всегда одно. Другое дело, если вы не можете четко выделить систему критериев и параметры функции определения оптимальности решения, тогда конечно несколько наиболее красивых решений можно назвать оптимальными. К примеру — что важнее, увеличение скорости работы алгоритма в 2.7 раза или уменьшение объема занимаемой объектом памяти в 1.45 раза? Если вы точно сможете в таких цифрах описать все составляющие вашей системы оценки качества кода для конкретного программного продукта на конкретном этапе его жизненного цикла, то, сравнив все возможные решения, найдете среди них то, что называется оптимальным. А после этого вас ждет сюрприз — пока вы оценивали варианты решений, индусы используя все перечисленные вами паттерны написали работоспособный код, который продали вашему заказчику в два раза дешевле %)
>С этим надо бороться — для каждой задачи имеется не одно, а несколько, красивых и оптимальных решений
Несколько решений не могут быть оптимальными — оптимальное решение всегда одно. Другое дело, если вы не можете четко выделить систему критериев и параметры функции определения оптимальности решения, тогда конечно несколько наиболее красивых решений можно назвать оптимальными. К примеру — что важнее, увеличение скорости работы алгоритма в 2.7 раза или уменьшение объема занимаемой объектом памяти в 1.45 раза? Если вы точно сможете в таких цифрах описать все составляющие вашей системы оценки качества кода для конкретного программного продукта на конкретном этапе его жизненного цикла, то, сравнив все возможные решения, найдете среди них то, что называется оптимальным. А после этого вас ждет сюрприз — пока вы оценивали варианты решений, индусы используя все перечисленные вами паттерны написали работоспособный код, который продали вашему заказчику в два раза дешевле %)
самый главный антипаттерн — тупое следование всем рекомендациям «как надо программировать, и как не надо».
Головой думать надо — вот главнейший паттерн.
Головой думать надо — вот главнейший паттерн.
НЛО прилетело и опубликовало эту надпись здесь
У меня с Паттернами довольно интерестная история. ООП я начал изучать после того, как вдоль и поперек изучил функциональное программирование.
ООП паттерны я использовать стал, даже не подозревая, что это паттерны и они как-то так называются. :)
В общем, можно сказать, что у меня происходит обратная реакция, чем описанная «Золотой молоток» :). Опыт не пропьёшь.
ООП паттерны я использовать стал, даже не подозревая, что это паттерны и они как-то так называются. :)
В общем, можно сказать, что у меня происходит обратная реакция, чем описанная «Золотой молоток» :). Опыт не пропьёшь.
У копипаста есть и обратная сторона: например на сайте 2 раздела: новости и статьи, при чём тз на статьи заказчиком ставилось так: «сделай, как новости». Дабы не копипастить делаешь одну систему (модели виды может даже контролы и таблицу дб с полем kind enum(news,articles) ) и разделяешь например параметром или значением свойства класса. На первый взгляд дёшево и сердито, но потом заказчик даёт корректировки на статьи типа: убери в списке статей картинку, сделай возможность добавлять несколько картинок в текст статьи, сделай другой фон у статьей… и приходится городить костыли, пока не приходит корректировка «сделай 3 уровня вложенности у статей» и тогда приходится таки разделять на две системы (вспоминая при этом заказчика не злым тихим словом :) )
или более распространённый пример: используешь html layout, т к «все страницы как первая», а потом заказчик присылает креатив своего дизайнера, где не то, что дизайн разный, а ширина шаблонов разная…
я не говорю, что копипаст хорошо, его минусы все знают, я о том, что при проектировании проекта нужно постараться предугадать его развитие, и потом решать, что копипастить, а что нет.
или более распространённый пример: используешь html layout, т к «все страницы как первая», а потом заказчик присылает креатив своего дизайнера, где не то, что дизайн разный, а ширина шаблонов разная…
я не говорю, что копипаст хорошо, его минусы все знают, я о том, что при проектировании проекта нужно постараться предугадать его развитие, и потом решать, что копипастить, а что нет.
прям чувствуется печальный опыт в вашем «например» =)
да, с заказчиками оно очень часто так. Поэтому лично я стараюсь делать по возможности более расширяемо, в пределах отведенного времени на таск. Побочный эффект ненужной сложности ни разу не возникал еще, т.к. времени всегда в обрез )
да, с заказчиками оно очень часто так. Поэтому лично я стараюсь делать по возможности более расширяемо, в пределах отведенного времени на таск. Побочный эффект ненужной сложности ни разу не возникал еще, т.к. времени всегда в обрез )
Ну в данном случае нужно выделить основные особенности обеих систем в отдельный класс, а уже потом создать наследников для новостей и статей. Причём почти сразу понятно, что нужно сделать именно так.
Кстати да, в _грамотном_ копипасте _отлаженного_ кода нет ничего плохого.
Все перечисленные анти-паттерны — атрибуты любого прототипа.
Если такой код написан не вами, скажите спасибо человеку написавшему этот код, вам осталось только отрефакторить, все ошибки перед вами, функциональные требования уже в коде.
Если же он написан вами, вам не позавидуешь, скорее всего вы не высыпаетесь уже неделю, проект нужно было сдать ещё на прошлой, а вам нужна ещё хотя бы одна. Вашему проекту натурально не хватает человеко-часов.
Если такой код написан не вами, скажите спасибо человеку написавшему этот код, вам осталось только отрефакторить, все ошибки перед вами, функциональные требования уже в коде.
Если же он написан вами, вам не позавидуешь, скорее всего вы не высыпаетесь уже неделю, проект нужно было сдать ещё на прошлой, а вам нужна ещё хотя бы одна. Вашему проекту натурально не хватает человеко-часов.
Я бы добавил сюда лень как самый главный анти-паттерн
SELECT a,b
FROM table_1 t1
WHERE EXISTS (SELECT '42' FROM ....)
Чем плохо 42? :)
FROM table_1 t1
WHERE EXISTS (SELECT '42' FROM ....)
Чем плохо 42? :)
Можно добавить анти-паттерн «Бездумное комментирование».
Работаю с кодом где полно комментариев вида
«end if here»
«end code here»
«added by Ahmed»
" — MAIN CODE START HERE -----------"
Есть комментарии построенные в форме в вопросительной форме.
Никакой полезной информации они не несут, но претендуют на комментированный код.
Лучше писать код понятно, чем объяснять, что же ты написал.
Работаю с кодом где полно комментариев вида
«end if here»
«end code here»
«added by Ahmed»
" — MAIN CODE START HERE -----------"
Есть комментарии построенные в форме в вопросительной форме.
Никакой полезной информации они не несут, но претендуют на комментированный код.
Лучше писать код понятно, чем объяснять, что же ты написал.
10 слов «рефактори....» в статье, одно в названии блога и одно в тэгах. ОМГ.
Статья понравилась. Только вот последняя фраза все убила.
«Программист не должен писать код так, чтобы его потом пришлось рефакторить, помните это ;)»
Это кто так может? Пусть первым поставит мне минус. Рефакторинг — это естейственный процесс.
Почитайте «Рефакторинг. Улучшение существующего кода» Мартин Фаулер
Там в каждой главе написано, что избежать рефакторинга неудается никому.
«Программист не должен писать код так, чтобы его потом пришлось рефакторить, помните это ;)»
Это кто так может? Пусть первым поставит мне минус. Рефакторинг — это естейственный процесс.
Почитайте «Рефакторинг. Улучшение существующего кода» Мартин Фаулер
Там в каждой главе написано, что избежать рефакторинга неудается никому.
Рефакторинг — действительно улучшение существующего кода. Но если программист пишет код и понимает, что его обязательно придётся рефакторить/переделывать ибо решение неоптимизированное, или даже ошибочное — значит что-то пошло не так.
Поставил =)
«Мой любимый паттерн проектирования — GodObject»
MVC классический пример паттерна Золотой молоток (Golden hammer) :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Что такое анти-паттерны?