Why Writing Software is not Like Engineering [Romanian]
De ce de ce scrierea software-ului nu seamănă cu ingineria
Terence Parr [autor de ANTLR parser generator etc ..]
Acest articol a apărut pe reddit și news.ycombinator.com
Оn timp ce talentul meu se bazează pe software, studiile mele universitare au fost inginerie de calculatoare (proiectarea şi construirea de computere digitale). Mereu mi-a admirat o observație: ingineria de calculatoare părea mai simplă decвt informatica (crearea de software). Există un set de reguli de proiectare tehnică pentru a urmări proiecte de inginerie care sunt mai susceptibile pentru lucru decвt proiectele software. Da, există unele eșecuri spectaculoase de inginerie, dar, empiric, software-ul de оncredere și util este mult mai dificil pentru creare. Pentru a ilustra idea mea, luaţi оn considerare sondele spațiale uimitoare pe care le vom trimite оn оntreg sistemul solar. Nave spațiale оnsuşi funcționează extrem de bine, de multe ori оn diferite teste оn timpul vieții de proiectare. Software-ul de control, pe de altă parte, trebuie să fie оn mod constant optimizat și оnţeles pentru a menține misiunea оmpreună. Eu nu оncerc să spun că este ușoară ingineria, nu este aşa. Scopul meu este pur și simplu de a explica de ce crearea software-ului este mai grea decоt proiecte de construcții fizice, оn general, și de ce "inginerie de software" este un termen nepotrivit.
Revista The Economist (27 noiembrie 2004, p. 71.) Citează estimările grupului Standish că
"… 30% din toate proiectele software sunt anulate, aproape jumătate cheltuie mai mult din buget decоt era planificat, 60% sunt considerate eșecuri de către organizațiile care le-au inițiat, și 9 din 10 sunt create prea tоrziu."
Articol continuă să sublinieze faptul că, deși cвteva proiecte mari de infrastructură sunt finalizate la timp şi bugetul acoperă totul, veți obține, de obicei, nu aceea оn sfоrşit. Trebuie să vă introduceți оn “оmpărăţia” de software (sau militară), оn scopul de a cheltui miliarde și de a nu primi nimic pentru aceasta. Cel mai important motiv pentru aceste cheltuieli cumplite constă оn aceea că, оn timp ce o clădire parţial finalizată sau un proiect de infrastructură cu defecte poate fi оncă utlizat, software-ul util, fie lucrează sau nu. Deoarece a obține un software corect este diabolic de dificil, de multe ori ajungem cu nimic (de exemplu, FBI Dumps Botched Computer Overhaul, F.B.I. Faces New Setback in Computer Overhaul).
De ce este scrierea software-ului nu seamănă cu inginerie? Răspunsul constă оntr-o singură diferență fundamentală cu ample ramificații: inginerie este constrвnsă de lumea reală, fizică și software-ul nu este astfel. Оn timp ce evident, aceasta este diferența crucială care explică de ce dezvoltarea de software este mai grea. Următoarele cвteva secțiuni studiază aceste ramificații.
Componente inginerice existente оn lumea reală
Proiectele de inginerie fizice sunt mai ușor de a vizualiza și, prin urmare, mai ușor de a construi.Şi chiar puteți atinge de fapt, componentele și produsul final cu mвinile sale. Оn continuare scăpăm de viziunea newtonian a lumii fizice pe care o experimentăm оn viața de zi cu zi, şi care e mai dificil de proiectat. Fizica cuantică este dificilă, deoarece particulele nu se comportă la fel ca pietre. Teoria corzilor, metoda cea mai promițătoare de modelare a fizicii cuantice, este greu de оnțeles оn primul rвnd pentru că se ocupă cu șase sau șapte dimensiuni suplimentare, dincolo de cele trei dimensiuni spațiale obișnuite. Imaginați-vă că оncercaţi să proiectaţi și să construiţi o casă pe o varietate Calabi-Yau Manifold (imaginea din dreapta este o proiecție 3-D).
Software-ul nu are nici o concepţie de dimensiune. S-ar putea spune că nu există linii оn care să se culorere. Cel puțin pentru proiecte de inginerie pe nivel cuantic, nimeni nu așteaptă să găsească structuri care "sfidează legile fizicii." Aceasta limitează ceea ce se poate construi fizic și modul оn care se poate construi, dar cel puțin oferă o lume bine definită, оn care putem lucra. Lumea eterică a software-ului nu are acest lux, dar instrumentele noastre devin tot mai bune. Programare obiect orintată a fost inventată pentru a face scrierea software-ului mai familiară pentru creierul nostru a culegătorilor şi vвnătorilor. Adică noi am inventat componente software, cu proprietăți și comportament ce au obiecte din lumea reală.
Componentele ingineriei interacționează оntr-un mod mai previzibil
Ingineria este mai puțin riscantă decвt inginerie de software, deoarece prezintă mai puține interacțiuni constitutive a componentelor. Оn timp ce modificări minore a unei părţi din structura unui automobil poate afecta cu ușurință robustețea accidentului de alta, ar fi neobișnuit pentru un defect de proiectare оn lumina cupolei să provoace tarabe intermitente a motorului. Оntr-un proiect de construcţii de case, va trebui să lucrăm destul de greu pentru a face o toaletă de fiecare dată cвnd cineva a sunat la ușă.
La crearea software-ului, pe de altă parte, trebuie să fiţi hipervigilant pentru a evita aceste interacțiuni nedorite. Unul din motivele pentru mulţi programatori, cum ar fi programare funcțional, pur şi simplu este lipsa de efecte secundare – nu există nici o cale pentru a spăla WC accidental atunci cвnd sună soneria.
Situația este și mai gravă оn limbi cum ar fi C + + fără protecție intrinsecă a supraоncărcăriid e buffer. Un fragment de cod distanțiat poate mult mai ușor modifica оn mod neintenționat comportamentul a toatei aplicaţii. De fapt, aceasta este slăbiciunea specială, pe care mai mulţi hackeri exploateză. Prin provocarea de supraоncărcarea a unui buffer, un atacator poate forța programul pentru a deschide o gaură оn apărarea sa.
Ingineria a avut mai puțini schimbări fundamentale de proiectare оn timpul său de dezvotare
Motivul final că de a obține software-ul corect este mult mai dificil decоt a se ocupa cu ingineria se referă la schimbările de design оn curs de dezvoltare a acestor ştiinţe. Lumea fizică nu este la fel de maleabilă ca şi lumea fără substanţă de software și, оn consecință, clienții au așteptări mai mici. Congresul nu merge la NASA la jumătate printr-o tragere din puşcă spre lună, cerоndu-le оn loc de asta să meargă pe Marte. Majoritatea proiectelor de inginerie sunt capabile de a utiliza efectiv metoda de cascadă a proiectării: adică, a determina cerințele funcționale, proiecta, implementa, testa. Pentru majoritatea proiectelor de software, aceasta este o reţetă contra dezastrului.
Din păcate, modificările de design оn curs de dezvoltare se оntвmpla оn software-ul tot timpul – de fiecare dată cвnd clientul ia o privire la software-ul care rulează. De fapt, metoda de dezvoltare agilă de software este un răspuns direct la cerințele de proiectare оn continuă schimbare. Programatorii sunt rugați să perceapă schimbarea ca pe o oportunitate. Cu toate acestea, modificările constant de design оmpiedică eforturile de dezvoltare şi dezvoltatorii trebuie constant să modifice software-ul pentru a preveni ca aceasta să devină o harababură оncвlcită fără bază.
S-ar putea оntreba de ce, dacă e atоt de greu de a obţine un software-ul corect, avioanele nu cad din cer. Se pare că ei fac ocazional software-ul rău care este adesea vinovat (de exemplu, uitaţi-vă la fly-by-wire Airbus 320 crash). Оn majoritatea cazurilor, cu toate acestea, software-ul de control al hardware-ului pentru avioane, automobile, și dispozitive medicale funcționează conform așteptărilor. Motivul pentru fiabilitate sporită este triplu. Оn primul rвnd, există vieți оn acest joc și oamenii sunt probabil mai atenți. Оn al doilea rвnd, de la dezvoltatori de software nu li se cere să-și modifice software-ul fundamental оn timpul dezvoltarii. De exemplu, un avion cu elice nu devine un avion reactiv оn mijlocul de dezvoltare. O echipa de ingineri va оncepe, оn timp ce o echipa de software de obicei cere să facă schimbări radicale оn curs de dezvoltare. Și, оn cele din urmă, astfel de proiecte software lucrează cu dispozitive de control fizic și оncep să cвștige unele dintre avantajele oferite de proiecte de inginerie fizică.
Este oare dezvoltarea de software o știință?
Deci, dacă dezvoltare de software nu este la fel ca ingineria, ce oare ea este? Noi numim o disciplina informatică, dar eu nu sunt sigur că acest termen este complet adecvat. Poate vă amintiți gluma veche, "Dacă o disciplină are" știință " оn titlu său, probabil că ea nu este aşa." Оn opinia noastră, știința este ceea care descoperă și descrie fenomenele fizice folosind o anumită metodă. Merriam-Webster descrie metoda științifică astfel:
"Principii și proceduri pentru urmărirea sistematică a cunoștințelor implică recunoașterea și formularea unei probleme, colectarea de date prin observație și experiment, precum și formularea și testarea ipotezelor."
Această descriere are o impresie de depanare mai mult decвt actul de scriere a software-ului. Informatica se ocupă cu construirea lucrurilor cum ar fi inginerie, dar fără luxul unui set de instrumente și componente luate din lumea fizică. Nimeni nu a elaborat proceduri fiabile și eficiente pentru construirea de fragmente mari de software cum inginerii au făcut pentru proiectul fizic. Așa cum Alan Kay crede, software-ul este "inginerie de un fel … dar se face prin forţa brută". O conversaţie cu Alan Kay:
"Daca vă uitaţi la software-ul de astăzi, prin prisma istoriei de inginerie, e cu siguranță un fel de inginerie – dar e un fel de inginerie pecare oamenii fără conceptul de arcă au făcut. Majoritatea software-ului seamănă foarte mult la un piramida egipteană cu milioane de cărămizi stivuite unul pe altul, fără integritatea structurală, construite prin forţă brută a miilor de sclavi. "
Scrierea software-ului este mai mult o artă decat o disciplină de inginerie
Scrierea software-ul foarte mult seamănă cu scrierea romanelor. Scrierea romanului artistic este de asemenea un act de creație оntr-un mediu fără restricții și eteric, cu cвteva reguli de construcție bine stabilite. Stim scrieri bune atunci cвnd le vedem, dar este greu să le оnvățăm. Experiența de scriere și feedback-ul de la scriitori mai buni (programatori) este mijlocul cel mai de оncredere pentru a deveni un scriitor bun (codificator). Fără un proces bine оnțeles, software-ul va rămвne mai mult o artă decвt o știință. Termenul "inginerie software-ului" este mai mult decвt un obiectiv decоt redarea faptului actual de scriere a software-ului.
By Terence Parr