![]() |
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 |
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