S tímto v zásadě souhlasím, ale proběhla tudy ještě jedna velice dobrá
připomínka, "nikdy nevíte kdy a kdo vás koupí". Já bych ji ještě doplnil
o "nikdy nevíte kdo a kdy u vás bude pracovat". Já osobně jsem dlouho
zápasil i s reporty od slovenských kolegů a nakonec jsme zavedli povinně
angličtinu jako jediný jazyk kódu, dokumentace, reportů, bug managementu
a musím říct, že se to výrazně vyplatilo. Cena firmy, která je v zásadě
připravena na prodej do zahraničí výrazně stoupá. Samozřejmě toto se
může lišit projekt od projektu a skutečně to nelze brát paušálně,
nicméně z mého pohledu by mě musel někdo dlouho přesvědčovat mnoha
argumenty, že máme psát getPolozkaFaktury, nebo nedej bože
getPoložkaFaktury....
Samozřejmě nás také tahá za uši detabata o fíčurách a klááásáách atd,
ale to je z mého pohledu daň za výše popsané výhody...
S pozdravem
Lukáš Záruba (Lukas Zaruba)
Chief Technical Officer
MEDIA SOLUTIONS SLOVAKIA A.S.
Lisabonská 4 (Budova Technologického Centra)
Praha 9 190 00
Czech Republic
On 21.7.2010 11:22, Tomáš Záluský wrote:
Možná nejsem dostatečně in, ale můj názor je, že smíšené názvy jako
getPolozkyFaktury mají v některých případech opodstatnění a není správné je
zavrhovat paušálně.
Někdy je doména zákazníka tak rozsáhlá a pojmy jsou tak zakořeněné, že překlad
z češtiny do angličtiny není přesný a celkově to pak působí křečovitě.
Obecně: pokud je kdekoli, problémovou doménou zákazníka počínaje a zdrojáky
výsledné aplikace konče, ustálena zvyklost používat české pojmy, pak by
zodpovědný programátor (analytik, technický garant...) měl zvážit, na kterém
místě bude optimální provést přechod na angličtinu. Z pohledu rizik jako
nepochopení pojmů, nutnosti překládat si pojmy interně při jednání s doménovým
expertem, reálné pravděpodobnosti, že projekt bude koupen/opensourcován atd. A
pokud mu vyjde, že je nejlépe zachovat češtinu až do zdrojáku, vůbec bych se na
něj nezlobil.
Řešili jsme to např. u projektu, jehož db měla tabulky a sloupce léta v
češtině. Naše aplikace navíc nebyla jediná, která nad db pracovala, takže
změnit db nepřicházelo v úvahu. I když mě dvojjazyčné identifikátory taky
tahají za uši (oči ? :-), nakonec jsme dospěli k tomu, že je to cesta
nejmenšího zla. Ukázalo se dokonce, že oddělení jazyků naopak napomáhá
čitelnosti - šlo o projekt pro telekomunikačního operátora, kde každému je léta
jasné, co je Sluzba (telekomunikační služba) nebo Pripojeni (telefonního
kabelu), zatímco jak by dopadl překlad na Service resp. Connection, když je
projekt implementován pomocí Springu a JDBC, si asi dokáže každý domyslet...
Takže kompromis zněl: český pojem = doménový pojem zákazníka, anglický pojem =
něco, co se týká implementace (s náhradou get/set za dej/sej taky nesouhlasím
:-)).
Neříkám, že výše uvedený postup je nejlepší pro každého, ale musí se k tomu
přistupovat s rozumem a ne pod vlivem módních trendů.
Tomáš Záluský
================================================
...with Ultimate flying is so easy...
http://www.frisbee.cz http://www.peaceegg.net
================================================
______________________________________________________________
Od: "Ondrej Nekola"<on...@nekola.cz>
Komu: Java<konference@java.cz>
Datum: 20.07.2010 13:40
Předmět: Re: diakritika
2010/7/20 Tomas Hubalek<tomas.huba...@onsemi.com>
On mezi nami takove treba getPolozkyFaktury() nebo getPacient() mi docela
solidne tha usi ;-) Osobne pisu zasadne vzdycky vsechno anglicky a o i kdyz
pisu neco pro sebe.
Tom
Pamatujte take, ze nikdy nevite, kdo vas koupi/kdy to budete chtit
opensourcovat...
Anglictina je sazka na jistotu.
--
S pozdravem
Ondřej Nekola
