[Foto] minden proci minden nyelven

[dMT alias Medve]

> Kicsit általánosítanék: adott technológiát mindenhová!
> Ahol a techno mindegy is, hogy micsoda, lehet Java, .NET, bármi.
> Az a lényeg, hogy univerzál platform, tehát elvben mindenre jó, a
> gyakorlatban meg épp emiatt semmire sincs igazán kihegyezve.
A kétféle szemlélet a kompromisszumokra:
* Az optimista ember azt mondja, hogy jó mindenre, igaz mindenütt kell
  egy kis engedmény.
* Passzimista szerint meg sehol sem jó, mindenütt van jobb.
Az én véleményem szerint a mai piaci helyzetben minden területen a
legjobbat kell nyújtani. Senki nem fogja megvenni tőlem a drágább,
hamarabb lemerülő fényképezőgépet csak azért, mert nekem könnyebb volt
kifejlesztenem, mert ugyanazt a Linuxos-javás csapatot használhattam.

> + (előny): fejlesztési hatékonyság (jó csillivilli fejlesztőeszközök,
Háááát. Amíg csak valami apróságot kell csinálni, addig jó a java. De
"komoly" fejlesztésekre már nem biztos, hogy elég jó. De van rá házon
belül is jó példa is, meg rossz példa is.

>  mindenre van kész megoldás, jól dokumentált best preaktice-ok, hibák/csapdák
> dokumentáltsága),
No, ezt nem nagyon tapasztaltam. (Nem én vagyok a jábás osztály
vezetője én csak felhasználójuk vagyok, de az én székemből ez
nem látszik erősebben, mint pl. ha C lenne.)

> hatalmas rugalmasság, univerzális, projektek között könnyen
> átmozgatható fejlesztők
Ez valószínűleg nagyobb cégnél jönne ki jobban. Nálunk azért a
fejlesztési ismeretnek csak kisebbik része a fejlesztési technológia
ismerete. A feladat, a környezet sokkal inkább meghatározó. Az, hogy
most C++-ban írok vagy javában szinte mindegy. De az, hogy mi fán
terem az ELCOM protokollt és hogyan kell a közvilágítást vezérelni
fontosabb.

>> b) Elég oda a Linux! Aztán, ha egyszer megy a Linux, akkor már mehet a
>>    gány, mehet mindenféle program, mindenféle szkript.
> Itt ugye megint nem a konkrét rendszer neve a lényeg, hanem az, hogy
> egy stabilnak gondolt alaprendszerre építesz magas szintű (VHLL, 4GL)
> programot.
A 4GL-ben nem hiszek, legalábbis a mi alkalmazási területünkön nem sok
értelmét látom.

> +: nagyon gyorsan készíthető modell/prototípus,
Ettől szenvedünk pár jávás területen! Hihetetlen gyorsan (pár
hónap alatt !!) elkészült egy prototípus. Azóta eltelt két és fél év,
három ember dolgozik rajta, de még mindig dőlnek ki a csontvázak a
szekrényből, még mindig stabilitási, performancia problémák vannak,
még mindig szégyelni való hibák jönnek vissza a felhasználóktól.
Szerintem a modell/prototípus nagyon veszélyes fegyver. Mert kivállóan
alkalmas arra, hogy egy ad hoc, nem megfelelő architektúra,
technológia megváltoztathatatlanul bebetonozódjon.

> +: teljes kontrollban vagy (nincs ismeretlen mellékhatású "fekete doboz"),
> a hardver minden aspektusa kihasználható, maximális futási hatékonyság,
> teljes validálhatóság (már megfelelő módszertan esetén)
> -: sokkal több, magasabb szakértelmet igénylő fejlesztési feladat, sokkal
> több tesztelendő szint, sokkal több hiba az életciklus elején, kód
> hordozhatósági problémák, fejlesztő átirányíthatatlan, a fejlesztés
> idő- és emberigénye becsülhetetlen
Ezzel muszáj vitába szállnom! Legalábbis az én terültemen.

> sokkal több, magasabb szakértelmet igénylő fejlesztési feladat,
Nem.
Merthogy kellő mennyiségű szakértelem nélkül akármilyen technológiával
szenved a fejlesztő. Ha viszont átlátja, megérti a feladatot, akkor
szinte mindegy, hogy mi az eszköz, mert bármivel közel azonos
hatékonysággal dolgozik. Sőt. Ha egy kontroller egyszerű gép kódjával
dolgozik, akkor kell ismernie 45 utasítást. Ha C-ben, akkor 200
beépített függvényt. Ha C++, akkor ezer oldalas referencia kézikönyv
mélyén elrejtett apró utalásokat kell figyelnie. Egy javás fejlesztő
az eszközre koncentrál. Egy ASM fejlesztő meg a feladatra.

> Erre azt szokás mondani, hogy jó neked, ha meg is engedheted magadnak. :)
Sajnos nem mindig. Ezért aztán igyekszem azokat a területeket
"megszerezni", ahol nemcsak szubjektíve, hanem objektíve is a c)
változat az optimális.

> A nagy francokat, az agilis módszertanok pont a kész panelek gyors
> összedobálásáról, majd a kész kupac programmá faragásáról szólnak,
> semmi sem áll távolabb tőlük, mint a Te c) változatod...
Hát én egy picit másképp látom, bár még az agilis módszertanok
bevezetése előtt vagyunk. Kérdezz rá két év múlva, hogy mi a
véleményem!

> (Nálad a b) a tipikus agilis hozzáállás, majd fokozatosan elvinni
> a projectet az a) irányába.)
Igaz, ami igaz, az agilis metodikák igénye először a b) területről
jött és én az a)-nél tk. az eddigi gyakorlat kanonizálásának tartanám.
De azért szerintem a c)-hez is jól fog passzolni.


--
dMT alias Medve