Забавные анти-паттерны

Забавные анти-паттерны

Недавно прочёл книгу "Mastering PHP Design Patterns" и нашёл для себя забавной главу об анти-паттернах. Речь шла не только о проектировании, но и о различных  организационных и управленческих моделях, что оказалось довольно интересным. Поскольку перевода данной книги не встречал, решил поделиться некоторыми выдержками.

Синдром "Придумано не здесь" (Not Invented Here Syndrome)

Что такое синдром NIH? Это случай, когда ложное чувство гордости за собственную способность организации или отдельных разработчиков приводит к созданию собственного решения, а не к использованию превосходных сторонних решений. Изобретать колесо не только дорого и ненужно, но может добавить дополнительные накладные расходы на обслуживание. Кроме этого, такое колесо может быть ужасно небезопасным. При этом следует помнить о том, что использование сторонних библиотек не освобожает от ответственности за проверку качества кода.

Объекты-боги (God Objects)

Объекты-боги являются следствием плохого проектирования программного обеспечения, а также плохо реализованной объектной ориентации.

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

Что же здесь не так? Когда у вас есть одна часть кода, связанная с каждой другой частью кода, поддержка становится катастрофой. Если вы подгоните логику метода для одного варианта использования, вы можете обнаружить, что это имеет непреднамеренные последствия для другого элемента.

Раздутый интерфейс (Interface Bloat)

Есть множество случаев, когда люди думают, что у них отличная архитектура, но оказывается, что их усилия были контрпродуктивными. Раздутый интерфейс - один из вариантов подобного.

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

Телега перед лошадью (Cart Before the Horse)

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

Управляемая тестировщиками разработка (Tester-Driven Development)

Не путать с Test Driven Development! Разработка, управляемая тестировщиками, - это ситуация, когда требования являются не более, чем ярлыками. Такая разработка также может называться разработкой, управляемой ошибками, поскольку она по существу приводит к тому, что отчеты об ошибках используются для определения действий и функций, которые должны реализовывать программисты.

Например, создаётся инструмент для экспорта данных из базы в электронную таблицу. Всё работает отлично, но тестировщик возвращает тикет, говоря, что в продукте есть ошибка, поскольку он не содержит возможности экспорта в PDF. Однако, если этого не было в требованиях, то и не должно рассматриваться как ошибка. И да, у вас должны быть чётко прописанные требования.

Команды тестировщиков существуют для проверки того, что программное обеспечение соответствует техническому заданию. Но не наоборот - они не существуют, чтобы самим определять требования.

Прокрастинация (Bikeshedding)

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

Преждевременная оптимизация (Premature Optimization)

Зачастую разработчики стремятся оптимизировать свой код преждевременно, не принимая в расчёт результаты анализа работы приложения, чтобы определить, где и когда следует проводить оптимизацию.

Написание чистого и читаемого кода - ваш первый приоритет. После этого вы можете использовать некоторые инструменты профилирования, чтобы определить узкие места. Например, есть случаи, когда для некоторых длительных вычислительных задач критически важно выполнить оптимизацию, "сократив" сложность алгоритма с O(N2) до O(N).

Синдром необразованного менеджера (Uneducated Manager Syndrome)

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

Пойдём еще дальше: менеджер по веб-разработке должен иметь не только технический опыт, но и веб-опыт. Разработка Java-приложения может полностью отличаться от разработки веб-приложения на PHP. Соответственно, в прошлом девелопер, а ныне менеджер должен иметь представление о такой дисциплине как веб и иметь некоторый опыт работы в данной сфере (хотя и не обязательно на том же конкретном языке).