Codificați și remediați

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Codul și remedierea este o practică foarte obișnuită în dezvoltarea de software, nu este considerată un model real de dezvoltare de software .

Este comparabil cu un model iterativ care alternează în două faze și este aproape total lipsit de organizarea procesului. De fapt, munca dezvoltatorilor începe fără ca aceștia să aibă o idee detaliată despre ce ar trebui să facă programul și cum ar trebui să fie implementat [1] . În consecință, este un model în care software-ul se adaptează progresiv la ceea ce dorește designerul său. Practic, scopul este să înțelegeți aproximativ care va fi răspunsul final al software-ului și să încercați în mod repetat să generați cod și să corectați erorile: dacă complexitatea este scăzută și experiența programatorului este bună, atunci aplicația va fi produsă într-un timp scurt.

Etape

Prima fază este în esență codificarea ( codul ), uneori precedată de o diagramă foarte elementară pentru a schematiza complexitatea problemei și o soluție primordială; apoi trecem la faza de mini test care are scopul de a stabili dacă programul funcționează corect și îndeplinește cerințele (aproape sigur nu sunt specificate în mod explicit într-un document). În caz contrar, revine la codificare pentru a remedia erorile sau tulburările. Ultimul pas este să ieșiți dacă programul îndeplinește cerințele.

Contextele în care este folosit

Modelul Code and Fix este adesea folosit atunci când aveți puțin timp pentru dezvoltarea software-ului . În astfel de situații, vă puteți gândi la economisirea timpului prin faptul că nu parcurgeți toate fazele de dezvoltare software. Cu toate acestea, în general, acest lucru nu pare a fi adevărat, deoarece, în majoritatea cazurilor, rezultatele dorite nu vor fi atinse și nici nevoile lor nu vor fi satisfăcute [1] . Figura proiectantului-programator coincide de obicei cu cea a utilizatorului final. Codul și corecția acordă foarte mult ingineriei procesului, atât de mult încât este aplicat în contexte în care numărul de linii de cod care trebuie produse nu depășește 1500. Este cel mai simplu mod de a dezvolta software, dar și cel mai scump . Din acest motiv, este de obicei folosit de companiile nou-născute [ fără sursă ] .

argumente pro şi contra

Acest model vă permite să obțineți rezultate într-un timp mai scurt, deoarece faza de proiectare nu este realizată, dar tocmai din acest motiv necesită o mulțime de lucrări de întreținere [1] În ciuda acestui fapt, dacă este utilizat pentru proiecte foarte mici, care nu implică lucrări majore riscuri pentru organizație, se dovedește a fi o abordare bună. De fapt, deoarece nu necesită investiții inițiale mari, proiectul poate fi ușor abandonat dacă nu se obține rezultatul dorit [2] .

Notă

  1. ^ a b c Gunther Lenz, Thomas Moeller, .NET-A Complete Development Cycle, Addison-Wesley Professional, 2003, pp. 26-27
  2. ^ Eric J. Brown, William A. Yarberry Jr., CIO eficient: Cum să obțineți un succes remarcabil prin alinierea strategică, managementul financiar și guvernanța IT , CRC Press, 2008, pp. 65-67

Bibliografie

  • ( EN ) Gunther Lenz, Thomas Moeller, .NET-A Complete Development Cycle , Addison-Wesley Professional, 2003. ISBN 978-0-321-16882-5
Informatică Portal IT : accesați intrările Wikipedia care se ocupă cu IT