Wymóg angielskiej terminologii uderza rykoszetem w dialogi
Jestem zwolennikiem terminologii angielskiej, czyli wszystkie identyfikatory w kodzie są w tym właśnie języku. Dzięki temu kod rzeczywiście jest samodokumentujący się, bo nie dławi go dysonans angielskiej składni i polskiej terminologii, który nieodwołalnie prowadzi do identyfikatorów typu „ponglish„, np. BeforeZapisz, RestoreZasoby. Oczywiście oddzielnym tematem jest jakość takiej terminologii (np. ewidencja dokumentów, to wszak nie DocumentEvidence 😉 ), niemniej – nawet jeśli ta kuleje – to da się ją w miarę sprawnie naprawić (narzędziami refaktoryzującymi), jak i zadbać o jej jakość (dając po prostu programiście już gotowe nazwy, których ma użyć oraz posiadając odpowiednie konwencje nazewnicze, których powinien się trzymać ustalając nazwy identyfikatorów).
O ile jednak kod taki czyta się bardzo sprawnie, o tyle prowadzenie na jego temat dyskusji zaczyna wyglądać kuriozalnie. Ta bowiem prowadzona jest w języku polskim (zakładam, że zespół nie jest międzynarodowy) i co chwila pojawiają się w niej angielskie słowa. Co gorsza są one spolszczane, bo chociażby odmiany przez przypadki wymaga od nas język polski. Dlatego tworzymy kustomersów i ci kastomersi (tak, tak, każdy inaczej to wymawia) są potem gdzieś przekazywani, aby jakąś operację na owych kastomerach (a co, przecież powinno się tworzyć liczbę mnogą, od liczby pojedynczej oryginału, a nie jego liczby mnogiej) przeprowadzić. No i powstaje nowomowa, która z boku brzmi jak bełkot, a i prowadzącym rozmowę nastręcza trudności interpretacyjnych. Bo: detekujemy czy resoursy egzists czy nie egzists, żeby móc je zasejwić w storydżu.
Trudno na ten stan cokolwiek poradzić, bo występuje tu efekt znany z popularnego doświadczenia, w którym przed czytającym stawiane jest zadanie nazwania koloru czcionek słowa, które jest nazwą zupełnie innego koloru – nie ma zmiłuj – człowiek czyta słowo zamiast określić rzeczywisty kolor (spróbujcie: czerwony, zielony, niebieski).
Osobiście staram się jednak – mimo wszystko – na bieżąco tłumaczyć omawiane terminy, od czasu do czasu dodając („czyli” i tu nazwę oryginalną z kodu). Nie jest to jednak proste zadanie, można się nieźle zmęczyć, niemniej mimo wszystko pozwala mi to lepiej trzymać wątek. Wszystko zależy od treningu ;). Często w ramach tego treningu specjalnie w rozmowie – pomimo, że rozmówca używa angielskiego terminu – zastępuję go polskim odpowiednikiem (zamiast hot-fix mówię po prostu poprawka, zamiast upgrade – ulepszenie lub aktualizacja).
Na koniec warto zwrócić uwagę, że w literaturze traktującej o czystości kodu i jego czytelności tego typu rozważania się nie pojawiają? Dlaczego? Ano dlatego, że zazwyczaj jest to literatura pisana przez anglojęzycznych autorów, dla których ten problem po prostu nie istnieje! Oni w tym języku, w którym piszą również prowadzą o nim dyskusje. Dopiero kiedy propagowane przez nich zalecenia zaczyna stosować cudzoziemiec, pojawia się ów dodatkowy aspekt (nie)czytelności. Paradoksalnie zatem nawet najbardziej czytelny kod z punktu widzenia posługującego się natywnym angielskim nie będzie tak czytelny dla cudzoziemca, bo tam zawsze będzie musiało następować tłumaczenie.
Mając na uwadze ten fakt warto jeszcze zwrócić uwagę, że piętnowanie komentowania klas, których sama nazwa powinna mówić o co chodzi (więc po co komentarz), w przypadku komentowania w innym języku, zaczyna mieć sens. Taki komentarz będzie po prostu jednoznacznym wskazaniem, jak dany byt należy interpretować. Dzięki temu owe – przywołane tu w ramach przykładu – DocumentEvidence, opatrzone komentarzem Ewidencja dokumentów pozwoli zmienić nazwę na poprawną. Ułatwi także rozmowę o terminach po polsku, bo InteliSense podpowie polski odpowiednik.
Nic dodać nic ująć.
Świetny post na – mogłoby się adeptom wydawać – błahy temat.
Największy problem logiczny następuje gdy nikt w zespole nie zada pytania i nie padnie odpowiedź.
Inaczej… Mniejsza o to w danym momencie dla zespołu polskojęzycznego jak wybiorą…
Czy klasy po angielsku, dokumentacja po polsku,
Czy dokumentacja w kodzie po angielsku, a dokumentacja procesów biznesowych na zewnątrz po polsku…
Najważniejsze to ustalić coś konkretnego i się tego trzymać.
Osobiście jestem fanem wszystkiego po angielsku, żadnych literałowych łańcuchów w aplikacji, wszystko powyciągane do słowników. .I trzymanie refów do dokumentacji procesów biznesowych w języku polskim.
Moje małe marzenie które staram się realizować z każdym projektem, przekonywac do tego wszystkich. Ale cieżko przekonać kogoś do nazw angielskich gdy te polskie wydają mu się naturalne.
Kilka przykładów w ramach ćwiczeń:
InternalAdmission
StorageAdmission
InternalDispatch
StorageDispatch
InterStorageAdmission
InterStorageDisplacement
Zamiast DocumentEvidence przyjąłbym chyba nazewnictwo bardziej generyczne (bezpieczniejsze?) i zastosował określenie DocumentList. Też by nie mylić z „rejestrem” itp.