Тэдний хэлснээр, хэрэв та хуучин кодоосоо ичихгүй бол програмист болж өсөөгүй гэсэн үг - би энэ саналтай санал нийлж байна. Би 40 гаруй жилийн өмнөөс, мэргэжлийн хувьд 30 гаруй жилийн өмнөөс хөгжилтэй байхын тулд программ хийж эхэлсэн болохоор надад маш их алдаа гардаг. маш их. Компьютерийн шинжлэх ухааны профессорын хувьд би оюутнууддаа тэдний, миний болон бусдын алдаанаас суралцахыг заадаг. Даруу зангаа алдахгүйн тулд алдаагаа ярих цаг болсон гэж бодож байна. Тэд хэн нэгэнд хэрэг болно гэж найдаж байна.

Гуравдугаар байр - Microsoft C хөрвүүлэгч

Сургуулийн багш маань Ромео, Жульетта хоёрыг эмгэнэлт явдал гэж үзэх боломжгүй, учир нь дүрүүд нь эмгэнэлт гэм буруугүй гэж үздэг байсан - тэд өсвөр насны хүүхдүүдийн адил тэнэг авир гаргасан. Би тэр үед түүнтэй санал нийлэхгүй байсан ч одоо түүний бодлоор, ялангуяа програмчлалтай холбоотой оновчтой байдлын үр тариаг олж харж байна.

Би MIT-ийн 86-р курсээ төгсөхдөө амьдрал болон программчлалын тал дээр залуу, туршлагагүй байсан. Зуны улиралд би Майкрософт компанид Си хөрвүүлэгчийн багт дадлага хийсэн.Эхлээд би профайл үүсгэх дэмжлэг гэх мэт энгийн зүйлсийг хийдэг байсан бөгөөд дараа нь хөрвүүлэгчийн хамгийн хөгжилтэй хэсэг (миний бодсоноор) backend optimization дээр ажиллахыг надад даалгасан. Ялангуяа би салбар мэдэгдлийн xXNUMX кодыг сайжруулах шаардлагатай болсон.

Боломжит тохиолдол бүрт оновчтой машины кодыг бичихээр шийдсэн тул би усан сан руу толгойгоо гашилгалаа. Хэрэв утгуудын тархалтын нягтрал өндөр байсан бол би тэдгээрийг оруулсан шилжилтийн хүснэгт. Хэрэв тэд нийтлэг хуваагчтай байсан бол би үүнийг хүснэгтийг чангаруулахын тулд ашигласан (гэхдээ зөвхөн хуваагчийг ашиглан хуваах боломжтой байсан бол) бит шилжилт). Бүх утгууд хоёрын хүч байх үед би өөр оновчлол хийсэн. Хэрэв утгуудын багц миний нөхцөлийг хангаагүй бол би үүнийг хэд хэдэн оновчтой тохиолдлуудад хувааж, аль хэдийн оновчтой болгосон кодыг ашигласан.

Энэ бол хар дарсан зүүд байсан. Олон жилийн дараа миний кодыг өвлөн авсан программист намайг үзэн яддаг гэж хэлсэн.

Сурсан хичээл

Дэвид Паттерсон, Жон Хеннесси нар "Компьютерийн архитектур ба компьютерийн системийн дизайн" номдоо бичсэнчлэн архитектур, дизайны үндсэн зарчмуудын нэг нь аливаа зүйлийг аль болох хурдан ажиллуулах явдал юм.

Нийтлэг тохиолдлуудыг хурдасгах нь ховор тохиолдлуудыг оновчтой болгохоос илүү үр дүнтэй гүйцэтгэлийг сайжруулах болно. Хачирхалтай нь нийтлэг тохиолдлууд нь ховор тохиолдлуудаас илүү хялбар байдаг. Энэхүү логик зөвлөгөө нь аль тохиолдлуудыг нийтлэг гэж үздэгийг мэддэг гэж үздэг бөгөөд энэ нь зөвхөн нарийн шалгалт, хэмжилтийн үйл явцаар л боломжтой юм.

Би өмгөөллийн хувьд практикт салбар хэллэгүүд ямар харагддагийг (хэдэн салбартай, хэрхэн тогтмол тархсан гэх мэт) олж мэдэхийг оролдсон боловч 1988 онд энэ мэдээлэл байхгүй байсан. Гэсэн хэдий ч одоогийн хөрвүүлэгч миний зохиосон зохиомол жишээний оновчтой кодыг үүсгэж чадахгүй байх үед би онцгой тохиолдлуудыг нэмэх ёсгүй байсан.

Би туршлагатай хөгжүүлэгчийг дуудаж, түүнтэй хамт нийтлэг тохиолдлууд юу болохыг бодож, тэдгээрийг тусгайлан шийдвэрлэх шаардлагатай болсон. Би бага код бичнэ, гэхдээ энэ нь сайн хэрэг. Stack Overflow-ийг үндэслэгч Жефф Атвудын бичсэнээр програмист хүний ​​хамгийн муу дайсан бол програмист өөрөө юм.

Та бид бүгдийн адил хамгийн сайн санаатай гэдгийг би мэднэ. Бид программ зохиодог бөгөөд код бичих дуртай. Ингэж л бид бүтээгдсэн. Ямар ч асуудлыг наалдамхай тууз, гар хийцийн таяг, чимх кодоор шийдэж болно гэж бид боддог. Кодерчид үүнийг хүлээн зөвшөөрөхөд хичнээн их зовж байгаа ч хамгийн сайн код бол байхгүй код юм. Шинэ мөр бүрт дибаг хийх, дэмжих шаардлагатай тул үүнийг ойлгох хэрэгтэй. Та шинэ код нэмэхдээ бусад бүх сонголт дууссан тул дурамжхан, дургүйцсэн байдлаар хийх хэрэгтэй. Олон програмистууд хэтэрхий их код бичдэг нь бидний дайсан болгодог.

Хэрэв би энгийн тохиолдлуудыг хамарсан энгийн код бичсэн бол шаардлагатай бол шинэчлэхэд илүү хялбар байх байсан. Би хэний ч шийдэхийг хүсээгүй эмх замбараагүй байдлыг үлдээсэн.

Хоёрдугаар байр: нийгмийн сүлжээн дэх сурталчилгаа

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

Программистууд алдааг шууд олж харж магадгүй: сүүлчийн аргумент нь i биш, j байх ёстой. Нэгжийн туршилт нь алдааг илрүүлээгүй бөгөөд миний шүүмжлэгч ч илрүүлээгүй. Эхлэх ажиллагаа явагдаж, нэг шөнө миний код серверт очиж, дата төвийн бүх компьютерийг сүйрүүлсэн.

Муу юм болоогүй. Дэлхий даяар хөөргөхөөс өмнө кодыг нэг дата төвд туршиж үзсэн тул хэнд ч юу ч эвдэрсэнгүй. SRE инженерүүд хэсэг хугацаанд билльярд тоглохоо больж, бага зэрэг ухрахгүй бол. Маргааш өглөө нь би ослын хаягдал бүхий и-мэйл хүлээн авч, кодыг засч, алдааг илрүүлэх нэгжийн туршилтуудыг нэмсэн. Би протоколыг дагаж мөрдсөн тул - эс тэгвээс миний код ажиллахгүй болно - өөр ямар ч асуудал гараагүй.

Сурсан хичээл

Ийм том алдаа нь буруутанг ажлаас халах нь гарцаагүй гэдэгт олон хүн итгэлтэй байгаа ч энэ нь тийм биш юм: нэгдүгээрт, бүх програмистууд алдаа гаргадаг, хоёрдугаарт, нэг алдааг хоёр удаа хийх нь ховор.

Ер нь нэг л алдаа гаргачихаад ажлаасаа халагдсан мундаг инженер байсан программист найз бий. Үүний дараа тэрээр Google-д ажилд орсон (мөн удалгүй албан тушаал ахисан) - ярилцлага өгөхдөө хийсэн алдааныхаа талаар үнэнчээр хэлсэн бөгөөд энэ нь үхлийн аюултай гэж үзээгүй.

Энд юу байна хэлэх IBM-ийн домогт тэргүүн Томас Уотсоны тухай:

Сая орчим долларын үнэ бүхий засгийн газрын захиалга зарлагдсан. IBM корпораци, эс тэгвээс ахлагч Томас Ватсон хувьдаа үүнийг авахыг үнэхээр хүсч байсан. Харамсалтай нь борлуулалтын төлөөлөгч үүнийг хийж чадаагүй бөгөөд IBM тендерт ялагдсан. Маргааш нь энэ ажилтан ноён Ватсоны өрөөнд орж ирээд ширээн дээр нь дугтуй тавив. Ноён Ватсон үүнийг харахаас ч санаа зовсонгүй - тэр ажилтнаа хүлээж байсан бөгөөд энэ нь огцрох тухай захидал гэдгийг мэдэж байсан.

Ватсон юу болсон талаар асуув.

Худалдааны төлөөлөгч тендерийн явцын талаар дэлгэрэнгүй ярилаа. Тэрээр зайлсхийх боломжтой байсан алдаануудыг нэрлэв. Эцэст нь тэрээр “Ноён Ватсон, надад тайлбарлаж өгсөнд баярлалаа. Энэ захиалга бидэнд ямар их хэрэгтэй байсныг би мэднэ. Би түүнийг ямар чухал байсныг мэднэ” гэж хэлээд явахаар бэлдэв.

Ватсон түүн рүү үүдэнд ойртож, нүд рүү нь хараад: “Би чамайг яаж явуулах вэ? Би чиний боловсролд сая долларын хөрөнгө оруулалт хийсэн.

Надад "Хэрвээ чи үнэхээр алдаанаасаа суралцдаг бол би аль хэдийн мастер болсон" гэсэн бичигтэй цамцтай. Ер нь алдааны тухайд бол би шинжлэх ухааны доктор хүн.

Эхний байр: App Inventor API

Үнэхээр аймшигтай алдаанууд нь асар олон тооны хэрэглэгчдэд нөлөөлж, олон нийтэд мэдэгдэж, засахад удаан хугацаа шаардагддаг бөгөөд үүнийг хийх боломжгүй хүмүүс хийдэг. Миний хамгийн том алдаа бол эдгээр бүх шалгуурт нийцдэг.

Муу байх тусмаа сайн

Би уншдаг Ричард Габриэлийн эссэ XNUMX-ээд оны төгсөх ангийн оюутан байхдаа энэ аргын талаар би маш их дуртай байсан тул оюутнуудаасаа үүнийг асуудаг. Сайн санахгүй байгаа бол ой санамжаа сэргээ, жижигхэн шүү. Энэхүү эссэ нь "зөв болгох" хүсэл эрмэлзэл, "муу нь илүү сайн" гэсэн хандлагыг энгийн байдал гэх мэт олон талаараа харьцуулж харуулдаг.

Энэ нь яаж байх ёстой вэ: дизайн нь хэрэгжилт, интерфейсийн хувьд энгийн байх ёстой. Интерфейсийн энгийн байдал нь хэрэгжилтийн энгийн байдлаас илүү чухал юм.

Илүү муу байх тусмаа сайн: дизайн нь хэрэгжилт, интерфейсийн хувьд энгийн байх ёстой. Хэрэгжүүлэх энгийн байдал нь интерфейсийн энгийн байдлаас илүү чухал юм.

Энэ тухай нэг минут мартацгаая. Харамсалтай нь би үүнийг олон жил мартсан.

Апп зохион бүтээгч

Google-д ажиллаж байхдаа би багийн нэг хэсэг байсан Апп зохион бүтээгч, Android хөгжүүлэгчдэд зориулсан чирж, буулгах онлайн хөгжүүлэлтийн орчин. Энэ бол 2009 он бөгөөд бид альфа хувилбарыг цаг тухайд нь гаргахаар яарч байсан тул зун намар хичээл заахдаа хүрээлэн буй орчныг ашиглах боломжтой багш нарт зориулсан мастер ангиудыг зохион байгуулах боломжтой байсан. Би TI-99/4 дээр тоглоом бичдэг байснаа дурсаж, спрайтуудыг хэрэгжүүлэхээр сайн дураараа ажилласан. Мэдэхгүй хүмүүсийн хувьд спрайт нь хоёр хэмжээст график объект бөгөөд бусад програм хангамжийн элементүүдийг хөдөлгөж, харилцан үйлчлэх боломжтой. Спрайтуудын жишээнд сансрын хөлөг, астероид, гантиг, цохиур зэрэг орно.

Бид Java хэл дээр объект хандалтат програм зохион бүтээгчийг хэрэгжүүлсэн тул тэнд хэдхэн объект байгаа. Бөмбөг болон спрайтууд хоорондоо маш төстэй ажилладаг тул би X, Y, Хурд (хурд) болон Гарчиг (чиглэл) шинж чанаруудтай (талбарууд) хийсвэр спрайт анги үүсгэсэн. Тэд мөргөлдөөнийг илрүүлэх, дэлгэцийн ирмэгээс үсрэх гэх мэт ижил аргуудтай байсан.

Бөмбөлөг болон спрайт хоёрын гол ялгаа нь яг юу зурсан байдаг - дүүргэсэн тойрог эсвэл растер. Би эхлээд спрайтуудыг хэрэгжүүлсэн тул зураг байгаа газрын зүүн дээд булангийн х ба у координатыг зааж өгөх нь логиктой байсан.

Спрайтууд ажиллаж эхэлмэгц би маш бага кодтой бөмбөгний объектуудыг хэрэгжүүлж чадна гэж шийдсэн. Цорын ганц асуудал бол би бөмбөгийг хүрээлж буй контурын зүүн дээд булангийн х ба у координатыг харуулсан хамгийн энгийн замыг (хэрэглэгчийн үүднээс) сонгосон явдал байв.

Чухамдаа ямар ч математикийн сурах бичиг болон тойргийн тухай дурдсан бусад эх сурвалжид заасны дагуу тойргийн төвийн х, у координатыг зааж өгөх шаардлагатай байсан.

Миний өмнөх алдаанаас ялгаатай нь энэ алдаа нь зөвхөн миний хамтран ажиллагсад төдийгүй олон сая App Inventor хэрэглэгчдэд нөлөөлсөн. Тэдний олонх нь хүүхэд эсвэл програмчлалд цоо шинэ хүмүүс байсан. Бөмбөг байгаа програм бүр дээр ажиллахдаа тэд олон шаардлагагүй алхамуудыг хийх шаардлагатай болсон. Хэрэв би бусад алдаануудаа инээж санаж байвал энэ алдаа өнөөдөр ч миний хөлсийг урсгадаг.

Би энэ алдааг саяхан буюу арван жилийн дараа зассан. Жошуа Блокийн хэлснээр API нь мөнхийн байдаг тул "зассан" биш "зассан". Одоо байгаа програмуудад нөлөөлөх өөрчлөлтийг хийх боломжгүй тул бид OriginAtCenter шинж чанарыг хуучин програмуудад худал, цаашдын бүх програмуудад үнэн гэж нэмсэн. Хэрэглэгчид логик асуулт асууж магадгүй: хэн ч гэсэн эхлэлийн цэгийг төвөөс өөр газар байрлуулах талаар бодож байсан. Хэнд? Арван жилийн өмнө ердийн API үүсгэхээс залхуурсан нэгэн програмист.

Хичээл сурсан

API дээр ажиллахдаа (бараг бүх програмист заримдаа үүнийг хийх ёстой) Жошуа Блочийн видеонд дурдсан хамгийн сайн зөвлөгөөг дагах хэрэгтэй "Хэрхэн сайн API үүсгэх вэ, энэ нь яагаад ийм чухал вэ"Эсвэл энэ богино жагсаалтад:

• API нь танд маш их ашиг тус, асар их хор хөнөөлийг авчрах болно.. Сайн API нь дахин үйлчлүүлэгчдийг бий болгодог. Муу нь таны мөнхийн хар дарсан зүүд болно.
• Алмаз шиг нийтийн API нь үүрд мөнхөд үлддэг. Бүх зүйлээ зориул: бүх зүйлийг зөв хийх боломж дахин хэзээ ч гарахгүй.
• API тойм нь товч байх ёстой - нэг хуудас, анги, аргын гарын үсэг, тайлбар бүхий, нэг мөрөөс хэтрэхгүй. Энэ нь анх удаагаа төгс болж чадахгүй бол API-ийн бүтцийг хялбархан өөрчлөх боломжийг танд олгоно.
• Хэрэглэх тохиолдлуудыг тайлбарлана ууAPI-г хэрэгжүүлэхээс өмнө эсвэл түүний тодорхойлолт дээр ажиллахаас өмнө. Ингэснээр та бүрэн ажиллагаагүй API-г хэрэгжүүлэх, зааж өгөхөөс зайлсхийх болно.

Хэрэв би хиймэл скриптээр богино хэмжээний конспект бичсэн бол алдаагаа олж засч залруулах байсан байх. Үгүй бол миний нэг хамт олон үүнийг хийх нь гарцаагүй. Алс хэтийн үр дагавартай аливаа шийдвэрийг дор хаяж нэг өдрийн турш бодох хэрэгтэй (энэ нь зөвхөн програмчлалд хамаарахгүй).

Ричард Габриэлийн зохиолын гарчиг нь "Муу нь илүү сайн" гэдэг нь төгс бус бүтээгдэхүүнтэй ч гэсэн зах зээлд анхдагч байхын давуу талыг илэрхийлдэг бол өөр хэн нэгэн төгс бүтээгдэхүүний араас үүрд мөнхөд ордог. Спрайт кодын талаар эргэцүүлэн бодоход би үүнийг зөв болгохын тулд нэмэлт код бичих шаардлагагүй гэдгээ ойлгосон. Юу ч гэж хэлсэн би маш их андуурсан.

дүгнэлт

Программистууд алдаатай код бичих эсвэл тэдний ур чадвар, бүтээмжийг дээшлүүлэх ямар нэг зүйлийг туршиж үзэхийг хүсэхгүй байгаа эсэхээс үл хамааран өдөр бүр алдаа гаргадаг. Мэдээжийн хэрэг, та над шиг ийм ноцтой алдаа гаргахгүйгээр програмист байж чадна. Гэхдээ алдаагаа ухамсарлаж, түүнээс суралцахгүйгээр сайн програмист болно гэдэг боломжгүй.

Хэт их алдаа гаргадаг, тиймээс программчлахаас татгалздаггүй оюутнуудтай би байнга тааралддаг. Мэдээллийн технологид хууран мэхлэгч хам шинж хэр түгээмэл байдгийг би мэднэ. Та миний жагсаасан сургамжийг сурна гэж найдаж байна, гэхдээ гол зүйлийг санаарай: бидний хүн нэг бүр алдаа гаргадаг - ичгүүртэй, инээдтэй, аймшигтай. Ирээдүйд нийтлэлийг үргэлжлүүлэх хангалттай материал байхгүй бол би гайхаж, бухимдах болно.

Эх сурвалж: www.habr.com