Necə deyərlər, köhnə kodunuzdan utanmırsınızsa, deməli, proqramçı kimi yetişmirsiniz - mən də bu fikirlə razıyam. Mən əylənmək üçün proqramlaşdırmaya 40 ildən çox əvvəl, peşəkar olaraq isə 30 il əvvəl başlamışam, ona görə də çoxlu səhvlərim var. çoxdur. Bir kompüter elmləri professoru olaraq, tələbələrimə səhvlərdən öyrənməyi öyrədirəm - onların, mənim və başqalarının səhvlərindən. Düşünürəm ki, təvazökarlığımı itirməmək üçün səhvlərimdən danışmağın vaxtıdır. Ümid edirəm kiməsə faydalı olacaqlar.

Üçüncü yer - Microsoft C kompilyatoru

Məktəb müəllimim hesab edirdi ki, Romeo və Cülyetta faciə hesab oluna bilməz, çünki personajların faciəvi günahı yoxdur – onlar özlərini sadəcə olaraq, yeniyetmələr kimi axmaq aparırdılar. O vaxt onunla razılaşmadım, amma indi onun fikrincə, xüsusən də proqramlaşdırma ilə bağlı bir rasionallıq taxılını görürəm.

MIT-də ikinci kursumu bitirəndə həm həyatda, həm də proqramlaşdırmada gənc və təcrübəsiz idim. Yayda Microsoft-da, C kompilyator komandasında təcrübə keçdim.Əvvəlcə profilin dəstəklənməsi kimi rutin işlərlə məşğul oldum, sonra isə kompilyatorun ən əyləncəli hissəsi (düşündüyüm kimi) - backend optimizasiyası üzərində işləmək mənə həvalə olundu. Xüsusilə, filial ifadələri üçün x86 kodunu təkmilləşdirməli oldum.

Hər bir mümkün vəziyyət üçün optimal maşın kodunu yazmağa qərar verdim, özümü hovuza atdım. Dəyərlərin paylanma sıxlığı yüksək olsaydı, mən onları daxil etdim keçid cədvəli. Əgər onların ümumi bölənləri varsa, mən ondan cədvəli daha sıx etmək üçün istifadə edirdim (ancaq bölgü istifadə etməklə həyata keçirilə bilərdisə) bit sürüşmə). Bütün dəyərlər ikinin gücü olduqda, başqa bir optimallaşdırma etdim. Əgər bir sıra dəyərlər mənim şərtlərimə cavab vermirsə, mən onu bir neçə optimallaşdırıla bilən hallara böldüm və artıq optimallaşdırılmış kodu istifadə etdim.

Bu kabus idi. Uzun illər sonra mənə dedilər ki, kodumu miras almış proqramçı mənə nifrət edir.

Dərs öyrənildi

David Patterson və John Hennessy "Kompüter Arxitekturası və Kompüter Sistemləri Dizaynı" kitabında yazdıqları kimi, memarlıq və dizaynın əsas prinsiplərindən biri, ümumiyyətlə, işlərin mümkün qədər tez işləməsini təmin etməkdir.

Ümumi halların sürətləndirilməsi nadir halların optimallaşdırılmasından daha effektiv performansı artıracaq. Qəribədir ki, adi hallar nadir hallardan daha sadə olur. Bu məntiqi məsləhət, hansı halın ümumi hesab edildiyini bildiyinizi güman edir - və bu, yalnız diqqətlə sınaq və ölçmə prosesi ilə mümkündür.

Mən öz müdafiəmdə budaq ifadələrinin praktikada necə göründüyünü anlamağa çalışdım (məsələn, neçə filial var və sabitlər necə paylanıb), lakin 1988-ci ildə bu məlumat mövcud deyildi. Bununla belə, indiki kompilyator mənim hazırladığım süni nümunə üçün optimal kod yarada bilmədiyi zaman xüsusi hallar əlavə etməməliydim.

Təcrübəli bir tərtibatçı çağırmalı və onunla birlikdə ümumi halların nə olduğunu düşünməli və onlarla xüsusi məşğul olmalı idim. Mən daha az kod yazardım, amma bu yaxşı bir şeydir. Stack Overflow-un yaradıcısı Jeff Atwood yazdığı kimi, proqramçının ən pis düşməni proqramçının özüdür:

Bilirəm ki, hamımız kimi sizin də ən yaxşı niyyətiniz var. Biz proqramlar yaradırıq və kod yazmağı sevirik. Biz belə yaradılmışıq. Düşünürük ki, istənilən problemi yapışqan lenti, evdə hazırlanmış qoltuqaltı və bir çimdik kodla həll etmək olar. Kodlayıcılara bunu etiraf etmək nə qədər əziyyət çəksə də, ən yaxşı kod mövcud olmayan koddur. Hər bir yeni sətir sazlama və dəstəyə ehtiyac duyur, onu başa düşmək lazımdır. Yeni kod əlavə etdiyiniz zaman bunu istəksizlik və ikrahla etməlisiniz, çünki bütün digər variantlar tükənmişdir. Bir çox proqramçı həddən artıq çox kod yazaraq onu düşmənimizə çevirir.

Ümumi halları əhatə edən daha sadə kod yazsaydım, lazım gələrsə yeniləmək daha asan olardı. Heç kimin öhdəsindən gəlmək istəmədiyi bir qarışıqlıq buraxdım.

İkinci yer: sosial şəbəkələrdə reklam

Mən Google-da sosial media reklamında işləyərkən (Myspace-i xatırlayırsınız?), C++-da belə bir şey yazdım:

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)) {
  }
}

Proqramçılar səhvi dərhal görə bilərlər: sonuncu arqument i deyil, j olmalıdır. Vahid sınağı səhvi aşkar etmədi və mənim rəyçim də etmədi. Başlatma həyata keçirildi və bir gecə mənim kodum serverə getdi və məlumat mərkəzindəki bütün kompüterləri sıradan çıxardı.

Pis heç nə olmadı. Heç kim üçün heç bir şey pozulmadı, çünki qlobal buraxılışdan əvvəl kod bir məlumat mərkəzində sınaqdan keçirilmişdir. SRE mühəndisləri bir müddət bilyard oynamağı dayandırmasalar və bir az geri çəkilməsələr. Ertəsi gün səhər mən qəza zibilliyi olan bir e-poçt aldım, kodu düzəltdi və xətanı tutacaq vahid testləri əlavə etdim. Mən protokola əməl etdiyim üçün - əks halda kodum sadəcə işləməyəcək - başqa heç bir problem yox idi.

Dərs öyrənildi

Çoxları əmindir ki, belə bir böyük səhv mütləq günahkarın işdən çıxarılmasına başa gələcək, lakin bu belə deyil: birincisi, bütün proqramçılar səhv edirlər, ikincisi, nadir hallarda eyni səhvi iki dəfə edirlər.

Əslində, mənim bir proqramçı dostum var, o, parlaq mühəndis idi və bircə səhvə görə işdən çıxarıldı. Bundan sonra o, Google-da işə götürüldü (və tezliklə yüksəldi) - müsahibədə etdiyi səhv barədə vicdanla danışdı və bu, ölümcül sayılmadı.

Budur deyin IBM-in əfsanəvi rəhbəri Thomas Watson haqqında:

Bir milyon dollara yaxın dövlət sifarişi elan edildi. IBM Korporasiyası - daha doğrusu, şəxsən Thomas Watson Sr. - həqiqətən onu əldə etmək istəyirdi. Təəssüf ki, satış nümayəndəsi bunu edə bilmədi və IBM təklifi itirdi. Ertəsi gün bu işçi cənab Vatsonun kabinetinə gəldi və onun masasına zərf qoydu. Cənab Uotson ona baxmaqdan belə çəkinmirdi - o, işçi gözləyirdi və bunun istefa məktubu olduğunu bilirdi.

Watson nəyin səhv olduğunu soruşdu.

Satış nümayəndəsi tenderin gedişi barədə ətraflı danışıb. O, qarşısı alına biləcək səhvlərin adını çəkdi. Nəhayət, o dedi: “Cənab Uotson, mənə izahat verdiyiniz üçün təşəkkür edirəm. Bu sifarişin bizə nə qədər lazım olduğunu bilirəm. Mən onun nə qədər vacib olduğunu bilirəm” dedi və getməyə hazırlaşdı.

Uotson qapıda ona yaxınlaşdı, gözlərinə baxdı və zərfi geri qaytardı: “Səni necə buraxım? Mən sizin təhsilinizə bir milyon dollar sərmayə qoymuşam.

Mənim köynəyimdə belə yazılıb: “Əgər həqiqətən səhvlərdən öyrənirsənsə, deməli mən artıq ustayam”. Əslində səhvlərə gəlincə, mən elmlər doktoruyam.

Birinci yer: App Inventor API

Həqiqətən dəhşətli səhvlər çox sayda istifadəçiyə təsir edir, ictimaiyyətə məlum olur, düzəltmək üçün uzun müddət tələb olunur və onları edə bilməyənlər tərəfindən edilir. Mənim ən böyük səhvim bütün bu meyarlara uyğun gəlir.

Nə qədər pis, bir o qədər yaxşıdır

oxudum Richard Gabriel tərəfindən esse XNUMX-cı illərdə bir aspirant kimi bu yanaşma haqqında və mən bunu o qədər bəyənirəm ki, tələbələrimə xahiş edirəm. Yaxşı xatırlamırsınızsa, yaddaşınızı təzələyin, kiçikdir. Bu esse sadəlik də daxil olmaqla bir çox cəhətdən "düzgün etmək" istəyi ilə "pis daha yaxşıdır" yanaşmasını əks etdirir.

Necə olmalıdır: dizayn icra və interfeys baxımından sadə olmalıdır. İnterfeys sadəliyi tətbiqin sadəliyindən daha vacibdir.

Nə qədər pis, bir o qədər yaxşıdır: dizayn icra və interfeys baxımından sadə olmalıdır. Tətbiqin sadəliyi interfeysin sadəliyindən daha vacibdir.

Bir dəqiqəlik bunu unudaq. Təəssüf ki, uzun illərdir bunu unutmuşam.

Tətbiq ixtiraçısı

Google-da işləyərkən komandanın bir hissəsi idim Tətbiq ixtiraçısı, istəyən Android tərtibatçıları üçün sürüklə və buraxan onlayn inkişaf mühiti. 2009-cu il idi və biz alfa versiyasını vaxtında buraxmağa tələsirdik ki, payızda dərs deyərkən ətraf mühitdən istifadə edə bilən müəllimlər üçün yayda ustad dərsləri keçirək. Mən TI-99/4-də oyun yazmağıma həsrət qalan spritləri həyata keçirmək üçün könüllü oldum. Bilməyənlər üçün sprite digər proqram elementləri ilə hərəkət edə və qarşılıqlı əlaqə qura bilən iki ölçülü qrafik obyektdir. Spritlərə misal olaraq kosmik gəmiləri, asteroidləri, mərmərləri və raketləri göstərmək olar.

Biz Java-da obyekt yönümlü Tətbiq İnventorunu tətbiq etdik, ona görə də orada sadəcə bir dəstə obyekt var. Toplar və spritlər çox oxşar davrandığından, xassələri (sahələri) X, Y, Sürət (sürət) və Başlıq (istiqamət) olan mücərrəd sprite sinfi yaratdım. Toqquşmaları aşkar etmək, ekranın kənarından sıçramaq və s. üçün eyni üsullara sahib idilər.

Top və sprite arasındakı əsas fərq, tam olaraq çəkilən şeydir - doldurulmuş dairə və ya rastr. Əvvəlcə spritləri tətbiq etdiyim üçün şəklin yerləşdiyi yerin yuxarı sol küncünün x və y koordinatlarını təyin etmək məntiqli idi.

Spritlər işlədikdən sonra, çox az kodla top obyektlərini həyata keçirə biləcəyimə qərar verdim. Yeganə problem o idi ki, topun çərçivəsini çəkən konturun yuxarı sol küncünün x və y koordinatlarını göstərən ən sadə marşrutu (həyata keçirən nöqteyi-nəzərdən) götürdüm.

Əslində hər hansı riyaziyyat dərsliyində və çevrələrdən bəhs edən hər hansı digər mənbədə öyrədildiyi kimi dairənin mərkəzinin x və y koordinatlarını göstərmək lazım idi.

Keçmiş səhvlərimdən fərqli olaraq, bu, təkcə həmkarlarıma deyil, həm də milyonlarla App Inventor istifadəçisinə təsir etdi. Onların bir çoxu uşaqlar idi və ya proqramlaşdırmaya tamamilə yeni başlamışdılar. Topun mövcud olduğu hər bir tətbiq üzərində işləyərkən çoxlu lazımsız addımlar atmalı idilər. Başqa səhvlərimi gülüşlə xatırlayıramsa, bu gün də məni tərləyir.

Mən nəhayət bu səhvi yalnız bu yaxınlarda, on il sonra düzəltdim. Joshua Bloch'un dediyi kimi, API-lər əbədidir, "yamaqlanmış", "sabit" deyil. Mövcud proqramlara təsir edəcək dəyişikliklər edə bilmədik, biz köhnə proqramlarda false və bütün gələcək proqramlarda true dəyəri ilə OriginAtCenter xassəsini əlavə etdik. İstifadəçilər məntiqli bir sual verə bilər: hətta başlanğıc nöqtəsini mərkəzdən başqa bir yerə yerləşdirməyi düşünənlər. Kimə? On il əvvəl normal API yaratmaq üçün çox tənbəl olan bir proqramçıya.

Öyrənilmiş dərslər

API-lər üzərində işləyərkən (demək olar ki, hər bir proqramçı bunu bəzən etməli olur), siz Joshua Bloch-un videosunda göstərilən ən yaxşı məsləhətlərə əməl etməlisiniz "Yaxşı bir API necə yaradılmalı və niyə bu qədər vacibdir"Ya da bu qısa siyahıda:

• API sizə həm böyük fayda, həm də böyük zərər verə bilər.. Yaxşı API təkrar müştərilər yaradır. Pis sizin əbədi kabusunuza çevrilir.
• Almazlar kimi ictimai API-lər əbədidir. Hər şeyinizi verin: hər şeyi düzgün etmək üçün bir daha şansınız olmayacaq.
• API konturları qısa olmalıdır — bir sətirdən çox olmayan sinif və metod imzaları və təsvirləri olan bir səhifə. Bu, API-nin ilk dəfə mükəmməl olmadığı təqdirdə asanlıqla yenidən qurulmasına imkan verəcəkdir.
• İstifadə hallarını təsvir edinAPI tətbiq etməzdən və ya hətta onun spesifikasiyası üzərində işləmədən əvvəl. Bu yolla siz tamamilə qeyri-funksional API tətbiq etməkdən və təyin etməkdən qaçacaqsınız.

Əgər süni ssenari ilə hətta qısa konspekt yazsaydım, çox güman ki, səhvi müəyyən edib düzəldərdim. Əgər belə olmasaydı, həmkarlarımdan biri mütləq bunu edərdi. Uzaqlaşan nəticələri olan istənilən qərar ən azı bir gün (bu, təkcə proqramlaşdırmaya aid deyil) üzərində düşünmək lazımdır.

Riçard Qabrielin “Daha pisi daha yaxşıdır” essesinin başlığı, başqasının mükəmməl məhsulun arxasınca əbədiyyət sərf etdiyi halda, hətta qeyri-kamil məhsulla belə, bazara ilk çıxmağın üstünlüyünə işarə edir. Sprite kodu üzərində düşünərək başa düşürəm ki, onu düzgün əldə etmək üçün daha çox kod yazmalıyam. Kim nə deyirsə desin, mən çox yanılmışam.

Nəticə

Proqramçılar hər gün səhvlər edirlər, istər səhv kodu yazır, istərsə də bacarıqlarını və məhsuldarlığını artıracaq bir şeyi sınamaq istəməzlər. Təbii ki, mənim etdiyim kimi ciddi səhvlərə yol vermədən proqramçı ola bilərsiniz. Amma səhvlərinizi dərk etmədən və onlardan dərs almadan yaxşı proqramçı olmaq mümkün deyil.

Mən daima çoxlu səhv etdiklərini düşünən və buna görə də proqramlaşdırma üçün kəsilməyən tələbələrlə qarşılaşıram. Mən İT-də saxtakarlıq sindromunun nə qədər geniş yayıldığını bilirəm. Ümid edirəm ki, sadaladığım dərsləri öyrənəcəksiniz - amma əsasını xatırlayın: hər birimiz səhv edirik - utanc verici, gülməli, dəhşətli. Gələcəkdə məqaləni davam etdirmək üçün kifayət qədər materialım olmasa, təəccüblənəcəyəm və üzüləcəyəm.

Mənbə: www.habr.com