Czy faktycznie takie technologie jak docker, terraform, kubernetes, orm, wszelkie frameworki i biblioteki i bazy danych można określić mianem "narzędzia"? Określnie na pewno zaporzyczone z dziedzin inżynierii bardziej "realnej", jak mechanika/elektryka/fizyka, i tam w rzeczy samej narzędzia są nieocenione - używa się ich, do czegoś. Np śrubokrętu do wkręcenia czegoś, miernika do sprawdzenia napięcia, wiertarki do zrobienia dziury. Ale po skończonym projekcie, wszystkie narzędzia mechaniczne są zabierane z powrotem przez firme która wykonała zadanie. Oczywiście pewne materiały musiały zostać użyte, jakiś cement, gips, luta, etc - owszem, to materiały. Ale narzędzia zostały zabrane. Ktoś inny, może przyjść z zupełnie innymi narzędziami i wprowadzić zmiane w mieszkaniu czy układzie. Z tej uwagi są wszechstronne, szybkie do użycia i bardzo tanie (koszt nauczenia się ich obsługi jest mały, względem tego co można nimi osiągnąć). Oczywiście, muszą spełniać pewne kryteria - płaskiego nie odkręcimy krzyżakiem; ale mamy dowolność w wyborze swojego śrubokręta lub wkrętarki.
Ale w programowaniu, rzeczy które noszą nazwę "narzędzia" nie cechują się tymi kryteriami. Kiedy "używamy" dockera do czegoś, to musimy napisać tam Dockerfile/docker-compose porobić odpowiednie obrazy, i dochodzi do sytuacji w której tak "zdockeryzowany" projekt już nie można odpalić bez dockera. Podobnie jest z wszystkimi frameworkami i bibliotekami - 99% programistów nie stosuje dependency inversion oraz odpowiednich abstrakcji (heh, interfejsów jest milion, ale dobrej abstrakcji nadal nie ma) więc raz dodany framework lub biblioteka jest na stałe przywiązana do tego projektu i nie sposób się jej pozbyć. Również korzystanie z bazy danych nas często ogranicza, bo ustawienia oraz specjalne hack często są specificzne do danej bazy danych - w dojrzałych projektach często zachodzą potrzeby zmiany silnika bazy danych, ale nie robi się tego przez zbyt dużą trudność techniczną. Dostając projekt do wykończenia, nie możemy użyć już innych narzędzi (tak jak inny pan majster mógłby), jesteśmy bardzo silnie związani z użytą technologią. Odpowiednim słowem "zbiorczym" na wszelkiego rodzaju dockery, terraformy, kubernetesy, frameworki i biblioteki to byłoby: "zależność". (Spodziewam się że wielu ludzi przywykły do myśli "dockerem można się oddzielić od systemu", więc jak docker mógłby być zależnością? :o No ale to jest po prostu inny rodzaj zależnośći - zamiast zależności od OS'a, mamy zależność od dockera - mniejsze zło). Servera również nie można nazwać narzędziem (chyba że w domyślnej konfiguracji), bo jak dodamy .htaccess
do projektu to bam - kolejna zależność.
Co więc można nazwać narzędziem? Moim zdaniem coś co jest pomocne przy wytwarzaniu oprogramowania, ale powstałe w ten sposób oprogramowanie można nadal rozwijać bez jego pomocy, lub przy pomoc czegoś innego.
Przykłady moim zdaniem to:
- IDE, edytory
- shelle (jak bash, fish)
- git (bo jedyna zależność gita na projekt to jest dodanie
.gitignore
, czyli bardzo mało) - kompilator (pod warunkiem że w oprogramowaniu nie ma zależności na ten kompilator, oprócz wersji)
- repozytorium (github, gitlab, bitbucket, azure - pod warunkiem że nie mamy zależności na ten cloud, np jakby spora cześć logiki była odpalana w github actions)
- klienty http (jak postman albo jakiś backuper bazy danych)
- generatory dokumentacji z kodu (pod warunkiem że nie mamy zależności na niego w kodzie, jak np swagger)
- Docker (np do postawienia bazy danych na szybko; bo w momencie jak dodajemy
Dockerfile
idocker-compose.yaml
do projektu, to znowu to jest zależność) - narzędzia developerskie: jak debugger i profiler
- scaffold frameworków (artisan, cargo, manage, rails)
I to by było na tyle? Chyba nic innego nie zasługuje na miano "narzędzie", bo cokolwiek innego chcemy "użyć" w projekcie, to automatycznie przywiązujemy nasz projekt do tego.
Więc pojawia się pytanie, skąd taka moda na używanie określeń takich jak tool?