သူတို့ပြောသလိုပဲ၊ မင်းရဲ့ကုဒ်ဟောင်းကို မရှက်ဘူးဆိုရင် ပရိုဂရမ်မာတစ်ယောက်အနေနဲ့ ကြီးထွားလာမှာမဟုတ်ဘူး၊ ဒီသဘောထားကို ငါသဘောတူတယ်။ လွန်ခဲ့တဲ့ အနှစ် ၄၀ ကျော်က အပျော်သဘောနဲ့ ပရိုဂရမ်ကို စတင်ခဲ့တာ ဖြစ်ပြီး လွန်ခဲ့တဲ့ အနှစ် 40 လောက်ကတည်းက ကျွမ်းကျင်ပိုင်နိုင်စွာ လုပ်ဆောင်ခဲ့တာဖြစ်လို့ အမှားတွေ အများကြီးပါ။ စာရေး. ကွန်ပြူတာသိပ္ပံပါမောက္ခတစ်ဦးအနေဖြင့် ကျွန်ုပ်သည် ကျောင်းသားများအား ၎င်းတို့၏အမှားများမှ သင်ခန်းစာယူရန် သင်ပေးပါသည်။ ကျိုးနွံမှုကို မပျောက်ပျက်စေဘဲ ငါ့အမှားတွေအကြောင်း ပြောဖို့ အချိန်တန်ပြီလို့ ထင်ပါတယ်။ တစ်စုံတစ်ယောက်အတွက် အသုံးဝင်မယ်လို့ မျှော်လင့်ပါတယ်။

တတိယနေရာ - Microsoft C compiler

ဇာတ်ကောင်များသည် ကြေကွဲဖွယ်အပြစ်မရှိသောကြောင့် ရိုမီယိုနှင့် ဂျူလီယက်တို့ကို ကြေကွဲဖွယ်အဖြစ်မသတ်မှတ်နိုင်ဟု ကျောင်းဆရာက ယုံကြည်ခဲ့သည်- ဆယ်ကျော်သက်များကဲ့သို့ မိုက်မဲစွာ ပြုမူတတ်ကြသည်။ အဲဒီတုန်းက သူနဲ့ကျွန်တော် သဘောမတူခဲ့ပေမဲ့ အခုချိန်မှာတော့ အထူးသဖြင့် ပရိုဂရမ်ရေးဆွဲခြင်းနဲ့ပတ်သက်တဲ့ သူ့အမြင်မှာ ကျိုးကြောင်းဆီလျော်မှုများစွာကို တွေ့နေရပါတယ်။

MIT မှာ ဒုတိယနှစ် ပြီးတဲ့ အချိန်မှာ ငယ်ငယ်ရွယ်ရွယ်နဲ့ အတွေ့အကြုံမရှိ ၊ ဘဝနဲ့ ပရိုဂရမ်ရေးခြင်း မှာရော ၊ နွေရာသီတွင်၊ C compiler အဖွဲ့တွင် Microsoft တွင် အလုပ်သင်ခဲ့သည်။ အစပိုင်းတွင် ပရိုဖိုင်းပံ့ပိုးမှုကဲ့သို့သော လုပ်ရိုးလုပ်စဉ်များကို လုပ်ဆောင်ခဲ့ပြီး၊ ထို့နောက် compiler ၏ အပျော်ဆုံးအပိုင်းတွင် (ကျွန်တော်ထင်ထားသည့်အတိုင်း) - backend optimization ကို လုပ်ဆောင်ရန် အပ်နှင်းခံရသည်။ အထူးသဖြင့်၊ ကျွန်တော်သည် ဌာနခွဲထုတ်ပြန်ချက်များအတွက် x86 ကုဒ်ကို ပိုမိုကောင်းမွန်အောင် လုပ်ခဲ့ရသည်။

ဖြစ်နိုင်သမျှ ကိစ္စတိုင်းအတွက် အကောင်းဆုံးသော စက်ကုဒ်ကို ရေးရန် စိတ်ပိုင်းဖြတ်ပြီး ရေကူးကန်ထဲသို့ ခေါင်းလောင်းချလိုက်မိသည်။ ဖြန့်ဖြူးရေးသိပ်သည်းဆတန်ဖိုးများ မြင့်မားနေပါက ၎င်းတို့ကို ကျွန်ုပ်ထည့်သွင်းပါ။ အကူးအပြောင်းဇယား. သူတို့မှာ တူညီတဲ့ ပိုင်းခြားမှုတစ်ခုရှိခဲ့ရင်၊ ဇယားကို ပိုတင်းကျပ်အောင်လုပ်ဖို့ ငါအသုံးပြုခဲ့တယ် (ဒါပေမယ့် ပိုင်းခြားမှုကို အသုံးချနိုင်မှသာ၊ နည်းနည်းပြောင်းတယ်။) တန်ဖိုးအားလုံးသည် နှစ်ခု၏ စွမ်းအားများဖြစ်သောအခါ၊ ကျွန်ုပ်သည် နောက်ထပ် ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ခဲ့သည်။ တန်ဖိုးတစ်ခုသည် ကျွန်ုပ်၏အခြေအနေများကို မကျေနပ်ပါက၊ ကျွန်ုပ်သည် ၎င်းကို ပိုမိုကောင်းမွန်အောင်ပြုလုပ်နိုင်သော ကိစ္စများစွာအဖြစ် ပိုင်းခြားပြီး ပြုပြင်ပြီးသားကုဒ်ကို အသုံးပြုပါသည်။

အိပ်မက်ဆိုးတစ်ခု ဖြစ်ခဲ့သည်။ နှစ်များစွာကြာပြီးနောက်တွင် ကျွန်ုပ်၏ကုဒ်ကို အမွေဆက်ခံသော ပရိုဂရမ်မာသည် ကျွန်ုပ်အား မုန်းတီးကြောင်း ပြောပြခဲ့ပါသည်။

သင်ခန်းစာယူခဲ့ပါတယ်။

David Patterson နှင့် John Hennessy တို့သည် Computer Architecture နှင့် Computer Systems Design တွင် ရေးသားခဲ့သလို၊ ဗိသုကာနှင့် ဒီဇိုင်း၏ အဓိက အခြေခံမူများထဲမှ တစ်ခုသည် ယေဘူယျအားဖြင့် အရာများကို တတ်နိုင်သမျှ မြန်မြန်ဆန်ဆန် လုပ်ဆောင်ရန် ဖြစ်သည်။

အဖြစ်များသော ကိစ္စများကို အရှိန်မြှင့်ခြင်းဖြင့် ရှားပါးသော ကိစ္စများကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်ခြင်းထက် စွမ်းဆောင်ရည်ကို ပိုမိုထိရောက်စွာ တိုးတက်စေမည်ဖြစ်သည်။ ရယ်စရာကောင်းတာက အဖြစ်များတာက ရှားရှားပါးပါး ကိစ္စတွေထက် ပိုရိုးရှင်းပါတယ်။ ဤယုတ္တိဗေဒအကြံပြုချက်သည် မည်သည့်ကိစ္စတွင် အဖြစ်များသည်ဟု ယူဆသည်ကို သင်သိသည်ဟု ယူဆသည်၊ ၎င်းသည် ဂရုတစိုက်စမ်းသပ်ခြင်းနှင့် တိုင်းတာခြင်းလုပ်ငန်းစဉ်အားဖြင့်သာ ဖြစ်နိုင်သည်။

ကျွန်ုပ်၏ကာကွယ်မှုတွင်၊ ဌာနခွဲထုတ်ပြန်ချက်များသည် လက်တွေ့တွင် မည်သို့ပုံသဏ္ဍာန်ရှိသနည်း (ဥပမာ ဘဏ်ခွဲမည်မျှရှိ၍ ကိန်းသေများကို မည်ကဲ့သို့ ဖြန့်ဝေခဲ့သည်) ကို အဖြေရှာရန် ကြိုးစားခဲ့သော်လည်း 1988 ခုနှစ်တွင် ဤအချက်အလက်ကို မရရှိနိုင်ပါ။ သို့သော်လည်း၊ လက်ရှိ compiler သည် ကျွန်တော်တင်ပြခဲ့သော ဥပမာအတုအတွက် အကောင်းဆုံးကုဒ်ကို မထုတ်ပေးနိုင်သည့်အခါတိုင်း အထူးကိစ္စရပ်များကို မထည့်သင့်ပါ။

အတွေ့အကြုံရှိတဲ့ ဆော့ဖ်ဝဲအင်ဂျင်နီယာကို ခေါ်ဖို့ လိုအပ်ပြီး သူနဲ့ အတူ အဖြစ်များတဲ့ ကိစ္စတွေကို တွေးပြီး အတိအကျ ကိုင်တွယ်ဖြေရှင်းဖို့ လိုပါတယ်။ ကုဒ်နည်းနည်းရေးချင်ပေမယ့် အဲဒါကောင်းပါတယ်။ Stack Overflow တည်ထောင်သူ Jeff Atwood ရေးခဲ့သလိုပဲ ပရိုဂရမ်မာတစ်ယောက်ရဲ့ အဆိုးဆုံးရန်သူက ပရိုဂရမ်မာကိုယ်တိုင်ပါပဲ။

ငါတို့အားလုံးလိုပဲ မင်းမှာ အကောင်းဆုံး ရည်ရွယ်ချက်တွေ ရှိတယ်ဆိုတာ ငါသိတယ်။ ကျွန်ုပ်တို့သည် ပရိုဂရမ်များကို ဖန်တီးပြီး ကုဒ်ရေးရန် နှစ်သက်ကြသည်။ ဒါပဲ ငါတို့လုပ်တယ်။ မည်သည့်ပြဿနာမဆို ပြွန်တိပ်၊ အိမ်လုပ် တုတ်တံနှင့် ကုဒ်အနည်းငယ်ဖြင့် ဖြေရှင်းနိုင်သည်ဟု ကျွန်ုပ်တို့ထင်ပါသည်။ ဝန်ခံရန်ကုဒ်သမားများကို နာကျင်စေသကဲ့သို့၊ အကောင်းဆုံးကုဒ်သည် မရှိသောကုဒ်ဖြစ်သည်။ လိုင်းအသစ်တစ်ခုစီတိုင်းသည် အမှားရှာပြင်ခြင်းနှင့် ပံ့ပိုးကူညီမှုများ လိုအပ်သည်၊ ၎င်းကို နားလည်ရန် လိုအပ်သည်။ ကုဒ်အသစ်ထည့်သည့်အခါ၊ အခြားရွေးချယ်စရာအားလုံး ကုန်သွားသောကြောင့် တွန့်ဆုတ်ပြီး စက်ဆုပ်ရွံရှာသင့်ပါသည်။ ပရိုဂရမ်မာ တော်တော်များများက ကုဒ်တွေ အများကြီး ရေးကြလို့ ငါတို့ရန်သူ ဖြစ်လာတယ်။

သာမာန်ကိစ္စများကို အကျုံးဝင်စေသော ရိုးရှင်းသောကုဒ်ကို ကျွန်ုပ်ရေးခဲ့လျှင် လိုအပ်ပါက အပ်ဒိတ်လုပ်ရန် ပိုမိုလွယ်ကူပါလိမ့်မည်။ ဘယ်သူမှ မကိုင်တွယ်ချင်သော အရှုပ်အထွေးကို ချန်ထားခဲ့မိသည်။

ဒုတိယနေရာ - လူမှုကွန်ရက်ပေါ်တွင် ကြော်ငြာခြင်း။

ဆိုရှယ်မီဒီယာကြော်ငြာမှာ Google မှာ အလုပ်လုပ်တုန်းက (Myspace ကို မှတ်မိလား)၊ 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)) {
  }
}

ပရိုဂရမ်မာများသည် အမှားကို ချက်ချင်းမြင်နိုင်သည်- နောက်ဆုံးအငြင်းအခုံမှာ j ဖြစ်သင့်သည်၊ မဟုတ်ဘဲ i ဖြစ်သင့်သည်။ ယူနစ်စမ်းသပ်ခြင်းတွင် အမှားအယွင်းကို မဖော်ပြဘဲ ကျွန်ုပ်၏သုံးသပ်သူလည်း မပါဝင်ပါ။ လွှင့်တင်ခြင်း လုပ်ဆောင်ပြီး တစ်ညတွင် ကျွန်ုပ်၏ကုဒ်သည် ဆာဗာသို့သွား၍ ဒေတာစင်တာရှိ ကွန်ပျူတာများအားလုံး ပျက်စီးသွားပါသည်။

ဆိုးဆိုးရွားရွား ဘာမှမဖြစ်ခဲ့ပါ။ အဘယ်ကြောင့်ဆိုသော် ကမ္ဘာလုံးဆိုင်ရာ စတင်မဖြန့်ချိမီ ဒေတာစင်တာတစ်ခုတွင် ကုဒ်ကို စမ်းသပ်ပြီးဖြစ်သောကြောင့် မည်သူတစ်ဦးတစ်ယောက်အတွက်မျှ အဆင်မပြေပါ။ SRE အင်ဂျင်နီယာများသည် ဘိလိယက်ကစားခြင်းကို ခဏတာရပ်ပြီး အနည်းငယ်ပြန်မကစားပါက၊ နောက်နေ့မနက်မှာ crash dump ပါတဲ့ အီးမေးလ်တစ်စောင်ကို လက်ခံရရှိပြီး ကုဒ်ကို ပြုပြင်ပြီး error ဖမ်းနိုင်မယ့် ယူနစ်စမ်းသပ်မှုတွေ ထပ်ထည့်ပါတယ်။ ကျွန်ုပ်သည် ပရိုတိုကောကို လိုက်နာသည် - မဟုတ်ပါက ကျွန်ုပ်၏ကုဒ်သည် ရိုးရိုးရှင်းရှင်း လည်ပတ်ရန် ပျက်ကွက်သွားသည် - အခြားပြဿနာများ မရှိပါ။

သင်ခန်းစာယူခဲ့ပါတယ်။

ထိုသို့သော ကြီးကြီးမားမားအမှားသည် တရားခံထုတ်ပယ်ခံရခြင်းအတွက် ကျိန်းသေသေချာသည်မှာ သေချာသည်၊ သို့သော် ထိုသို့မဟုတ်ပါ- ပထမဦးစွာ၊ ပရိုဂရမ်မာများအားလုံး အမှားလုပ်ကြပြီး ဒုတိယအနေဖြင့် တူညီသောအမှားကို နှစ်ကြိမ်ပြုလုပ်ခဲပါသည်။

တကယ်တော့ ကျွန်တော့်မှာ ထူးချွန်တဲ့ အင်ဂျင်နီယာတစ်ယောက်ဖြစ်ပြီး အမှားတစ်ခုကြောင့် အလုပ်ထုတ်ခံရတဲ့ ပရိုဂရမ်မာသူငယ်ချင်းတစ်ယောက်ရှိပါတယ်။ အဲဒီနောက်မှာတော့ သူ့ကို Google မှာ ငှားရမ်းခြင်းခံရပြီး (မကြာခင်မှာ ရာထူးတိုးခြင်း) - အင်တာဗျူးတစ်ခုမှာ သူလုပ်ခဲ့တဲ့ အမှားအကြောင်း ရိုးရိုးသားသားပြောခဲ့ပြီး ဒါဟာ အသက်အန္တရာယ်မဖြစ်စေပါဘူး။

အဲဒါဘာလဲ ပြောပြပါ။ IBM ၏ ဂန္တဝင် အကြီးအကဲ Thomas Watson အကြောင်း

ဒေါ်လာတစ်သန်းခန့်တန်ဖိုးရှိ အစိုးရအမိန့်ကို ထုတ်ပြန်ကြေညာခဲ့သည်။ IBM Corporation - ဒါမှမဟုတ် Thomas Watson Sr. ကိုယ်တိုင်ကိုယ်ကျ - အဲဒါကို တကယ်လိုချင်ခဲ့တယ်။ ကံမကောင်းစွာပဲ၊ အရောင်းကိုယ်စားလှယ်က ဒါကို မလုပ်ဆောင်နိုင်ခဲ့လို့ IBM က လေလံကို ဆုံးရှုံးခဲ့ရပါတယ်။ နောက်တစ်နေ့တွင် ဤဝန်ထမ်းသည် မစ္စတာ Watson ၏ ရုံးခန်းသို့ ရောက်ရှိလာပြီး ၎င်း၏ စားပွဲပေါ်တွင် စာအိတ်တစ်ခု ချထားခဲ့သည်။ Mr. Watson သည် ၎င်းကိုကြည့်ရန်ပင် စိတ်မ၀င်စားခဲ့ဘဲ ဝန်ထမ်းတစ်ဦးကို စောင့်ဆိုင်းနေပြီး ၎င်းသည် နုတ်ထွက်စာဖြစ်ကြောင်း သိရှိခဲ့သည်။

Watson က ဘာဖြစ်သွားတာလဲလို့ မေးတယ်။

တင်ဒါအောင်မြင်မှုနှင့်ပတ်သက်၍ အရောင်းကိုယ်စားလှယ်မှ အသေးစိတ်ရှင်းလင်းပြောကြားခဲ့ပါသည်။ ရှောင်လွှဲနိုင်သော အမှားများဟု အမည်ပေးခဲ့သည်။ နောက်ဆုံးတွင် သူက “မစ္စတာဝပ်ဆန်၊ ကျွန်တော့်ကို ရှင်းပြခွင့်ပေးတဲ့အတွက် ကျေးဇူးတင်ပါတယ်။ ဒီအမိန့်စာ ဘယ်လောက် လိုအပ်တယ်ဆိုတာ သိပါတယ်။ သူဘယ်လောက်အရေးကြီးတယ်ဆိုတာ ကျွန်တော်သိပါတယ်” လို့ ပြောပြီး ထွက်ခွာဖို့ ပြင်ဆင်ခဲ့ပါတယ်။

Watson သည် တံခါးဝသို့ ချဉ်းကပ်ကာ မျက်လုံးများကို ကြည့်လိုက်ကာ စာအိတ်ကို ပြန်ပေးသည်- “မင်းကို ငါ ဘယ်လို လွှတ်နိုင်မလဲ။ မင်းရဲ့ပညာရေးအတွက် ဒေါ်လာတစ်သန်းလောက် ရင်းနှီးမြှုပ်နှံခဲ့တယ်။

ငါ့မှာ တီရှပ်တစ်ထည်ရှိတယ်- "မင်းအမှားတွေကနေ တကယ်သင်ခန်းစာယူမယ်ဆိုရင် ငါက သခင်ဖြစ်နေပြီ" တဲ့။ တကယ်တော့ အမှားတွေကြုံလာတဲ့အခါ ငါဟာ သိပ္ပံပညာရဲ့ ဆရာဝန်တစ်ယောက်ပါ။

ပထမနေရာ- App Inventor API

အမှန်တကယ် ကြောက်မက်ဖွယ်ကောင်းသော အမှားများသည် သုံးစွဲသူအများအပြားကို ထိခိုက်စေပြီး၊ အများသူငှာ အသိပညာများ ဖြစ်လာစေရန်၊ ပြုပြင်ရန် အချိန်အတော်ကြာကာ ၎င်းတို့ကို မဖန်တီးနိုင်သူများမှ ဖန်တီးထားခြင်းဖြစ်သည်။ ကျွန်ုပ်၏ အကြီးမားဆုံးအမှားမှာ ဤစံနှုန်းအားလုံးနှင့် ကိုက်ညီပါသည်။

ပိုဆိုးလေ ပိုကောင်းလေပါပဲ။

ကျွန်တော်ဖတ်သည် Richard Gabriel ရေးတဲ့ စာစီစာကုံး ဘွဲ့ရကျောင်းသားတစ်ယောက်အနေနဲ့ ကိုးဆယ်ကျော်လောက်က ဒီချဉ်းကပ်နည်းကို ကျွန်တော်အရမ်းကြိုက်လို့ ကျောင်းသားတွေကို မေးကြည့်တယ်။ ကောင်းကောင်းမမှတ်မိရင် မှတ်ဉာဏ်ကို ပြန်လည်ဆန်းသစ်ပြီး သေးငယ်ပါတယ်။ ဤစာစီစာကုံးသည် ရိုးရှင်းခြင်းအပါအဝင် နည်းလမ်းများစွာဖြင့် “ပိုဆိုးသည် ပိုကောင်းသည်” ချဉ်းကပ်လိုသောဆန္ဒနှင့် ဆန့်ကျင်ဘက်ဖြစ်သည်။

၎င်းသည် မည်သို့ဖြစ်သင့်သည်- ဒီဇိုင်းသည် အကောင်အထည်ဖော်မှုနှင့် interface တွင် ရိုးရှင်းသင့်သည်။ အင်တာဖေ့စ်၏ရိုးရှင်းမှုသည် အကောင်အထည်ဖော်မှုရိုးရှင်းခြင်းထက် ပိုအရေးကြီးသည်။

ပိုဆိုးသည်က ပိုကောင်းသည်- ဒီဇိုင်းသည် အကောင်အထည်ဖော်မှုနှင့် interface တွင် ရိုးရှင်းသင့်သည်။ အကောင်အထည်ဖော်မှု၏ရိုးရှင်းမှုသည် အင်တာဖေ့စ်၏ရိုးရှင်းမှုထက် ပိုအရေးကြီးသည်။

အဲဒါကို တစ်မိနစ်လောက် မေ့ထားလိုက်ရအောင်။ ကံမကောင်းစွာပဲ၊ အဲဒါကို နှစ်ပေါင်းများစွာ မေ့သွားခဲ့တယ်။

App တီထွင်သူ

Google မှာ အလုပ်လုပ်တုန်းက ကျွန်တော်ဟာ အဖွဲ့ထဲမှာ ပါဝင်ခဲ့ပါတယ်။ App တီထွင်သူအလိုရှိသော Android developer များအတွက် ဆွဲယူ၍ချပေးသည့် အွန်လိုင်းဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်။ 2009 ခုနှစ်ဖြစ်ပြီး၊ နွေရာသီတွင် နွေရာသီတွင် စာသင်သည့်အခါ ပတ်ဝန်းကျင်ကို အသုံးပြုနိုင်သည့် ဆရာများအတွက် မာစတာအတန်းများ ကျင်းပနိုင်စေရန်အတွက် ကျွန်ုပ်တို့သည် အယ်လ်ဖာဗားရှင်းကို အချိန်မီထုတ်ရန် အလျင်လိုနေပါသည်။ TI-99/4 မှာ ဂိမ်းတွေရေးခဲ့ဖူးတာကို လွမ်းဆွတ်လွမ်းဆွတ်ရင်း sprites ကို အကောင်အထည်ဖော်ဖို့ စေတနာ့ဝန်ထမ်းလုပ်ခဲ့တယ်။ မသိသူများအတွက်၊ sprite သည် အခြားဆော့ဖ်ဝဲလ်ဒြပ်စင်များနှင့် ရွေ့လျားနိုင်ပြီး အပြန်အလှန်အကျိုးပြုနိုင်သော နှစ်ဖက်မြင်ဂရပ်ဖစ်အရာဝတ္ထုတစ်ခုဖြစ်သည်။ sprites ၏ဥပမာများတွင် အာကာသယာဉ်များ၊ ဂြိုဟ်သိမ်များ၊ စကျင်ကျောက်များနှင့် ရက်ကွက်များ ပါဝင်သည်။

ကျွန်ုပ်တို့သည် Java တွင် object-oriented App Inventor ကို အကောင်အထည်ဖော်ခဲ့သည်၊ ထို့ကြောင့် ထိုနေရာတွင် အရာဝတ္ထုများစွာရှိသည်။ ဘောလုံးများနှင့် sprites များသည် အလွန်ဆင်တူသောကြောင့်၊ ကျွန်ုပ်သည် ဂုဏ်သတ္တိများ (အကွက်များ) X၊ Y၊ Speed ​​(အမြန်နှုန်း) နှင့် Heading (လမ်းကြောင်း) တို့ပါရှိသော abstract sprite အတန်းကို ဖန်တီးခဲ့သည်။ ၎င်းတို့တွင် တိုက်မိမှုများကို ထောက်လှမ်းရန်၊ ဖန်သားပြင်အစွန်းမှ ခုန်ထွက်ခြင်းစသည်ဖြင့် တူညီသောနည်းလမ်းများ ရှိသည်။

ဘောလုံးနှင့် sprite အကြား အဓိကကွာခြားချက်မှာ အတိအကျရေးဆွဲထားသည် - ဖြည့်ထားသော စက်ဝိုင်း သို့မဟုတ် raster တစ်ခုဖြစ်သည်။ ကျွန်တော် sprites ကို ပထမဆုံး အကောင်အထည်ဖော်တဲ့အတွက်၊ ရုပ်ပုံတည်ရှိရာရဲ့ ဘယ်ဘက်အပေါ်ထောင့်ရဲ့ x- နဲ့ y-coordinates တွေကို သတ်မှတ်ရတာ ယုတ္တိရှိပါတယ်။

sprites တွေအလုပ်လုပ်ပြီးတာနဲ့၊ ကုဒ်နည်းနည်းနဲ့ ဘောလုံးအရာဝတ္ထုတွေကို အကောင်အထည်ဖော်ဖို့ ဆုံးဖြတ်ခဲ့တယ်။ တစ်ခုတည်းသော ပြဿနာမှာ ဘောလုံးကို ဘောင်သွင်းသည့် ကွန်တို၏ ဘယ်ဘက်အပေါ်ထောင့်ရှိ x- နှင့် y-coordinates များကို ညွှန်ပြသော အရိုးရှင်းဆုံး လမ်းကြောင်း (အကောင်အထည်ဖော်သူ၏ မြင်ကွင်းမှ) ကို ယူခဲ့ခြင်း ဖြစ်သည်။

အမှန်မှာ၊ သင်္ချာဖတ်စာအုပ်နှင့် စက်ဝိုင်းများကိုဖော်ပြသော အခြားအရင်းအမြစ်တစ်ခုခုတွင် သင်ကြားထားသည့်အတိုင်း စက်ဝိုင်း၏အလယ်ဗဟို၏ x နှင့် y-coordinates များကို ညွှန်ပြရန် လိုအပ်ပါသည်။

ကျွန်ုပ်၏ယခင်အမှားများနှင့်မတူဘဲ၊ ဤအရာသည် ကျွန်ုပ်၏လုပ်ဖော်ကိုင်ဖက်များသာမက App Inventor အသုံးပြုသူသန်းပေါင်းများစွာကိုလည်း ထိခိုက်စေပါသည်။ အများစုမှာ ကလေးသူငယ်များ သို့မဟုတ် ပရိုဂရမ်ရေးဆွဲခြင်းအတွက် လုံးဝအသစ်အဆန်းများဖြစ်သည်။ ဘောလုံးရှိနေသည့် application တစ်ခုစီတွင် လုပ်ဆောင်သည့်အခါ မလိုအပ်သော အဆင့်များစွာကို လုပ်ဆောင်ခဲ့ရသည်။ တခြားအမှားတွေကို ရယ်မောရင်း သတိရမိရင် ဒီနေ့တောင် ချွေးထွက်စေတယ်။

မကြာသေးမီကပဲ၊ ဆယ်နှစ်အကြာတွင် ငါသည် ဤ bug ကို နောက်ဆုံးတွင် ဖာထေးခဲ့သည်။ Joshua Bloch ကပြောသည့်အတိုင်း API များသည် ထာဝရတည်မြဲနေသောကြောင့် "Patched" မဟုတ်ဘဲ "Patched" ဖြစ်သည်။ လက်ရှိပရိုဂရမ်များအပေါ် သက်ရောက်မှုရှိမည့် အပြောင်းအလဲများကို မပြုလုပ်နိုင်ပါက၊ ကျွန်ုပ်တို့သည် ပရိုဂရမ်ဟောင်းများတွင် false တန်ဖိုးဖြင့် OriginAtCenter ပိုင်ဆိုင်မှုကို ထည့်သွင်းပြီး အနာဂတ်အားလုံးတွင် မှန်ပါသည်။ အသုံးပြုသူများသည် ယုတ္တိကျသောမေးခွန်းကို မေးနိုင်သည်- စင်တာမှလွဲ၍ အခြားတစ်နေရာတွင် အစမှတ်ကို နေရာချထားရန် တွေးတောနေပါသည်။ ဘယ်သူ့ထံ? လွန်ခဲ့သော ဆယ်နှစ်က ပုံမှန် API တစ်ခုကို ဖန်တီးရန် အလွန်ပျင်းရိသော ပရိုဂရမ်မာတစ်ဦးအတွက်။

သင်ခန်းစာများ

APIs များပေါ်တွင်အလုပ်လုပ်သောအခါ (ပရိုဂရမ်မာတိုင်းနီးပါးလုပ်ရလေ့ရှိသည်)၊ Joshua Bloch ၏ဗီဒီယိုတွင်ဖော်ပြထားသောအကောင်းဆုံးအကြံဉာဏ်ကို လိုက်နာသင့်သည်။ကောင်းမွန်တဲ့ API တစ်ခုကို ဘယ်လိုဖန်တီးမလဲ၊ ဘာကြောင့် အရမ်းအရေးကြီးတာလဲ။"သို့မဟုတ် ဤစာရင်းတိုတွင်:

• API တစ်ခုသည် သင့်အား ကြီးစွာသောအကျိုးနှင့် ကြီးစွာသောဒုက္ခနှစ်ခုလုံးကို ယူဆောင်လာနိုင်သည်။. ကောင်းသော API သည် ထပ်ခါတလဲလဲ ဝယ်ယူသူများကို ဖန်တီးပေးသည်။ မကောင်းတဲ့ဟာက မင်းရဲ့ထာဝရအိပ်မက်ဆိုးဖြစ်လာတယ်။
• စိန်များကဲ့သို့ အများသူငှာ API များသည် ထာဝရတည်မြဲသည်။. အားလုံးကို ပေးလိုက်ပါ- အရာရာတိုင်းကို မှန်အောင်လုပ်ဖို့ နောက်ထပ်အခွင့်အရေးဆိုတာ ဘယ်တော့မှ ရှိမှာမဟုတ်ဘူး။
• API အကြမ်းဖျဉ်းဖြစ်သင့်သည်။ — စာကြောင်းတစ်ကြောင်းထက်မပိုဘဲ အတန်းနှင့်နည်းလမ်း လက်မှတ်များနှင့် ဖော်ပြချက်များပါရှိသော စာမျက်နှာတစ်ခု။ ၎င်းသည် ပထမအကြိမ်တွင် ပြီးပြည့်စုံမှုမရှိပါက API ကို အလွယ်တကူ ပြန်လည်ဖွဲ့စည်းနိုင်မည်ဖြစ်သည်။
• အသုံးပြုမှုကိစ္စများကိုဖော်ပြပါ။API ကို အကောင်အထည်မဖော်မီ သို့မဟုတ် ၎င်း၏သတ်မှတ်ချက်အပေါ် လုပ်ဆောင်ခြင်းပင်။ ဤနည်းအားဖြင့် သင်သည် လုံးဝအလုပ်မလုပ်သော API ကို အကောင်အထည်ဖော်ခြင်းနှင့် သတ်မှတ်ခြင်းတို့ကို ရှောင်ကြဉ်ပါမည်။

အကယ်၍ ကျွန်ုပ်သည် ဇာတ်ညွှန်းအတုဖြင့် အတိုကောက်အကျဉ်းချုပ်ကိုပင် ရေးခဲ့မည်ဆိုလျှင်၊ အမှားအယွင်းကို ဖော်ထုတ်ပြီး ပြင်နိုင်ဖွယ်ရှိသည်။ မဟုတ်ရင် ငါ့လုပ်ဖော်ကိုင်ဖက်တစ်ယောက်က သေချာပေါက် လုပ်လိမ့်မယ်။ ကြီးမားကျယ်ပြန့်သော အကျိုးဆက်များရှိသည့် ဆုံးဖြတ်ချက်တိုင်းကို အနည်းဆုံး တစ်ရက်ခန့် စဉ်းစားရန် လိုအပ်သည် (၎င်းသည် ပရိုဂရမ်ရေးဆွဲခြင်းအတွက်သာမက)။

Richard Gabriel ၏ "Worse Is Better" ဟူသော စာစီစာကုံး ခေါင်းစဉ်သည် မစုံလင်သော ထုတ်ကုန်တစ်ခုနှင့်ပင် စျေးကွက်သို့ ဦးစွာရောက်ရှိသွားသည့် အားသာချက်ကို ရည်ညွှန်းသည်- အခြားသူသည် ပြီးပြည့်စုံသော အရာကို ထာဝရ လိုက်ရှာနေချိန်တွင်ပင် ဖြစ်သည်။ sprite ကုဒ်ကို ပြန်တွေးကြည့်တော့ ကုဒ်မှန်ဖို့ ကုဒ်တွေ ထပ်ရေးဖို့တောင် မလိုဘူးဆိုတာ သိလိုက်ရတယ်။ ဘာပဲပြောပြော ကျွန်တော် လုံးလုံးလျားလျား မှားသွားတယ်။

ကောက်ချက်

ပရိုဂရမ်မာများသည် ၎င်းတို့၏ ကျွမ်းကျင်မှုနှင့် ကုန်ထုတ်စွမ်းအားကို တိုးတက်စေမည့် အရာတစ်ခုခုကို မကြိုးစားလိုသည်ဖြစ်စေ buggy code ရေးသည်ဖြစ်စေ နေ့တိုင်း အမှားအယွင်းများလုပ်ကြသည်။ ဟုတ်ပါတယ်၊ ငါလုပ်ခဲ့သလိုမျိုး ကြီးလေးတဲ့အမှားတွေမလုပ်ဘဲ ပရိုဂရမ်မာတစ်ယောက်ဖြစ်နိုင်ပါတယ်။ ဒါပေမယ့် မင်းရဲ့အမှားတွေကို အသိအမှတ်ပြုပြီး သင်ခန်းစာမယူဘဲ ပရိုဂရမ်မာကောင်းတစ်ယောက်ဖြစ်ဖို့ဆိုတာ မဖြစ်နိုင်ပါဘူး။

အမှားတွေအများကြီးလုပ်မိသလိုခံစားရတဲ့ ကျောင်းသားတွေကို အမြဲကြုံတွေ့နေရပြီး ပရိုဂရမ်ရေးခြင်းအတွက် ဖြတ်မထားပါ။ IT မှာ အဖြစ်များတဲ့ impostor syndrome ဆိုတာ သိပါတယ်။ ကျွန်ုပ်ဖော်ပြထားသောသင်ခန်းစာများကို သင်လေ့လာနိုင်လိမ့်မည်ဟု မျှော်လင့်ပါသည် - သို့သော် အဓိကအချက်ကို သတိရပါ - ကျွန်ုပ်တို့တစ်ဦးစီသည် အမှားများပြုလုပ်ကြသည် - ရှက်စရာ၊ ရယ်စရာ၊ ကြောက်စရာကောင်းသည်။ နောင်တွင် ကျွန်ုပ်တွင် ဆောင်းပါးကို ဆက်လက်ရေးသားရန် လုံလောက်သော အကြောင်းအရာ မရှိပါက ကျွန်ုပ် အံ့အားသင့်ပြီး စိတ်မကောင်း ဖြစ်ပါမည်။

source: www.habr.com