Na przestrzeni dziejów, językom przytrafiają się rozmaite role do odegrania. Łacina, przez wpływ Kościoła, stała się międzynarodowym językiem średniowiecza. Chiński, będąc pierwszym przed wieloma innymi w Azji, który zyskuje formę pisemną, wpływa na Japonię, która do dziś w dużej mierze korzysta z chińskich znaków. Niemcy, rozwijając kulturę miejską szybciej od nas, pierwsi wymyślają pewne słowa, które trafiają później do polszczyzny – na przykład ratusz (w staroniemieckim Rathus).
Dominacja technologiczna krajów anglosaskich sprawiła, że zarówno w komunikacji morskiej, jak i lotniczej językiem oficjalnym stał się angielski. To samo wydarzyło się z technologią informacyjną. Wszystkie omal języki programowania składają się z słów kluczowych wyrażonych w języku Shakespeare’a. Komendy, które wpisujemy w konsoli to również słowa angielskie. Chcemy tego, czy nie – językiem branży IT jest język angielski.
Nie ma w tym nic odkrywczego. Co drugie ogłoszenie o pracę dla programisty zawiera na liście wymagań znajomość angielskiego. Jest to wymaganie wyrastające z potrzeby współpracy z zagranicznymi klientami albo członkami rozproszonych zespołów wielonarodowych. W wielu krajowych firmach nie wymaga się angielskiego. I choć z pozoru ma to sens, to konsekwencje mogą być poważne.
Każdy chyba, kto studiował, pisał podobne do poniższych koszmarki:
class Zwierze {
oddychaj() {
console.log('Sap sap')
}
}
class Kot extends Zwierze {
miaucz() {
console.log('Miau miau');
}
}
class Pies extends Zwierze {
szczekaj() {
console.log('Hau hau');
}
}
let pies = new Pies();
let kot = new Kot();
pies.szczekaj();
pies.oddychaj();;
kot.oddychaj();
kot.miaucz();
Mieszanie języków jest powszechnie uznawane za nieeleganckie i nie spotkałem się jeszcze z takim kodem w żadnej firmie, w której pracowałem, czy to polskiej, czy zagranicznej.
W pewnym minimalnym stopniu każdy programista angielski zna. Bez niego ciężko utrzymać się w branży, w której cała niemalże dokumentacja techniczna jest w nim wyrażona. Subtelny problem, który niełatwo na pierwszy rzut oka zauważyć polega na głębokości znajomości języka.
Nie da się pisać czystego kodu nie znając dobrze angielskiego.
Jak wiemy kod powinien być czytelny. Nazwy zmiennych adekwatne, metody krótkie, zwięzłe, klasy odpowiedzialne za to, co ich nazwy sugerują. Niestety, jeśli programista nie czuje się z językiem angielskim naprawdę komfortowo, to dość szybko dopadnie go problem z nazwaniem nawet nieprzesadnie skomplikowanych rzeczy w kodzie.
Wszyscy znamy urocze pomyłki w gastronomii:
Żeby być jednak uczciwym, nie jesteśmy w IT wolni od grzechu. Podczas telekonferencji ze współpracownikami z zagranicy mój kolega powiedział swego czasu it’s in the first akapit – zapominając, że przecież akapit w języku angielskim nie istnieje, bo jest to paragraph. Choć równie urocze pomyłki zdarzają się ze strony klientów. Pewna Włoszka kazała mi, kilka lat temu, pewną rzecz semplificare zamiast simplify.
Tyle, że kiedy w kodzie pojawiają się takie pomyłki nie jest już zbyt zabawnie. Szczególnie, gdy znajdujemy je w odziedziczonym systemie sprzed dziesięciu lat i nie możemy dojść do ładu, o co w nim chodzi, a zapytać już nie ma kogo, bo wszyscy jego autorzy pracują u konkurencji.
Żeby jednak nie być gołosłownym, przytoczę kilka przykładów wziętych z życia:
- exhibitConfirmation – zamiast issueConfirmation
- doneDate – zamiast completionDate
- eogAvailable – zamiast eea (European economic area, po polsku Europejski obszar gospodarczy)
To krótkie, smutne pomyłki, ale o wiele gorsze są dłuższe nazwy zmiennych, metod i klas. Tam braki językowe uwidaczniają się mniej spektakularnie, ale są nieraz dotkliwsze dla czytelności kodu. Wreszcie – kiedy ktoś stworzy jakąś klasę lub metodę robiącą to i owo, a następnie nie umie ich po angielsku zgrabnie nazwać, to nadaje jej nic nie mówiącą nazwę getData albo saveData albo processData.
Język angielski warto doskonalić. Czytać, pisać, słuchać, utrzymywać z nim kontakt, oglądać filmy, wiadomości, czytać książki, podręczniki, blogi, pisać cokolwiek jeszcze poza kodem. Najlepiej moim zdaniem rozmawiać z obcokrajowcami.
Tworząc zaś zespół lub zatrudniając programistę – dobrze jest zwrócić uwagę na tę subtelną różnicę między B2, a C1, czy C2. Z klientem porozumieć się jest dość łatwo. Dość łatwo jest także napisać kod, który będzie niegramatyczny, nieczytelny i kosztowny w utrzymaniu.
Comments