Convention over Configuration

Convention over Configuration (w skrócie CoC) to zasada projektowa stosowana w tworzeniu frameworków oraz aplikacji, polegająca na przyjęciu domyślnych konwencji w celu ograniczenia liczby niezbędnych konfiguracji. Dzięki temu programiści mogą skupić się na logice biznesowej, zamiast definiować szczegóły techniczne, które w większości przypadków są przewidywalne.

Historia

Idea convention over configuration wyłoniła się w latach 80. i 90. XX wieku, jednak największą popularność zyskała wraz z powstaniem Ruby on Rails (2004) – frameworku internetowego, w którym zasada została sformalizowana i wprowadzona jako paradygmat projektowy. Od tego czasu CoC jest wykorzystywany w innych środowiskach, takich jak Django (Python), Spring (Java) czy ASP.NET Core (C#).

Zasada działania

CoC opiera się na trzech podstawowych elementach:

Domyślne konwencje – standardowe nazwy, struktury katalogów, typy plików i wzorce projektowe, które są przyjęte w danym ekosystemie.
Automatyczne wykrywanie – framework w czasie uruchamiania sam odkrywa elementy aplikacji spełniające konwencje (np. klasy modeli, kontrolery, widoki).
Możliwość nadpisania – programista może w dowolnym momencie skonfigurować zachowanie, jeśli domyślne ustawienia nie spełniają wymagań projektu.

Przykłady w praktyce

Najbardziej rozpoznawalne implementacje CoC to:

Ruby on Rails – domyślna struktura katalogów app/models, app/views, app/controllers oraz konwencja nazewnictwa klas (np. User → tabela users).
Django – konwencja models.py, views.py, a także automatyczne generowanie interfejsu administracyjnego.
Spring Boot – konwencja nazewnictwa beanów i automatyczne wykrywanie komponentów przy użyciu adnotacji (@Component, @Service).
ASP.NET Core – konwencja katalogu Pages w razie Razor Pages oraz automatyczne mapowanie routingu.

Porównanie z innymi podejściami

Tradycyjne podejście configuration over convention wymagało rozbudowanej konfiguracji (np. plików XML, INI, YAML). CoC przeciwstawia się temu, redukując potrzebę utrzymywania takiej dokumentacji. W praktyce:

Cecha	Configuration over Configuration	Convention over Configuration
Rozmiar kodu	Większy – wiele deklaracji	Mniejszy – większość ustawień domyślnych
Krzywa uczenia	Może być łagodna, ale wymaga znajomości licznych opcji	Początkowo wyższa – konieczność poznania konwencji
Elastyczność	Wysoka – wszystko konfigurowalne	Dobra – istnieje możliwość nadpisania domyślnych zachowań

Zalety i wady

Zalety:

Redukcja powtarzalnego kodu – wspiera zasadę DRY (Don’t Repeat Yourself).
Szybszy start projektów – mniejsze bariery wejścia dla nowych zespołów.
Łatwiejsze utrzymanie – mniej plików konfiguracyjnych do przeglądania.

Wady:

Ukryta złożoność – domyślne zachowanie może być niejasne dla początkujących.
Potencjalny konflikt konwencji – przy integracji z innymi systemami może wymagać dodatkowej konfiguracji.
Ograniczona kontrola – w niektórych scenariuszach programista musi najpierw wyłączyć domyślne zachowanie.

Znaczenie w nowoczesnym oprogramowaniu

Współczesne programowanie coraz częściej opiera się na frameworkach i narzędziach, które przyjmują zasadę CoC jako podstawę swojej architektury. Dzięki temu zespół może skupić się na architekturze aplikacji, wzorcach projektowych oraz testowaniu, a nie na zbędnych szczegółach konfiguracyjnych.

Powiązane pojęcia

Bibliografia

Artykuły i materiały źródłowe pochodzą głównie z dokumentacji oficjalnych frameworków oraz publikacji poświęconych tematyce inżynierii oprogramowania.