W jakim języku mam nazwać swoje klasy biznesowe?

29

Proszę o najlepszą praktykę w tym pytaniu. Jest to problem tylko wtedy, gdy firma będąca klientem ma wyłącznie krajowy język ojczysty inny niż angielski, tak myślę.

Jeśli klient ma wiele wyrażeń głównie specyficznych dla domeny (powiedzmy niemiecki), zmieszanych z niektórymi mniejszymi nazwami specyficznymi dla domeny. Językiem naszych komentarzy do kodu, nazw klas / metod / zmiennych jest angielski. Czy przetłumaczysz wszystkie nazwy specyficzne dla domeny?

naming

— Zeemee
źródło

11

Język angielski. Lingua franca do programowania.

— rig

6

Jednym z bardziej „wymagających” komunikatów o błędach PHP ma ciekawy twist hebr unexpected T_PAAMAYIM_NEKUDOTAYIM. Widząc to kilka razy w życiu, nie mam wątpliwości, że należy używać angielskiego.

— K.Steff,

3

Czy któreś z niemieckich wyrażeń specyficznych dla domeny ma niestandardowe znaki (np. Umulauts (sp?))? Jeśli zatrudnisz programistów spoza twojego regionu, może nie być w stanie znaleźć klawiatury z wymaganymi znakami (moje nie). Tak, są sposoby na zmianę języka „na maszynie”, ale nie chciałbym, aby to było kłopotliwe.

— Clockwork-Muse,

2

Grecki - używanie alfabetów innych niż łacińskie zapewnia lepsze bezpieczeństwo pracy niż klingon.

— Wyatt Barnett,

3

@ X-Zero wychodząc poza zwykły ASCII otwiera puszkę robaków „jakiego kodowania znaków używamy”. Zwykle gryziesz się i nie idziesz tam ponownie.

16

Pracuję w Niemczech i wolę wybrać angielski.

Czasami np. Rzeczy specyficzne dla domeny, takie jak tworzenie modułu do „DATEV” (niemieckie oprogramowanie do faktur / faktur) Używam niemieckich nazw. Niektórych niemieckich słów nie można poprawnie przetłumaczyć, np. „Referenzbuchungsnummer” (ReferenceBookingNum?) Lub „Sachkontenlaenge” (..?). Wydaje mi się też, że rzeczy specyficzne dla domeny skończyłyby się horrorem konserwacyjnym. Może pamiętasz, że ReferenceBookingNum odnosi się do „Referenzbuchungsnummer”, ale co z twoimi współpracownikami? Muszą zapoznać się z wewnętrzną dokumentacją dotyczącą nazewnictwa, jeśli taka dokumentacja istnieje. Nie będą zbyt dobrze zaznajomieni z modułem bez odpowiednich nazw. Jest to niepotrzebna złożoność, jeśli wszyscy inni deweloperzy również są Niemcami. Ale „CakeFactory” brzmi znacznie lepiej niż „KeksFabrik”;)

Więc wszystko zależy.

— lurkerbelow
źródło

2

Ta odpowiedź najbardziej odzwierciedla mój osobisty sprzeciw po przeczytaniu innych odpowiedzi. Zwłaszcza ten punkt: „Tłumaczenie wszystkiego jest niepotrzebną złożonością, jeśli wszyscy inni deweloperzy też są Niemcami”.

— Zeemee,

1

@Mulmoth: „Niepotrzebna jest złożoność, jeśli wszyscy inni deweloperzy również są Niemcami” - skąd możesz mieć pewność, że w pewnym momencie, za kilka lat, projekt nie zostanie zlecony innemu krajowi? Skąd możesz mieć pewność, że programista niemówiący po niemiecku nie zostanie wprowadzony do projektu w pewnym momencie?

— Coral Doe,

5

@Coral Doe - Myślę, że nowy / inny / outsourcing programista musi już zagłębić się w domenę biznesową i jej specyficzne wyrażenia. Imho łatwiej jest odwzorować to, co klient (który nadal będzie niemieckim), mówi do nazwanych klas niemieckich zamiast źle / źle przetłumaczonych angielskich nazw.

— Zeemee,

2

„Faktury” związane z niemieckimi fakturami / podatkami nigdy nie będą zlecane na zewnątrz w kraju niemówiącym. Na uniwersytecie ktoś powiedział mi, że 85 procent wszystkich książek rachunkowych / podatkowych odnosi się do niemieckiego prawa i jest napisanych po niemiecku. na calym swiecie.

— lurkerbelow

3

Zgadzam się, ale jednym z problemów, który prawie zawsze się zdarza, jest to, że język używany przez programistów przenika do użytkowników i innych interesariuszy. Nie jako część interfejsu użytkownika, ale sposób mówienia o problematycznej dziedzinie. To nieuchronnie doprowadzi do zamieszania, ponieważ nie wszyscy mówią tak dobrze po angielsku, jak większość programistów.

— Mille Bessö,

14

Jako Norweg pracujący w norweskiej firmie, moje przedmioty nazywam po angielsku. Oczywiście niektóre słowa lub pojęcia mogą nie mieć odpowiednika w języku angielskim, w takim przypadku można argumentować, że zamiast złego zastąpienia lub dosłownego tłumaczenia, które nie ma znaczenia, można użyć rodzimego słowa. Oczywiście, wiele z tych problemów może polegać na tym, że niektórzy z nas powinni mieć lepsze słownictwo, więc zwykle pytam kolegę, czy nie mogę wymyślić dobrego angielskiego imienia :)

Niektórzy z naszych pracowników nie są Norwegami, a więc pisanie po angielsku przynosi im korzyści. Możliwość zatrudniania programistów z większości krajów Europy jest korzystna dla gospodarki, więc moja firma również z tego korzysta.

BTW: Pamiętam, że raz przeczytałem źródło Hermesa (implementacja ebXML b2b) i miałbym trudności z napisaniem i skomentowaniem w języku mandaryńskim.

— Sylwester
źródło

5

Prawie zredagowałem „college” do tego, co, jak zakładam, ma być „kolegą”, ale nie byłem pewien, czy to było zamierzone.

— Jacob Schoen,

Oczywiście miałem na myśli kolegę :)

— Sylwester

Of course some words or concepts might not have a English counterpart- Zawsze jestem ciekawy, kiedy pojawia się to w programowaniu, prawie tak, jakbyś mógł znać wzór, którego nie wymyśliliby tylko anglojęzyczni. Czy masz szybki przykład?

— Izkata,

5

@Izkata: pytanie dotyczyło klas biznesowych . Częściej są one związane z przepisami i regulacjami obowiązującymi w danym kraju. Np. Jeśli prawo zmusza cię do śledzenia lokalizacji wszystkich ciężarówek z niebezpiecznymi chemikaliami, możesz równie dobrze nazwać tę klasę na podstawie tego prawa.

— MSalters,

9

Uważam, że ponieważ angielski jest lingua franca w branży IT, ograniczenie kodu źródłowego do innego języka stwarza sztuczne przeszkody w jego rozwoju. Najpierw ogranicz liczbę osób, które mogą przyczynić się do osób mówiących określonym językiem. Ten sam powód, o który prosiłeś w wymianie stosu, a nie na stronie lokalnej.

Nie wiesz także, skąd pochodzą składki i dokąd jechać. Co się stanie, jeśli użyjesz próbki ze strony, czy to przetłumaczysz? Co się stanie, jeśli produkt rozszerzy się i będzie używany przez klientów w innym kraju? Czy potrzebujesz trochę zatrudnić kontrahenta / outsourcing? Po co ograniczać się do jednej puli i nie być jak najlepiej dopasowanym z całego świata?

Można założyć, że jest OK dla niektórych struktur specyficznych dla domeny, które nie są łatwo mapowane na inne języki lub jeśli zachowana jest istniejąca baza kodu.

— Dimitrios Mistriotis
źródło

9

Moim ostatnim celem projektu było modelowanie domeny biznesowej zabezpieczeń i hipotek. Wszyscy programiści i firma, dla której pracowaliśmy, pochodzą z Polski. Oprogramowanie zbudowaliśmy zgodnie z zasadami projektowania opartego na domenach. Użyliśmy polskich nazw dla wszystkich podmiotów gospodarczych i myślę, że był to bardzo dobry wybór. Myślę, że dzięki temu podejściu udało nam się uniknąć problemów z komunikacją. Domena biznesowa składała się z wielu terminów, których nawet nie znałem po polsku, nie mówiąc już o tłumaczeniach na angielski. Używaliśmy tylko liter łacińskich, a wszystkie klasy techniczne nazwano po angielsku.

— empi
źródło

4

To dobra uwaga: jeśli cała wiedza na temat domeny jest w języku lokalnym i nie istnieją uzgodnione nazwy angielskie dla pojęć domenowych, użycie języka lokalnego może być dobrym pomysłem.

— Joachim Sauer,

7

Generalnie łatwiej jest odczytać kod źródłowy napisany w jednym języku. To dla większości języków programowania oznacza, że powinieneś napisać to po angielsku.

To powiedziawszy, istnieje poważny problem z koncepcjami domen, które niełatwo tłumaczyć na angielski. Typowym przykładem jest unikalny identyfikator, który społeczeństwo podaje jednostce - w USA najbliższym pojęciem jest numer ubezpieczenia społecznego, ale nie jest to dokładne odwzorowanie. Nazwy i numery telefonów zwykle mapują się całkiem dobrze.

Uważam, że zazwyczaj konieczne jest utrzymanie warunków domeny, ilekroć dokładne mapowanie nie jest łatwo dostępne w języku angielskim, ale tylko te - resztę należy zachować w języku angielskim. Spowoduje to nietypowe identyfikatory, takie jak KommuneImpl, ale powinno to mieć natychmiastowy sens dla tych, którzy znają domenę.

2

Projekty typu open source / społeczność międzynarodowa

Wspólnym językiem projektów otwartych i międzynarodowych społeczności jest angielski. W tym przypadku językiem stron stosu wymiany jest angielski. Aby zapewnić jak najszerszą dostępność, w przypadku wszystkich kodów i nazw obiektów należy używać języka angielskiego.

Projekty komercyjne

Większość międzynarodowych firm programistycznych zleca pisanie kodu w języku angielskim. Jest to największy wspólny mianownik, dlatego warto używać angielskiego jako środka zapewniającego spójność.

Wiele regionalnych firm programistycznych pisze w swoim ojczystym języku. Nie wszyscy stosują to podejście, ale ma to sens z ich punktu widzenia - używają wspólnego języka dla wszystkich swoich programistów.

Nazewnictwo obiektów biznesowych

Do nazwania obiektów należy używać języka kodowania zespołu.
Priorytetem jest, aby programiści mogli komunikować się ze sobą w odniesieniu do obiektów i wymagań projektu. Jeśli zespół pisze w języku francuskim, obiekty biznesowe należy nazwać po francusku. Jeśli kodują w języku angielskim, nazwij obiekty w języku angielskim.

Twoje pytanie dodaje zmarszczek, ponieważ klient mówi w ojczystym języku innym niż język programowania Twojego zespołu. Nadal powinieneś używać języka kodowania swojego zespołu do nazywania obiektów.
Gdy analitycy biznesowi lub programiści muszą komunikować się z klientem na temat określonych obiektów biznesowych, może być wymagane tłumaczenie nazwy obiektu z języka kodowania na język klienta. Z mojego doświadczenia wynika, że dość rzadko rozmawiałem o konkretnych obiektach kodu z klientem, więc tłumaczenie z powrotem na język klienta nie było tak naprawdę potrzebne.

Jedynym wyjątkiem od reguły nazewnictwa jest sytuacja, gdy obiekt nie ma innego wystarczająco zwięzłego terminu, aby uchwycić zamiar obiektu. IMO, to naprawdę rzadkie, ale może się zdarzyć. W rzeczywistości jednak to samo robi język mówiony, aby wyrazić określone pojęcia. „ Fasada ” jest początkowo francuskim terminem, ale został dostosowany przez angielski w celu wyrażenia koncepcji i jest wspólnym wzorcem projektowym. „ Schadenfreude ” to kolejny dobry przykład pożyczonego terminu, chociaż nie sądzę, że ma odpowiedni wzór.

1

Wygląda na to, że ostatni akapit jest całkowicie sprzeczny z pierwszym

— James

@James - dzięki! Usunąłem tę sekcję, ponieważ w tej chwili nie mam czasu, aby wyjaśnić, co miałem na myśli. To miało być wsparcie, ale nie ważne.

1

Kategorycznie się nie zgadzam. Ponieważ podstawowe pojęcia praktycznie każdego języka, z którym się spotkasz, są napisane w języku angielskim, użycie nieanglojęzycznej terminologii prowadzi do mniej czytelnego kodu źródłowego. Umysł stale musi przeskakiwać między angielskim a drugim językiem. Kod powinien być płynny i czytelny.

— Mike Adler,

@MikeAdler - nie jest jasne, czy nie zgadzasz się z tym, co sugeruję jako ogólną zasadą (nazwij rzeczy w języku zespołu) lub przypadkiem wyjątku, który powinien być bardzo rzadki.

Zgoda. Wyjaśnię: Nie zgadzam się, że jakikolwiek obiekt powinien być kiedykolwiek nazwany w języku innym niż angielski. Twój pierwszy nagłówek „Projekty typu Open Source / społeczność międzynarodowa” bardzo dobrze odzwierciedla mój punkt widzenia. Po tym wszystkim nie kupuję. Jak już wspomniano, przyczyną jest łatwość konserwacji, która moim zdaniem powinna być nadrzędna dla praktycznie każdej decyzji projektowej (w tym schematu nazewnictwa).

— Mike Adler,