6 мая 2009 в 16:43

Что такое анти-паттерны?

Анти-паттерны — полная противоположность паттернам. Если паттерны проектирования —
это примеры практик хорошего программирования, то есть шаблоны решения определённых задач. То анти-паттерны — их полная противоположность, это — шаблоны ошибок, которые совершаются при решении различных задач. Частью практик хорошего программирования является именно избежание анти-паттернов. Не надо думать, что это такая непонятная теоретическая фигня — это конкретные проблемы, с которыми сталкивался практически каждый разработчик. Кто осведомлен, тот и вооружён! Рассмотрим же несколько расрпотранённых анти-паттернов в программировании.


Программирование копи-пастом (Copy and Paste Programming)


Данный анти-паттерн является, наверное, самым древним в программировании. Когда от программиста требуется написание двух схожих функций, самым «простым» решением является написание одной функции, её копирование и внесение некоторых изменений в копию. Какие проблемы это сулит? Во-первых, ухудшается переносимость кода — если потребуется подобный функционал в другом проекте, то надо будет искать все места, где программист накопипастил и переносить их по отдельности. Во-вторых, понижается качество кода — часто программист забывает вносить требуемые изменения в скопированный код. В-третьих, усложняется поддержка кода — так, как если в изначальном варианте был баг, который в будущем надо будет исправить, то этот баг попал во все то, что, опять-таки, накопипастил программист. Это приводит так же к возникновению различных множественных исправлений, которые будут возникать по мере нахождения бага в разных частях кода, для одного единственного бага. В-четвертых, code review значительно усложняется, так как кода становится больше, без видимой значительной выгоды и роста производительности труда. Главными причинами возникновения подобных ошибок являются — отсутствие мыслей про будущее разработки (программисты не продумывают свои действия), недостаток опыта (программисты берут готовые примеры и модифицируют, адаптируя под свои нужды). Решение же, является очень простым — создание общих решений и их использование. Об этом следует думать ещё при разработке решений небольших задач — возможно, что нам потребуется решить эту задачу где-нибудь ещё, или решить эту же задачу, но в другой интепретации.

«Брось, можно писать не только одну функцию!» или Спагетти-код (Spaghetti code)


Спагетти-код — слабо структурированная и плохо спроектированная система, запутанная и очень сложная для понимания. Такой код так же очень часто содержит в себе множество примеров анти-паттерна программирования копи-пастом. Подобный код в будущем не сможет разобрать даже его автор. В ООП спагетти-код может быть представлен в виде небольшого количества объектов с огромными, по размеру кода, методами. Причинами являются — разработка по принципу «Да ну, оно же работает! Целых пять тысяч строк!», малоэффективные code review, недостаток опыта в ООП разработке, удалённая работа отдельных программистов. Ипользовать спагетти-код повторно невозможно и нежелательно. Если в вашем проекте начинает возникать спагетти-код, а вам как раз надо расширить функционал, который он реализует — не ленитесь, рефакторьте спагетти полностью или напишите эту часть заново! Проиграв немного времени сейчас — вы получите огромный плюс в будущем. Или наоборот — проиграете, если оставите спагетти-код в проекте.

Золотой молоток (Golden hammer)


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

«Что за 42?» или Магические числа (Magic numbers)


Магическое число — константа, использованная в коде для чего либо (чаще всего — идентификации данных), само число не несёт никакого смысла без соответствующего комментария. Числа не несут абсолютно никакой семантики. Когда в коде вашего проекта начинаются появлятся числа, значение которых не является очевидным — это очень плохо. Программист, который не является автором такого кода, с трудностями сможет объяснить как это работает. Со временем и автор кода, с присутствием магических чисел, не сможет объяснить что-либо. Числа затрудняют понимание кода и его рефакторинг. Главными причинами этой ошибки — спешка при разработке, отсутствие практики программирования. Данный анти-паттерн надо пресекать на корню, оговаривая использование числовых констант перед началом разработки.

«Что значит d:\proj\tests.dat?» или Жёсткое кодирование (Hard code)


Жёсткое кодирование — внедрение различных данных об окружении в реализацию. Например — различные пути к файлам, имена процессов, устройств и так далее. Этот анти-паттерн тесно связан с магическими числами, частенько они переплетаются. Захардкодить — жёстко прописать значение каких-либо данных в коде. Главная опасность, исходящая от этого анти-паттерна — непереносимость. В системе разработчика код будет исправно работать до перемещения или переименования файлов, изменения конфигурации устройств. На любой другой системе код может вовсе не заработать сразу же. Как правило, программист практически сразу забывает где и что он захардкодил, даже если делает это в целях отладки кода. Это делает выявление и локализацию данного анти-паттерна очень сложной. С этим надо бороться — оговорив запрет на жёсткое кодирование перед началом разработки и проводя тщательные code review.

Мягкое кодирование (Soft code)


Мягкое кодирование — параноидальная боязнь жёсткого кодирования. Это приводит к тому, что незахардкожено и настраивается абсолютно всё, что делает конфигурацию невероятно сложной и непрозрачной. Этот анти-паттерн является вторым концом палки о жёстком кодировании и поэтому тоже является опасным. Во-первых, при разработке много ресурсов уходит на реализацию возможности настроек абсолютно всего. Во-вторых, развёртывание такой системы повлечет так же дополнительные затраты. Перед началом решения определённой задачи следует определить, что должно быть настариваемым, а что является постоянным для различных систем или может быть настроено автоматически.

Ненужная сложность (Accidental complexity)


Простыми словами — это заумность решения. Ненужная сложность может быть внесена в решение любой задачи. Это могут быть как и ненужные проверки, части кода, продуцированные мягким кодированием, отсутствие какой-либо оптимизации. Это приводит к усложнению понимания кода, понижению скорости работы. Причинами являются — отсутствие или некачественность рефакторинга, некомпетентность программиста. Бороться довольно просто — следует проводить тщательные code review, эффективный рефакторинг.

Лодочный якорь (Boat anchor)


Этот анти-паттерн означает сохранение неиспользуемых частей системы, которые остались после оптимизации или рефакторинга. Часто, после рефакторинга когда, который является результатом анти-паттерна, некоторые части кода остаются в системе, хотя они уже больше не используются. Так же некоторые части кода могут быть оставлены «на будущее», авось придётся ещё их использовать. Такой код только усложняет системы, не неся абсолютно никакой практической ценности. Эффективным методом борьбы с лодочными якорями является рефакторинг кода для их устранения, а так же процесс планирования разработки, с целью предотвращения возникновения якорей.

Изобретение велосипеда (Reinventing the wheel)


Смысл этого анти-паттерна в том, что программист разрабатывает собственное решение для задачи, для которой уже существуют решения, очень часто лучшие чем придуманное программистом. Разработчик считает себя наилучшим, поэтому для каждой задачи пытается придумать собственное решение, не смотря на опыт его предшественников. Чаще всего это приводит лишь к потере времени и понижению эффективности работы программиста — так как решение может быть найдено далеко неоптимальное или вообще ненайденное. Полностью же отбрасывать возможность самостоятельного решения нельзя, так как это прямой дорогой к приведет к программированию копипастом. Разработчик должен ориентироваться в задачах, которые могут предстать перед ним, чтобы грамотно их решить — используя готовые решение или изобретая собственные. Очень часто причиной этого анти-паттерна является банальная нехватка времени. А время — это деньги.

Изобретение одноколёсного велосипеда (Reinventing the square wheel)


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

«От твоего кода дурно пахнет» или Поток лавы (Lava flow)


На каком либо этапе разработки вы можете осознать, что некоторая часть кода очень давно не менялась и вообще недокументирована, или такому коду сопутствует комментарий вида "// Не знаю, как оно работает, но оно работает. Не удалять и не менять!". Если ничего не предпринимать, то такой код и останется в проекте. Но и рефакторить, разбирать его довольно сложно, особенно ели его автор уже не работает над проектом. Проще предусмотреть возникновение такого мёртвого кода, при разработке надо руководствоваться тем, что код в будущем возможно будет немного оптимизирован или дописан, но никак не переписан полностью. Главными причинами возникновения потоков лавы являются — написание больших частей проекта одним программистом, отсутствие code review, ошибки в проектировании архитектуры.

«А если i+1?» или Программирование перебором (Programming by permutation)


Многие начинающие программисты пытаются решать некоторые задачи методом перебора — не брутфорсом решения, а именно подбором параметров, порядка вызова функций и так далее. Все эти игры с +1, -1 к параметрам и подобные штучки устраняют только симптомы, и не дают понимания сути происходящего. А если программист не понимает происходящего, то он не сможет предусмотреть все варианты развития событий и обязательно о чём-то забудет. Он потратит время на подбор работающего для него решения и позднее потратит время для переделки этого решения. Все подобные подобранные решения вылазят боком и хорошо ещё — если в процессе разработки или отладки. К подобному ни в коем случае нельзя привыкать, достигая успеха на небольших задачках. Если программист не может решать задачи другим путём — он некомпетентен и ему не следует доверять разработку — вам же будет хуже.

«Как это вы передали строку вместо числа?!» или Слепая вера (Blind faith)


Этот анти-паттерн — недостаточная проверка корректности входных данных, исправления ошибки или результатов работы кода. Очень часто программист думает, что его код всегда будет в идеальных условиях, никогда не выдаст ошибки и не получит неверных входных данных или, ещё чего, данных неверного типа. Но все лгут ©, поэтому нельзя доверять никакому коду, даже собственному. Но и не следует доводить это недоверие до паранойи, то есть приходить к анти-паттерну ненужной сложности. Просто следует помнить про проверку входных данных и возможные проблемы у чужого кода, который используете вы.

Бездумное комментирование


Результат «работы» данного анти-паттерна — большое количество лишних и неинформативных комментариев. Код не следует комментировать ради комментирования! Ведь комментарии — очень полезный инструмент, который должен помочь задокументировать нужную информацию для облегчения понимания кода, как автору в будущем, так и другим разработчикам. Ни в коем случае нельзя допускать диалога разработчиков в комментариях — лучше перенести данную функцию с комментариев на специализированные инструменты для code review, или на личное обсуждение.

Божественный объект (God Object)


«Мне нужен такой-то функционал. — Используй MegaCoreObject! — И ещё, мне нужен и… — Я же сказал, используй MegaCoreObject!»


Божественный объект — анти-паттерн, который довольно часто встречается у ООП разработчиков. Такой объект берет на себя слишком много функций и/или хранит в себе практически все данные. В итоге мы имеем непереносимый код, в котором, к тому же, сложно разобраться. Так же, подобный код довольно сложно поддерживать, учитывая, что вся система зависит практически только от него. Причинами являются — некомпетентность разработчика, взятие одним разработчиком большой части работы (особенно, когда размер работы «превышает» уровень опыта этого разработчика). Бороться с таким подходом надо — разбивать задачи на подзадачи, с возможностью решения этих подзадач различными разработчиками.

Выводы


Анти-паттерны — главные враги разработчика, под их влияние программист частенько попадает из-за давление заказчика или проект-менеджера. Банальная нехватка времени и спешка сейчас запросто могут вылиться в огромные проблемы и неработоспособность системы в будущем. Следует помнить пару простых принципов — «Тише едешь — дальше будешь» и «Не подмажешь — не поедешь». Анти-паттерны надо не просто знать, надо знать их причины и методы борьбы, а ещё лучше — заранее предостерегать себя от их «использования». Программист не должен писать код так, чтобы его потом пришлось рефакторить, помните это ;)
Денис @dotcomrade
карма
57,2
рейтинг 0,0
Самое читаемое Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Головой думать надо — вот главнейший паттерн.
    • 0
      Ага! Плюс опыт многого писАния.
  • +2
    Спасибо за систематизацию и собственно топик — это должно было быть сказано.

    Предлагаю продолжение темы — «Как донести изложенное до того, кто платит тебе зарплату, не вступая при этом в конфликт с законодательством?»
    • 0
      Поддерживаю целиком и полностью. Очень хочется работать правильно, чтобы не стыдно было потом за продукт и его код. А для этого надо, чтобы и начальство понимало, как это, «правильно». На голом энтузиазме ведь не будешь работать…
  • 0
    У меня с Паттернами довольно интерестная история. ООП я начал изучать после того, как вдоль и поперек изучил функциональное программирование.

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

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

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

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

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

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

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

    Это кто так может? Пусть первым поставит мне минус. Рефакторинг — это естейственный процесс.
    Почитайте «Рефакторинг. Улучшение существующего кода» Мартин Фаулер
    Там в каждой главе написано, что избежать рефакторинга неудается никому.
    • 0
      Рефакторинг — действительно улучшение существующего кода. Но если программист пишет код и понимает, что его обязательно придётся рефакторить/переделывать ибо решение неоптимизированное, или даже ошибочное — значит что-то пошло не так.
      • +1
        «Преждевременная оптимизация — зло», — говорили отцы-основатели.
        • 0
          Отбрасывая преждевременную оптимизацию не надо писать так «абы работало», особенно в крупных проектах. Проще не совершать грубых ошибок, чем потом их исправлять. Но сразу не совершать — не может никто, это со временем приходит.
      • +1
        Оптимизированное ≠ не поддающееся рефакторингу.
    • 0
      Поставил =)
  • +1
    «Мой любимый паттерн проектирования — GodObject»
    • +1
      Добавил.
  • 0
    MVC классический пример паттерна Золотой молоток (Golden hammer) :)

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