![]() |
Chirurgia endoscopică a hipofizei
"Standardul de aur" în chirurgia hipofizară îl reprezintă endoscopia transnazală transsfenoidală. Echipa NeuroHope este antrenată în unul din cele mai mari centre de chirurgie a hipofizei din Europa, Spitalul Foch din Paris, centrul în care a fost introdus pentru prima dată endoscopul în chirurgia transnazală a hipofizei, de către neurochirurgul francez Guiot. Pe lângă tumorile cu origine hipofizară, prin tehnicile endoscopice transnazale pot fi abordate numeroase alte patologii neurochirurgicale. www.neurohope.ro |
Baze de date embedded – exercitiu practic (pentru programatori mid-level)
Last Updated: Oct 10 2018 14:21, Started by
jegmihai
, Sep 07 2018 22:27
·
0

#181
Posted 07 October 2018 - 11:15

Dacă făceam TDD de la ĂŽnceput, pe lângă celelalte beneficii pe care presupun că le-ar aduce, aș fi avut un cod 100% testabil? OK. Scopul unei suite de teste nu e test coverage de 100%. Unul dintre scopuri este identificarea părții din cod care crează probleme. Exemplu, pentru feature "adăugare contact" ai o serie de teste: 1. Unul sau câteva acceptance tests. Acestea testează toată aplicația prin exersarea UI, simularea de clicuri și de apăsări de taste. Când aceste teste trec, îi spui lui PO că e gata feature. Te ajută să păstrezi direcția generală atunci când dezvolți. 2. Teste de integrare a diferitelor layere/plugins, în diferite combinații. Un test ar fi faptul că apelarea lui addContact într-adevăr crează o intrare în baza de date. Ușor de făcut in-memory cu sqlite. 3. Unit tests. Acestea testează metodele publice. Dacă testul din 1 eșuează, el îți spune ceea ce ți-ar spune utilizatorul că nu e în ordine, dar nu îți spune tehnic ce e greșit : clicul nu a funcționat, datele nu au fost validate de domeniu, baza de date nu are o intrare, etc - știi doar la nivel abstract ce feature nu funcționează. Dar testele 2 și 3 te ajută să identifici exact partea de cod vinovată. Deduci asta din constelația de teste roșii. Problema e următoare : integrările dintre componente tind să fie testate cu mocks. Însă dacă ai un pod clar în arhitectură clar, îl poți folosi pe el în loc de mock, adică într-adevăr testezi punctul de integrare, fără a te baza pe "inside knowledge" prea mult. "mai testabil" în acest context înseamnă "suită de teste mai robustă, mai de încredere". Observer pattern descrisă anterior ar fi un astfel de pod în arhitectură. Nu e ca și cum asta ar fi marea salvare, e unul dintre pașii mici pe care îi poți face. Există numeroase abordări, unele în alte direcții, toate bune. Ceea ce vrei e o direcție coerentă, consistentă cu sine însăși, nu să umbli în zigzag. E abstract ce zic, dar cel mai eficient e dacă mă exprim în metafore. |
#182
Posted 07 October 2018 - 13:36

Cât de abstractă trebuie să fie interfața IObserver?
Eu am gândit-o așa, dar nu mă ajută foarte mult. class IObserver { public: virtual ~IObserver() = default; virtual void update() = 0; }; |
#183
Posted 07 October 2018 - 14:05

Nu mă ajută în sensul că pot exista 3 moduri diferite prin care state-ul poate fi schimbat, și nu doar una.
|
#184
Posted 10 October 2018 - 14:21

Din păcate timpul nu îmi mai permite să lucrez atât de des la proiect.
|
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users