În curând vor lansa o versiune beta publică a browserului Netscape 6.0. Versiunea 5.0 nu a fost. Ultima actualizare majoră la 4.0 a fost acum trei ani. Trei ani este o perioadă foarte lungă de timp pe Internet. Și tot acest timp Netscape a fost lipsit de putere să urmărească scăderea rapidă a cotei de piață a browserului său.
Dar nu este prea presumptuos să îi criticăm pentru întârzierea îndelungată pe care au luat-o în mod deliberat?
După ce au luat o astfel de decizie, au făcut cea mai gravă greșeală strategică a tuturor posibililor pentru compania dezvoltatoare.
Ei au decis să rescrie codul de la zero.
Nu au fost primii care au făcut o astfel de greșeală. Borland a făcut același lucru, după ce la cumpărat pe Argo și încercând să o transforme în dBase for Windows, proiectul, condamnat de la început, a durat atât de mult încât, după lansare, nu a putut rezista competiției cu Microsoft Access. Au fost repetate, rescriind Quattro Pro de la zero, cu capabilități uimitor de mizerabile. Aceeași eroare a fost aproape făcută de Microsoft, încercând să rescrie Word din Windows de la zero, compania încearcă să nu-și amintească de cei răi de la naștere și a închis în curând proiectul Puramid. Din fericire pentru Microsoft, dezvoltatorii săi au continuat să lucreze cu codul vechi și puteau oferi clienților cel puțin ceva, astfel încât catastrofa financiară să nu se transforme într-una strategică.
Suntem programatori. Toți programatorii sunt arhitecți în inimă, doresc întotdeauna să distrugă vechiul la fund și să construiască ceva în schimb. Nu suntem atrași de îmbunătățirea treptată, cum ar fi repararea și defalcarea paturilor de flori.
Din exterior este invizibil, dar din acest motiv, programatorii vrem să ștergem vechiul cod și să începem din nou. Codul vechi pare rău rău pentru ei. Și cel mai interesant lucru este că cel mai probabil se înșală. Codul vechi pare să fie răsfățat din cauza legii fundamentale a programării.
Din acest motiv, este atât de greu să reutilizați codul și fiecare membru al echipei dvs. are propria versiune a funcției care separă o linie într-o serie de mai multe. Este mai ușor și mai plăcut să le scrieți decât să înțelegeți funcțiile altor persoane.
Consecința inevitabilă a acestui axiom este răspunsul oricărui programator la întrebarea despre codul pe care îl dezvoltă: "Este groaznic, mai presus de toate vreau să scuip pe el și să încep totul din nou".
De ce este teribil?
"Ei bine", spun ei, "uitați-vă la această funcție, necesită două pagini și majoritatea codului nu este necesar! Nu înțeleg de ce este nevoie de jumătate din apelurile API".
Înainte de lansarea noii versiuni a foii de calcul de la Borland pentru Windows presa a citat în mod constant declarații laudative Borland fondatorul Philippe Kahn (Philippe Kahn) beneficiază Quattro Pro pe Excel din faptul că el a fost rescris de la zero. Codul sursă este complet nou! Ca și cum ar putea să ruineze.
A considera că noul cod este mai bun decât cel vechi este ridicol prin definiție. Codul vechi este practicat de practică. A fost testat, a găsit o mulțime de glitches și le-a fixat. E în regulă. Nu se încurcă de la faptul că se află pe hard disk. Dimpotrivă! Program care, ruginind chiar și în garaj sunt Zhiguli vechi? Sau pe un ursuleț de pluș din cârpe vechi, care material îl face dezgustător?
Să revenim la funcția de două pagini. Ea doar trage fereastra, dar din motive necunoscute este acoperita cu un numar de cod incomprehensibil, stiu. Și voi explica de ce: acestea sunt reparații de bug-uri. Aici este această bucată de cod stabilește glitch-ul care a apărut în Katie, atunci când rulați programul pe un computer fără Internet Explorer. Acolo se rezolvă o eroare care apare în condițiile unei lipse de memorie. Un alt remediază o eroare care apare atunci când un utilizator elimină brusc o dischetă cu un fișier pe care rulează programul nostru. Și acest apel îngrozitor pentru LoadLibrary asigură că programul funcționează pe versiunile anterioare ale Windows 95.
Pentru a detecta fiecare dintre ele, a durat multe săptămâni pentru a lucra cu programul în practică. Este posibil ca programatorul să petreacă câteva zile pentru a le replica în laborator și pentru a le corecta. Cel mai probabil pentru corecție trebuia să scriu doar câteva linii de cod, sau chiar să schimb doar câteva caractere, dar aceste simboluri au avut mult timp și de lucru.
Refuzând codul vechi și începând să scrie unul nou de la zero, pierdeți toate aceste informații. Pierdeți toate bug-urile acumulate și mulți ani de programare.
Împreună cu codul, renunțați la poziția de lider pe piață, dați câțiva ani concurenților, credeți-mă, acest lucru este foarte mult în domeniul dezvoltării programelor.
De câțiva ani vânzarea versiunii vechi a codului pentru lipsa unui nou, imposibilitatea de a face schimbări serioase și de a răspunde cerințelor pieței, vă conduceți într-o situație foarte periculoasă. Cu același succes puteți închide compania pentru acest moment.
Și, în același timp, cheltuiți o sumă imensă de bani pentru scrierea codului deja scris.
Există o alternativă? Se pare că nimeni nu contestă o evaluare scăzută a calității vechiului cod Netscape. Știi, poate a fost rău, dar a funcționat perfect pe un număr mare de computere.
Când programatorii numesc codul oribil (ca de obicei), cel mai probabil este cauzat de unul din trei motive:
Prima este legată de arhitectură. Codul poate avea o structură incorectă. Codul de rețea, de exemplu, poate atrage independent ferestre, deși aceasta este o chestiune a codului GUI. Astfel de neajunsuri pot fi corectate una câte una, mișcare atentă și restructurare a codului, schimbarea interfețelor. Aceasta este prin forțele unuia, lucrand cu atenție și reverificând toate schimbările, programatorul. Și în vechiul cod puteți schimba foarte serios arhitectura. În Juno, am petrecut odată câteva luni redând arhitectura: pur și simplu mișcați codul de la loc la loc, curățați-l, creând clase de bază semnificative și interfețe clare între module. Am lucrat cu cea mai mare parte a codului, fără să facem noi greșeli și să nu abandonăm vechile dezvoltări.
Un alt motiv este ca programatorii considera codul corupt fara speranta - ineficienta sa. Se spune că codul pentru desenarea paginilor în Netscape a fost foarte lent. Dar aceasta se referă la o parte foarte mică a proiectului. Pentru a corecta, nu este nevoie să rescrieți totul. Când se optimizează viteza, 1% din lucrare aduce 99% din rezultate.
Și al treilea motiv - codul poate părea urât. Lucram la un proiect cu tipul de date FuckedString (FuckedLine). Într-un alt proiect conform acordului inițial, numele funcțiilor au început cu o subliniere, dar mai târziu au trecut la cele mai comune "m_". Ca rezultat, jumătate dintre funcții au început cu "_", iar cealaltă cu "m_", părea îngrozitor. Sincer, astfel de probleme sunt rezolvate în cinci minute printr-un script banal în Emacs, și nu prin rescrierea codului de la zero.
Nu există niciun motiv să se creadă că munca începută din nou va fi făcută mai bine decât ultima oară, este foarte important să nu uităm de ea. Cel mai probabil va fi făcut de o altă echipă, astfel încât nici măcar nu veți fi "mai experimentați". Veți repeta majoritatea greșelilor făcute ultima dată și adăugați altele noi.
YARPP alimentat de AdBistro
Articole similare
Trimiteți-le prietenilor: