Cum să programați o coincidență
Să presupunem că Fred are sarcina de a scrie un program. Fred face un program, încearcă să o execute și pare să funcționeze. Fred scrie un alt fragment, încearcă să o înceapă și din nou totul funcționează. În această situație, mai sunt încă câteva săptămâni, dar brusc programul nu mai funcționează și, după ce a petrecut mai multe ore de reparare a defectului, Fred încă nu știe care este motivul. Fred poate petrece mult timp săpără în acest fragment, fără posibilitatea de a restabili programul. Și orice face, se pare că programul nu va funcționa corect.
Fred nu știe de ce programul nu reușește, pentru că nu știe de ce a lucrat la început. Părea doar să lucreze în condițiile unei "teste" limitate, care a fost condusă de Fred, dar aceasta a fost doar o coincidență. Fiind în robie de încredere falsă, Fred a căzut în uitare. Mulți intelectuali sunt familiarizați cu această imagine a lui Fred, dar îl cunoaștem mai bine. Nu ne bazăm pe coincidență, nu-i așa?
Cu toate acestea, uneori ne bazăm. Uneori este ușor să confundați un eveniment fericit cu o planificare specifică. Să luăm în considerare câteva exemple.
O implementare aleatorie este ceva ce se întâmplă doar pentru că programul este scris exact așa cum este scris. Încetezi să te bazezi pe o condiție de eroare sau limită nedocumentată.
Se pare că Fred face încercări disperate de a aduce ceva pe ecran. Dar aceste subrutine nu sunt concepute pentru a fi accesate în acest fel; deși par să funcționeze, în realitate este doar o coincidență.
Pentru a nu obține noi hituri, atunci când componenta este încă desenată, Fred nu încearcă să se întoarcă și să elimine cererile false. "Acum funcționează, o să lăsăm la asta ...".
Astfel de gânduri vă pot rătăci. De ce risti, strica ceea ce functioneaza? Deci, vă puteți gândi din mai multe motive:
• Programul nu funcționează cu adevărat, poate părea că funcționează.
• Condiția la care vă bazați nu poate fi decât un caz particular. În diverse situații (de exemplu, cu o rezoluție diferită a ecranului), programul se poate comporta diferit.
• Comportamentul nedocumentat se poate modifica odată cu lansarea unei noi versiuni a bibliotecii.
• Apelurile suplimentare și opționale încetinesc programul.
• De asemenea, apelurile suplimentare cresc riscul de a introduce noi defecte asociate acestor apeluri.
Când scrieți un program numit de alți dezvoltatori, principiile de bază ale modularizării clare și ascunderea implementării pentru interfețe simple, bine documentate pot fi utile. Un contract clar definit (a se vedea "Proiectarea contractelor") poate elimina neînțelegerile.
Pentru subrutinele pe care le apelați, se bazează numai pe comportamentul documentat. Dacă dintr-un anumit motiv nu puteți face acest lucru, atunci documentați în mod clar presupunerea dvs.
De asemenea, vă puteți întâlni cu un "context aleatoriu". Să presupunem că scrieți un modul de serviciu. Deoarece în acest moment scrieți un program pentru mediul grafic, ar trebui modulul să se bazeze pe interfața grafică existentă? Te bazezi pe utilizatorii vorbitori de limba engleza? Pe utilizatori înzestrați? Încă mai țineți cont de un context, a cărui prezență nu este garantată?
Coincidența poate fi înșelătoare la toate nivelurile - de la generarea de cerințe la testare. Testarea este în special plină de prezența legăturilor cauzale false și a coincidenței aleatoare a rezultatelor. Este ușor să presupunem că A solicită U, dar, așa cum se menționează în secțiunea "Debugging", nu presupune acest lucru, ci dovedește-o.
La toate nivelurile, oamenii lucrează ținând multe ipoteze în cap, dar acestea sunt rareori documentate și provoacă adesea contradicții între dezvoltatori. Ipotezele care nu se bazează pe fapte cunoscute pot otrăvi orice proiecte.
Sfat 44: Nu scrieți programe bazându-se pe coincidența circumstanțelor
Articole similare
Trimiteți-le prietenilor: