Hlavní navigace

Odpověď na názor

Odpovídáte na názor ke článku Rubinius 1.0 již klepe na dveře.

  • 27. 12. 2007 18:43

    Miloslav Ponkrác (neregistrovaný)

    [15] Ano, tady s Vámi musím naprosto souhlasit, napsal jste to lépe, než já.

    Velmi záleží na projektu, který děláte a na rozvaze kolem toho. Nutno si ale přidat, několik věcí:

    1) Spuštění unit testů není, nebyla a nikdy nebude záruka bezchybnosti programu. Pečlivě odladěný kód nevyrobíte pouhým spuštěním unit testů. Z hlediska teorie i praxe je dokonce nemožné udělat unit testy, které projedou všechny možné stavy sytému. Tudíž takto nezískáte odladěný projekt. Unit testy jsou velmi užitečná věc, o tom žádná.

    2) Velmi důležité kritérium pro náklady projektu je udržovatelnost - skoro jsem ochoten tvrdit, že začátečníka od profesionála poznáte podle toho jak moc klade váhu a důležitost na udržovatelnost programu. Zkušený harcovník už ví, že ušetřená hodina práce na vývoji se mu může bohatě vymstít stovkami hodin práce navíc na údržbě. Začínající programátor toto velmi podceňuje a nevysvětlíte mu to.

    Pak je to také o tom, jak moc hrozí, že program budete udržovat. Pokud píšete jednorázový, nabo krátkodobě používaný program, tak náklady na údržbu lze zanedbat.

    Velmi důležité pro tento moment jsou kromě kvalit jazyka a jeho neměnnosti také existující knihovny, které určiují někdy ekonomickou stránku projektu více, než jazyk.

    Hodně často vidím ve firmách scénář: Nějaký programátor naprogramuje program v rekordním čase - všichni ho plácají po zádech, je to borec, šéf se na něho usmívá. Pak se program používá, či prodá a zákonitě nastane potřeba prvních úprav - a najednou borec ne a ne úpravu dokončit, či pokud je nemorální, snaží se to shodit na někoho jiného pod libovolnou záminkou, aby ten průser odnesl někdo jiný. Pokud je programátorský tým zkušený, tak to padne na původního autora, pokud ne, najde se někdo, kdo se to snaží opravit a velmi často skončí pro "neschopnost" dodat opravu v termínu. Prostě co se ušetřilo v rychlosti vývoje původního programu, to je 1000x více prodraží v údržbě a program nejde rozumně dlouhodobě udržovat. A samostatnou kapitolou jsou multithreadové programy takových borců sdílejících mezi thready stovky i tisíce globálních proměnných a objektů bez jakékoli synchronizace.

    Závěr: Vše je třeba posuzovat v kontextu daného problému - co chcete dělat a co s tím v budoucnu chcete dělat atd.. Neexistuje žádný nejlepší programovací jazyk, proto jsem tu ani žádný neuváděl. Jen jsem uvedl kontext "serióznosti". Rozhodně dlouhodobý projekt bych nedělal v jazycích bez seriózních záruk jak jsem psal výše. Vždy najdete srovnatelný jazyk podobné úrovně, který je seriózní a dává nějaké záruky do budoucna, pokud budete opravdu objektivně hledat.