Ты, ссылка на http://c2.com/cgi/wiki?AntiPatternsCatalog, я переведу тебя!
Я приступаю.
Вообще, их там так много, что полюбому надо будет разбить работу на несколько частей. Не потому что много, а потому что вы много не прочитаете.
Начинаю с буквы "A", одной буквы действительно хватит.
Abstraction Invertion.
Обращение абстракции.
По английски говоря, абстракция - это смысл того, что написано в программе. Это называется абстракцией потому что оно абстрагирует важные вещи, в то время, как оставляет ненужные забортом. А обращение абстракции - это когда более сложная вещь становится основанием для более абстрактной вещи(менее сложной).
Дальше идет пример с языком Ада. Думаю, его мы опустим. Мне там понравился только пример с использованием Vector вместо массива там, где массива вполне достаточно. Так же например то, что аяксом выдавать XML, хотя можно передавать JSON и не париться с парсингом.
Если кратко сказать, то это как использовать швейцарский нож с 10 лезвиями для нарезки хлеба.
Кстати, этот антипаттерн не всегда вреден. Например берете CMS для создания блога/магазина/форума и делаете обычный сайт-визитку с гостевой книгой. Да, вы используете более сложную вещь, чтобы сделать более простую, но что же делать. Если вы знаете CMS лучше чем PHP, то почему бы и нет?
Accidental Compelxity
Гребаная сложность.
Это происходит, когда человек пишет библиотеку "для себя". Зачем ему думать о удобстве. Ведь оно и так понятно. Жаль, что все люди разные и остальные программисты будут его тихо материть за функцию CreateNewIfNonNewExist. Или за то, что чтобы получить экземпляр MovieViewer, надо создать Kinoteatr, потом Kassa, потом PopCornSeller. Ведь ему казалось, что все так делают. А если не делают, то их проблемы. В общем, если вы что-то пишете, то подумайте, легко ли это использовать *не* вам.
Accidental Inclusion
Случайное включение
Тип: проектирование API
Случайное включение обработчиков событий в классы компонентов.
Сначала вы создаете компонент, который включает XxxListener
public class SuperComponent extends JComponent implements XxxListener {
/** @see XxxListener */
public void xxx(final XxxEvent xxxEvent) {
doImportantStuff();
}
}
public class MyComponent extends SuperComponent {
/** @see XxxListener */
public void xxx(final XxxEvent xxxEvent) {
doSomethingElse();
}
}
Потом вы его используете. Но при этом doImportantStuff(); никогда не произойдет. Единственное что может вам помочь - это прочитать /** @see XxxListener */
Но много ли людей читают эти скучные комментарии и идут смотреть исходный код XxxListener?
Вот примерно так
Acme Pattern
a.k.a. GodClass
Нам намекают, что рассмотрим когда будем читать про GodClass. Не грузимся, идём дальше
Alcohol Fueled Development
Алкоголь ориентированая разработка
Тип: организационный
Да, это кода большая организация или не очень работает под стрессом и предпочитает расслабиться в баре. Так же упоминается Пик Баллмера. Это оптимальное содержание алкоголя в крови, которое делает из человека суперпрограммиста. Можете попробовать. Но я вас предупреждал, это АНТИпаттерн. Что бы вам не говорили про расслабиться.
Ambigious Viewpoint
Нечёткая точка зрения
Вы хотите брать на себя ответственность и говорить, что этот продукт всех порвёт? Нет, вы ждёте, пока кто -то еще скажет это. Ведь можно и облажаться. Пусть кто-нибудь другой лажает. Что самое смешное, кто-нибудь другой думает точно так же. В результате все садятся и прерисовывают иконки или переписывают тесты. А что, вы делаете свою работу, не подвергая себя риску. Всё ок. К тому же всегда можно скзать, что дизайнеры не прислали нужную картинку, поэтому вы не решились открыть бета версию.
Analogy BreakDown AntiPattern
Разбитие кода по аналогии.(естественно не верной, это же антипаттерн)
Пример из реальной жизни. Кто-то в интернете постоянно слышить про копирайт, лицензии и прочее. Он слышит слово авторское право, пираты. И поэтому любую программу, скачаную за бесплатно, он считает спираченой. Плохо понял, не то услышал. Всё что качается - интеллектуальная собственнось. В результате неправильная аналогия: всё что скачано - своровано. Да, и триал и опенсорс. Ему всё равно.
В программировании - человек привык всё, что делается по нажатию кнопки, помещать в onclick. Да, всё и смену цвета и аякс запрос с перерисовкой страницы. "Если оно работает при нажатии кнопки, то должно быть написано в онклик". Иногда идут дальше и вообще всё реализуют при помощи волшебной кнопки с onclick.
Analysis Paralysis
Паралич аналитический.
Стадия анализа прокета заканчивается, когда проект отменен.
Описание:
Не пишете код, пока полностью не завершён анализ
Постоянная смена руководителей и их философии
Много целей или они враждуют между собой(иногда даже надо тратить время на "они нас не засудят, если мы сделаем это? Давайте подумаем, как нам это обойти программно")
Синдром большого проекта(мы возьмем лучших разработчиков, лучшие программы, лучшие сервера, будем писать код по новейшим технологиям! Да, напишем всё с нуля, полностью перепишем проект)
Избежать риска. Да, вдруг надо будет переписывать.
Как вылечить от этой фигни коллектив?
Не читайте их бумажки. Смотрите на реальное продвижение продукта.
Напишите работающий прототип. Пусть потом его обвешивают.
An Athena
Афина(Как и акме - я хз, что именно имеется в виду. Ну с акме то примерно ясно, а с афиной - я сам в шоке.)
Тип: Менеджмент, набор работников
Вам надо срочно нанять сотрудников. Вы пишете требуется 3 года опыта работы с Java. При этом непонятно, что за опыт работы у человека. Писал он мидлеты или сервлеты. Мб вообще бибилиотеки.
Афина тут упомниается при том, что она была готова принять любого, кто подходтит под стандартные критерии и ожидает, что этот человек сможет сразу же делать работу.(что за миф тут обыгрывается я не знаю)
Ну вы поняли, нанимаете человека с опытом написания J2ME приложений написать несколько JSP.
Решение: писать более подробное описание работы.
Appointed Team
Назначеная команда
Я упоминал, что программирование - творческая профессия? Я повторюсь. Вы не можете собрать 2 разработчика приложений с БД, 3 верстальщика, 2 дизайнера и 3 PHP программистов и ожидать, что они будут работать как команда. Они люди и если собрать людей которые друг друга считают ламерами или "PHP для лохов, попробуйте нормальную БД спроектировать", "Да чё там верстать страницы, вот аякс написать - вот это занятие", то команда будет вымотана и ничго хорошего не напишет.
Краткое резюме: Вы верите, что назначаете людей в команду и они сразу становятся командой.
Решение: самонаборные группы. Да, люди, которые друг друга знают и уважают - знают друг друга и уважают.
Architects don`t code
Архитекторы не кодируют(зря вы себе представили человека с тубусом на военной базе)
Проблема: команда состоит из Junior`ов и опытных експертов.
Что происходит? Супер проект закодирован не так как его себе представлял Senior Developer.
Как решить? Тот, кто составлял проект должен что - то писать. Пусть не так много, но всё же. Альтернативное решение из Мифический человеко-месяц - выкинуть всех начинающих и набрать специалистов. Круто конечно, но как тогда молодежь научите? Но если вам нужен качественный продукт за короткие сроки, то выкинуть всё-таки придётся.
Architecture as Requirements.
Архитектура как Требования.
Например вы хотите сайт визитку с предоставлением товаров. Без покупки и тп. Вам пока этого не надо. Но вам начинают активно навязывать супер приложение на Dgango или Bitregz. Ведь "PHP для ламеров" или "Корпоративный Сайт - это круто". Либо убеждают, что писать надо только под IIS, ASP, MSSQL. Всё остальное тормозит и сделано опенсорс ламерами!
Решение: просто сделать то, что вас просят. Сэкономьте время себе и заказчику.
Architecture by Implication.
Проектирование по связкам(не найду более подходящего слова)
Проектирование основывается на слабой спецификации или обосновании.
Вы добавляете функционал не основываясь на заранее продуманном плане, а просто "по пути"
Результат такого развития - проблемы с производительностью, затрата времени на обучение нестандартным веткам развития и тп.
Решение - создайте листы с функционалом в определённых точках программы. В веб приложениях это будет особенно просто. Берёте страницы и смотрите, что вам будет надо на них(страница регистрации, заглавная, обратная связь, карта сайта). Определяете, что вам надо хранить, какие библиотеки использовать и тп.
И в результате у вас не получится, что строка навигации с jquery в header конфликтует с аякс компонентом, на странице навигации, написаном на prototype.
Asynchronous Unit Testing
Несинхронное тестирование
Допустим у вас есть тесты. Одни тесты на одно, другие на другое. Все разработчики их запускают. И тратят время на прогонку тестов. Чтобы не тратить их время на ожидание зелёной полоски, выделите тестирование на отдельную машину и запускайте их по крону раз в час/когдахотите. В результате программисты свободны и не ждут по 2 минуты на прогонку тестов. Да, очевидная проблема - один накосячил, а видят все. Значит надо чтобы человек сразу исправлял свою ошибку. Поэтому попытайтесь и дальше улучшить эту систему, дав всем разработчикам воможность прогонять тесты отдельно ото всех. В результате остальные не будут потревожены, а "накосячивший" сможет спокойно разобраться с багом.(Если вы ничго не поняли, то это понятно. Даже на той странице написано, что это требует "the time (and pain and cost)", значит дело не шуточное)
Autogenerated Stovepipe
Самогенерирующийся дымоход
Проблема: Программист ненарадуется на новую генерилку кода. Например берёте дельфи и накидываете приложение с использованием БД. Это даже не автогенерация кода, а этап дизайна. Но он создает схему базы данных и кучу связей.
Причина: Все хотят создать супер простую среду разработки, где можно просто пить кофе и код будет сам генерироваться.
Последствия: Огромные расходы на поддержание этого сгенерированного монстра.
Решение: Не брать на работу людей, которые делают программы быстро и надёжно с использованием суперкурсов Как написать веб сайт за 24 часа.
Итак, одна буква готова. Скоро перейду к следующим и когда закончу, можно будет разбить по категориям.