Kama wanasema, ikiwa huoni aibu na nambari yako ya zamani, basi haukua kama programu - na ninakubaliana na maoni haya. Nilianza programu kwa ajili ya kujifurahisha zaidi ya miaka 40 iliyopita, na kitaaluma miaka 30 iliyopita, kwa hiyo nina makosa mengi. mengi ya. Kama profesa wa sayansi ya kompyuta, ninawafundisha wanafunzi wangu kujifunza kutokana na makosa—yao, yangu, na ya wengine. Nadhani ni wakati wa kuzungumza juu ya makosa yangu ili nisipoteze unyenyekevu wangu. Natumaini watakuwa na manufaa kwa mtu.

Nafasi ya tatu - mkusanyaji wa Microsoft C

Mwalimu wangu wa shule aliamini kwamba Romeo na Juliet hawangeweza kuchukuliwa kuwa janga kwa sababu wahusika hawakuwa na hatia mbaya - walitenda kijinga, kama vijana wanapaswa. Sikukubaliana naye wakati huo, lakini sasa ninaona nafaka ya busara kwa maoni yake, hasa kuhusiana na programu.

Kufikia wakati nilipomaliza mwaka wangu wa pili huko MIT, nilikuwa mchanga na sina uzoefu, maishani na katika programu. Katika majira ya joto, nilijihusisha na Microsoft, kwenye timu ya mkusanyaji C. Mwanzoni nilifanya mambo ya kawaida kama usaidizi wa wasifu, na kisha nilikabidhiwa kufanya kazi kwenye sehemu ya kufurahisha zaidi ya mkusanyaji (kama nilivyofikiria) - uboreshaji wa nyuma. Hasa, ilinibidi kuboresha nambari ya x86 ya taarifa za tawi.

Nikiwa na nia ya kuandika msimbo bora wa mashine kwa kila kesi inayowezekana, nilijitupa kwenye dimbwi la maji. Ikiwa msongamano wa usambazaji wa maadili ulikuwa juu, niliwaingiza meza ya mpito. Ikiwa walikuwa na mgawanyiko wa kawaida, niliitumia kuifanya meza kuwa ngumu zaidi (lakini tu ikiwa mgawanyiko unaweza kufanywa kwa kutumia mabadiliko kidogo) Wakati maadili yote yalikuwa nguvu ya mbili, nilifanya uboreshaji mwingine. Ikiwa seti ya maadili haikukidhi masharti yangu, niliigawanya katika hali kadhaa zinazoweza kuboreshwa na kutumia nambari iliyoboreshwa tayari.

Ilikuwa ni ndoto mbaya. Miaka mingi baadaye niliambiwa kwamba mtayarishaji programu ambaye alirithi msimbo wangu alinichukia.

Somo limeeleweka

Kama David Patterson na John Hennessy wanavyoandika katika Usanifu wa Kompyuta na Usanifu wa Mifumo ya Kompyuta, moja ya kanuni kuu za usanifu na muundo ni kufanya mambo kufanya kazi haraka iwezekanavyo.

Kuharakisha kesi za kawaida kutaboresha utendakazi kwa ufanisi zaidi kuliko kuboresha kesi nadra. Kwa kushangaza, kesi za kawaida mara nyingi ni rahisi kuliko nadra. Ushauri huu wa kimantiki unadhania kuwa unajua ni kesi gani inachukuliwa kuwa ya kawaida - na hii inawezekana tu kupitia mchakato wa kupima kwa uangalifu na kipimo.

Katika utetezi wangu, nilijaribu kubaini taarifa za tawi zilionekanaje kimatendo (kama vile matawi mangapi yalikuwepo na jinsi zile za kudumu zilisambazwa), lakini mnamo 1988 habari hii haikupatikana. Walakini, sikupaswa kuongeza kesi maalum wakati mkusanyaji wa sasa hakuweza kutoa nambari bora kwa mfano bandia niliokuja nao.

Nilihitaji kumwita msanidi uzoefu na, pamoja naye, fikiria juu ya kesi za kawaida na kushughulikia haswa. Ningeandika nambari kidogo, lakini hiyo ni jambo zuri. Kama mwanzilishi wa Stack Overflow Jeff Atwood aliandika, adui mbaya zaidi wa programu ni mpangaji programu mwenyewe:

Najua una nia nzuri, kama sisi sote. Tunaunda programu na tunapenda kuandika msimbo. Hivyo ndivyo tunavyoumbwa. Tunafikiri kwamba tatizo lolote linaweza kutatuliwa kwa mkanda wa kuunganisha, crutch ya nyumbani na pinch ya kanuni. Kadiri inavyotia uchungu waimbaji kuikubali, msimbo bora zaidi ni msimbo ambao haupo. Kila mstari mpya unahitaji utatuzi na usaidizi, unahitaji kueleweka. Unapoongeza nambari mpya, unapaswa kufanya hivyo kwa kusita na kuchukiza kwa sababu chaguzi zingine zote zimeisha. Watengenezaji programu wengi huandika msimbo mwingi, na kuifanya kuwa adui yetu.

Ikiwa ningeandika nambari rahisi zaidi ambayo inashughulikia kesi za kawaida, ingekuwa rahisi kusasisha ikiwa ni lazima. Niliacha fujo ambayo hakuna aliyetaka kushughulika nayo.

Nafasi ya pili: matangazo kwenye mitandao ya kijamii

Nilipokuwa nikifanya kazi kwa Google kwenye utangazaji wa mitandao ya kijamii (unakumbuka Myspace?), niliandika kitu kama hiki katika C++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

Watayarishaji wa programu wanaweza kuona kosa mara moja: hoja ya mwisho inapaswa kuwa j, sio i. Upimaji wa kitengo haukuonyesha kosa, na mkaguzi wangu pia hakuonyesha. Uzinduzi ulifanyika, na usiku mmoja nambari yangu ilienda kwa seva na kugonga kompyuta zote kwenye kituo cha data.

Hakuna kitu kibaya kilichotokea. Hakuna kilichovunjika kwa mtu yeyote, kwa sababu kabla ya uzinduzi wa kimataifa msimbo ulijaribiwa ndani ya kituo kimoja cha data. Isipokuwa wahandisi wa SRE waliacha kucheza mabilioni kwa muda na wakarudisha nyuma kidogo. Asubuhi iliyofuata nilipokea barua pepe iliyo na dampo la kuacha kufanya kazi, nilisahihisha msimbo na kuongeza vipimo vya vipimo ambavyo vinaweza kupata hitilafu. Kwa kuwa nilifuata itifaki - vinginevyo nambari yangu ingeshindwa kufanya kazi - hakukuwa na shida zingine.

Somo limeeleweka

Wengi wana hakika kuwa kosa kubwa kama hilo litagharimu kufukuzwa kwa mkosaji, lakini sivyo: kwanza, waandaaji wa programu wote hufanya makosa, na pili, mara chache hufanya makosa sawa mara mbili.

Kwa kweli, nina rafiki wa programu ambaye alikuwa mhandisi mzuri na alifukuzwa kazi kwa kufanya kosa moja. Baada ya hapo, aliajiriwa kwa Google (na hivi karibuni alipandishwa cheo) - alizungumza kwa uaminifu juu ya kosa alilofanya katika mahojiano, na haikuzingatiwa kuwa mbaya.

Hiyo ni nini sema kuhusu Thomas Watson, mkuu wa hadithi wa IBM:

Amri ya serikali yenye thamani ya takriban dola milioni moja ilitangazwa. IBM Corporation - au tuseme, Thomas Watson Sr. binafsi - alitaka sana kuipata. Kwa bahati mbaya, mwakilishi wa mauzo hakuweza kufanya hivi na IBM ilipoteza zabuni. Siku iliyofuata, mfanyakazi huyu alikuja katika ofisi ya Bw. Watson na kuweka bahasha kwenye meza yake. Bwana Watson hakujishughulisha hata kuiangalia - alikuwa akingojea mfanyakazi na alijua kuwa ilikuwa barua ya kujiuzulu.

Watson aliuliza nini kilienda vibaya.

Mwakilishi wa mauzo alizungumza kwa undani juu ya maendeleo ya zabuni. Alitaja makosa yaliyofanywa ambayo yangeweza kuepukika. Hatimaye, alisema, “Bwana Watson, asante kwa kuniruhusu nieleze. Ninajua ni kiasi gani tulihitaji agizo hili. Najua jinsi alivyokuwa muhimu,” na kujiandaa kuondoka.

Watson alimkaribia mlangoni, akamtazama machoni na kurudisha bahasha hiyo yenye maneno haya: “Ninawezaje kukuacha uende? Nimewekeza dola milioni moja katika elimu yako.

Nina T-shati inayosema: "Ikiwa kweli unajifunza kutokana na makosa, basi mimi ni bwana tayari." Kwa kweli, linapokuja suala la makosa, mimi ni daktari wa sayansi.

Mahali pa kwanza: API ya Mvumbuzi wa Programu

Makosa ya kutisha sana huathiri idadi kubwa ya watumiaji, kuwa maarifa ya umma, kuchukua muda mrefu kusahihisha, na hufanywa na wale ambao hawakuweza kuyafanya. Kosa langu kubwa linafaa vigezo hivi vyote.

Mbaya zaidi ni bora zaidi

Nilisoma insha na Richard Gabriel kuhusu mbinu hii katika miaka ya tisini kama mwanafunzi aliyehitimu, na ninaipenda sana hivi kwamba ninaiuliza kwa wanafunzi wangu. Ikiwa hukumbuki vizuri, furahisha kumbukumbu yako, ni ndogo. Insha hii inatofautisha hamu ya "kuipata" na njia ya "mbaya ni bora" kwa njia nyingi, ikiwa ni pamoja na unyenyekevu.

Jinsi inapaswa kuwa: kubuni inapaswa kuwa rahisi katika utekelezaji na interface. Urahisi wa kiolesura ni muhimu zaidi kuliko unyenyekevu wa utekelezaji.

Mbaya zaidi, bora zaidi: kubuni inapaswa kuwa rahisi katika utekelezaji na interface. Urahisi wa utekelezaji ni muhimu zaidi kuliko unyenyekevu wa kiolesura.

Hebu tusahau kuhusu hilo kwa dakika. Kwa bahati mbaya, niliisahau kwa miaka mingi.

Mvumbuzi wa Programu

Nilipokuwa nikifanya kazi katika Google, nilikuwa sehemu ya timu Mvumbuzi wa Programu, mazingira ya ukuzaji wa mtandaoni ya kuvuta na kuangusha kwa wasanidi wa Android wanaotaka. Ilikuwa 2009, na tulikuwa na haraka ya kutoa toleo la alpha kwa wakati ili katika majira ya joto tuweze kufanya madarasa ya bwana kwa walimu ambao wangeweza kutumia mazingira wakati wa kufundisha katika msimu wa joto. Nilijitolea kutekeleza sprites, nostalgic kwa jinsi nilivyokuwa nikiandika michezo kwenye TI-99/4. Kwa wale ambao hawajui, sprite ni kitu cha picha mbili-dimensional ambacho kinaweza kusonga na kuingiliana na vipengele vingine vya programu. Mifano ya sprites ni pamoja na spaceships, asteroids, marumaru, na raketi.

Tulitekeleza Kivumbuzi cha Programu kinacholenga kitu katika Java, kwa hivyo kuna vitu vingi tu humo. Kwa kuwa mipira na sprites zinafanana sana, niliunda darasa la sprite la kufikirika na mali (uwanja) X, Y, Kasi (kasi) na Kichwa (mwelekeo). Walikuwa na njia zile zile za kugundua migongano, kuruka nje ya ukingo wa skrini, nk.

Tofauti kuu kati ya mpira na sprite ni nini hasa kinachotolewa - mduara uliojaa au raster. Kwa kuwa nilitekeleza sprites kwanza, ilikuwa ni jambo la busara kutaja viwianishi vya x- na y vya kona ya juu kushoto ya mahali picha ilipo.

Mara tu sprites ilipofanya kazi, niliamua kuwa naweza kutekeleza vitu vya mpira na nambari ndogo sana. Shida pekee ilikuwa kwamba nilichukua njia rahisi (kutoka kwa mtazamo wa mtekelezaji), nikionyesha viwianishi vya x- na y vya kona ya juu kushoto ya contour inayounda mpira.

Kwa kweli, ilihitajika kuonyesha viwianishi vya x- na y vya katikati ya duara, kama inavyofundishwa katika kitabu chochote cha hisabati na chanzo kingine chochote kinachotaja miduara.

Tofauti na makosa yangu ya zamani, hii iliathiri sio tu wenzangu, lakini pia mamilioni ya watumiaji wa App Inventor. Wengi wao walikuwa watoto au wapya kabisa kwa programu. Ilibidi wafanye hatua nyingi zisizo za lazima wakati wa kufanya kazi kwa kila programu ambayo mpira ulikuwepo. Nikikumbuka makosa yangu mengine kwa kucheka, basi hili linanitoa jasho hata leo.

Hatimaye nilibandika mdudu huyu hivi majuzi tu, miaka kumi baadaye. "Imewekewa viraka", sio "imewekwa", kwa sababu kama Joshua Bloch anavyosema, API ni za milele. Hatukuweza kufanya mabadiliko ambayo yataathiri programu zilizopo, tuliongeza kipengele cha OriginAtCenter chenye thamani isiyo ya kweli katika programu za zamani na kweli katika programu zote zijazo. Watumiaji wanaweza kuuliza swali la kimantiki: ni nani hata alifikiria kuweka mahali pa kuanzia mahali pengine isipokuwa katikati. Kwa nani? Kwa mtayarishaji programu mmoja ambaye alikuwa mvivu sana kuunda API ya kawaida miaka kumi iliyopita.

Mafunzo Yanayopatikana

Wakati wa kufanya kazi kwenye API (ambayo karibu kila mtayarishaji anapaswa kufanya wakati mwingine), unapaswa kufuata ushauri bora ulioainishwa kwenye video ya Joshua Bloch "Jinsi ya kuunda API nzuri na kwa nini ni muhimu sana"Au katika orodha hii fupi:

• API inaweza kukuletea manufaa makubwa na madhara makubwa.. API nzuri huunda wateja wa kurudia. Mbaya huwa ndoto yako ya milele.
• API za umma, kama almasi, hudumu milele. Toa yote yako: hakutakuwa na nafasi nyingine ya kufanya kila kitu sawa.
• Muhtasari wa API unapaswa kuwa mfupi — ukurasa mmoja wenye saini za darasa na mbinu na maelezo, bila kuchukua zaidi ya mstari. Hii itakuruhusu kupanga upya API kwa urahisi ikiwa haitakuwa kamili mara ya kwanza.
• Eleza kesi za matumizikabla ya kutekeleza API au hata kufanyia kazi vipimo vyake. Kwa njia hii utaepuka kutekeleza na kubainisha API isiyofanya kazi kabisa.

Ikiwa ningeandika muhtasari mfupi na hati bandia, uwezekano mkubwa ningegundua kosa na kulisahihisha. Ikiwa sivyo, basi mmoja wa wenzangu bila shaka angefanya hivyo. Uamuzi wowote ambao una matokeo makubwa unahitaji kufikiriwa kwa angalau siku (hii inatumika sio tu kwa programu).

Kichwa cha insha ya Richard Gabriel, "Mbaya zaidi ni Bora," kinarejelea faida ambayo huenda kwa kuwa wa kwanza sokoni - hata kwa bidhaa isiyo kamili - wakati mtu mwingine anatumia umilele kukimbiza ile kamilifu. Kwa kutafakari nambari ya sprite, ninagundua kuwa sikuhitaji hata kuandika nambari zaidi ili kuiweka sawa. Chochote ambacho mtu anaweza kusema, nilikosea sana.

Hitimisho

Watayarishaji programu hufanya makosa kila siku, iwe ni kuandika msimbo wa hitilafu au hawataki kujaribu kitu ambacho kitaboresha ujuzi na tija yao. Kwa kweli, unaweza kuwa mtayarishaji programu bila kufanya makosa makubwa kama mimi. Lakini haiwezekani kuwa mpangaji mzuri wa programu bila kutambua makosa yako na kujifunza kutoka kwao.

Mara kwa mara mimi hukutana na wanafunzi ambao wanahisi kama wanafanya makosa mengi sana na kwa hivyo hawajatengwa kwa ajili ya programu. Ninajua jinsi ugonjwa wa udanganyifu ulivyo kawaida katika IT. Natumai utajifunza masomo ambayo nimeorodhesha - lakini kumbuka kuu: kila mmoja wetu hufanya makosa - ya aibu, ya kuchekesha, ya kutisha. Nitashangaa na kufadhaika ikiwa katika siku zijazo sina nyenzo za kutosha za kuendelea na makala.

Chanzo: mapenzi.com