[ Stijak @ 20.10.2011. 03:19 ] @
Sada sam imao diskusiju sa kolegom na ovu temu? Iako sam apsolutni početnik u programiranju - ali mi je totalno logično da koristim engleski za sve u vezi programiranja (osim eventualno output-a na ekranu ako mi je bitno da je na srpskom)... Uostalom - učim iz knjiga na engleskom, čitam APIje na engleskom, sintaksa je na engleskom, neke stučne pojmove više i ne znam kako se kažu na srpskom, mješanje oba jezika bi samo stvaralo konfuziju u mojoj glavi...

Tu je i šerovanje/saradnja sa programerima u inostranstvu - iako su svi moji dosadašnji programčići uglavnom vježbice za kućnu upotrebu - kontam da mi je lakše da iz početka radite kako treba i kako je logično...

Kolega se baš i nije apsolutno složio sa mnom... Mada je rekao da u nekim stvarima imam pravo jer kad je on šerovao kod strancu - morao je da prevodi komentare...

Kako vi radite? Kako se radi u domaćim softverskim firmama (ako pretpostavimo da nisu neke koje isključivo za strance rade)?

[Ovu poruku je menjao Stijak dana 20.10.2011. u 04:46 GMT+1]
[ ArsicS @ 20.10.2011. 07:33 ] @
UVEK na engleskom, nema diskusije
[ Predrag Supurovic @ 20.10.2011. 08:08 ] @
U reusable kodu korsitim engleski ali sam nasao da je prakticno da u samoj aplikaciji koristim srpski (ako je aplikacija na srpskom) jer tako dodatno lako razlikujem sta je lokalno u aplikaciji a sta je iz biblioteka.
[ Mihajlo Cvetanović @ 20.10.2011. 09:10 ] @
Meni je kod na engleskom, a komentari na srpskom. Engleski mi je bolji za imenovanje promenljivih, klasa i funkcija. Ima više raznovrsnih kratkih reči, nema padeža, ne trebaju mi domaća slova, a i nekako je sistematičniji. Od značaja je i što je sve drugo u kodu na engleskom, pa ne moram stalno da switchujem sopstveni mindset dok programiram. Komentari su na srpskom jer tada mogu bolje da se izrazim, i lakše mi je da shvatim na šta sam mislio dok sam pisao kod.
[ mmix @ 20.10.2011. 09:12 ] @
Engleski, uzduz i popreko. Ako nista, mogu da koristim ansi encoding ;)
[ Nedeljko @ 20.10.2011. 09:21 ] @
Na Engleskom, a ako je potrebno, naknadno se Qt aplikacija preko Qt Linguist-a prevede na Srpski. Dakle, QObject::translate("press the button");, a onda se aplikacija može prevoditi na proizvoljan broj jezika.
[ mmix @ 20.10.2011. 09:26 ] @
Mislim da ne pricamo o lokalizaciji vec o praksi upotrebe jezika za imenovanje identifikatora i pisanje komentara.
[ Shadowed @ 20.10.2011. 09:59 ] @
Engleski, dok se ne trazi drugacije :)
[ X Files @ 20.10.2011. 10:05 ] @
Lepše i sočnije se opsuje ako je komentar na srpskom.

Šalu na stranu, pregledah svoju arhivu i vidim kako sam se menjao i opet vraćao na staro, bez neke definitivne odluke u jednom smeru. Opet, to je zavisilo i od toga da li je projekat 100% moj, da li sam ga nasledio ili samo učestvujem u razvoju. Obično pratim ustanovljeni stil.



Za mene je ipak važnije kako imenujem identifikatore (klase, objekte, promenljive). Nekako sam tu shvatio da ne sme biti popuštanja...


[ Nedeljko @ 20.10.2011. 10:57 ] @
Citat:
mmix: Mislim da ne pricamo o lokalizaciji vec o praksi upotrebe jezika za imenovanje identifikatora i pisanje komentara.


A ja sam mislio da sam shvaćen da identifikatore, makroe i komentare pišem na engleskom, kao i stringovske literale.
[ Nedeljko @ 20.10.2011. 12:27 ] @
Jedan od razloga zašto pišem identifikatore na Engleskom je što ne umem da pišem latinicom na Srpskom. Morao bih da ukucam ćirilicom to ne ovom sajtu, pa da vidim kako je to preveo na latinicu.
[ Sini82 @ 20.10.2011. 18:11 ] @
Komentare piši jezikom na kojem razmišljaš, dakle na srpskom. Kome treba neka si prevodi. Što se tiče imena promjenjivih, nije uopšte bitno kojim jezikom ih pišeš. U komentarima ćeš, ako je potrebno, napisati dodatno objašnjenje u vezi promjenjivih.
[ Stijak @ 20.10.2011. 18:47 ] @
He he - nije mi problem da razmišljam na engleskom... Uostalom - tek bi nered nastao kada bi pokušao sve te stvari koje učim na engleskom i koje kucam na engleskom da u komentaru prevodim na srpski...

Npr. "koristim javni metod (public) iz biblioteke SomeEnglishWord i dobijam double koji ovdje castujem kao integer brojGolova- potom iteriram kroz sve vrijednosti Enuma igrači"... Ne znam za vas - meni to mnogo glupo... Mada - neka svako radi šta njemu odgovara - ko ne zna dobro engleski - neka svakako komentira na srpskom...

I taj isti kolega koji komentariše na srpskom se žalio da je on tako jednom prilikom morao da radi sa nekom klasom komentarisanom na španskom...

A inače mnogo sam upućeniji u svijet nauke - i tamo je izbor jezika već davno odlučen - pogledajte sajt instituta za fiziku - http://www.phy.bg.ac.rs/ - i radovi koji izdaju domaći naučnici su na engleskom - i posdtiplomske mogu bez većih problema biti na engleskom - pa tako i naši studenti odlaze da studiraju širom evrope i svijeta bez učenja dodatnih jezika - većina dobre literature je na engleskom... Da nije toga - ne bi uopšte bila moguća ovakva saradnja naučnika koja danas postoji...
[ biske86 @ 21.10.2011. 00:43 ] @
Nemam nikakav problem da promenljivu napišem na srpskom.
U programima koje vežbam dok učim Javu komentare pišem čak i ćirilicom, i tu nema nikakvih problema. Potrebno je samo u Eklipsi postaviti da je enkoding utf8 i vozi..
Naravno nemam problem ni da se izražavam na engleskom, sve zavisi od situacije. Na primer kad imam neki problem i hoću da pitam nekog ko govori engleski naravno da ću promenljive i komentare napisati na engleskom, da bi olakšao tom čoveku posao i naravno da bi dobio odgovarajuće rešenje za problem.
[ vlaiv @ 21.10.2011. 08:47 ] @
English +1

I toplo preporucujem svima koji se bave programiranjem da u struci to smatraju primarnim i jedinim jezikom (localization excluded).
Znaci posvetite malo vremena da sto bolje naucite engleski (help, literatura, net ...)
[ mmix @ 21.10.2011. 09:13 ] @
A meni je zanimljiva jedna stvar..

Zasto vi mislite da vas kôd nece gledati niko sem ljudi iz Srbije? Cak i da je full-on domestic firma ne znaci da dve, tri godine kasnije nece biti otkupljena od nekih stranaca.
[ Mihajlo Cvetanović @ 21.10.2011. 09:22 ] @
Da, ali zašto se cimati oko nečega što se možda i neće desiti? Ako se u budućnosti desi da ono što sada pišem mora da čita neki stranac, i ako stranac zahteva da to što čita bude na njemu razumljivom jeziku, i ako meni zapadne zaduženje da mu omogućim čitanje na njemu razumljivom jeziku, tek onda bih se bavio komentarima na engleskom.
[ mmix @ 21.10.2011. 09:28 ] @
Da, ali tad ces imati source base od ko zna koliko stotina hiljada linija koda. Bas ces tad da prevodis tokom pregovora o kupovini.
[ Milos911 @ 21.10.2011. 09:42 ] @
Ja sam skoro editovao nesto na norveskom(valjda je bio norveski :)). Isto tako covek mislio da je svejedno na kom jeziku pise, lako ce posle prepraviti, i na kraju naravno nije mogao da prepravi... A meni je bilo jedno 10 puta teze editovati taj kod, cak i uz njegovu pomoc.
Tako da sto se mene tice engleski je za sve. Ne vidim razlog zasto koristiti srpski, osim ako nemate problema sa engleskim. Opet je "I milos. I use english" bolje od srpskog.
Vec je bio topic, ali se uklapa i ovde. Osim jezika, kako pisete imena varijabli, funkcija... Ja koristim something_like_this(), $or_this;.
[ X Files @ 21.10.2011. 10:12 ] @
^
Prilagodjavam se stilu koji je ustanovljen, kako na nivou celog projekta, tako i na nivou bloka.


Ako je VCL projekat, sve što se tiče dizajna mora da izgleda kao da sam deo njihovog tima:
- ako su rekli da se klasa piše početnim T - onda T. (izuzetak je neki moj akronim, iza T a ispred naziva, koji služi da "razlikuje" moj rad)
- ako su rekli da se naslov zove Caption - onda Caption, a ne Text ili Naslov.
- ako su rekli da se naziv osobine piše velikm slovom, onda veliko slovo
- ako u argumentima funkcija koje tretiraju neki interval pišu uvek AFrom i ATo - onda i ja.
- ako u celom Frameworku koriste Tmp za privremeni objekat, onda Tmp a ne Temp.
- i sl.


E sad, implementacija:
Skoro je nemoguće ceo projekat uraditi u jednom Frameworku, bez potezanja recimo za Win32API-jem ili C podsistemima (DLL) ili STL-om. Tada nastavljam kako je i započeto, tj kao da je deo toga.



Sve ovo znači da *ima* mešanja stilova, ali je to i dalje vrlo čitljivo i razumljivo.
[ Sini82 @ 21.10.2011. 17:24 ] @
Citat:
biske86:
U programima koje vežbam dok učim Javu komentare pišem čak i ćirilicom, i tu nema nikakvih problema. Potrebno je samo u Eklipsi postaviti da je enkoding utf8 i vozi..


Ovo ti je genijalno. Biće mi uživanje da prvom prilikom primjenim.
[ Stijak @ 21.10.2011. 17:35 ] @
U javi nema problema ni da identifikatore (promjenljive, klase, metode) pišete ćirilicom! Ja sam čak probao dok sam učio i kada sam čitao da podržava puni unicode i naravno odlično funkcioniše... Samo mi je totalno suludo...
[ biske86 @ 21.10.2011. 17:41 ] @
Citat:
Sini82: Ovo ti je genijalno. Biće mi uživanje da prvom prilikom primjenim.

Malo me zezaš?

Citat:
Stijak: U javi nema problema ni da identifikatore (promjenljive, klase, metode) pišete ćirilicom! Ja sam čak probao dok sam učio i kada sam čitao da podržava puni unicode i naravno odlično funkcioniše... Samo mi je totalno suludo...

Nisam znao da je i to moguće , baš ću da probam. Mada nešto mislim da nema smisla.
[ loonies @ 21.10.2011. 22:36 ] @
Isklucivo sve na engleskom:
- promenljive
- komentari
- commit poruke

bas sve...
[ Sini82 @ 22.10.2011. 19:10 ] @
Ne zezam te.

[Ovu poruku je menjao Sini82 dana 22.10.2011. u 20:26 GMT+1]
[ Dragi Tata @ 24.10.2011. 02:03 ] @
A zar nema nikoga ko koristi besmislene nazive promenljivih i ne piše komentare? To potpuno rešava problem.
[ milanche @ 24.10.2011. 03:23 ] @
Da li se samo meni ucinilo na mah da je ovuda prosao duh Dragog Tate ?
[ mmix @ 24.10.2011. 09:04 ] @
i meni se ucini, morao sam da mu otvorim profil da budem siguran da se neko lazno ne predstavlja
[ Nedeljko @ 24.10.2011. 09:48 ] @
Citat:
Dragi Tata: A zar nema nikoga ko koristi besmislene nazive promenljivih i ne piše komentare? To potpuno rešava problem.


A koji problem? Izbora jezika? Ja pišem programa u C++-u, komantare u C#-u, identifikatore i makroe u C-u, a komit poruke u FORTRAN-u.
[ Dragi Tata @ 26.10.2011. 03:38 ] @
Citat:
mmix: i meni se ucini, morao sam da mu otvorim profil da budem siguran da se neko lazno ne predstavlja ;)


Eto, ostavio sam ti forum (.NET) u amanet, a sad se lažno predstavljam :)
[ milanche @ 26.10.2011. 04:03 ] @
Citat:
Dragi Tata: Eto, ostavio sam ti forum (.NET) u amanet, a sad se lažno predstavljam :)


...sto se jos moze optimizovati u "Ostavio sam ti u ama.NET"
[ aaaca @ 26.10.2011. 18:49 ] @
Koristim isključivo srpski na ćirilici - za sve ono što ne može da izazove problem. Da li će to razumeti neki Japanac baš me i ne zabrinjava, a uostalom šta ima da ga zanima moj izvorni kod.

Imena promenljivih pišem na srpskom, ali abecedom, jer mi je mnogo lakše da se snađem. Na primer, mnogo mi je zgodno kada neki upit nazovem imenom nadji_korisnika za razliku od nadji_korisnike. Ili šta fali promenljivoj id_broj_korisnika?

Naravno, za programski jezik koristim ono što se mora: engleski na abecedi.
[ bondja @ 21.04.2012. 23:45 ] @
Sledim pravilo : koristim onaj jezik koji me nece ometati / prekidati u razmisljanju / resavanju problema.

Engleski nam nije maternji jezik, tako da tu postoji mala zadrska pre nego sto se prebacite na njega, bez obzira koliko
ste toga svesni ili ne, i bez obzira koliko dobro vladate tim jezikom.

Engleski je bolji za nazive promenljivih, klasa itd, kao sto neko rece, nema padeza, lakse je difinisati s malim skupom reci dosta toga,
ali kada dodjem do toga da prevodim - prebacujem na engleski, vec sam prilicno svario problem, razumeo namenu te klase, promenljive, sta god.
U tom trenutku nema potrebe ni za komentarom , jer dobar (elegantan) kod ne trazi dodatna objasnjenja, kod sam sebe opisuje.
[ Milos911 @ 22.04.2012. 01:53 ] @
Citat:
bondja:Engleski nam nije maternji jezik, tako da tu postoji mala zadrska pre nego sto se prebacite na njega, bez obzira koliko
ste toga svesni ili ne, i bez obzira koliko dobro vladate tim jezikom.

Ovo nije tacno. Engleski mi nije maternji, ali u it svetu jeste (bar meni). Smrt mi je kad moram nesto da komentarisem na srpskom, a engleski mi dodje prirodno. Srpski je samo za debug, kad se duze mucim pa mi sladje da mu pomenem familiju na srpskom...

Inace se slazem sa poslednjom recenicom, "jer dobar (elegantan) kod ne trazi dodatna objasnjenja, kod sam sebe opisuje.". Jeste da ponekad imam imena tipa: get_direct_chat_options_for_user_projects($uid) (ovo je rekord do sada), ali bar znam gde je sta. Ako ubacim i komentare, sarenis u kodu me ubije totalno i nema sanse da se snadjem.

Ovo je matoro, al moram da kazem:
Citat:
aaaca: Koristim isključivo srpski na ćirilici - za sve ono što ne može da izazove problem. Da li će to razumeti neki Japanac baš me i ne zabrinjava, a uostalom šta ima da ga zanima moj izvorni kod.
Prvi deo je cisto biip. Em izgubis brdo vremena na prebacivanje sa jednog na drugi jezik (alt+shift jeste dugo vremena, jer kasnije isto razmisljas o tome da je raspored slova promenjen, a i bez toga...), em ti kasnije sigurno nije bas svejedno kad citas pola cirilicu pola latinicu.
Drugi deo, bice ti zao kad jednog dana shvatis da ipak ima nekad nekoga da zanima tvoj kod, pa ce da ti bude zesce tesko da se odviknes od te lose navike...

"Na primer, mnogo mi je zgodno kada neki upit nazovem imenom nadji_korisnika za razliku od nadji_korisnike. Ili šta fali promenljivoj id_broj_korisnika?"
find_user, find users? id_broj_korisnika. A za ime koristis ime_ime_korisnika? A sta fali uid (skraceno od user_id)?
[ Nedeljko @ 22.04.2012. 09:43 ] @
Citanje pola cirilice, a pola latinice je prednost kada treba razlikovati kod od komentara. Druga je stvar ako ti je cirilica odbojna. Ja pisem sve na Engleskom iz sasvim drugog razloga, koji si vec pomenuo.
[ aaaca @ 26.05.2012. 20:35 ] @
Malo kasnim sa komentarom ali takav je život. Meni uopšte nije problem da istovremeno čitam abecedu, latinicu i ćirilicu. Pod latinicom podrazumevam abecedu sa dodatim našim slovima.

Ako je nekome problem istovremeno razlikovanje različitih pisama, onda ne vredi ni razgovarati na ovu temu. U toj situaciji pametno je koristiti ono što ne ometa u radu.

Programi koje sam pravio i trenutno pravim su toliko specifični, da nema ni teoretske šanse da ga koristi iko drugi osim onih kojima je namenjen.

Osim toga, pismo kojim se pišu imena promenljivih i komentara je sporedno u odnosu na jezik i pismo teksta koji se pojavljuje u programu. Ako neki Englez ne razume jezik koji se pojavljuje u formama programa, ništa mu neće značiti komentari na engleskom - osim ako komentari nisu toliko detaljni da apsolutno sve objašnjavaju.

Još bih napomenuo da bi bilo dobro da se trudimo da u našim malim životima i još manjim programima očuvamo maternji jezik.

Nisam za varijantu Windows-a na srpskom jeziku. Engleski treba koristiti gde kod je potrebna unifikacija i ništa nećemo dobiti time što je Bil napravio Windows na srpskom. Samo nastaje problem sa prevođenjem termina. Bez engleskog se ne može baratati računarima koliko god softver bio na srpskom. Nismo mi Rusi pa da apsolutno sve možemo da imamo na svom jeziku.

Srpski jezik se čuva izbegavanjem svakodnevnih termina kao što su lajkovanje i slično. To se postiže samo tako što će svako u svome životu paziti šta radi.
[ Nedeljko @ 26.05.2012. 21:45 ] @
Citat:
aaaca: Programi koje sam pravio i trenutno pravim su toliko specifični, da nema ni teoretske šanse da ga koristi iko drugi osim onih kojima je namenjen.


Kakvi su to prgrami, ako nije tajna? Ubeđen sam da grešiš.
[ Stijak @ 26.05.2012. 21:57 ] @
Vidiš - meni je mnogo čudno da neguješ srpski jezik u kodu, a ne neguješ u npr lokalizaciji windowsa (već postoji windows na srpskom - jer mi se iz tvog teksta čini da nisi svestan).

Inače - volim frameworke u kojima je lokalizacija znatno olakšana - najčešće u obliku nekog spoljnog file-a... I npr. u Androidu kojim se najviše bavim je to spoljni file koji posebno praviš za koje god jezike hoćeš...

I osnovni razlog i nije to da bi drugi razumjeli moj kod - to je recimo vrlo bitan ali drugi razlog po važnosti - već što za sve što je u vezi koda već sam navikao da razišljam na engleskom i poznajem engleske termine jer učim iz literature na engleskom... Naveo sam već nekoliko primjera u prethodnim postovima. Kada bi se trudio da mi imena promjenljivih i komentari budu na srpskom - trebalo bi mi mnogo truda da shvatim kako se prevode štojekakvi termini... A i nekako mi ne zvuči konzistentno da npr. ispred for petlje stavljam komentar ova za petlja, ili da brkam jezike pa pišem for petlja sa inicijacijom...
[ plus_minus @ 26.05.2012. 22:55 ] @
Komentare i nazive promenjivih, nazive klasa, dakle, sve.. on ingliš.
Ingliš jer je bilo koji programski jezik sa predefinisanim bilo čim - alfabet. Engleska reč ili sleng.
Alfanumerički set karaktera je, ako se ne varam.. default. abcdefgxzy.. 01234..

Zašto bih ja onda komplikovao?

Što se komentara tiče, to zavisi da li je klijent naš ili nije naš. :)
Ak' je naški, komentari idu u sr-latin, dok sve ostalo ostaje na engleskom.

Što kaže milos911, lakše bre.. nekako prirodnije.. skraćenice, slengovi, 'padežovi', ma sve..
Onda kad mi BIOS bude na srpskom, e onda ću i ja da krenem da čukam imena promenjivih na srpskom.
[ aaaca @ 29.05.2012. 17:30 ] @
Pa šta da kažem. Ja ne razmišljam na engleskom jeziku nego na sprskom, pa mi je valjda zato normalno da komentare pišem na srpskom jeziku. A uz srpski jezik ide ćirilica. Latinica očigledno nije za srpski jezik jer u njoj ne postoje jedinstvene oznake za slova lj, nj, dž. Elem, meni je najprirodnije da sve pišem ćirilicom na srpskom jeziku, ali nemam snage da ikoga prisilim na to. Dok nas je samo par miliona nema ništa od toga. Sasvim je normalno da onaj ko razmišlja na engleskom, sve radi na istom i tu nema pogovora.

Vrlo dobro znam da odavno postoji Windows na srpskom, samo ne razumem namenu istog. Sve mlađe generacije znaju engleski pa njima isti nije potreban. Starijim generacijama Windows na srpskom ništa neće pomoći u korišćenju, jer masa (da ne kažem sav) softvera je na engleskom. Čak i da je sve na srpskom, neće im vredeti jer ne razumeju terminologiju i ne mogu da se snađu onako kako bi trebalo. Ako je neko hteo da se bori za očuvanje srpskog jezika pogrešio je način. Najlakše je nekolicini volontera naturiti ideju i sada oni ispadoše odgovorni borci za očuvanje jezika. A to što se u svakodnevnom životu pa čak i u zvaničnim državnim emisijama zaboravlja na gramatiku, srpski i ćirilicu - e za to su nam krivi svi drugi.

Programi koje pravim su razne baze podataka sa kojekakvim formama, izveštajima, analizama... U suštini informacioni sistem koji je namenjen bolnici i to vojnoj. Terminologija specifična, zakon specifičan. Nigde ga nema osim ovde.
[ Nedeljko @ 29.05.2012. 19:42 ] @
Zamisli sada da ti neko sa strane naruči nešto slično tome što si pravio i da mnogo toga možeš da iskoristiš.
[ Stijak @ 29.05.2012. 20:08 ] @
Citat:
aaaca: Pa šta da kažem. Ja ne razmišljam na engleskom jeziku nego na sprskom, pa mi je valjda zato normalno da komentare pišem na srpskom jeziku. A uz srpski jezik ide ćirilica. Latinica očigledno nije za srpski jezik jer u njoj ne postoje jedinstvene oznake za slova lj, nj, dž. Elem, meni je najprirodnije da sve pišem ćirilicom na srpskom jeziku, ali nemam snage da ikoga prisilim na to. Dok nas je samo par miliona nema ništa od toga. Sasvim je normalno da onaj ko razmišlja na engleskom, sve radi na istom i tu nema pogovora.

Vrlo dobro znam da odavno postoji Windows na srpskom, samo ne razumem namenu istog. Sve mlađe generacije znaju engleski pa njima isti nije potreban. Starijim generacijama Windows na srpskom ništa neće pomoći u korišćenju, jer masa (da ne kažem sav) softvera je na engleskom. Čak i da je sve na srpskom, neće im vredeti jer ne razumeju terminologiju i ne mogu da se snađu onako kako bi trebalo. Ako je neko hteo da se bori za očuvanje srpskog jezika pogrešio je način. Najlakše je nekolicini volontera naturiti ideju i sada oni ispadoše odgovorni borci za očuvanje jezika. A to što se u svakodnevnom životu pa čak i u zvaničnim državnim emisijama zaboravlja na gramatiku, srpski i ćirilicu - e za to su nam krivi svi drugi.

Ok tvoje pravo - iako ne vidim kako ne povlačiš paralelu između windowsa na engleskom i programiranja. Ali dobro - sve dok radiš sam - to je OK. Ja samo ne bih volio da imam nekog takvog u svom timu...

Citat:
aaaca:Programi koje pravim su razne baze podataka sa kojekakvim formama, izveštajima, analizama... U suštini informacioni sistem koji je namenjen bolnici i to vojnoj. Terminologija specifična, zakon specifičan. Nigde ga nema osim ovde.

Hoćeš da kažeš da si sve procedure bolnice, zakonske propise hardkodovao u program??? Ne samo što si učinio teško primjenljivom na neke druge bolnice (to te možda ne interesuje) - već i program teško izmjenljivim u slučaju da se te procedure i zakonska rešenja promjene - a to može da se desi sutra. A tek ako bolnica postane civilna ili se privatizuje(jer su obe opcije izgledne za jedinu vojnu bolnicu koju ja znam)???

Poenta je da se pisanje komentara na engleskom u cilju saradnje sa stranim programerima i korištenja stranih biblioteka poprilično dobro slaže sa filozofijom departmanizacije, i modularnosti / promjenljivosti / prilagodljivosti programa...

Ne želim da me pogrešno shvatite - ne naturam ja engleski nikome. Čak se divim kako možete bilo šta programirati bez heavy korištenja APIja programskog jezika /framework-a koji su svi sa komentarima i imenima identifikatora na engleskom. Pa čak i kad bih pretpostavio da mogu programiranje učiti iz nekih knjiga na srpskom i razmišljati na srpskom - opet bi mi smetalo sve to mjenjanje jezika između mog koda i API elemenata...
[ aaaca @ 29.05.2012. 21:17 ] @
Citat:
Nedeljko: Zamisli sada da ti neko sa strane naruči nešto slično tome što si pravio i da mnogo toga možeš da iskoristiš.

Nešto slično?! Nema sličnoga. Razlika može da bude samo tolika da se mnogo više isplati praviti sve novo.

Citat:
Stijak: Hoćeš da kažeš da si sve procedure bolnice, zakonske propise hardkodovao u program??? Ne samo što si učinio teško primjenljivom na neke druge bolnice (to te možda ne interesuje) - već i program teško izmjenljivim u slučaju da se te procedure i zakonska rešenja promjene - a to može da se desi sutra. A tek ako bolnica postane civilna ili se privatizuje(jer su obe opcije izgledne za jedinu vojnu bolnicu koju ja znam)???

Poenta je da se pisanje komentara na engleskom u cilju saradnje sa stranim programerima i korištenja stranih biblioteka poprilično dobro slaže sa filozofijom departmanizacije, i modularnosti / promjenljivosti / prilagodljivosti programa...

Ne želim da me pogrešno shvatite - ne naturam ja engleski nikome. Čak se divim kako možete bilo šta programirati bez heavy korištenja APIja programskog jezika /framework-a koji su svi sa komentarima i imenima identifikatora na engleskom. Pa čak i kad bih pretpostavio da mogu programiranje učiti iz nekih knjiga na srpskom i razmišljati na srpskom - opet bi mi smetalo sve to mjenjanje jezika između mog koda i API elemenata...

Da bih napravio toliko elastičan i potpuno dinamičan program, univerzalan i prilagodljiv, morali bi da me plate mnogo, mnogo više od 500 evra mesečno. A to mi je plata ne samo za razvoj sistema, nego i za održavanje mreže, softvera na računarima i tako dalje. Ovo što sam do sada razvio ima oko 200.000 linija koda, a nisam ni zagrebao ceo sistem - pod celim sistemom podrazumevam totalno izbacivanje papira i ostalog.

Što se tiče saradnje sa drugima, slobodnih biblioteka itd. to je teško izvodljivo. Radim u ColdFusion jeziku koji je veoma malo (čitaj: nikako) zastupljen u Srbiji. Sve radim sam. To je velika manjkavost. Međutim, CF je toliko dobar da se muka isplati.

Možda bih pitanje jezika komentara drugačije shvatao kada ne bih svako slovo i znak ručno unosio u kodne strane. Ne koristim nikakve alate osim Notepada++. Valjda mi je zato normalno da programiram onako kako i razmišljam.
[ aaaca @ 29.05.2012. 21:29 ] @
Citat:
Stijak: Ok tvoje pravo - iako ne vidim kako ne povlačiš paralelu između windowsa na engleskom i programiranja. Ali dobro - sve dok radiš sam - to je OK. Ja samo ne bih volio da imam nekog takvog u svom timu...


Zaboravih na Windows. Nema paralele jer Windows komentarišem sa globalnog stanovišta. Kao što sam ranije objasnio, ne vidim svrhu postojanja Windows-a na srpskom. Za očuvanje maternjeg jezika moramo se boriti u svojim životima. To što postoji Windows na srpskom neće nas spasiti od zaborava, a nikome i ne koristi. Ako mi ne zaboravimo naš jezik i ne izbacimo ga iz svakodnevne pravilne upotrebe, nećemo propasti.

Dakle, radi se o dve stvari:
1. Windows - globalna upotreba, neko drugi ga koristi
2. programiranje - to je u svakom od naših ličnih života (mislim na one koje se time bave), lična stvar

Ko hoće da promeni svet, treba da počne od sebe.

I baš si lepo zaključio da ne bi voleo u svom timu nekog kao što sam ja. Kako si samo uspeo tako brzo da zaključiš?
[ Shadowed @ 30.05.2012. 00:23 ] @
Citat:
aaaca: programiranje - to je u svakom od naših ličnih života (mislim na one koje se time bave), lična stvar

To je tako samo dok sam radis na projektu i onog za koga radis ne zanima kod nego samo aplikacija. Ukoliko ih zanima kod ili radis u timu, to nije tako. A u vecini slucajeva je upravo taj nacin rada.

Moja je pretpostavka da je to odgovor i na ovo pitanje:
Citat:
aaaca: I baš si lepo zaključio da ne bi voleo u svom timu nekog kao što sam ja. Kako si samo uspeo tako brzo da zaključiš?


[ Stijak @ 30.05.2012. 00:56 ] @
Inače - da mene plaćaju 500 evra za sve to - vjerovatno bi to outsource-ovao tako što bi to dao nekom klincu da skarabudži u Accessu :) Tako da mislim da se ti i previše trudiš. Tako da se nemoj ljutiti zbog onoga u timu - shadowed ti je fino objasnio. Vidi se da imaš svoj sistem - i ako tebi radi i ti zadovoljan - super.

Ali - da ne bude zabune - za modularan kod uopšte ne postoji overhead. Tj. postoji striktno u pisanju koda neki overhead - ali to se i te kako nadohnadi daleko lakšim debugovanjem, pa na kraju ispadne brže... I aplikacija je nešto sporija - ali ja cijenim svoje vrijeme mnogo više od kompjuterskog (do sad nisam imao baš potrebe da pišem real-time aplikacije, kodeke i slične stvari koje ipak zahtjevaju daleko optimizovaniji kod)...

Nego - da ipak ne skrećemo dalje sa teme jezika. Ako nekog zanima ova tema - neka pokrene novu.
[ aaaca @ 30.05.2012. 20:19 ] @
Ono sa nabrajanjem pod 1. i 2. je bilo obrazloženje zašto ne povlačim ćirilično-srpskojezičnu paralelu između Windows-a i ličnog programiranja. Windows na srpskom je za korisnike, a komentari u programskom kodu su za programere. Da se više ne ponavljam.

Nijedan klinac ne bi mogao da u Access-u skarabudži 200.000 linija koda. Pogotovo to ne bi mogao da uradi tako da sve funkcioniše za 900 umreženih računara.

Komentar da neko sa nekim ne bi voleo da bude u timu, samo na osnovu nekoliko rečenica, je prilično brzoplet. To ni dr Haus ne bi uspeo.
[ Nedeljko @ 30.05.2012. 20:36 ] @
Da meni ponude 500 evra, samo bih se zahvalio na ponudi. To je poenta priče sa klincem.
[ aaaca @ 30.05.2012. 21:08 ] @
Citat:
Nedeljko: Da meni ponude 500 evra, samo bih se zahvalio na ponudi. To je poenta priče sa klincem.

To mi je mesečna plata za stalan posao. S obzirom na krizu u kojoj smo, moram da se držim onoga šta je sigurno. Imaš li kakav predlog?
[ Shadowed @ 30.05.2012. 21:20 ] @
Citat:
aaaca: Nijedan klinac ne bi mogao da u Access-u skarabudži 200.000 linija koda. Pogotovo to ne bi mogao da uradi tako da sve funkcioniše za 900 umreženih računara.

Mozda nije ni potrebno imati tih 200k linija.


Citat:
aaaca: To mi je mesečna plata za stalan posao. S obzirom na krizu u kojoj smo, moram da se držim onoga šta je sigurno. Imaš li kakav predlog?

Imam ja. Ako si dobar u programiranju, potrudi se malo oko timskog rada i fleksibilnosti u radu i skoro sigurno ces moci da nadjes posao koji je bolje placen.
[ aaaca @ 30.05.2012. 22:56 ] @
Citat:
Shadowed: Mozda nije ni potrebno imati tih 200k linija.


Verujem da bi u .Net-u i Asp-u to izašlo na celih 2.000.000 linija koda. Samo u .Net-u ne bi moglo da radi kako treba: on i web - he, he. U CFM jeziku kompaktnost je oko deset puta veća od Jave, a to znači da ono šta u Javi ide na 100 linija u CFM-u ide na 10.

Ako si imao kontakta sa ozbiljnim sistemima ne bi trebao da imaš takve dileme. Za računanje srednje statističke greške i kvadratnog korena sigurno treba mnogo manje koda. Eno za Vojnomedicinsku akademiju napraviše softver baš od 2 miliona linija i naplatiše ga tričavih milion evra.
[ Nedeljko @ 31.05.2012. 00:29 ] @
Citat:
aaaca: Samo u .Net-u ne bi moglo da radi kako treba: on i web - he, he.


.NET i web se ne mirišu? Otkad to?
[ Boris_ZR @ 31.05.2012. 18:29 ] @
Mislim da je krajnje neozbiljno porediti .net ili javu sa ColdFusion-om.
[ aaaca @ 31.05.2012. 22:23 ] @
Citat:
Nedeljko: .NET i web se ne mirišu? Otkad to?

Imao sam prilike da vidim kako rade web aplikacije urađene u .Net-u. Mnogo sporo.Dok ne rade ništa, dobro je. Kada se malo više opterete podacima i analizama - katastrofa.

Citat:
Boris_ZR: Mislim da je krajnje neozbiljno porediti .net ili javu sa ColdFusion-om.

Izvinjavam se. Neću više.
[ Nedeljko @ 31.05.2012. 22:27 ] @
Biće da nije problem do .NET-a, nego do onih koji su radili.
[ plus_minus @ 01.06.2012. 09:21 ] @
Citat:
aaaca: Imao sam prilike da vidim kako rade web aplikacije urađene u .Net-u. Mnogo sporo.Dok ne rade ništa, dobro je. Kada se malo više opterete podacima i analizama - katastrofa.


Evo jedne male liste.
Šta koji sajt koristi od tehnologija.





Mogao bi ti da promeniš mišljenje, ali, što pre, to bolje po tebe.

Sasvim KONTRA. Kada se malo više opterete upitima, podacima i analizama, coldfusion, php, java.. sve to kreće da "gubi" poene..
Pričamo o jako velikom broju querija npr.

ASP.net je tu - tata.
[ Nedeljko @ 01.06.2012. 09:52 ] @
Za php razumem, ali otkud ti to za javu? Ovaj spisak to ne pokazuje.
[ plus_minus @ 01.06.2012. 09:56 ] @
Koju ulogu ima java kod amazona ili YouTube? Ja da budem iskren, ne znam.
A definitivno ima poentu i dobru ulogu čim je koriste.

Glavna poenta je da se .net i web "slažu" veoma dobro.
[ aaaca @ 01.06.2012. 13:43 ] @
Gornja tabela uopšte nije relevantna za izvedeni zaključak.

Razlog je jednostavan. Da bi koristili Cold Fusion morali bi da plate debele pare. Pri tome bi zavisili od Adobe-a. Mislite da bi navedene kompanije to sebi dozvolile? Nema šanse.
[ Ivan Dimkovic @ 01.06.2012. 13:51 ] @
Apsolutno je besmisleno koristiti Amazon, Facebook, Google i sl... kao nekakav primer za bilo sta.

To su firme koje mogu da priuste da stave 10 hiljada developera da rade na infrastrukturi. Sa takvom radnom snagom mogu komotno da naprave i svoj OS optimizovan za njihove potrebe ako im se hoce. Softver koji trci njihove servise je debelo optimizovan i kastomizovan za njihove potrebe i u to su ulozeni milioni radnih sati.

99.999% firmi na ovom svetu nema takav luksuz, i moraju koristiti tudje framework-e i okruzenja, cesto gomilu gotovih stvari bibloteka i sl... - iz prostog razloga sto im je potpuno neisplativo da prave svoju bespoke infrastrukturu (vecina firmi i nema budzete za tako nesto).

Sto nas vraca na pitanje jezika - svi moderni jezici se na kraju prevode u optimizovani kod, razlike tu su kozmeticke osim ako ne pricamo o kriticnom kodu koji je neko pisao koristeci low-level pristup hardveru (tipa rucno pisan SIMD ili CUDA/OpenCL kod) - a i u ovom slucaju je taj kod brzi koju desetinu % do nekoliko puta max ako je algoritam takav da se jako dobro optimizuje, a njegov razvoj je vise puta skuplji.

Daleko vise uticaja na performanse ima sam pisani kod - od optimizacije algoritama pa do adaptiranja algoritama na konkretan programski jezik / implementaciju posto sa visokim jezicima koji imaju virtuelnu masinu moze da se desi da JIT kompajler ima specificnosti i da voli / ne voli neke konstrukte.

[ maksvel @ 01.06.2012. 13:52 ] @
Ne vidim iz ove tabele ni da je PHP inferioran. Dovoljan je FB "samo".

//edit
(Kad li samo Dimković stigne da svuda odgovara? Garant mu je onaj "Nervozni sistem-demo" preuzeo nalog)
[ Ivan Dimkovic @ 01.06.2012. 13:58 ] @
:)

Pa PHP nije inferioran ako ti nije problem da skaliras svoj datacentar... Verovatno bi rucno raspisan C++ kod koji koristi debele optimizacije bio brzi ali sigurno ne vise od par puta... Sto bi se cimao i imao veci hardverski tie-in, kada mozes bez problema da roknes jos servera i svom datacentru i kompenzujes razlike :-)
[ Nedeljko @ 01.06.2012. 14:09 ] @
Koliko znam, FB kompajlira php u mašinski kod, pa onda to izvršava. Eto, FB može sebi da priušti taj luksuz da napravi tako nešto. No, od lošeg skaliranja nijedan jezik ne spasava.

Zato ja kažem

Citat:
Nedeljko: Biće da nije problem do .NET-a, nego do onih koji su radili.


odnosno

Citat:
Ivan Dimkovic: Daleko vise uticaja na performanse ima sam pisani kod - od optimizacije algoritama pa do adaptiranja algoritama na konkretan programski jezik / implementaciju posto sa visokim jezicima koji imaju virtuelnu masinu moze da se desi da JIT kompajler ima specificnosti i da voli / ne voli neke konstrukte.


Najveći uticaj ima sam algoritam. Tu se dobijaju ubrzanja i od po milion puta, ako je problem algoritamski zahtevan.
[ ivan.mojsilovic @ 04.06.2012. 19:28 ] @
Nasledih neki projekat koji je bio on hold jedno vreme pa sad treba polako da se gura dalje.

Nema cirilice hvala bogu (nikakve veze sa srbovanjem) ali kad videh DobavljacDaoImpl.java i NalogZaNabavkuState.java kad suzu ne pustih :D
[ Nedeljko @ 04.06.2012. 20:08 ] @
Ma, naravno. Ja pišem na Srpskom isključivo ćirilicom, osim kad je tehnički nemoguće, ali kad je izvorni kod u pitanju, pa naravno da sve što je ozbiljno ili može jednom postati deo nečeg ozbiljnog, treba da bude na Engleskom.
[ ivan.mojsilovic @ 04.06.2012. 20:14 ] @
Jel radi ćirilica na ES-u? Ako radi što ne pišeš istom?

EDIT: ovo je bio test koji je pokazao da ne radi :D
[ aaaca @ 05.06.2012. 13:28 ] @
Citat:
ivan.mojsilovic: Nema cirilice hvala bogu (nikakve veze sa srbovanjem) ali kad videh DobavljacDaoImpl.java i NalogZaNabavkuState.java kad suzu ne pustih :D

A zašto sve mora da se ispolitizuje - da ne upotrebim neki teži termin. Čim neko spomene srpski jezik, a naročito ćirilicu, odmah se lupaju razne etikete. Valjda možemo u tehnici i informatici da preskočimo takve stvari. Nijedan normalan narod ne pljuje po svom jeziku i pismu. Mi smo izuzetak. Sve nas nešto sramota.

Što se same teme tiče, očigledno je bitno da se sistem rada usaglasi sa ljudima s kojima se sarađuje. Ako su Kinezi u pitanju verovatno će biti potreban kineski jezik, što znači da od posla nema ništa - osim ako znaju engleski ili srpski.
[ ivan.mojsilovic @ 05.06.2012. 13:50 ] @
Zbog toga sam se i ogradio. Kad kazem 'nema cirilice hvala bogu' mislim da na to da nema nebulozne mesavine latinice, cirilice i dva jezika sto je po meni teska glupost.

Ako pises na srpskom, onda sve pisi na srpskom ali ipak latinicom jer ti nece raditi copy/paste sa neta kako treba pa je besmisleno.

Ako imas NalogZaNabavkuState nazovi ga NalogZaNabavkuStanje ali i to samo pod uslovom da si 1000% da kod nece napustiti Srbiju.
[ bondja @ 19.07.2012. 12:09 ] @
Ma kakav komentar!? Kada bolje razmislim, ako postoje Unit testovi za taj kod, kome treba komentar?!
Jasno se vidi iz testova sta radi taj kod, kako ce da radi u raznim slucajevima koriscenja, kada nece da radi,
koji su ocekivani rezultati. Svaki komentar (na bilo kom jeziku) kada ima unit testove je suvisan. :(
[ ivan.mojsilovic @ 19.07.2012. 12:56 ] @
^ to je bila sala, jel tako?
[ bondja @ 20.07.2012. 21:28 ] @

Generalno pravilo: k0d treba da bude "elegantan" - sam sebe da objašnjava, da se veći problemi razbiju na manje delove,
drugim rečima da je prilično jasno šta radi i čemu taj deo k0da služi.

U suprotnom, komentari postaju neophodni, ali problem je što ne slede matematičku preciznost kao k0d
(tačno definisana sintaksa) tj. komentari su proizvoljni, te mogu biti čak i zbunjujući.

Pomoću k0da u unit testovima (ima jasnu/preciznu sintaksu), za posmtrani k0d dobijamo:
dokaz da je ispravan, primere korišćenja, dokumentaciju o ponašanju (šta da očekujemo).



[ Nedeljko @ 20.07.2012. 21:36 ] @
Citat:
bondja: k0d treba da bude "elegantan" - sam sebe da objašnjava

+1
[ Stijak @ 20.07.2012. 22:36 ] @
Potpuno očiglednom tvrdnjom da kod sam po sebi treba da bude jasan pokušavate braniti neobranjivo - da komentari nisu ni potrebni.

Evo samo nekoliko primjera kada su meni komentari veoma korisni za upoznavanje sa nepoznatim kodom:
-Kada je originalni koder odlučio da umjesto očiglednog rešenja upotrebi na očigled komplikovanije (zbog performansi - koje nisu očigledne, jer se pokazalo da očigledno izleće iz nekih drugih ograničenja programa - npr. memorije, ili se sukobljava sa nekim drugim djelom aplikacije, zbog ispravka bug-a) - da bi spriječio onog ko pregleda kod da promjeni
- Kada se poziva nešto što je u drugoj klasi, radi bog zna šta, zavisi od druge klase ili nešto slično - a jednostavno se može objasniti - da bi se olakšalo programeru da prati taj dio koda bez skakanja sa klase na klasu(ovdje su meni odlični i oni /** komentari u javi koje IDEi sami čitaju)
- kada se koristi neki specifičan način da se nešto uradi - jer je tako definisano negdje u dokumentaciji - da ne bi programer morao za svaku glupost da se referencira na dokumentaciju


Istina je da loši komentari mogu da zbune - ali i loš kod itekako može da zbuni - izazivam vas da svojim logičkim aparatom izađete na kraj sa ovim kodom (mada su u ovom slučaju kod pisali dobri programeri)

Naravno da bi između odličnog koda bez komentara i lošeg koda sa komentarima izabrao ovo prvo - ali to nije nikakav argument da se dobar kod ne može učiniti još boljim dobrim komentarima. Uostalom - pogledajte velike projekte i nadjite neki koji ne nekomentarisan?
[ bondja @ 21.07.2012. 06:55 ] @
Da li ste procitali do kraja moja dva prethodna posta ili samo prvu rečenicu?

"Pomoću k0da u unit testovima (ima jasnu/preciznu sintaksu), za posmatrani k0d dobijamo:
dokaz da je ispravan, primere korišćenja, dokumentaciju o ponašanju (šta da očekujemo)."

"Jasno se vidi iz unit-testova sta radi taj kod, kako ce da radi u raznim slučajevima korišćenja, kada neće da radi,
koji su očekivani rezultati. Svaki komentar (na bilo kom jeziku) kada ima unit testove je suvišan."

@Stijak
Slazem se da postoje extremene/specificne situacije, ali izuzetak ne predstavlja pravilo.
Ako programer napravi takav k0d da mu je zaista neophodan komentar, i dodatna objasnjenja, onda je pitanje
da li je sam zakomplikovao, da li ga je mrzelo da nadje kompaktnije resenje, ili nije imao vremena? (a kako je testirao, samo on zna).
U svakom slucaju, drugi programer, koji nakon toga treba da izmeni/doradi (a to je neminovno pre ili kasnije), ili reši neki nov bug koji je otkriven,
je "obrao bostan" ako se nadje u situaciji : "da bi spriječio onog ko pregleda kod da promjeni".

Za one koji čitaju postove do kraja:
U slucaju da nema unit testova, bez obzira na kvalitet k0da, onda je komentar i više nego dobrodošao, sva moguća dokumentacija, svi testovi (makar i u nekom pomoćnom txt fajlu), svako usmeno objašnjenje ili bilo kakva smernica, pa čak i link (forum, sajt) odakle je taj k0d kopiran...

[ Nedeljko @ 21.07.2012. 07:47 ] @
1. Šta klasa radi treba da bude očigledno iz naziva klase.
2. Čemu funkcija/metoda služi i kako se poziva, treba da bude jasno iz njenog naziva i spiska argumenata.
3. Implementacija treba da bude jasna.
4. Komentari su potrebni samo u preostalim slučajevima. Znači, vrlo retko.
5. Ako iz naziva klase nije jasno čemu ona služi, naziv ne sme da navodi na pogrešan trag.
6. Ako iz naziva i spiska argumenata funkcije/metode nije jasno šta rade i kako se koriste, onda treba da bude očigledno da to nije jasno, tj. ne sme se navoditi na pogrešan trag.

Znači, onaj ko interveniše na nekom kodu treba sam da vidi da mu je čitanje nečega potrebno, i to samo onda kada zaista jeste ptrebno, a inače ne treba gubiti vreme na pisanje komentara. Skram kao lean metodologija razvoja odbacuje pisanje tehničke dokumentacije. Razmislite zašto. Odgovor nije u ovoj mojoj poruci.
[ mmix @ 21.07.2012. 08:27 ] @
E, jos kad bi svet bio tako idealno i savrseno mesto kakvim ga vi zamisljate, a o bransi i da ne govorim
[ ivan.mojsilovic @ 21.07.2012. 09:57 ] @
Vidim da je vama svima lepo :) Nadam se da cu imati prilike da radim u takvim savrsenim okolnostima. Do tada, pisanje komentara ce biti MUST tamo gde se ja pitam. Gubljenje vremena na komentare? Od svih razloga za gubljenje vremena, taj je najbezazleniji.
[ negyxo @ 21.07.2012. 12:19 ] @
Da probam ja da zacinim malo :-)

Dokaz da je cela ova bransa krenula u krivom smeru su unit testovi. Po meni unit testovi su kao komentari, pa ako vazi pravilo da za dobar code ne trebaju komentari, onda bi valjda trebalo da vazi i za unit testove :-)
[ Nedeljko @ 21.07.2012. 12:39 ] @
junit testovi dokazuju da je kod ispravan/neispravan, dok komentari ne rade ništa.

Ako nekome pucaju testovi, pa ne zna zbog čega, neka pročita potreban do dokumentacije. Podvlačim, samo potreban deo dokumentacije ima smisla pisati.
[ negyxo @ 21.07.2012. 12:55 ] @
Cek, ko dokazuje da su unti testovi ispravni? :-)

No da ne bude da sam dosao da trollujem, mislim da komentare je tesko izbeci, postoje situacije kada je sasvim malo komentara dovoljno da bi se opisao code, mnogo brze nego sto je to gledanja code-a. Recimo, ono sto mi pada je parser, dok ja krenenm da evaluiram code u glavi, dve linije komentara sasvim to lepo objasnjavaju.

No, sto se tice unit testova, mislim da sav onaj deo sto je statican je trebalo prebaciti na kompajler (nesto vec danas moze, a nesto zahteva dodatni razvoj kompajlera/biblioteka, doduse zavisi i kojih kompajlera), ono sto je meni neshvatiljivo da su neki spremni da pisu gomilu unit testova umesto da "specijalizuju" svoj code, pa kroz kompajler da izbegnu gomilu gresaka.

[ ivan.mojsilovic @ 21.07.2012. 13:01 ] @
Kad se vise izgubi vremena, kad se napise koometar kojem ne trab vise od minut-dva i koji se procita za 10 sekundi, ili da se bulji u unit testove, kapira kod itd?

Pogotovo ako ne poznajemo kontekst aplikacije ili njenog dela dovoljno dobro a sto je kod velikih projekata stalnost.
[ Nedeljko @ 21.07.2012. 14:33 ] @
Niko da mi odgovori na ovo pitanje:
Citat:
Nedeljko: Skram kao lean metodologija razvoja odbacuje pisanje tehničke dokumentacije. Razmislite zašto.

Recimo da imam prokjekat od oko 10,000 funkcija. Ništa posebno, ništa nerealno. Da bih ga ja dokumentovao, ne treba uložiti par čovek-minuta, nego par čovek-meseci. E, sad, dolazi novi programer u firmu i nije mu jasno 50 funkcija, a dokumentacije nema. Šta onda? Pa, ništa, pitaće nekoga ko zna i on će mu to objasniti za sat vremena. Šta je racionalnije, uložiti par čovek-meseci ili jedan čovek-sat?

Lean metodologije razvoja zabranjuju da se radi bilo šta će naknadno biti neupotrebljeno. U prethodnom primeru neupotrebljeno je 99,5% dokumentacije. U scrum-u postoje pojmovi proizvoda (onoga što se radi) i korisnika proizvoda (onoga ko će to da koristi). Recimo, ako je proizvod alat za dalji proces proizvodnje, korisnik je radnik koji će da koristi taj alat u daljem procesu proizvodnje. U slučaju proizvoda za masovno tržište, korisnik je masa ljudi koja se anketira itd. Ono što nema korisnika ili ima "zamišljenog" ili "potencijalnog" korisnika se ne radi. Ko je korisnik dokumentacije? Pa, onaj ko se naknadno bude uključio u projekat. Dakle, radi se o "potencijalnom" korisniku. Mi ne znamo šta će od detalja njemu tačno da treba, tj. kojih 0,5% dokumentovati. Zato dokumentaciju ne treba ni raditi, već ga pustiti da sam dođe da pita ono što mu nije jasno. Takođe, dokumentacija koja je jednosmerna je po pravilu opširnija od "žive reči" koja je dvosmerna, gde se objašnjava samo ono što zaista nije jasno.

Da se popravim. Obično se zna kojih je 0,5% koda problematično i samo to treba dokumentovati da se ne bi objašnjavalo svaki put kada neko dođe.
[ Nedeljko @ 21.07.2012. 14:49 ] @
Citat:
negyxo: Cek, ko dokazuje da su unti testovi ispravni? :-)

Ništa nije savršeno, ali njih je pisao neko ko zna dotični modul, a koristi neko ko možda i ne zna.
[ aaaca @ 21.07.2012. 14:56 ] @
Citat:
Nedeljko: Niko da mi odgovori na ovo pitanje:

Recimo da imam prokjekat od oko 10,000 funkcija. Ništa posebno, ništa nerealno. Da bih ga ja dokumentovao, ne treba uložiti par čovek-minuta, nego par čovek-meseci. E, sad, dolazi novi programer u firmu i nije mu jasno 50 funkcija, a dokumentacije nema. Šta onda? Pa, ništa, pitaće nekoga ko zna i on će mu to objasniti za sat vremena. Šta je racionalnije, uložiti par čovek-meseci ili jedan čovek-sat?
......


Nekoliko čovek-meseci uloženih u pisanje dokumentacije, nije ništa u odnosu na nekoliko čovek-godina uloženih u pisanje dotičnih funkcija.
[ Nedeljko @ 21.07.2012. 15:50 ] @
Ali previše u odnosu na alternativu od nekoliko desetina čovek-minuta.
[ negyxo @ 22.07.2012. 06:48 ] @
Citat:
Nedeljko: Ništa nije savršeno, ali njih je pisao neko ko zna dotični modul, a koristi neko ko možda i ne zna.


Ma znam Nedeljko, negde se mora povuci granica, ne moze se stalno preispitivati sve, zavrsili bi u mrtvoj petlji :-)

No ja i dalje mislim da su unit testovi previse hype-ovani. Po meni, static checking je majka, ako ti napises dovoljno informacija onda kompjuter moze da pise testove mesto tebe (OK ne sve, posto bi nesto zahtevalo priliko duboku hierarhiju definisnaja problema, odnosno vec se zalazi u domen AGI-a :-)). Primer automatskog testiranja je recimo PEX. Naravno, PEX ima samo smisla ako ti napises dovoljno informacija, kako bi on znao sta da trazi... ali eto, nesto mi se cini da MS ovo napusta, nekako sve je ostalo u experimentalnoj fazi. tj. ja sam bio iznenadjen da je prilicno mali broj ljudi upoznat sa tim, problem je sto ovakav nacin pisanja programa mu dodje kao nova paradigma, isto kao objektno orijentisano programiranje, zahteva drugi mentalni pristup.

Mislim da bi zlatna sredina bila kada bi se sve to integrisalo u neko novo okruzenje, programski jezik koji bi bio mnogo vise intuitivan...
[ mmix @ 22.07.2012. 09:24 ] @
Dobro, i ja resim cost benefit analizom da zatvorim to odeljenje i prebacim ceo dev u srbiju/kinu/avganistan i sad imam tonu scrum(tm) koda i zavisiim od lika kojeg planiram da otoustim da uradi knowedge transfer? Techdoc je keva, scrum je po mnogim pitanjima liabilty za firme
[ ivan.mojsilovic @ 22.07.2012. 10:26 ] @
Nedeljko a ako nemam koga da pitam (sto umrli, sto otisli)? Projekat je live vec 10 godina a ja treba da resim problem a nema nkoga da se pita? I sto neko kaze nekoliko covek-meseci na projektu od nekoliko covek-godina nije apsolutno nista. Jos da ponovim na cemu se sve gubi vreme, komentari su u domenu statisticke greske.

Unit test - em ne kapira covek kontekst projekta ondah, em ne kapira kod najbolje i tu unit test da mu pojasni zasto je nesto kako jeste? Nema sile.
[ negyxo @ 22.07.2012. 10:37 ] @
Komentare je najbolje pisati kada programer oseca potrebu za to. Znam da je ovo relativno, ali tako je bar kod mene. Najgluplje sto sam video je forsiranje komentara na svakoj funkciji, property-u, delegatu, eventu, sta god. Pa recimo dobijes company standard violation ako ne napises za property IsVisible komentar @!#$!@!@@#$%^#....
[ Nedeljko @ 22.07.2012. 10:37 ] @
Neki to rešavaju tako što za svaku komponentu imaju najmanje dva čoveCa koja je znaju, pa kad jedan umre/ode, zaposli se nov kome onaj drugi prenese znanje.
[ CiM0beTa @ 22.07.2012. 10:41 ] @
ne znam kako je po firmama. ali ja evo pisem komentare- pola srpski pola engleski. Jer mi engleski bas nije savrsen...a i neke stvari je nemoguce prevesti. Uvek me buni email, browser itd...prevoditi ili ne.. inace funkcije promenljive, imena fajlova, sve to na engleskom. A kad zavrsim sve to..recimo neki project uvek mi se javi želja da izbrišem sve komentare i što više zbijem kod, da bi bio brzi :)
[ ivan.mojsilovic @ 22.07.2012. 10:55 ] @
Citat:
Nedeljko:
Neki to rešavaju tako što za svaku komponentu imaju najmanje dva čoveCa koja je znaju, pa kad jedan umre/ode, zaposli se nov kome onaj drugi prenese znanje.


Kazem ja, savrsen je to svet :)
[ flighter_022 @ 23.07.2012. 10:40 ] @
U korist detaljnog pisanja komentara je i sledece:

Recimo, dodjete u situaciju da ste pre na primer 7-8 godina nekom uradili softver za neku odredjenu namenu. Sors jer kod vas, ali posto ste to radili specijalno za tog klijenta, vise sors niste dirali do sada. I sada treba napraviti neke promene na softveru, razlog i priroda promena su nebitni, ali je bitno da treba da prodjete kroz mnogo linija koda, prisetite se sta ste i kako, i zasto, pisali pre 7-8 godina? Bez komentara trebace vam barem nekoliko dana da vidite gde i sta treba uraditi. Sa komentarima, mnogo manje.

A zamislite onda recimo da je klijent zaposlio (stalno ili privremeno, nebitno) nekog ko moze da uradi izmene, ali nema sors. Naravno, mozete dati sors takav kakav je, bez komentara, ili sa komentarima na jeziku koji taj programer ne zna. Njemu ce trebati izuzetno mnogo vremena da se snadje.

Zato, standard treba da postoji, i za to gde se i kako pisu komentari, i za to na kom jeziku.

Ja licno radim na softveru, i kako koji modul je spreman, uradim komentare. Cesto se desi da tokom pisanja komentara vidim neki manji problem, sansu za ispravke ili unapredjenja, i svi su zadovoljni :D
[ ivan.mojsilovic @ 23.07.2012. 10:52 ] @
Pa da, samo u savrsenom svetu gde programiraju savrsenni programeri. koji su btw tako rodjeni, moze fino da funkcionise bez komentara.
[ Mihajlo Cvetanović @ 23.07.2012. 11:06 ] @
Pisanje komentara doprinosi boljem kodu. Umesto da se sramotim komentarom tipa "ovo je ovako, jer me je mrzelo onako" radije ću da prepravim kod tako da više nema potrebe za takvim komentarom. Za ostale komentare moram da imam u vidu šta sve treba da zna prosečni programer, kao i sebe kad pozaboravljam detalje posle pola godine. Ono što prevazilazi bilo jednog bilo drugog treba da ide u komentar. Na žalost, nikako nemam volje za one glavne komentare, zaglavlja funkcija. To mi je slabost.
[ ivan.mojsilovic @ 23.07.2012. 11:47 ] @
Kad se poznaje kontekst aplikacije onda je lakse snaci se u kodu i bez komentara. Ali kad se ne zna kontekst, ili se slabo poznaje (tipa potrebno je bar 12 meseci da se sve pohvata) onda su komentari spas.
[ Nedeljko @ 23.07.2012. 11:57 ] @
Citat:
flighter_022: U korist detaljnog pisanja komentara je i sledece:

Recimo, dodjete u situaciju da ste pre na primer 7-8 godina nekom uradili softver za neku odredjenu namenu. Sors jer kod vas, ali posto ste to radili specijalno za tog klijenta, vise sors niste dirali do sada. I sada treba napraviti neke promene na softveru, razlog i priroda promena su nebitni, ali je bitno da treba da prodjete kroz mnogo linija koda, prisetite se sta ste i kako, i zasto, pisali pre 7-8 godina? Bez komentara trebace vam barem nekoliko dana da vidite gde i sta treba uraditi. Sa komentarima, mnogo manje.

E, sad lepo pomnoži tu vremensku uštedu sa verovatnoćom da ćeš to ikada raditi, pa uporedi sa vremenom potrebnim za pisanje svih tih komentara.
Citat:
ivan.mojsilovic: Pa da, samo u savrsenom svetu gde programiraju savrsenni programeri. koji su btw tako rodjeni, moze fino da funkcionise bez komentara.

Nešto si pobrkao. Kod će raditi na potpuno isti način i ako se izbace svi komentari iz njega.

Na kraju krajeva, pronicanje u kod koji je neko drugi pisao je opšti programerski skil. To se jednostavno podrazumeva. Zamisli da ti se pokvari frižider, pozoveš majstora a on se žali na to da nemaš tehničku dokumentaciju frižidera. To jednostavno nije masjtor. Takvom bih se zahvalio i pozvao drugog.
[ mmix @ 23.07.2012. 12:32 ] @
Babe i zabe, nedeljko.

Ako vec hoces realnije poredjenje to bi bilo da firma A prodaje firmi B dizajn frizidera i kaze "ma snaci cete se vi samo pratite crveni kabl" i kad traze techdoc ti im kazes "kakvi ste vi to inzenjeri" :)

Sansa da ces raditi follow up nekog softverskog proizvoda je ogromna, ako ne pre onda u trenutku promene platformi, ako ne ti onda neko ko to bude gledao kroz 10 ili 20 godina. Ja stvarno ne mogu da verujem da se kao relana zastupa teza da je dokumentacija visak (to ukljucuje i komentare, i u novije vreme doc comments tagove).
[ aaaca @ 23.07.2012. 12:37 ] @
Frižider baš i nije najbolji primer jer ima pet sastavnih delova.

Stare televizore nije bilo šanse popraviti bez detaljne elektronske šeme istog. Ovi novi televizori ne mogu da se poprave bez specijalnog uređaja koji će "majstoru" reći gde je kvar.
[ Nedeljko @ 23.07.2012. 12:58 ] @
Programski jezik je već jezik, tako da je dokumentovanje ništa drugo do pisanje iste stvari na dva jezika.

Zašto po istom rezonu ne bismo pisali istu stvar na više programskih + više prirodnih jezika?

Zlatna sredina između dokumentovanja svega i nedokumentovanja ničega je dokumentovanje onih 0.5% koda koji zaslužuju dokumentaciju.
[ mmix @ 23.07.2012. 13:42 ] @
Programski jezik jeste jezik ali ljudi nisu kompjuteri. Programski jezici prenose instrukcije, prirodni jezik moze da prenosi i instrukcije i razumevanje koristeci nasu urodjenu sposobnost komunikacije i vizuelizacije. Trece, ljudi imaju razlicite stepene predznanja i razlicite nacine razmisljanja i resavanja problema i sposobnost ekstrapolacije znacenja iz koda nije univerzalna. Tebi se mozda cini da 0.5% koda treba dokumentovati ali za nekog je potrebno dokumentovati mnogo vise, za nekog treceg je potrebno dokumentovati 0.2% koda koji tebi izgledaju kao da su trivijalni (kao sto bi njemu tvojih 0.5% izgledalo trivijalno). Zato se takve stvari ne ostavljaju slucaju i postoji nekoliko nivao dokumentacije koja ide uz projekt, zavrsno sa komentarima koda.
[ Stijak @ 23.07.2012. 13:44 ] @
Vi ljudi protiv komentara - jer radite vi kao programeri u nekom timu ili su to čista teorijska naklapanja?

Jer mislite da su softverske firme pale sa marsa kada sve do jedne promovišu komentare? Mislite da kada bi to bilo efikasnije - da se ne bi našla jedna velika firma koja bi rekla - vrijeme naših programera možemo pametnije iskoristiti - i zbog toga - nema komentarisanja kod nas? I svoju filozofiju dokazala većom produktivnošću programera?

Ajde navedite mi ijedan primjer iole ozbiljnog projekta koji nije komentarisan?

Naravno da ako pravim neku glupu aplikaciju od par klasa koju sam sklepam od danas za sutra- da ne moram da komentarišem - ali pravi projekti - a ovdje o tome pričamo moraju imati komentare jer će te kasnije svaki ušteženi sekund koštati dane.

@nedeljko - pričaš gluposti. I mašinski jezik je "jezik" pa ne vidim da ga ljudi tako lako tumače - baš bih volio da vidim nekog ko kao u matrixu proleće kroz heksa zapis mašinskog jezika i vidi pametne strukture petlji, uslova i slično ;)

Viši jezici su lakši i bliži prirodnima - ali i dalje to nije to...

P.S. Sledeći vašu logiku - logika je ista ako se promjenljiva zove winningNumber ili w, a ovo drugo je brže za kucanje - ili metod b(), ha ha ha - baš bih volio vidjeti neki takav kod - nisam odavno ;)

[Ovu poruku je menjao Stijak dana 23.07.2012. u 15:02 GMT+1]
[ CiM0beTa @ 23.07.2012. 15:01 ] @
Najlepsa varijanta jeste da sve funkcije vracaju samo true ili false..onda tu nista ne treba komentarisati, samo zapamtiti imena funkcija. A koja cemu sluzi, trebalo bi se znati. Ako se to ne zna, onda dzaba i komentari.
A komentare ubacivati tamo gde je prekid kod-a, gde se pozivaju drugi fajlovi, klase... Mnogo su korisniji komentari koji opisuju strukturu aplikacije nego oni koji opisuju samo posao koji radi neki kod.
[ ivan.mojsilovic @ 23.07.2012. 15:26 ] @
Citat:
CiM0beTa:
Najlepsa varijanta jeste da sve funkcije vracaju samo true ili false..onda tu nista ne treba komentarisati, samo zapamtiti imena funkcija. A koja cemu sluzi, trebalo bi se znati. Ako se to ne zna, onda dzaba i komentari.


Trebalo bi se znati? A kako si zamislio da se to zna?
[ Nedeljko @ 23.07.2012. 16:13 ] @
Citat:
mmix: Trece, ljudi imaju razlicite stepene predznanja i razlicite nacine razmisljanja i resavanja problema i sposobnost ekstrapolacije znacenja iz koda nije univerzalna. Tebi se mozda cini da 0.5% koda treba dokumentovati ali za nekog je potrebno dokumentovati mnogo vise, za nekog treceg je potrebno dokumentovati 0.2% koda koji tebi izgledaju kao da su trivijalni (kao sto bi njemu tvojih 0.5% izgledalo trivijalno).

E, pa, nije sve relativno. Ako sam primenio bilo kakvo nestandardno rešenje, dužan sam da ga dokumentujem nezavisno od "trivijalnosti. Za standardne stvari (a to je 99,5% koda), aman. Čemu dokumentacija?
Citat:
Stijak: P.S. Sledeći vašu logiku - logika je ista ako se promjenljiva zove winningNumber ili w, a ovo drugo je brže za kucanje - ili metod b(), ha ha ha - baš bih volio vidjeti neki takav kod - nisam odavno ;)

E, pa vidiš. Naravno da promenljivu treba nazvati winningNumber. Kada je tako nazoveš, onda je jasno čemu služi i čemu onda još i komentar? Svojim nazivom je već dokumentovana.

I da, znam nza više softverskih firmi sa velikim projektima koji nisu dokumentovani.

@mmix

Ovde ti je odgovor na konstataciju da ljudi nisu kompjuteri - zato se identifikatori pišu na prirodnom jeziku. To je taj kompromis.
[ Nedeljko @ 23.07.2012. 16:18 ] @
Citat:
Stijak: pravi projekti - a ovdje o tome pričamo moraju imati komentare jer će te kasnije svaki ušteženi sekund koštati dane.

E, to bih vodeo da mi neko dokaže, da ćeš ulaganjem vremena A u dokumentovanje više od 1% koda kasnije uštedeti vreme B koristeći kod određen broj puta čije je matematičko očekivanje N, tako da bude A<NB.
[ ivan.mojsilovic @ 23.07.2012. 16:21 ] @
Nisam racunao ali tamo gde sam imamo komentare znao odmah na koje klsae i servise treba da obratim paznju, a tamo gde ih nije bilo gledao sam kod da bihprovalio. Nasledio sam projekat posle 10 godina.
[ Nedeljko @ 23.07.2012. 16:45 ] @
OK, koliko ti je trebalo da se ukačiš u nedokumentovan kod, a koliko je bilo potrebno da se napiše dokumentacija za 100% koda?

Opet, da je bilo onih 0,5% dokumentacije, da li bi onda znao koje klase da gledaš?

Koliko treba pisati da bi znao koje klase da gledaš? Rekao bih jedan kraći word fajl za veliki projekat.

Znam ja da je teško napustiti uvrežena shvatanja, ali pokušajte da merite stvari i da ih upoređujete bez predrasuda.
[ CiM0beTa @ 23.07.2012. 16:49 ] @
Citat:
ivan.mojsilovic: Trebalo bi se znati? A kako si zamislio da se to zna?


Pa ako bi sistem bio tako napravljen, kao sto sam rekao, da funkcije vracaju samo true i false, onda bi te funkcije bile, morale da budu jednostavne. Provera da li email postoji u bazi, da li korisnik logovan, da li je registrovan itd...sve su to proste funkcije cije se znacenje vidi odmah iz koda a isto iz imena funkcije.
Ali, sta ja tu pricam, pa ja i nisam pravi programer, a mislim da nije ni nedeljko... :)
[ Nedeljko @ 23.07.2012. 16:51 ] @
Ako su za razumevanje dela koda dovoljni kod i opšta znanja iz struke, onda ga svakako ne treba dokumentovati, jer čak i ako neko nema neko opšte znanje, pitaće nekoga ko ga ima - to nije vezano za projekat.

Ako kod sadrži nešto nestandardno, tj. za razumevanje nisu dovoljna opšta znanja iz struke, onda to svakako treba dokumentovati.

Tako se dolazi do onih 0,5%. Preostalih 99,5% dokumentacije su dobro izabrana imena identifikatora, fajlova i projekata.
[ CiM0beTa @ 23.07.2012. 17:39 ] @
Ja sam sve vreme mislio na php..a tek sad vidim da je ovo forum Art of Programming. Tako da, ups. Treba da postoje komentari :D

Da, vrlo zanimljiva diskusija. Mislim da realno stvari stoje ovako. Source treba da sadrzi komentare, opsirne u zavisnosti od strukture tima, ideje, namene, proširivosti, projekta itd.. A da li taj source posle prosledjivati dalje, pa to zavisi valjda od licence i opet od volje programera. Naravno da je za krajnji rezultat (za korisnika) najbitnije da je program brz i ispravan a to opet postavlja pitanje postojanja komentara. Tako da eto jeste da ne razumem baš najbolje javascript, ali mi ses vidja sto su zbili onako kod. A usput ima i source...
[ Nedeljko @ 23.07.2012. 18:19 ] @
A ja govorim pre svega o velikim, ozbiljnim, profesionalnim projektima.
[ mmix @ 23.07.2012. 18:44 ] @
Ja stvarno ne znam o kojim projektima ti pricas, ali u mom svetu ta tvoja prica ne pije ni malo vode. Mozda sam ja subjektivan jer da prica ide kako ti kazes ja ne bih imao 80% svojih radnih obaveza ali mene bi cak bilo sramota da dam ponudu za projekat a da isti nema dokumentaciju. Al nemam ni potrebe za time jer je jedan od projektinih zahteva UVEK izrada dokumentacije od koje gro bude izradjen pre nego se uradi i linija koda. Sta vise, neka dokumentacija se pise na razlicite nacine za ISTU stvar, jedna verzija arhitekture sistema ide u risk managment grupu, druga u PM za project tracking, treca u IT board za approval i akviziciju opreme i softvera, itd. Developeri ne vide skoro nista od toga dok projekat ne dodje do nekih 30% zavrsetka i izlaze iz price na nekih 80% nakon cega ide UAT, treninzi, project closure, itd. Pravi se dvonedeljni presek i projekat je uvek up-to-date i dokumentovan do te mere da kompletan dev moze da se pauzira, stornira, cak i prebaci u potpuno novu ekipu. Ne ide to tako vise bre da ti sednes i iskucas program i svi srecni I prosla su vremena kad su devovi kontrolisali tok projekta scrumm je bezobrazni pokusaj da se to ponovo aktivira kroz agile ali znamo i mi za jadac
[ Nedeljko @ 23.07.2012. 19:25 ] @
Citat:
mmix: Ja stvarno ne znam o kojim projektima ti pricas

Evo, ko na primer radi sve bez dokumentacije:

www.arahne.si
www.investintech.com
www.teletrader.com

Budi siguran da nisu jedini, a uspešne su firme u pitanju.

Investintech je čak prebacivao nedokumentovane projekte sa novim ljudima sa MFC-a na Qt (pa čak i sa C++ MFC-a na C#). I? Ništa! Transfer complete.
[ Stijak @ 23.07.2012. 22:50 ] @
Dobro sad - moj ideal je nešto izmedju nedeljka i mmix. Sa jedne strane - nešto mora unapred biti definisano i dokumentovano uz male izmjene poslije (npr. komunikacija - XML specifikacija i sl), ali mi je suludo da za cijeli projekat spremam ogromnu dokumentaciju i pre nego počnem i tu mi je sasvim uredu agile.

U samom kodu dokumentacija mi je uglavnom - svako public/protected polje i metod po jedan javadoc stub koji se proširuje ukoliko se radi o nečemu netrivijalnom - plus tamo gdje mislim da treba - sveukupno - možda 10% koda je dokumentacija. Ovih 0.5% mi se čini baš mnogo malo... I tih 10% mi oduzima možda 5% dodatnog vremena - a s obzirom da se trudim da dokumentujem metod nakon što ga iskodiram (naravno ima izuzetaka kada imam ideju za više povezanih metoda pa sve u jednom dahu završim) i to mi dodje kao dobro vrijeme da rezimiram šta sam uradio. I često dok pišem komentar uvidim da bi to moglo bolje uz neku sitnu optimizaciju.

Ne znam da li znate za onu aksiomu da u principu mnogo više naučiš kada neko gradivo predaješ drugima - nego kada ga samo učiš. Na sličan način mi pisanje komentara pomaže da sagledam moj kod i steknem bolji utisak kako sve zajedno funkcioniše. Tako da to i zbog toga ne smatram izgubljenim vremenom. Nismo mi programeri mašine koje izbacuju određeni broj linija koda po minuti - pa je samo pitanje koliko će od toga biti komentari, da bi toliko bila bitna ta "produktivnost".
[ tdusko @ 25.07.2012. 10:06 ] @
Ja sam sa mmix-om i Ivanom 100% mada znam i za ove kao sto je Nedeljko, sta vise trenutno radim u takvom okruzenju gde se forsira scrum bez ikakve dokumentacije neracunajuci video tutorijale za end usere. 3.5 godine sam radio tako sto sve mora da se dokumentuje na vise nivoa bukvalno ovako kako je mmix opisao i navikao sam kad preuzimam nesto da radim prvo gledam dokumentaciju. Samim tim najezim se kad dodjem u tim i glavni baja mi samo otvori solution i kaze teraj, a packe sam dobio kad sam dokumentovao prvi feature koji sam radio uz obrazlozenje "kod je najbolja dokumentacija, a UML je za slabice" :)
[ Nedeljko @ 25.07.2012. 10:36 ] @
A jeste li vi čuli za aktivnu dokumentaciju? Hint: test driven development.
[ mmix @ 25.07.2012. 10:43 ] @
Ma sve je to super dok oni piske u svom dvoristu i niko ih ne pita za nista, a onda kad pocne interakcija sa ozbiljnim klijentima onda svi u timu peru ruke i daju jednoglasan odgovor "to je odnos sa klijentom, to radi product manager" i tako dobijes paradoksalnu situaciju da product manager koji veze nema sa time mora da pise tehnicku dokumentaciju za klijenta, pa mozes misliti nasta to lici na kraju i koliko je "tehnicka" ta dokumentacija. Ceo taj scrum je made by devs, for the devs i kao takav je potpuno nakaradan u svetu s/w biznisa gde je prioritet obrt kapitala a ne izbegavanja dosadnih poslova.
[ tdusko @ 25.07.2012. 11:02 ] @
Citat:
Nedeljko: A jeste li vi čuli za aktivnu dokumentaciju? Hint: test driven development.


Nemam ja nista protiv da se testovi pisu pre kodiranja funkcionalnosti pa da kroz iteracije fail-success dodjes do cilja, ali imam protiv toga da se to koristi kao jedina dokumentacija.
[ Nedeljko @ 25.07.2012. 13:39 ] @
Citat:
mmix: Ma sve je to super dok oni piske u svom dvoristu i niko ih ne pita za nista, a onda kad pocne interakcija sa ozbiljnim klijentima onda svi u timu peru ruke i daju jednoglasan odgovor "to je odnos sa klijentom, to radi product manager" i tako dobijes paradoksalnu situaciju da product manager koji veze nema sa time mora da pise tehnicku dokumentaciju za klijenta, pa mozes misliti nasta to lici na kraju i koliko je "tehnicka" ta dokumentacija. Ceo taj scrum je made by devs, for the devs i kao takav je potpuno nakaradan u svetu s/w biznisa gde je prioritet obrt kapitala a ne izbegavanja dosadnih poslova.

Taj skram primenjuju i MS i Google i Yahoo, ali ne, oni ne znaju da obrću kapital ili im to nije prioritet.

Ako dokumentacija treba da se radi za klijenta, OK. Onda mu se lepo izračuna koliko košta postojeći projekat u postojećem stanju, a koliko dokumentovanje, pa neka sam odluči. Neću ja da ga učim šta njemu treba (čitaj "da ga pravim budalom"). Ako on odluči da mu se isplati da plati dokumentovanje, nema problema, ali to onda više nije tehnička dokumentacija, već finalni proizvod.
Citat:
tdusko: Nemam ja nista protiv da se testovi pisu pre kodiranja funkcionalnosti pa da kroz iteracije fail-success dodjes do cilja, ali imam protiv toga da se to koristi kao jedina dokumentacija.

A čemu služi preostala dokumentacija?
[ mmix @ 25.07.2012. 16:18 ] @
Ti stvarno treba da proveris svoje izvore, MS ne koristi scrum i prilicno sam siguran da ga Google ne koristi (ali eto provericu da budem 100% siguran), sve i da ne poznajem ljude koji rade tamo to je bilo moje eksplicitno pitanje program menadzeru na intervjuu. Izuzev TFSa ja ne znam nijedan MS projekat da je radjen Scrum metodologijom. Jedini veci shop za koji ja znam da definitivno koriste scrum je salesforce ali oni tesko da su neki reper agilnosti a tehnicke dokumentacije ima podosta.

Ja stvarno ne znam kako ti zamisljas da izgledaju pregovori i bidovanje i naknadna realizacija? Naravno da ce da plate dokumentaciju i da cu im ja pride dati popust za to i da ce mi potpisati svako relevantno parce dokumentacije i pre i posle i da cu i dalje biti jeftiniji od TDD ekipe i da ce softver raditi podjednako dobro ako ne i bolje bez i jedne jedine linije test koda ili sa minimalnim testovima core-a sistema, ako je biding ostar, a obicno jeste, testovi prvi lete. Nije to hobi, prijatelju, to je posao, kad se nesto ne slaze postoji medijacija i cak i sudski procesi i ta dokumentacija sluzi koliko njima za odrzavanje toliko i meni da sam pokriven da softver radi ono sto su trazili. Da li ti zaista mislis da cu ja da pridjem VPu risk menadzment grupe i da mu kazem "vidis prijatelju sva dokumentacija ti je u kodu, ako si bas pglu i ne kontas iz sorsa koji portovi treba da se otvore, mi cemo ti rado to prepevati na engleski po zgodnoj ceni od XYZ". Jbt, pa ja ne mogu ni da zamislim to, niti njihovo iznenadjenje To je u rangu sa onim kad udjes u pun lift i kazes "I bet you are all wondering why I gathered you here ". Ili da prvo potrosim tonu vremena da izradim sve detaljne testove u crevca da bi imao dokumentaciju za approval (sve i da mi neko plati pre toga) i time zapravo napravim dva programa za cenu jednog? To moze da prolazi u inhouse ekipama u nekim nafilovanim startupima gde ima love za mazanje na mooda pa svaka linija koda moze da se pise dvaput, jednom za test a drugi put za program (ili obrnuto, kako je ko zaludjen kojom metodologijom), u realnom svetu treba stvarno da budes naivan pa da te ta ekipa namaze

Da se ne lazemo, mnogo stosta u Scrumu je sasvim ok, neke procese i sam forsiram ali cela ta ideologija da su devovi etericna bica kojima ne treba nadzor i kontrola jer se oni samoregulisu kroz liderske role koje nemaju formalni autoritet je presmesna isto kao i to "devovi lakse citaju kod pa nam ne treba dokumentacija" filozofiranje. To kumbaja druzenje i "kreativna kohezija" puca posle prvog veceg sranja i pokazivanja prstima.



[ Nedeljko @ 25.07.2012. 16:39 ] @
Citat:
mmix: Ti stvarno treba da proveris svoje izvore, MS ne koristi scrum

Izvor je dev koji radi u MDCS, pa ako on laže, lažem i ja.

Ja zaista od pro-doc ekipe nikako da vidim argument zasnovan na računici - ulaganje X čovek dana u izradu dokumentacije, kasnije donosi uštedu od Y čovek dana, pri čemu je X<Y. Izvinite, ali ja od vas čujem samo filozofiju zasnovanu na dogmama - to mora tako i nikako drugačije.

Citat:
mmix: i da cu i dalje biti jeftiniji od TDD ekipe

Hmm... Ja bih pre rekao "prema svecu i tropar". Za neke vrste projekata je TDD zamlaćivanje, a za neke je neophodan.
Citat:
mmix: ta dokumentacija sluzi koliko njima za odrzavanje toliko i meni da sam pokriven da softver radi ono sto su trazili.

Alo, dokumentacija nije user manual, tj. specifikacija onoga što softver treba da radi. OK, i to je neki vid dokumentacije, ali ja uopšte ne pričam o tome, već o onome što je dev-ovima koji to razvijaju potrebno za razumevanje koda. Recimo, MSDN je uputstvo, koje svakako treba da postoji, ali to nije tehnička dokumentacija, već finalni proizvod.
Citat:
mmix: Da li ti zaista mislis da cu ja da pridjem VPu risk menadzment grupe i da mu kazem "vidis prijatelju sva dokumentacija ti je u kodu, ako si bas pglu i ne kontas iz sorsa koji portovi treba da se otvore, mi cemo ti rado to prepevati na engleski po zgodnoj ceni od XYZ". Jbt, pa ja ne mogu ni da zamislim to, niti njihovo iznenadjenje :)

Baš probaj da zamisliš. Šta bi bilo? Meni je to profi odnos. Sve može i sve ima cenu.
Citat:
mmix: Ili da prvo potrosim tonu vremena da izradim sve detaljne testove u crevca da bi imao dokumentaciju za approval (sve i da mi neko plati pre toga) i time zapravo napravim dva programa za cenu jednog?

Čekaj, ako sam te dobro razumeo nećeš da dupliraš vreme aktivnom, ali hoćeš pasivnom dokumentacijom.

Ponavljam, nisam ja 100% protiv dokumentacije, već za zlatnu sredinu - opisna imena + onih 0.5% dokumentacije na engleskom. TDD na odgovarajućim projektima.
[ bondja @ 26.07.2012. 07:57 ] @
Nisam neko vreme posao na ovu temu... auu... ala se zakomplikovalo :)

Hmm.. izlgeda da mi programeri imamo jedan dodatni problem na celu priču: poslodavci (klijenti).

Hteli bi smo da pišemo k0d (+aktivna dokumentacija, unit testovi), a ne da se gnjavimo sa pasivnom dokumentacijom, ali na žalost,
uslovljavaju nas (poslodavci, klijenti) da udjemo u njihov svet, sa mnogo teorije, opisa, dokumentacije, a često bez konkretnih primera.
Onda kažu : pa treba da shvatiš biznis (doduše, u tome smo 20 godina, ali svarićeš ti to za 20tak dana...)
Da ne spominjem već uobičajenu praksu da se klijent predomisli u sred izrade, pa promeni kompletno zahteve ;)

Nije idealno, ali naravno treba krenuti od sebe, mi programeri treba da radimo na tome da se i u ovu našu branšu (koja je ovde
još u povoju), uvedu neke odredjene prakse (npr TDD, Scrum, šta god... ), ovo nije nimalo jednostavno ni lako, ali... što bi rekao:
"Ilovača?!" "Znam, ni ja je nevolim, takav je posao." ;)

poz


[ mmix @ 26.07.2012. 08:29 ] @
Ne postoji nijedan projekat na kojem je TDD neophodan, a postoji dosta projekata na kojima je nemoguc ili jednostavno neisplativ, komplikovan i neprimeren (poimence skoro svi koji imaju presentation logiku u WPFu ukodiranu u XAML jer ne mozes da je testiras bez aktivnog ucesca desktop composera). TDD, isto kao i Scrum, je zilotsko sektarenje i izivljavanje radi neke forme, a tamo gde je forma najvaznija sustina strada pre ili kasnije (onda dobijas lidere kojima je UML za slabice i bandu nekontrolisanih devova koji sikaniraju program menadzera i samim tim klijente i to nazivaju profi odnosom) ili se napusta "izvorni" TDD i Scrum i seku coskovi i dobije neka papazjanija od razvojnog procesa ili se, najgore, iz razvojnog procesa eliminisu tehnolgoije i mogucnosti tehnologija koje se ne uklapaju u sektasko vidjenje sveta. Postoje i druge agile i testing metodologije koje su mnogo primerenije realnom svetu i koje sluze biznis modelu firme umesto da firma sluzi njima.

Tebi je MSDN samo uputstvo jer ti ne mozes da menjas kod koji on dokumentuje, da imas sors .NETa npr MSDN bi ti itekako bio tehnicka dokumentacija u slucaju da treba da izmenis neku od klasa ili da je jednostavno koristis u drugom modulu, etc. Sama vasa tvrdnja da je umesto toga dovoljno okaciti sors test klase i da ce programer brze da shvati neku klasu iz test koda nego iz opisne dokumentacije je bezvezna, na iole ozbiljnom projektu niko od devova ne moze da zna napamet sve klase i da svaki put umesto dokumentacije treba da petljaju po test kodu da bi dosli do zakljucka "aaa, ovde mi baca exception jer sam poslao null" je konstantan gubitak vremena i upravo suprotnost ustedi jer ista informacija moze iz doca da se pokupi za 5 sekundi.

C# je pride veoma zgodan za dokumentovanje sorsa kroz doc tagove (///*) sakrivene u #region segmentima iznad svih relevantnih elemenata, tako da je izrada i odrzavanje dokumentacije daleko od dupliranja vremena narocito jer ja ne ocekujem od devova taj nivo detaljnosti koji ima MSDN, i pravilo je prosto: ako menjas nesto sto utice na strukturu xmldoca ili deklarativni opis, potrosi odmah par minuta da sredis xmldoc. Sandcastle, VS help sistem i intelisense posle resavaju sve probleme, cak imam i custom temu za help sistem koju mogu da brendiram za svakog klijenta pojedinacno. Mozda nije profi i nije zilotski, ali ljudi koji nisu devovi vole takve stvari, a nasuprot tome ne vole pametnjakovice koji im impliciraju da su glupi jer nisu devovi.

Dokumentovanje je u sustini inzenjerstva bilo koje vrste pa i softverskog.
[ ivan.mojsilovic @ 26.07.2012. 09:27 ] @
Amen.
[ dejanet @ 26.07.2012. 09:27 ] @
^ Dobro receno, zbog mladjih kolega..

Inace, iskustvo sa jednog od poslednjih Agile pristup projekata, da je klijent trazio 70% koda(metoda) bude pokriveno test kodom..

Tako da svi znamo gde se nalazi shupak -> ne nalazi se kod klijenta, niti u menadzmentu firme..
[ Nedeljko @ 26.07.2012. 09:57 ] @
mmix

Dakle, prodaješ priču kako devovi ne znaju šta im treba za razumevanje koda, pa će PM-ovi, VP-ovi i ne znam ko da im to objasni.

Drugo, u slučaju aktivne dokumentacije dev zna da li (aktivnu) dokumentaciju uopšte treba da čita u datoj situaciji i ako treba, šta treba da čita. Znači, čitaće samo relevantnih 0,5% testova. Kod pasivne dokumentacije prinuđen je da pročita praktično sve.
[ mmix @ 26.07.2012. 10:07 ] @
Ko to kaze? Ja to sasvim sigurno nisam rekao. Tech dokumentacija jos od 80'ih nije word document, tajna je u navigaciji i organizaciji podataka u dokumentaciji tako da na najbrzi nacin (po mogucstvu preko jednog F1) dodjes o relevantne informacije. Ili ti mislis da ja klijentima saljem 10 risova istampanih papira?

Nedeljko druze, ova prica je beskorisna i u rangu je sa pricom o religiji, nista sto ti ja kazem o realnom svetu tebe nece pomaci u tvojoj veri kao sto i nikakva tvoja racionalizacija ne moze da me ubedi da prestanem da verujem u realnost.

Btw, ovo sad kucam dok pravim architecture diagram za sistem koji ce pratiti MS Mediaroom IPTV implementaciju, i to radim na 3G mrezi dok gledam u more sa terase. Scrum that.

Btw2, tu dokumentaciju pravim na osnovu tehnicke dokumentacije koju sam dobio od MSa u vidu 4 CHM fajla gde sam putem navigacije nasao relevantne delove za moj projekat. Mozda bi bilo bolje da su mi jednostavno dali svoje test klase, sta sti mislis?
[ Shadowed @ 26.07.2012. 10:15 ] @
Citat:
mmix: Tech dokumentacija jos od 80'ih nije word document

Ehhh... Steta sto to nisu culi u nekim firmama sa kojima sam radio..
[ tdusko @ 26.07.2012. 12:00 ] @
Citat:
dejanet
Inace, iskustvo sa jednog od poslednjih Agile pristup projekata, da je klijent trazio 70% koda(metoda) bude pokriveno test kodom..


Ima jedna platforma gde ne mozes da pustis kod u produkciju bez da imas 75% code coverage, cak ni na silu ;)
[ dejanet @ 26.07.2012. 12:52 ] @
^ Konkretno klijent firme za koju sam radio se drzi tog pravila, dev okruzenje: svn/maven/Jenkins. Mislim da ne postoji Jenkins parametar kojim se moze definisati pokrivenost koda test klasama (mozda gresim), vec je 'stvar' definisana ugovorom/dokumentacijom.
Inace Jenkins radi build i pusta testove, posle svakog commit-a koda, tako da cela prica 'gore' postaje moguca.

Ono sto je bitno da u java 'svetu', gore okruzenje svn/maven/Jenkins, defakto postaje industrijski standard.

Sa druge strane salesforce, server/cloud side WS dev. definise striktno pravilo da je code coverage testom 75%, sto me je navelo u tom ranijem projektu, da se strikno drzim vec ponudjenih sf interface-a web servisa, da bi muka bila manja.
Ovaj pristup salesforce-a, nam mozda moze nagovestiti i u kojim slucajevima se primenjuje test code coverage u visokom %, jer njih kao prodavca cloud usluge generalno ne zanima nasa projektna dokumentacija.

Inace generalno sto se tice rasprave, moje neko misljenje da je projektna dokumentacija koja se pise po metodologijima jos od 80-tih i bez koje nema posla, predstavlja VERTIKALNU dokumentaciju, a standardizovani komentari u kodu, komentari kod commit-a koda, a mozda i timesheet komentari predstavljaju HORIZONTALNU dokumentaciju, koja se uklapa sa vertikalnom po zakljucenju posla.

Zameniti sve ili veci deo testovima mi deluje sumnjivo, sto je vec receno.
[ mmix @ 26.07.2012. 15:43 ] @
Upravo salesforce je pokazatelj idiotizma celog tog pristupa. To je super kad ti imas dve, tri klase i kao nesto prckas i faca si. Kad imas deset novih poslovnih procesa i oko 80ak klasa najobicnija izmena na serveru traje preko 20 minuta dok salesforce odradi sve testove, i to sa potpuno minimizovanim idiotskim testovima cija je jedina funkcija da namaknu minimalnih 75%. Ti testovi videli assert nisu. Cisto izivljavanje nad klijentima koji im daju nemalu lovu.
[ Nedeljko @ 26.07.2012. 17:38 ] @
Citat:
mmix: Nedeljko druze, ova prica je beskorisna i u rangu je sa pricom o religiji, nista sto ti ja kazem o realnom svetu tebe nece pomaci u tvojoj veri kao sto i nikakva tvoja racionalizacija ne moze da me ubedi da prestanem da verujem u realnost.

Donekle se slažem, ali mislim da si ti taj koji ovde potura religijske dogme. Kako drugačije nazvati ovo
Citat:
mmix: Dokumentovanje je u sustini inzenjerstva bilo koje vrste pa i softverskog.

Drugo, ti realnošću nazivaš neke ustaljene religiozne obrede (pisanje brda dokumentacije). To se tako radi, to je "realnost" i sve ostalo je u sukobu sa "realnošću". Ja sa tvoje strane ne vidim mnogo argumenata, već samo dogme tipa "kako da izađem na oči", "bio bi me blam", "to je suština", "to je realnost" itd.

Da li shvataš da je svaki neobrazloženi stav u bilo kojoj diskusiji pretpostavka? Ti svo vreme pokušavaš da me ubediš da je dokumentacija neophodna na osnovu pretpostavke da je to tako. Da li primećuješ neki problem u logici?

E, sad, po pitanju MSDN-a i tehničke dokumentacije za projekat na kome se radi:

Pošto MFC programer neće menjati nijednu MFC klasu/funkciju, čak i da su mu izručili gomilu testova, nikad nijedan ne bi pukao, pa je bolje isporučiti klasičnu dokumentaciju. Testovi služe da te navedu na ono u čemu grešiš menjajući kod (koji si nedovoljno razumeo) i štedeći ti vreme time što čitaš samo ono što ti zaista nije jasno, a ne sve od kulina bana. Ako pak neki kod nećeš da menjaš, nego samo da koristiš, onda nemaš u čemu da pogrešiš menjajući kod, pa testovi gube smisao.

Ko je rekao da umesto help sistema za word treba isporučiti testove njegovih funkcija? Dakle, korisnicima uputstvo (koje je finalni proizvod, a ne dokumentacija, pa zvalo se ono MSDN ili kako god), a razvijaocima testove.
[ mmix @ 26.07.2012. 20:07 ] @
Realnost nije dogma, zakljuci izvedeni obzervacijom funkcionisuceg sistema nije religija. Sa druge strane Scrum tek treba da izdrzi test vremena, isto kao i TDD sa sve svojim zadrtostima i nefleksibilnostima. I infranet je nekad bio all the rage i ljudi su me lozili da je buducnost u infranetu a ja se napisah desktop aplikacija za medalju obezbedjujuci korisnicima komparativnu prednost, da ne pominjem da su mi najsladji projekti bili rewrite infranet appova . Moja sreca (ili nesreca) je da sam se nagledao tih eksperimenata podosta i da je skoro uvek veoma malo korisnog ostajalo iza svega toga (al nije da nije, da ne gresim dusu) i da je ta dogma kako je ti zoves i dalje u upotrebi i da ja danas radim posao koji volim dok vecina tadasnjih infranet likova danas bije bitke za projekte sa new age web developerima i dizajnerima kojih ima kilo za peni. Nije da nemam sta da pokazem a sve se to desilo bez svakodnevnog jutarnjeg 15minutnog klanjanja bogu scruma. Ako ti to ne vidis, jbg, ne znam sta bih ti jos rekao. Svako u se i u svoje kljuse pa da vidimo na kraju sta ce biti.
[ Nedeljko @ 26.07.2012. 20:40 ] @
Realnost nije dogma. Slažem se. Ali, šta ti nazivaš realnošću? To što neko izvodi religiozne obrede ti nazivaš "jedinim mogućim načinom rada". Realnost je da postoje religiozni obredi u mnogo čemu, ali ta realnost ne menja činjenicu da se radi o religioznim obredima. To je ono u čemu se ne slažemo.

Takođe, iznosiš tvrdnje koje nisi potkrepio argumentima. Šta je to ako ne dogma?

Slažem se ja da je način na koji radiš jedan od mogućih načina. E, sad, ja za svaki način rada smatram da se može mnogo unaprediti i načini rada će se kroz istoriju razvijati i unapređivati.

A to što se skrama tiče, ne bih rekao da se on do sada nije dokazao.
[ mmix @ 27.07.2012. 08:18 ] @
Jesi ti svestan uopste da bi ti i dalje jahao magarca po vodu sa potoka da ljudi nisu vekovima dokumentovali svoje naucne i inzenjerske poduhvate? Nazivati to religijom jednostavno nema smisla. Pa po tvojem vidjenju religioznih obreda onda je i naucni metod religija jer ima svoje "obrede", sto sasvim sigurno nije vec je uspostavljeni sistem rada koji ne treba rusiti dok stvarno ne naidje nesto dokazano bolje a to se eto jos nije desilo. Ja sam siguran da bi recimo lekovi bili mnogo jeftiniji i da bi se skratio time2market kad bi se isekli neki coskovi u tom testiranju, ono odmah testiranje na ljudima, bez placeboa, bez double-blinda, etc. Mislim, cemu religiozni obred, ako je lek los nekom ce da pozli (puci ce test ), jel tako, budimo agilni...
Jedino u CS svaki put kad neki nalozenko napise PhD tezu o necemu krene izvrtanje cele industrije naopacke u nekoj vecitoj potrazi za novim fiksom jer sve sto je novo mora da je dobro, a investitori ce to da plate jer plivaju u lovi. I naravno da se Scrum nije dokazao, samo je pokazao da je trenutno jeftiniji jer sece coskove, izmedju ostalog i sa ovom dokumentacijom. Da li je ili nije deferred cost bubble ce tek vreme pokazati, imho jeste. Ako trazis empirijski dokaz ja ga nemam jer je proces jos uvek u toku, najbolje sto ja mogu je da dam educated guess baziran na svom tehcniko-menadzerskom iskustvu. Medjutim samo trazenje dokaza od mene je zamena teza jer nisam ja taj koji treba da opovrgne scrum vec vi treba da dokazete da je scrum bolji a vi to ne mozete jer jos nemate sve podatke na osnovu kojih mozete da donesete nepobitan dokaz.
[ Ivan Dimkovic @ 27.07.2012. 08:32 ] @
IMHO, Scrum i ostale "tehnike" su nista drugo nego dokumentovane (o, ironije) dovitljivosti za hronicno under-staffovane timove u danasnjoj IT industriji. Cilj tih dovitljivosti je da se kaze da postoji proces koji, navodno, garantuje nekakve rezultate u takvim uslovima kako bi mid-level tehnicki menadzment imao cime da se pokrije.

U realnosti, taj "proces" je nista drugo nego kreativna dovitljivost koja ne moze da zameni kompletan proces razvoja sa svim normalnim outputima koji bi trebalo da postoje za kompleksan tehnicki projekat (ukljucujuci i dokumentaciju). Sad, sto se neko hvata toga kao nekakvog svetog pisma i resenja za glad u Africi je stvar za neku drugu raspravu koja nema puno veze sa strukom.

Ne sumnjam (cak sam i licno video) da neki scrum projekti dodju do kraja i postanu upotrebljivi - ali sam prilicno siguran da ce se dosta para potrositi kasnije za nadomescivanje nepostojecih outputa ako taj projekat zaista postane sire koriscen i od strane drugih, a ne samo devova koji su pisali kod.
[ Nedeljko @ 27.07.2012. 15:39 ] @
Citat:
mmix: Jesi ti svestan uopste da bi ti i dalje jahao magarca po vodu sa potoka da ljudi nisu vekovima dokumentovali svoje naucne i inzenjerske poduhvate?

Jesam, svestan sam. E, sad, ja nisam uopšte protiv dokumentacije koda, već samo smatram da postoje vidovi dokumentacije (npr. opisna imena), koje ti uporno izbegavaš da vidiš.

Poređenje sa lekovima nije adekvatno jer si zanemario poređenje cene pucanja testa. U slučaju softvera, cena pucanja testa je 0, a u slučaju lekova... znaš i sam. Dakle, lekovi bi na taj način bili skuplji, jer bi razvoj plaćali mučenici kod Dr Mengelea po najvišoj ceni.

Takođe, naučni metod postaje religiozni obred ako se ne zna zašto se primenjuje. Tako se naučnim metodom dokazuje da "Bog ne postoji" primenom Okamove oštrice, bez obzira što ona nije primenljiva van područja merljivog makar u načelu. Sa druge strane, kada se razume svrha primene nekog naučnog metoda, onda se umesto vršenja religioznog obreda koristi pravi alat za datu stvar.

E tako ja nisam za izbacivanje dokumentacije već za analizu kako je treba raditi, zašto se radi i kako je najbolje da se radi. Opisna imena jesu vid dokumentacije. To je činjenica. Da li je taj vid dokumentacije dovoljan? Obično nije. Da vidimo, koliko i kakve dokumentacije još treba itd. Dakle, ja sam za racionalizaciju, a ne za slepo dokumentovanje svega samo da bi se imala dokumentacija. E, to je religiozni obred.
Citat:
mmix: I naravno da se Scrum nije dokazao, samo je pokazao da je trenutno jeftiniji jer sece coskove, izmedju ostalog i sa ovom dokumentacijom. Da li je ili nije deferred cost bubble ce tek vreme pokazati, imho jeste.

Eto, i sam priznaješ da je jeftiniji, makar i kratkoročno. Što se dugoročnih troškova tiče, treba uzeti u obzir sledeće:

Da li je za kuću dovoljan jedan automobil? Možda jeste, a možda i nije. Šta je pametnije, da se odmah kupe dva-tri komada ili da se za početak kupi jedan, a onda, ako se ukaže potreba kupi još, a ako se potreba ne ukaže ostati na jednom? Da, ako kupiš jedan, a ispostavi se da su potrebna dva, imaćeš jedan odloženi trošak. Da li bi ga izbegao kupovinom dva automobila odmah? Pa, sigurno da ne.

Upravo je u tomke suština lean metodologija - da se nešto radi samo ako se za time ukaže potreba, a ne da se nešto radi zato što će možda biti potrebe za time.

Naravno, postoji mogućnost da je nešto jeftinije uraditi odmah. No, tu se postavljaju sledeća pitanja:

1. Kolika je verovatnoća da će to što se ne bi eventualno radilo naknadno biti potrebno?
2. Kolike uštede mogu biti ako se to uradi odmah?
3. Koliko košta vreme koje će proteći do trenutka kada to bude trebalo da se radi ako dođe do toga?

Što se tačke 3 tiče, često je jeftinije dati 105 dinara za godinu dana, nego 100 dinara odmah, jer je vreme novac. U protivnom krediti ne bi postojali.

Dakle, bez analize ove tri tačke se ne može tvrditi šta je bolje. Naravno, tu analizu nije lako napraviti, a ono za šta se ja zalažem je zlatna sredina, koja se određuje na osnovu intuitivne procene koji bi deo dokumentacije čemu služio, odnosno koji delovi dokumentacije najverovatnije neće imati svrhu.
[ Mihajlo Cvetanović @ 27.07.2012. 15:53 ] @
Recimo da praviš kuću i sa kućom i garažu. Garaža je maltene sastavni deo kuće i jednom kad se napravi mnogo bi koštalo da se proširuje. Da li napraviti garažu za jedna ili za dvoja kola?
[ Nedeljko @ 27.07.2012. 17:02 ] @
Problem je u onome "mnogo". Kada budeš konkretniji, onda ćeš dobiti realan odgovor. Moraš prvo da odgovoriš na ova tri pitanja:
Citat:
Nedeljko: 1. Kolika je verovatnoća da će to što se ne bi eventualno radilo naknadno biti potrebno?
2. Kolike uštede mogu biti ako se to uradi odmah?
3. Koliko košta vreme koje će proteći do trenutka kada to bude trebalo da se radi ako dođe do toga?

Jasno je da ako to "mnogo" teži beskonačnosti, da je bolje uložiti odmah. Međutim, beskonačnost i realnost obično ne idu zajedno.
[ Nedeljko @ 27.07.2012. 20:36 ] @
Da bi nešto bilo upotrebljivo, mora se napraviti kvalitetno. Ako se nešto ne pravi kvalitetno, onda ga nema smisla ni praviti, jer neće biti upotrebljivo. A da bi se nešto kreativno kvalitetno napravilo mora biti jasno zbog čega se pravi. Iz motivacije proističu ideje o tome kako nešto kreativno treba raditi i tek onda se stvaraju preduslovi za kvalitetan kreativni rad.

Isto važi i za dokumentaciju. Ako neko piše dokumentaciju da bi mogao nekome da izađe na oči, na šta ta dokumentacija može da liči? Napraviće nešto čisto da toga ima, a to onda ne služi ničemu.

E, to je ono o čemu pričam. Ako ne znam svrhu dodatnog dokumentovanja nekog dela koda, onda to neću ni raditi.
[ Mister Big Time @ 20.08.2012. 12:49 ] @
Opanak varijanta, lokalni sleng. :)