Neurochirurgie minim invazivă
"Primum non nocere" este ideea ce a deschis drumul medicinei spre minim invaziv. Avansul tehnologic extraordinar din ultimele decenii a permis dezvoltarea tuturor domeniilor medicinei. Microscopul operator, neuronavigația, tehnicile anestezice avansate permit intervenții chirurgicale tot mai precise, tot mai sigure. Neurochirurgia minim invazivă, sau prin "gaura cheii", oferă pacienților posibilitatea de a se opera cu riscuri minime, fie ele neurologice, infecțioase, medicale sau estetice. 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