Programuotojai daug laiko praleidžia derindami, o ne rašydami kodą. Jūs tikriausiai turėjote šiek tiek mokymų mokytis kalbos ar pagrindų, bet kaip išmokote pašalinti savo programinės įrangos defektus?
Kai įsimylėjote programavimą (arba bent jau nusprendėte, kad tai yra atlyginanti karjera), tikriausiai galvojote apie tai kaip apie kūrybinę veiklą. Jūs suprojektuosite puikią programinę įrangą, parašysite kodą ir pūkas!- tai puikiai veiktų pirmą kartą.
Taip. Teisingai.
Realiame pasaulyje jūs praleidote daug laiko derindami kodą, o ne rašėte naujus dalykus. Esu įsitikinęs, kad galėčiau išsiaiškinti neaiškią procentą kūrėjo laiko, skirto defektams šalinti, o ne kurti naujas funkcijas, bet abejoju, ar reikia išgirsti skaičių. Jūs galite per lengvai vaizduoti dienas, kurias praleidote ieškodami klaidos iš pragaro, ir jos poveikį jūsų projekto tvarkaraščiui.
Dabar yra daugybė būdų, kaip programuotojai gali išmokti ir išmokti naujų programinės įrangos įgūdžių, nesvarbu, ar tai skaityti knygą, ar lankytis technologijų konferencijoje, ar lankytis tokiose svetainėse kaip „JavaWorld.com“. (Džiaugiuosi, kad darote pastarąjį.) Tačiau dažniausiai tai skiriama įrankiams, pvz., Kalboms ar sistemoms, o ne metatechnikoms, tokioms kaip „Kaip rasti tą klaidą per dvi valandas, o ne dvi dienas“. Kalbos gali atsirasti ir atsirasti, taip pat atsiras ir IDE derintojams, tačiau galimybė suprasti, po kuria uola slepiasi jūsų klaida, liks visam laikui.
Didelė mokymosi derinti įgūdžių dalis, žinoma, yra patirtis. Tai gali būti jūsų pačių patirtis arba galimybė būti „Žiogais“ pagrindinio programuotojo kojose. Taip pat įtariu, kad kai kurie žmonės turi įgimtą talentą spręsti gedimus (taip pat svarbu sutvarkyti sugedusį automobilį kaip netinkamai veikiančią programą), o be mūsų tai gali tik pavydėti.
Tačiau kai kurie to galima išmokti. Pavyzdžiui, vienas mano pažįstamo pagrindinis programuotojas turėjo aksiomą: jei jūs (santykinai) ilgai ieškojote klaidos ir jos nerandate, jis pasakė: „Jūs ieškote ne toje vietoje“. Akivaizdžiai skambantis, bet tikrai teisingas ... ir kaip dažnai sugaišote laiką ieškodamas XYZ modulio, kai problema kilo visai kitur?
Aš paklausiau kelių kūrėjų, kaip jie išmoko ar tobulino derinimo įgūdžius. Stebėtinai daug jų kalbėjo apie savo IDE derintuvo meistriškumą ar kitas žinias apie įrankius, tačiau labiausiai norėjau sužinoti jų patarimus, kaip pagerinti gebėjimą taisyti klaidas. Čia pateikiama trumpa jų atsakymų santrauka.
- Būkite drausmingi. Derinimas yra procesas, sakė vienas kūrėjas, o ne atsitiktinių įvykių serija. Negalima atsitiktinai pakreipti rankenėlių; sekite kodo vykdymo procesą. Kaip ir taisydamas vejapjovę, sakė jis. Ar A dalis gauna reikiamą informaciją? Kaip apie produkciją? Jei viskas gerai, eik toliau.
- Norėdami patobulinti savo įgūdžius, derinkite kitų, o ne savo kodus. Lengviau bus pastebėti kito žmogaus prielaidų trūkumus nei savo. Tai galite padaryti kaip tarpusavio kodo peržiūros ir tarpusavio derinimo dalį. Jūs išsiugdysite gebėjimą greičiau atpažinti dažniausiai pasitaikančias defektų priežastis, pažadėjote vieną kūrėją ir išmokysite atpažinti (ir atsisakyti) savo blogą vystymosi praktiką.
- Apsimesk, kad esi kompiliatorius. Prieš paspausdami mygtuką Sudaryti suraskite ir ištaisykite kuo daugiau klaidų. Nors dauguma šiuolaikinių IDE apima integruotus derintuvus (pvz., „Visual Studio“ „Intellisense“), iš jų automatizavimo sužinosite mažiau nei sąmoningai nagrinėdami procesą. (Tuo pačiu būdu jūs niekada neišmoksite rašybos taisyklingai, pasikliaudami rašybos tikrintuvu, kuris atliks visą darbą.)
- Išmokite ištaisyti klaidas kuo ankstyvesniame kūrimo proceso etape. Tai gali reikšti ką nors įforminto, pvz., Bandomąjį kūrimą. Tai taip pat reiškia laiko skyrimą dizaino derinimui, o ne kodavimui.
- Derinti lengviausia, kai gali galvoje laikyti visą sistemą. Nesuklyskite sutelkdami dėmesį tik į vieną programos dalį. Atkreipkite dėmesį į modulių tarpusavio ryšius. Perskaitykite kodą keliais abstrakcijos lygiais, patarė vienas programuotojas. „Rasti klaidą yra sunkiausia ir reikia aiškiai suprasti, ką daro keli kodo fragmentai“, - sakė ji.
- Manau, kad to paties patarimo dalis yra kažkieno pasiūlymas: gerai supraskite sistemą vienu lygiu žemiau, nei jūs dirbate. „Jei derinate C sistemos lygio programą, tai padeda sužinoti apie surinkimą ir kažką apie OS“, - paaiškino pagrindinis sistemos programinės įrangos inžinierius. "Jei derinate J2EE programą, tai padeda ką nors sužinoti apie" Java "gijas, RMI ir GC." Daugeliu atvejų jis nurodė, kad klaidų pranešimai gaunami iš vieno lygio. „Jei galite suprasti, ką tai reiškia, tai padės išsiaiškinti, kas negerai jūsų abstrakcijos lygiu“, - paaiškino jis.
Keli kūrėjai taip pat rekomendavo papildomų išteklių. Tarp jų yra Davido Agano knyga „Derinimas“, žadanti devynias būtinas taisykles, ir „Kodėl nepavyksta programos: sistemingo derinimo vadovas“, kuri netrukus bus išleista antruoju leidimu. Pastarąjį rekomendavęs kūrėjas sako, kad jis moko sistemingo derinimo su daugeliu praktinių pavyzdžių. Kitas pasiūlė internetinę esė „Dešimt labai efektyvių programinės įrangos testuotojų įgūdžių“.
Man patinka visi tie atsakymai, bet įtariu, kad išmintimi galima pasidalinti dar daugiau. Kaip įgijote derinimo įgūdžius? Kaip padėjai kitiems patobulinti savo?
Šią istoriją „Mokymasis ir jūsų derinimo įgūdžių tobulinimas“ iš pradžių paskelbė „JavaWorld“.
