Second Opinion
Folosind serviciul second opinion ne puteți trimite RMN-uri, CT -uri, angiografii, fișiere .pdf, documente medicale. Astfel vă vom putea da o opinie neurochirurgicală, fără ca aceasta să poată înlocui un consult de specialitate. Răspunsurile vor fi date prin e-mail în cel mai scurt timp posibil (de obicei în mai putin de 24 de ore, dar nu mai mult de 48 de ore). Second opinion – Neurohope este un serviciu gratuit. www.neurohope.ro |
UML in one-man project
Last Updated: Aug 21 2014 12:26, Started by
IonutYo
, Aug 20 2014 14:06
·
0
#1
Posted 20 August 2014 - 14:06
Am citit zilele astea ceva mai mult despre UML-uri si ma intrebam daca in practica chiar se fac tot felul de diagrame inainte de a incepe proiectul. Intr-un un proiect mic, dezvoltat de un singur om, ar avea sens sa realizez mai intai diagramele(activity, use case si class)?
Edited by IonutYo, 20 August 2014 - 14:09. |
#2
Posted 20 August 2014 - 14:29
Pai ce rost are daca tot tu detii si mintea care a conceput programul?! Alea se fac in firme cu multi oameni si pentru proiecte mari.
|
#3
Posted 20 August 2014 - 14:59
Plus ca pana te apuci de cod, te mai razgandesti de cateva ori legat de ce/cum anume vei face. Sau nu esti inca stapan pe tehnologii si realizezi ca trebuie o alta abordare.
|
#4
Posted 20 August 2014 - 15:12
daca e un proiect serios atunci orice planificare e buna.
o fi totul in mintea ta, dar peste 7-8 luni cand te va suna clientul si-ti va cere o modificare o sa vezi ce bine e sa ai ceva documentatie. |
#6
Posted 20 August 2014 - 16:58
Cu siguranta are sens sa documentezi arhitectura si design-ul. Intrebarea e: cat de detaliat? Pericolul e ca nu cumva sa scrii tone de diagrame si scheme si desene, insa design-ul (poate chiar arhitectura!) sa se modifice pe parcurs - iar documentatia sa nu fie mentinuta la zi.
|
#7
Posted 20 August 2014 - 20:21
Intrebarea defapt e ce avantaj ai daca folosesti UML in loc la limbaj natural sau o diagrama clasica.
Ca UML-ul a fost inventat in speranta ca din diagramele formale poti genera automat o parte din cod, ori realitatea faptelor demonstreaza ca (1) codul generat e trivial de scris si (2) UML-ul nu e suficient de "expresiv" pentru a exprima chestii mai complexe. Tot ce-a iesit utilizabil din UML au fost usecase-uri mult prea specializate. Edit: stiu, eu privesc lucrurile superficial, din perspectiva cuiva care lucra la proiecte cu 3-4-5 developeri, nu 300. E nais sa-ti pastrezi o documentatie a arhitecturii intr-un limbaj foarte formal pe care teoretic il intelege oricine cand nu esti "prieten" cu toti membrii echipei si tehnologiile se schimba de trei ori pe parcursul dezvoltarii. |
#8
Posted 21 August 2014 - 07:07
IonutYo, on 20 august 2014 - 14:06, said:
Am citit zilele astea ceva mai mult despre UML-uri si ma intrebam daca in practica chiar se fac tot felul de diagrame inainte de a incepe proiectul. Intr-un un proiect mic, dezvoltat de un singur om, ar avea sens sa realizez mai intai diagramele(activity, use case si class)? UML, daca e bun, e bun la comunicare, si cam atat. Dar daca ai ceva neclaritati cu privire la ce vei face, poti sa scrijelesti niste schite pe o fituica, nu e musai sa fie UML. |
#10
Posted 21 August 2014 - 12:26
sunt utile, nu conteaza dimensiunea proiectului
cel mai util mi se par daca dupa un timp, vrei sa intelegi o functionalitate, in loc sa te uiti pe cod, te poti uita peste diagrame ele iau insa timp si necesita mentenanta. daca schimba ceva in cod care schimba arhitectura sau flow-ul in aplicatie, trebuie sa schimbi si diagramele exista tool-uri care genereaza UML-urile pe baza codului scris, dar nu stiu cat de eficiente sunt eu as fi pentru diagrame care nu intra in detalii, ci sunt o vedere high level. depinde de proiect \ companie cred Edited by fuel, 21 August 2014 - 12:28. |
|
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users