Ular aytganidek, agar siz eski kodingizdan uyalmasangiz, demak siz dasturchi sifatida o'smaysiz - va men bu fikrga qo'shilaman. Men o'yin-kulgi uchun dasturlashni 40 yil oldin va professional ravishda 30 yil oldin boshlaganman, shuning uchun menda juda ko'p xatolar bor. juda ko'p. Informatika professori sifatida men o'quvchilarimga xatolardan o'rganishni o'rgataman - ularniki, meniki va boshqalar. O‘ylaymanki, kamtarlikni yo‘qotmaslik uchun xatolarim haqida gapirish vaqti keldi. Umid qilamanki, ular kimgadir foydali bo'ladi.

Uchinchi o'rin - Microsoft C kompilyatori

Maktab o‘qituvchim Romeo va Julettani fojia deb hisoblab bo‘lmaydi, deb hisoblardi, chunki qahramonlarda fojiali ayb yo‘q – ular o‘zini o‘smirlar kabi ahmoqona tutishgan. O'shanda men u bilan rozi bo'lmaganman, lekin hozir men uning fikrida, ayniqsa dasturlash bilan bog'liq holda, ratsionallik donini ko'rmoqdaman.

MITda ikkinchi kursni tamomlaganimda men hayotda ham, dasturlashda ham yosh va tajribasiz edim. Yozda men Microsoft kompaniyasida, C kompilyatorlar jamoasida stajirovka o‘tkazdim.Avvaliga profil yaratishni qo‘llab-quvvatlash kabi muntazam ishlarni qildim, keyin esa kompilyatorning eng qiziqarli qismi (men o‘ylaganimdek) – backend optimization ustida ishlash menga ishonib topshirildi. Xususan, men filial bayonotlari uchun x86 kodini yaxshilashim kerak edi.

Har bir mumkin bo'lgan holat uchun optimal mashina kodini yozishga qaror qilib, o'zimni basseynga tashladim. Agar qiymatlarni taqsimlash zichligi yuqori bo'lsa, men ularni kiritdim o'tish jadvali. Agar ularning umumiy bo'luvchisi bo'lsa, men undan jadvalni qattiqroq qilish uchun ishlatardim (lekin bo'lish faqat bit siljishi). Barcha qiymatlar ikkita kuchga ega bo'lganda, men yana bir optimallashtirish qildim. Agar qiymatlar to'plami mening shartlarimga javob bermasa, men uni bir nechta optimallashtirilgan holatlarga ajratdim va allaqachon optimallashtirilgan koddan foydalandim.

Bu dahshatli tush edi. Ko'p yillar o'tgach, mening kodimni meros qilib olgan dasturchi meni yomon ko'rishini aytishdi.

O'rganilgan saboq

Devid Patterson va Jon Xennessi "Kompyuter arxitekturasi va kompyuter tizimlari dizayni" asarida yozganidek, arxitektura va dizaynning asosiy tamoyillaridan biri shundaki, umuman olganda, narsalar imkon qadar tezroq ishlashi kerak.

Umumiy ishlarni tezlashtirish kamdan-kam holatlarni optimallashtirishdan ko'ra samaradorlikni oshiradi. Ajablanarlisi shundaki, tez-tez uchraydigan holatlar kamdan-kam holatlarga qaraganda oddiyroq. Ushbu mantiqiy maslahat siz qaysi holat keng tarqalganligini bilishingizni nazarda tutadi - va bu faqat sinchkovlik bilan tekshirish va o'lchash jarayoni orqali mumkin.

Himoya qilishda men filial bayonotlarining amalda qanday ko'rinishini aniqlashga harakat qildim (masalan, nechta filial bor va konstantalar qanday taqsimlangan), lekin 1988 yilda bu ma'lumot mavjud emas edi. Biroq, joriy kompilyator men o'ylab topgan sun'iy misol uchun optimal kodni yarata olmasa, maxsus holatlarni qo'shmasligim kerak edi.

Men tajribali ishlab chiquvchini chaqirishim va u bilan birgalikda umumiy holatlar nima ekanligini o'ylab ko'rishim va ular bilan alohida shug'ullanishim kerak edi. Men kamroq kod yozardim, lekin bu yaxshi narsa. Stack Overflow asoschisi Jeff Atvud yozganidek, dasturchining eng ashaddiy dushmani dasturchining o'zidir:

Bilaman, siz ham hammamiz kabi yaxshi niyatdasiz. Biz dasturlar yaratamiz va kod yozishni yaxshi ko'ramiz. Biz shunday yaratilganmiz. O'ylaymizki, har qanday muammoni yopishqoq lenta, uy qurilishi tayoqchasi va bir chimdim kod yordamida hal qilish mumkin. Koderlar buni tan olishlari qanchalik qiyin bo'lsa ham, eng yaxshi kod mavjud bo'lmagan koddir. Har bir yangi qatorni tuzatish va qo'llab-quvvatlash kerak, uni tushunish kerak. Yangi kodni qo'shganda, buni istamay va jirkanish bilan qilishingiz kerak, chunki boshqa barcha imkoniyatlar tugadi. Ko'pgina dasturchilar juda ko'p kod yozishadi va bu bizning dushmanimizga aylanadi.

Agar men umumiy holatlarni qamrab oluvchi oddiyroq kod yozganimda, kerak bo'lganda yangilash ancha oson bo'lar edi. Men hech kim bilan shug'ullanmoqchi bo'lmagan tartibsizlikni qoldirdim.

Ikkinchi o'rin: ijtimoiy tarmoqlarda reklama

Men Google’da ijtimoiy media reklamasida ishlaganimda (Myspace esingizdami?), C++ da shunday yozganman:

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

Dasturchilar xatoni darhol ko'rishlari mumkin: oxirgi argument i emas, j bo'lishi kerak. Birlik testi xatoni aniqlamadi va mening sharhlovchim ham. Ishga tushirish amalga oshirildi va bir kechada mening kodim serverga kirib, ma'lumotlar markazidagi barcha kompyuterlarni buzdi.

Hech qanday yomon narsa bo'lmadi. Hech kim uchun hech narsa buzilmadi, chunki global ishga tushirishdan oldin kod bitta ma'lumot markazida sinovdan o'tgan. Agar SRE muhandislari bir muddat bilyard o'ynashni to'xtatib, biroz orqaga qaytishmasa. Ertasi kuni ertalab men elektron pochta xabarini oldim, kodni tuzatdim va xatoni aniqlaydigan birlik testlarini qo'shdim. Men protokolga amal qilganim uchun - aks holda mening kodim ishlamay qolar edi - boshqa muammolar yo'q edi.

O'rganilgan saboq

Ko'pchilik bunday katta xato, albatta, aybdorni ishdan bo'shatishga qimmatga tushishiga amin, ammo bu unday emas: birinchidan, barcha dasturchilar xato qiladilar, ikkinchidan, ular kamdan-kam hollarda bir xil xatoni ikki marta qilishadi.

Darhaqiqat, mening bir dasturchi do'stim bor, u zo'r muhandis edi va bitta xato qilgani uchun ishdan bo'shatildi. Shundan so'ng u Google-ga ishga qabul qilindi (va tez orada lavozimga ko'tarildi) - u intervyuda qilgan xatosi haqida halol gapirdi va bu halokatli deb hisoblanmadi.

Mana nima aytib bering IBMning afsonaviy rahbari Tomas Uotson haqida:

Bir million dollarga yaqin davlat buyurtmasi e'lon qilindi. IBM korporatsiyasi - to'g'rirog'i, shaxsan Tomas Uotson Sr - uni olishni juda xohlagan. Afsuski, savdo vakili buni qila olmadi va IBM taklifni yutqazdi. Ertasi kuni bu xodim janob Uotsonning kabinetiga kirib, stoliga konvert qo'ydi. Janob Uotson unga qarashga ham ulgurmadi - u xodimni kutayotgan edi va bu ishdan bo'shatish to'g'risidagi xat ekanligini bilardi.

Uotson nima bo'lganini so'radi.

Savdo vakili tenderning borishi haqida batafsil gapirib berdi. U yo'l qo'yilishi mumkin bo'lgan xatolarni nomladi. Nihoyat, u shunday dedi: “Janob Uotson, tushuntirishga ruxsat berganingiz uchun rahmat. Bu buyurtma bizga qanchalik zarurligini bilaman. Men uning qanchalik muhimligini bilaman”, dedi va ketishga tayyorlandi.

Uotson eshik oldida unga yaqinlashdi, uning ko'zlariga qaradi va konvertni qaytarib berdi: "Qanday qilib sizni qo'yib yuborishim mumkin? Men sizning ta'limingizga bir million dollar sarmoya kiritdim.

Mening futbolkam bor: "Agar siz haqiqatan ham xatolardan o'rgansangiz, men allaqachon ustaman". Aslida xatolar haqida gap ketganda, men fan doktoriman.

Birinchi o'rin: App Inventor API

Haqiqatan ham dahshatli xatolar juda ko'p foydalanuvchilarga ta'sir qiladi, ommaga ma'lum bo'ladi, tuzatish uchun uzoq vaqt kerak bo'ladi va ularni amalga oshira olmaganlar tomonidan amalga oshiriladi. Mening eng katta xatoim bu mezonlarning barchasiga mos keladi.

Qanchalik yomon bo'lsa, shuncha yaxshi

Men o'qiyman Richard Gabriel tomonidan yozilgan insho 90-yillarda aspirant sifatida ushbu yondashuv haqida va menga juda yoqadi, men buni talabalarimga so'rayman. Yaxshi eslamasangiz, xotirangizni yangilang, u kichik. Ushbu insho "to'g'ri olish" istagini va "yomoni yaxshiroq" yondashuvini ko'p jihatdan, shu jumladan soddalik bilan taqqoslaydi.

Qanday bo'lishi kerak: dizayn amalga oshirish va interfeysda sodda bo'lishi kerak. Interfeysning soddaligi amalga oshirishning soddaligidan muhimroqdir.

Qanchalik yomon bo'lsa, shuncha yaxshi: dizayn amalga oshirish va interfeysda sodda bo'lishi kerak. Amalga oshirishning soddaligi interfeysning soddaligidan muhimroqdir.

Buni bir daqiqaga unutaylik. Afsuski, ko'p yillar davomida men buni unutib qo'ydim.

Ilova ixtirochisi

Googleda ishlaganimda men jamoaning bir qismi edim Ilova ixtirochisi, intiluvchan Android ishlab chiquvchilari uchun sudrab va tashlab onlayn ishlab chiqish muhiti. Bu 2009 yil edi va biz yozda kuzda dars berishda atrof-muhitdan foydalana oladigan o'qituvchilar uchun mahorat darslarini o'tkazishimiz uchun alfa versiyasini o'z vaqtida chiqarishga shoshildik. Men TI-99/4 da qanday qilib o‘yin yozganimga nostaljik bo‘lgan spritlarni amalga oshirishga ko‘ngilli bo‘ldim. Bilmaganlar uchun sprite ikki o'lchovli grafik ob'ekt bo'lib, u boshqa dasturiy ta'minot elementlari bilan harakatlanishi va o'zaro ta'sir qilishi mumkin. Spritelarga misol sifatida kosmik kemalar, asteroidlar, marmarlar va raketkalar kiradi.

Biz Java-da ob'ektga yo'naltirilgan App Inventor-ni joriy qildik, shuning uchun u erda bir nechta ob'ektlar mavjud. To'plar va spritlar juda o'xshash bo'lgani uchun men X, Y, Tezlik (tezlik) va Sarlavha (yo'nalish) xususiyatlariga ega mavhum sprite sinfini yaratdim. Ular to'qnashuvlarni aniqlash, ekranning chetidan sakrash va hokazolar uchun bir xil usullarga ega edi.

To'p va sprayt o'rtasidagi asosiy farq aynan nima chizilganligidir - to'ldirilgan doira yoki rastr. Avval spritlarni amalga oshirganim uchun, tasvir joylashgan joyning yuqori chap burchagining x va y-koordinatalarini belgilash mantiqan to'g'ri edi.

Spritlar ishlagandan so'ng, men juda kam kod bilan to'p ob'ektlarini amalga oshirishga qaror qildim. Yagona muammo shundaki, men to'pni ramkalashtirgan konturning yuqori chap burchagining x va y koordinatalarini ko'rsatadigan eng oddiy marshrutni (tadqiqotchi nuqtai nazaridan) oldim.

Darhaqiqat, har qanday matematika darsligida va doiralar haqida eslatib o'tilgan boshqa manbalarda o'rgatilganidek, aylana markazining x va y koordinatalarini ko'rsatish kerak edi.

Mening oldingi xatolarimdan farqli o'laroq, bu nafaqat mening hamkasblarim, balki millionlab App Inventor foydalanuvchilariga ham ta'sir qildi. Ularning aksariyati bolalar edi yoki dasturlash uchun mutlaqo yangi edi. To'p mavjud bo'lgan har bir dastur ustida ishlashda ular juda ko'p keraksiz qadamlarni bajarishlari kerak edi. Boshqa xatolarimni kulish bilan eslasam, bu xato bugun ham meni terlaydi.

Nihoyat, men bu xatoni yaqinda, o'n yil o'tgach tuzatdim. Joshua Bloch aytganidek, “tuzatilgan” emas, “yamalgan”, APIlar abadiydir. Mavjud dasturlarga ta'sir qiladigan o'zgarishlarni amalga oshira olmadik, biz OriginAtCenter xususiyatini eski dasturlarda false va kelajakdagi barcha dasturlarda true qiymati bilan qo'shdik. Foydalanuvchilar mantiqiy savol berishlari mumkin: kim hatto boshlang'ich nuqtani markazdan boshqa joyga qo'yishni o'ylagan. Kimga? O'n yil oldin oddiy API yaratish uchun juda dangasa bo'lgan bir dasturchiga.

O'rganilgan saboqlar

API-lar ustida ishlayotganda (deyarli har bir dasturchi ba'zan bajarishi kerak), siz Joshua Blochning videosida keltirilgan eng yaxshi maslahatga amal qilishingiz kerak "Qanday qilib yaxshi API yaratish va bu nima uchun juda muhim"yoki ushbu qisqa ro'yxatda:

• API sizga katta foyda ham, katta zarar ham keltirishi mumkin.. Yaxshi API takroriy mijozlarni yaratadi. Yomon sizning abadiy dahshatingizga aylanadi.
• Ommaviy API'lar, olmos kabi, abadiy davom etadi. Unga hamma narsani bering: hamma narsani to'g'ri qilish uchun boshqa hech qachon imkoniyat bo'lmaydi.
• API konturlari qisqa bo'lishi kerak — bir satrdan ko'p bo'lmagan sinf va usul imzolari va tavsiflari bilan bitta sahifa. Bu birinchi marta mukammal bo'lmasa, APIni osongina qayta qurish imkonini beradi.
• Foydalanish holatlarini tavsiflangAPIni joriy qilishdan yoki hatto uning spetsifikatsiyasi ustida ishlashdan oldin. Shunday qilib, siz to'liq ishlamaydigan APIni amalga oshirish va belgilashdan qochasiz.

Agar men sun'iy skript bilan qisqacha konspekt yozganimda, ehtimol xatoni aniqlab, uni tuzatgan bo'lardim. Agar yo'q bo'lsa, unda mening hamkasblarimdan biri buni albatta qiladi. Katta oqibatlarga olib keladigan har qanday qarorni kamida bir kun o'ylab ko'rish kerak (bu nafaqat dasturlash uchun amal qiladi).

Richard Gabrielning "Yomonroq narsa yaxshiroq" inshosining sarlavhasi bozorda birinchi bo'lib, hatto nomukammal mahsulot bo'lsa ham, boshqa birov abadiy mukammal mahsulotning orqasidan quvib ketadigan afzalliklarga ishora qiladi. Sprite-kod haqida o'ylab, men uni to'g'ri olish uchun ko'proq kod yozishim shart emasligini tushunaman. Kim nima desa ham, men qo'pol xato qildim.

xulosa

Dasturchilar har kuni xatoga yo'l qo'yishadi - bu xato kodni yozish yoki ularning mahorati va samaradorligini oshiradigan biror narsani sinab ko'rishni xohlamaslik. Albatta, siz men kabi jiddiy xatolarga yo'l qo'ymasdan dasturchi bo'lishingiz mumkin. Lekin xatolaringizni tan olmay va ulardan o'rganmay turib, yaxshi dasturchi bo'lib bo'lmaydi.

Men doimo o'zlarini juda ko'p xatoga yo'l qo'ygandek his qiladigan va shuning uchun dasturlash uchun kesilmagan talabalarga duch kelaman. Men IT sohasida firibgarlik sindromi qanchalik keng tarqalganligini bilaman. Umid qilamanki, siz men sanab o'tgan saboqlarni o'rganasiz - lekin asosiysini eslang: har birimiz xato qilamiz - sharmandali, kulgili, dahshatli. Kelajakda maqolani davom ettirish uchun etarli material bo'lmasa, hayron qolaman va xafa bo'laman.

Manba: www.habr.com