Жирийн нэг оффисын өрөөнд вирус, өт батгана, хорхой шавж, тэсрэх бөмбөг, Трой -н модон морь, “үхлийн” алдаа байна гэвэл битгий гайхаарай. Иймэрхүү хурц, цочир хэллэгүүдийг гагц компьютерийн ухаанаас бусад ШУ -ны салбаруудад төдийлөн олж харахгүй тул тэрхүү өрөөнд нэгэн програмист сууж байгаагаас зайлахгүй юм. ПХ хөгжүүлэлтийн талаар илүү сайн ойлголттой болохыг хүсвэл иймэрхүү зүйрлэлүүдийг мэддэг байх нь зүйтэй юм.
Зүйрлэхийн ач тус
Өөрийн маруухан мэддэг зүйлийг түүнтэй ижил бөгөөд сайн мэддэг юмтайгаа адилтган үзвээс илүү амар хялбараар ойлгох боломж нээгддэг билээ. Зүйрлэлийг ийнхүү ашиглахыг “загварчлах” хэмээн нэрийддэг.
ШУ -ны олон ч нээлтийг хийхэд зүйрлэл их чухал үүрэг гүйцэтгэсэн байдаг. Химич Кекүлэ нэгэн шөнө сүүлээ хазсан могой зүүдэлсэн нь түүнтэй адил цагираг хэлбэртэй Бензиний молекулын бүтцийг тайлахад тусалсан байх жишээний.
Зарим зүйрлэл ийнхүү байгаа оносон байдаг бол зарим нь банзандаа ч тусаагүй байх тохиолдол бий. Ер нь сайн зүйрлэл гээч нь энгийн, бусад зүйрлэлтэйгээ нийцсэн утгатай байдаг юм.
Дахиад нэгэн жишээ дурьдъя. Хүнд чулууг олсоор дүүжилчихээд 2 тийш нь савлуулж байна гэж төсөөл. Аристотелийн сургуулийг баримтлагчидад үүнийг үзүүлсэн бол “Наад чулуу чинь дээд байрлалаасаа доош тайван байдал руу тэмүүлж байна” гэх байлаа. Гэтэл энэ үзэгдлийг түүнээс хойшхи Галилейн сургуулийг баримтлагчдад үзүүлсэн бол “Наадах чинь дүүжин байна. Чулуу 2 тал руугаа яг ижил зайг туулж байгааг нь харж байна уу” гэнэ. Эндээс л зүйрлэл, адилтгалын ялгаа харагдаж байгаа юм. Аристотелийнхон энэ үзэгдлээс чулууны жин, анхны өндөр, тайван байдалдаа очих өндөр зэргийг анхааран авч үзэх бол Галилейнхэн чулууны жингээс гадна, дүүжингийн савалгааны уртыг, савалгаа бүрт өөрчлөгдөх өнцгийн өөрчлөлтийг онцгойлон үзэх байв. Ингээд эцэст нь Аристотелийн дэг сургуулиар бол олж нээгдэхээргүй байгалийн хуулиудыг Галилейнхэн олж нээсэн юм. Гол ялгаа нь тэд зөв үзэгдлийг зүйрлэн бодож, зөв асуултыг өөрсдөөсөө асууцгаажээ.
Ийнхүү зүйрлэлийг зөв ашиглах нь програм хангамж хөгжүүлэхэд ч чухал нөлөөтэй юм. Орчин цагийн өгөгдлийн сангийн технологид үнэмлэхүй хувь нэмэр оруулан Тюрингийн шагналыг хүртсэн Charles Bachman 1970 -аад оны програмчлалын үеийг дэлхий төвт үзлээс нар төвт Коперникийн үзэл рүү шилжиж байх 16-р зууны үетэй зүйрлэжээ. Тэр үед өгөгдөл боловсруулалтын компьютер төвт үзлээс өгөгдлийн сан төвт үзэл рүү дөнгөж шилжиж байсан тул харин ч нэг тохирсон зүйрлэл болсон нь тэр.
Нар төвт үзлийн ачаар олон од эрхэсийг нээн илрүүлж хүн төрөлхтний хорвоо ертөнцийг үзэх үзлийг үндсээр нь өөрчилөн дэвшилд хүргэсний адилаар өгөгдлийн сан төвт үзэл нь мөн тийнхүү ахиц дэвшлийг авчирна гэсэн юм. Үүнээс тун ч удалгүй өгөгдлийг компьютерээр урсан өнгөрч буй картуудын урсгал гэж үздэг байсныг халж дээр нь үйлдэл гүйцэтгэх боломжтой “өгөгдлийн усан сан” гэж үзэх болжээ.
Ийнхүү шинэ соргог, үнэн зөв зүйрлэлийг хүлээн авах нь зүйтэй тул хуучинтайгаа зууралдан үлдэх нь тухайн ШУ -ны салбарын хөгжлийг хойш татах нөлөө үзүүлдэгийг анхаарууштай юм.
Тэгээд ч ер нь програм хангамжийн зүйрлэлүүдийг хэр сайн ойлгож байгаа нь тухайн хүн програм хангамжийг хэр сайн ойлгодог болохыг илтгэдэг билээ.
Програм хангамжид зүйрлэлийг яаж ашиглах вэ
Зүйрлэл болбоос газрын зураг биш гар чийдэн юм. Юу хийхийг чинь алхам бүрээр нь зааж өгөхгүй, харин зөв алхамыг өөрөө бодож олоход тань тусална гэсэн үг.
Тэгэхээр зүйрлэлийг алгоритмтэй шууд адилтгаж болохгүй болж байгаа юм. Жишээ нь хэн нэгний гэрт таныг хүргэх алгоритм байлаа гэж бодьё: “10 -р хорооллын автобусны буудлаас баруун тийш 500 метр яваад баруун эргэ, 50 метр яваад хурдаа сааруул” гэх мэт. Харин зүйрлэл байвал яах вэ? “Мессенжерээр явуулсан нөгөө хаягаар юу ч гэсэн хүрээд ир. Олохгүй байвал ойр орчныхоо хүмүүсээс асуухад л мэднэ дээ манай байрыг” гэх мэт.
Програмчлалын асуудал бүрийг яв цав заасан алгоритмаар шийдчихэж болдог бол уг нь сайхан. Гэхдээ энэ ШУ дэндүү залуу байгаа болоод ч тэр үү ойрын үед лав тийм болно гэж худлаа болов уу. Мөн програмчлалын хамгийн хүнд даваа нь концепцын асуудал байдаг тул түүнийг шийдвэрлэхэд зүйрлэлийг ашиглах нь зүйтэй юм.
Ийнхүү програм бүтээхдээ зүйрлэлийг ашиглах нь програмчлалыг илүү сайн ойлгоход чинь тусална. Ойлгосон зүйлээ хийхэд илүү амар биш гэж үү?
Програм хангамжийн зүйрлэлүүд
Програм хангамжид юу л байна зүйрлэл байна. David Gries: програм хангамж бол шинжлэх ухаан (1981). Donald Knuth: энэ бол урлаг юм(1998). Watts Humphrey: энэ бол процесс юм(1989). P. J. Plauger & Kent Beck: энэ бол яг л машин барих шиг юм (Plauger 1993,
Beck 2000). Alistair Cockburn: энэ бол тоглоом юм(2002). Eric Raymond: энэ бол хар зах шиг юм (2000). Andy Hunt & Dave Thomas: энэ бол цэцэг арчилгаа шиг юм. Paul Heckel: энэ бол яг л цасан гуа ба долоон одой киноны зураг авалт шиг юм (1994). Fred Brooks: энэ бол ферм ажиллуулах шиг, хүн чоно агнах шиг, давирхайт хонхорт динзаавруудтай хамт живэх шиг ч юм шиг. (1995).
Аль нь хамгийн сайн тохирох юм шиг байна?
Програм тэрлэхүй буюу “Код бичих”
Хүн бүр “код бичих” гэж ярьдаг болоод ч тэр үү Програмчлалыг зүйрлэх үед хамгийн түрүүнд толгойд орж ирдэг нь програм хангамжийн үйл ажиллагааг “бичих” -тэй адилтгасан адилтгал юм. Мөн уншвартай програм энэ тэр гээд л яриад байдаг болохоор сайхан зүйрлэл ч юм шиг. Энгийн захидал бичиж байгаа юм шиг нэг суудал дээрээ тэрлээд дуусгачихдаг, олон юм бодох шаардлагагүй үйл ажиллагаа гэж ойлгогдохоор ч юм шиг.
Энгийн, жижиг хэмжээний төслийн хувьд ч тохирч болох л юм. Гэхдээ захидлаа бичээд л шуудангийн хайрцаганд хийчихсэн бол болоо гээд бодчихвол болохгүй шүү дээ. Бодит байдал дээр програм хангамжийн төсөл шиг дуусч өгдөггүй зүйл байдаггүй л байх. Дундаж төслийн ажлын 90% нь зах зээлд нийлүүлэгдснийхээ дараа эхэлдэг байх жишээний (Pigoski 1997). Мөн юм бичихэд бусдаас санаа авалгүйгээр цоо шинэ санааг тэрлэх нь чухал байдаг бол програм хангамжид загварчлалын санаа, код, тестийн нөхцлүүдийг өмнөх төслөөсөө авах нь харин ч сайн арга барилд тооцогддог. Ингээд бодоод үзэхээр энэ “бичих” гэдэг зүйрлэл маань арай л тохирохгүй байх шиг.
Курсын ажил дээрээ хийж байгаа бяцхан програм бол ч яахав. Харин өндөр цамхагийн дайны өртөгтэй програмчлалын системийг иймэрхүү байдлаар жишиж болохгүй байх аа.
Програмчлалын ферм буюу “Систем ургуулах”
“Код тэрлэх” зүйрлэлээс арай уян хатан нэгэн зүйрлэл байгаа нь энэ юм. Програмчлалыг үр суулгах, тариа ургуулахтай зүйрлэнэ гэсэн үг. Бяцхан хэсгийн загварчлалыг хийгээд түүнийхээ кодыг бичнэ, тестэлнэ, бага багаар системд нэмээд явна. Ингэснээр эрсдэл багатайгаар системийг бүтээх юм.
Дээр дурьдсан “өсөлттэй”, “алгуур” арга барил нь зөв боловч яг үнэнийг хэлэхэд фермийн зүйрлэл програм хангамжид жаахан тохиромжгүй. Бага багаар бий болгох гэдгээс өөрөөр өргөтгөх боломжгүй шахуу, хөгжүүлэгчээс хамаарах хамаарал нь “байгаль, цаг уурын” хамаарлаас багад тооцогдох тул ер нь л програмчлалыг тэр чигт нь сайтар илэрхийлж чадахгүй байна.
Програмчлалын хясааны ферм буюу “Системийг өсгөхүй”
“Систем өсгөх” гэдэг нь “System accretion” гээчийг хэлж байгаа хэрэг. Энэ болбоос бага багаар нэмэгдэх, органик өсөлт гэсэн утгатай үг юм.
Системийг ажиллаж болох хамгийн энгийн хувилбараар нь бүтээснийхээ дараа аажим аажмаар нэмсээр бүрэн бүтэн систем бий болгохыг далдуур зүйрлэж байгаа хэрэг. Яг л ганц элсэн ширхэг дээр кальцын корбанат нэмсээр сувд бий болгодог хясаа шиг гэсэн үг.
Програм угсралт буюу “Програм барих” (барилга шиг)
Програмыг барилга шиг барьж байна гэж зүйрлэх нь тариа шиг ургуулах, захидал шиг бичих зэргээс хамаагүй дээр. Төлөвлөлт, бэлтгэл ажил, гүйцэтгэлийн хувьд ч тэр нилээд дөхөж очихоор зүйрлэл юм.
Чамайг нохойн үүр барих гэж байна гээд төсөөлье. Цайз зах орж мод, хадаас аваад л хэдхэн цагийн дотор банхарынхаа орох оронг бэлэн болгочихно. Ингэхдээ хаалга хийхээ мартчихвал ч юм уу өөр алдаа гаргавал нэг бол дахиад эхэлнэ. Үгүй бол тэрүүхэн тэнд нь засчихна. Нэг их асуудал гарахгүй.
Энэ бол яг л програм хөгжүүлэлтийн үед тулгардаг асуудал юм. 1000 мөр код доторх алдааг хайж илрүүлээд засахад ч юм уу эсвэл шинээр эхлэхэд нэг их хүч шаардагдахгүйтэй адил юм.
Харин том байшин барих гэж байгаа бол сайтар төлөвлөх хэрэгтэй. Эхний ээлжинд яг ямар байшин барих гэж байгаагаа тодорхойлно. Энэ нь програмын хувьд асуудлын тодорхойлолттой адил юм. Дараа нь нэг архитектор дагуулж ирээд архитектурын зураг гаргана. Энэ нь програм хангамжийн архитектур гаргахтай ижил. Үүний дараа барилгын компаниа олж, нарийвчилсан зураг гаргана. Энэ нь шаардлагын загварчлалтай төстэй. Дараа нь хундаамаа цутгаж, ханаа өрж, дээврээ байрлуулна. Энэ нь програм угрсалтын үетэй ижил. Тэгээд фасаад янзлах, дотоод засал чимэглэл хийх зэрэг нь програмын оптимизаци хийхтэй, барилга угсралтын явцын хяналт шалгалт нь кодын үзлэгтэй адил байгаа юм.
Үүнтэй адилаар нэг ханыг хагас метрээр нааш цааш холдуулах шаардлагатай боллоо гэхэд угтаа бол ямар ч материалын зардал гарахгүй мэт харагдавч хүн хүчний зардал ихээр гардаг нигууртай юм.Үүн шиг програм хангамж хөгжүүлэхэд материалын зардал гэж төдийлөн гарахгүй боловч хүн хүчний зардалд хамаг мөнгө урсана.
Энэ зүйрлэлийн өөр нэгэн төсөөтэй тал бол урьдын бэлэн байгаа зүйлийг барилга барихдаа ашигладаг явдал юм. Ухаандаа нэг байшин барьж байна гээд доторх бүх тавилга, сантехникийн холболтыг шинээр бий болгоно гэж байдаггүй. Харин ч бэлэн болсон бүтээгдэхүүнүүдийг зохьцуулан угсардаг билээ. Цонх, хаалга, шал, унтлагын өрөөний тавилгууд, чийдэн, гэрлийн бүрхүүл зэрэг нь бүгд хэн нэгний өмнө нь бүтээсэн зүйлс байдаг. Програм хангамж дээр ч энэ нь ялгаагүй бөгөөд програмыг дээд түвшний хэл дээр, бэлэн сангуудыг ашиглан бичдэг билээ. Түүнээс биш онцын шаардлагагүй үед ассемблер ч юм уу ашиглаад бүх зүйлийг 0 -ээс нь эхлээд явна гэж байхгүй.
Харин дээд зэрэглэлийн тансаг байгууламж барих гэж байгаа үед доторх тавилгуудыг нь ч гэсэн байшингийхаа бүтэцтэй хослуулан анхнаас нь захиалгаар хийлгэж, эсвэл өөрсдөө хийж угсардаг билээ. Түүнтэй адил програм хангамжийн зарим төслүүд дээр бэлэн сангуудыг ашиглалгүйгээр өөрсдийн системд 100% нийцэх хэсгүүдийг өөрсдөө бичих тохиолдол ч гардаг.
Төлөвлөлтийн хувьд ч мөн ялгаагүй. Юм хадгалах амбаар барих гэж байгаа бол нэг хэрэг, цөмийн цахилгаан станц, тэнгэр баганадсан цамхаг барих гэж байгаа бол бүүр ч нэг өөр хэрэг болох нь дамжиггүй. Түүнтэй адил програмын том жижгээс хамааран төлөвлөлтийн хэмжээ ч харилцан адилгүй байдаг. Жишээлбэл 1998 онд гаргасан судалгаагаар 1 сая мөр код бүхий програмд дор хаяж 69 төрлийн баримт бичиг, 3000 – 5000 хуудас бүхий шаардлагын тодорхойлолд байдаг аж.
Барилга барихтай зүйрлэсэн зүйрлэл нэг иймэрхүү. Ер нь үүнийг хамгийн оновчтой нь гэж хэлж болох билээ. “Програм угсралт”, “суурь классууд”, “програм хангамжийн архитектур” гээд л ярьцгаадаг шүү дээ бид чинь.
Хослуулан хэрэглэхүй
Сайн программистуудын “цээжинд” үргэлж хэрэгтэй хэрэгслүүд нь явж байдаг. Тэд алийг нь ямар үед хэрэглэхээ гаргаалгүй мэддэгийн дээр програм хангамжтай холбоотой асар их мэдлэгийн санг хуримтлуулсан байдаг юм. Тэрхүү мэдлэгийн сангийн нэгээхэн хэсэг нь дээр дурьдсан зүйрлэлүүд юм. Нэг л зүйрлэлийг бүх зүйл дээр ашиглаад байх нь өрөөсгөл тул хооронд нь хослуулан хэрэглэх учиртай. Заримдаа захиа бичиж буй мэт, заримдаа чонын авд гарсан мэт төсөөлөн програмчлаарай.
ЭХ СУРВАЛЖ: ZOLBAYAR.COM
