Цікаві анти-патерни

27.12.2018 19:33 | Інше

Нещодавно прочитав книгу "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. Відповідно, в минулому девелопер, а нині менеджер повинен мати уявлення про таку дисципліну як веб, і мати певний досвід роботи в даній сфері (хоча і не обов'язково на тій же конкретній мові).