Kotlin to język działający na tej samej maszynie wirtualnej co kod, który organizacja ma dziś, z pełną wymiennością wywołań w obie strony. Decyzja o nim nie jest ćwiczeniem ze składni. Jest rozstrzygnięciem o tym, czy koszt zmiany języka zwraca się szybciej niż koszt utrzymania tego, który jest.
Na skróty
Czego dowiesz się z artykułu:
- Jaki koszt organizacja ponosi w kodzie, zanim ktokolwiek zaproponuje zmianę języka
- Jakie warunki muszą wystąpić razem, żeby ta zmiana była właściwą odpowiedzią
- W jakich sytuacjach zmiana języka nie odpowiada na realny problem
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje, wprowadzając drugi język do jednego repozytorium
Dla kogo ten artykuł:
- Kierownicy zespołów rozstrzygający, w czym powstaje nowy kod
- Architekci odpowiadający za spójność technologiczną systemu
- Menedżerowie planujący budżet rekrutacji i szkoleń na lata
Ile kosztuje organizację kod, w którym ta sama klasa błędów wraca co wydanie?
Rachunek nie zaczyna się od nazwy języka. Zaczyna się od pozycji, których nikt nie księguje osobno: awaria produkcyjna wywołana odwołaniem do wartości, której nie było, przegląd kodu zajęty tym samym rodzajem uwagi co poprzednio, i godziny spisywania konstrukcji, które nie niosą żadnej decyzji biznesowej. Każda z tych pozycji jest mała. Razem stanowią stałą pozycję w koszcie każdego wydania.
Do tego dochodzi koszt, który widać dopiero w rozmowie o zatrudnieniu. Kod pisany stylem sprzed lat czyta się wolniej, więc wdrożenie nowej osoby trwa dłużej, a przy odejściu autora nikt nie chce podjąć jego modułu. Organizacja odkłada wtedy zmiany tam, gdzie utrzymanie jest najdroższe — i to odkładanie, a nie sam kod, jest realnym wydatkiem.
Problem ma odmiany, a ich pomylenie kosztuje najwięcej. Pierwsza odmiana to jakość: powtarzalna klasa defektów, którą da się usunąć konstrukcją języka, a nie dyscypliną zespołu. Druga to tempo: kod działa poprawnie, ale jego pisanie i czytanie zajmuje czas nieproporcjonalny do tego, co wyraża. Trzecia to zasięg: ten sam fragment logiki jest utrzymywany osobno na serwerze i w aplikacji mobilnej, więc każda zmiana reguły biznesowej jest wykonywana i testowana dwukrotnie. Rozstrzygnięcie nie zależy od tego, ile lat zespół pisze w języku zastanym — zależy od tego, którą z tych odmian organizacja faktycznie ponosi.
Kiedy zmiana języka na tej samej platformie jest właściwą odpowiedzią?
Zmiana języka jest właściwą odpowiedzią wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno:
- Kod pozostaje na tej samej platformie uruchomieniowej. Nowy język kompiluje się do tego samego formatu i woła istniejące biblioteki bez warstwy pośredniej, więc migracja jest przyrostowa i odwracalna. Zmiana platformy jest decyzją innego rzędu i innego budżetu.
- Klasa defektów do usunięcia jest nazwana przed startem. Jeżeli powodem jest odwołanie do wartości nieistniejącej albo rozjazd między obiektami przenoszącymi dane, konstrukcja języka wyręcza tu przegląd kodu. Jeżeli powodem jest „nowocześniejsza składnia”, nie ma czego zmierzyć po wdrożeniu.
- Organizacja godzi się na okres współistnienia. Przez lata w jednym repozytorium będą dwa języki naraz: dwa zestawy narzędzi, dwie konwencje, wspólny proces budowania. Zespół, który tego nie zaplanuje, dostanie ten stan i tak, tylko bez decyzji.
Dopiero gdy te warunki występują łącznie, sensu nabiera nauka samego języka: typy dopuszczające brak wartości, klasy danych, funkcje rozszerzające i obsługa współbieżności bez ręcznego zarządzania wątkami. Ten zakres — od struktur języka po pierwszy działający moduł — obejmuje szkolenie Kotlin dla początkujących.
Kiedy tej technologii nie wybierać?
Najczęstszym błędem jest sięgnięcie po nowy język w imię modernizacji, bez nazwania kosztu, który ma zniknąć. Zespół dostaje wtedy repozytorium z dwiema konwencjami i bez żadnej korzyści, którą dałoby się pokazać w przeglądzie po roku.
Poza tym są sytuacje, w których zmiana języka nie odpowiada na realny problem. System w fazie utrzymania, do którego wchodzą wyłącznie poprawki, nie zwróci kosztu migracji — nowy język podnosi tam ryzyko regresji i nie skraca niczego, bo nowego kodu prawie nie ma. Zespół bez planu przeszkolenia całego składu dostanie kod, który pisze pojedyncza osoba, a reszta obchodzi; taka wyspa jest droższa niż język zastany, bo do jej utrzymania potrzeba konkretnego nazwiska. Problem leżący poza kodem — w architekturze, w procesie wydawniczym albo w braku testów — nie znika po zmianie składni; przenosi się do nowych plików w niezmienionej postaci. Żadnej z tych sytuacji nie zmienia to, ile pracy włożono już w rozpoznanie narzędzia. Punktem odniesienia dla kosztu pozostania przy stanie obecnym jest język, który dziś w tym systemie pracuje — rozkłada go tekst o popularności, zaletach i zastosowaniach Javy.
Jakie są alternatywy i ile kosztują?
Pozostanie przy języku zastanym i podniesienie jego wersji nie wymaga rekrutacji ani nowych narzędzi, a nowsze wydania platformy same zdejmują część rozwlekłości. Ceną jest to, że klasa defektów wynikająca z braku wartości pozostaje możliwa i nadal zależy od dyscypliny przeglądu. Analiza statyczna z adnotacjami wykrywa część tych samych błędów bez zmiany języka, ale działa jako warstwa obok kompilatora: trzeba ją utrzymywać i egzekwować w procesie budowania, a jej ostrzeżenia bywają wyłączane pod presją terminu. Wydzielenie problematycznego fragmentu do osobnej usługi pozwala napisać go w czymkolwiek, tyle że płaci się za to rachunkiem operacyjnym: własnym wdrożeniem, monitorowaniem i granicą sieciową tam, gdzie wcześniej było wywołanie funkcji.
Ostatnia droga bywa najtańsza i najrzadziej rozważana: zostawienie języka w spokoju i naprawienie procesu — testy tam, gdzie ich nie ma, i przegląd, który wyłapuje rzeczy istotne zamiast formatowania. Bywa też jedyną, która działa, bo pozostałe zakładają, że problemem jest narzędzie. Które kompetencje rzeczywiście opłaca się dziś budować w zespole, rozkłada zestawienie języków programowania wartych nauki.
Co organizacja podpisuje, wprowadzając drugi język do jednego repozytorium?
Podpisuje przede wszystkim okres przejściowy bez daty końcowej. Wymienność wywołań w obie strony sprawia, że migracja może iść plik po pliku — i dokładnie dlatego zwykle nigdy się nie kończy. Bez zapisanej reguły, co powstaje w nowym języku, a co zostaje, organizacja utrzymuje dwa style w nieskończoność i płaci za oba.
Podpisuje też zależność narzędziową: proces budowania obsługujący obie ścieżki kompilacji, dłuższy czas budowy i biblioteki sprawdzane pod kątem współpracy z nowym językiem. Najdroższą pozycją nie jest jednak żadna z tych rzeczy, tylko kompetencja całego składu. Wyspa kodu czytana przez pojedynczą osobę jest większym ryzykiem niż język zastany, bo zamienia zmianę w kolejkę do jednego kalendarza. Rolą, która ten rachunek obniża, jest zespół potrafiący czytać i pisać w obu językach w jednym projekcie — czyli zakres szkolenia Kotlin dla programistów Java. Bez tego organizacja płaci podwójnie: za migrację i osobno za każdą zmianę w części, której nie umie utrzymać.
FAQ — najczęściej zadawane pytania
Czy trzeba przepisać istniejący kod, żeby zacząć?
Nie. Wywołania działają w obie strony, więc nowy język wchodzi zwykle przez nowe moduły i testy, a kod zastany zostaje bez zmian. Ryzykiem nie jest technologia, lecz brak reguły: jeżeli nikt nie zapisze, co powstaje w którym języku, repozytorium rozjeżdża się samo.
Czy zmiana języka poprawi jakość naszego oprogramowania?
Usunie tę klasę defektów, którą wyklucza konstrukcją — przede wszystkim odwołania do wartości nieistniejącej. Nie usunie błędów logiki biznesowej, braków w testach ani wad architektury. Jeżeli przegląd defektów z ostatniego roku wskazuje na te drugie, zmiana języka jest wydatkiem bez pokrycia.
Po czym poznać, że migracja utknęła?
Po tym, że reguła podziału przestaje być czytelna: nowe funkcje powstają w obu językach zależnie od tego, kto je pisze, a granica przebiega przez autorstwo, a nie przez moduły. To jest moment na decyzję o zakresie, a nie na kolejne szkolenie — dwuletni stan przejściowy kosztuje więcej niż każda z dróg wybrana wprost.