Перейти до основного вмісту

Test desiderata

· 3 хв. читання
Petro Ostapuk
Software Engineer
    Йди спокійно серед шуму і поспіху,
і пам'ятай, який мир може бути в тиші

Нещодавно я опублікував цей твіт (Kent Beck):

    Тести повинні бути пов'язані з поведінкою коду і відокремлені від 
структури коду. Побачивши тести, які не спрацьовують за обома пунктами.

Я думав, що ця властивість тестів очевидна і широко зрозуміла, але твіт вибухнув. Я бачив тести, які є просто жахливим синтаксисом, що повторює в точності те, що вже сказано у вихідному коді, який тестується. Я пішов і перечитав TDD: На прикладі, і цих властивостей ніде не було, тож, гадаю, не варто було дивуватися.

Domain-driven design

· 8 хв. читання
Petro Ostapuk
Software Engineer

Domain-driven design (Предметно-орієнтоване проєктування, рідше проблемно-орієнтоване) - це набір принципів і схем, спрямованих на створення оптимальних систем об'єктів. Зводиться до створення програмних абстракцій, які називаються моделями предметних областей. У ці моделі входить бізнес-логіка, що встановлює зв'язок між реальними умовами області застосування продукту і кодом.

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

Стратегічне проєктування

Проєктування на високому рівні абстракції, без технічних нюансів, що здійснюється всією командою - як менеджерами/замовниками, так і технічними фахівцями.

Основною метою застосування DDD є отримання високоякісної моделі програмного забезпечення, яка максимально точно відображатиме поставлені бізнес-цілі. Для реалізації цього потрібне об'єднання зусиль як розробників, так і експертів у предметній області. Створення дружної та згуртованої команди дає змогу отримати велику кількість переваг для бізнесу. Обмін знаннями між членами команди знижує шанси появи "таємного знання" про модель, досягається консенсус між експертами предметної області щодо різних понять і термінології, розробляється більш точне визначення та опис самого бізнесу.

GRASP

· 4 хв. читання
Petro Ostapuk
Software Engineer

GRASP (General Responsibility Assignment Software Patterns) - шаблони проектування, які використовують для вирішення загальних завдань із призначення обов'язків класам і об'єктам.

Відомо дев'ять GRASP шаблонів, спочатку описаних у книжці Крейга Лармана "Застосування UML і шаблонів проєктування". На відміну від звичних читачеві патернів із Банди Чотирьох, GRASP патерни не мають вираженої структури, чіткої сфери застосування і конкретної розв'язуваної проблеми, а лише є узагальненими підходами/рекомендаціями/принципами, які використовують під час проєктування дизайну системи.

Розглянемо характеристики основних GRASP шаблонів.

Don't Repeat Yourself (DRY)

· 2 хв. читання
Petro Ostapuk
Software Engineer

У програмуванні існує принцип DRY, або "не повторюйся" (Don't Repeat Yourself). Як правило, якщо ви повторюєте частини своєї логіки, у вас буде більше місць, які потрібно буде виправити, якщо буде виявлено проблему, і ймовірність появи невідповідностей у вашому додатку, оскільки майбутні вимоги збільшують складність додатка.

Одним з підходів до створення DRY коду, про який я хотів би поговорити, є функціонал в PHP під назвою traits, який дозволяє повторне використання коду в будь-якому класі в кодовій базі.

Keep It Stupid Simple (KISS)

· 4 хв. читання
Petro Ostapuk
Software Engineer

Що означає KISS?

KISS - це абревіатура від Keep It Stupid Simple або Keep It Simple, Stupid

Що це означає?

Цей принцип був ключовим і приніс величезний успіх за роки роботи в галузі програмної інженерії. Поширеною проблемою серед інженерів та розробників програмного забезпечення сьогодні є те, що вони схильні надмірно ускладнювати проблеми.

The twelve-factor app

· 2 хв. читання
Petro Ostapuk
Software Engineer

Більше детально можна ознайомитись на сайті: Дванадцять факторів

Дотримання цієї методології, потребує розвинутої DepOps культури, але це не означає, що не потрібно прагнути до досконаліших процесів в розробці. Навпаки, чим більш уніфіковані процеси розгортання локального середовища і чим менша різниця між development, stage, production середовищем, тим швидша адаптація нових розробників, котрі приєднуються до команди.

Soft skills

· 1 хв. читання
Petro Ostapuk
Software Engineer

Колись давно на Youtube дивився відео і зробив замітки на чернетку. Щоб інформація з папірця не згубилась, просто лишу це тут.

На мою думку, це є важливі навички не тільки для розробника.

Ось їх список: