1963 Timesharing: A Solution to Computer Bottlenecks

Хөтөлбөрлөлийг Сургааль болгосон нь

- үргэлжлэл -

Улам бүр өсөн нэмэгдэж байсан хөтөлбөрлөлийн бэрхшээлүүдийг тусгайлан онилсон урьдын олон жилийн хүчин чармайлтуудаас үл хамааран 1968 онд хөтөлбөрлөлийн хямрал нүүрлэв. Хөтөлбөрлөлд нүүрлэсэн асуудлуудыг олж хараад шинэ санаа дэвшүүлсэн эрдмийн хүрээллийн ертөнц дэхь судлаачид нь үндсэндээ Э. Дикстра болон К. Хоар нар байлаа. 1965 онд Дикстра өөрийн алдарт "Бүтэцлэг хөтөлбөрлөлийн талаархи тэмдэглэлүүд"-ээ бичиж хөтөлбөрлөл бол урлал бус харин сургааль хэмээн тунхагласан байв. Түүнчлэн 1965 онд Хоар өгөгдлийн бүтцийн талаар чухал нийтлэлээ нийтлүүлээд байлаа. Хөтөлбөрлөлийн шинэ хэлүүд, ялангуяа Паскал хэл бүтээхэд эдгээр санаа гүнзгий нөлөөлсөн юм. Шинэ хэлүүд нь эдгээр шинэ санааг илэрхийлэн тээгчийн үүрэг гүйцэтгэжээ. Бүтэцлэг хөтөлбөрлөлийг бүтэцлэг хөтөлбөрлөлийн хэлүүдээр дэмжих боллоо.     
             
1966 онд, Дикстра ээлжлэн хорших үйлүүдийн тухай ном бичиж семафорт суурилсан сургаалиа дэвшүүлсэн юм. Өрсөлдөгч үйлүүдийг уялдуулах анхдагч нэгж болох семафорыг 0 ба 1 гэсэн утгууд болон P ба V гэсэн эгэл үйлдлүүдээс бүрдэх өгөгдлийн төрөл хэмээн үзэж болно. (P(s) нь - өөр үйлийн үйлдлээр - s-ийн утга 1 болох хүртэл дуудагч үйлийг саатуулж байгаад дараа нь семафороо тэглэнэ. V(s) нь s-ын утгыг 1 болгоно.) Дараахан нь Хоар 1966 онд суваг ба нөхцлүүд гэсэн ухагдахуун, түүнчлэн "?" (байцаах) болон "!" (нөхцөл нягтлах) тэмдгүүдээр тэмдэглэсэн хоёр үйлдэгч дээр суурилсан Мэдээ солилцогч Цуврал Үйлүүдээ дэвшүүлсэн юм. Ирээдүйд хөтөлбөрлөгчид өрсөлдөгч үйлүүд тойрсон элдэв бэрхшээлүүдтэй нүүр тулах болно гэдгийг Хоар бүрэн ухаарчээ. Өрсөлдөөнтэй тулгарах бодит шаардлага нь бүтэцлэг болон сургаальлаг аргачлал аминд тулсныг илүү тодоор харуулсан юм.         

Энэ бүх хүчин чармайлттай зэрэгцээд, 1968 оны НАТО-гийн бага хурлын үеэр хөтөлбөрлөлийн талбар нь учраа олохгүй алмайрсан, тэр бүү хэл задарч, бутарсан байдалтай байв. Дикстра, Хоар болон бусад хүмүүсийн хөгжүүлсэн чухал хөгжүүлэлтүүд нь бүх бэрхшээлийг ганц шөнөдөө арилган туурвилын нөхцөл байдлыг өөрчилж чадсангүй, чадах ч боломжгүй. Хөтөлбөрлөгчдийнх нь хэрэглэж байсан багаж хэрэгслэлүүд болон хэлүүдэд 1968 онд үүссэн эдгээр шинэ санаанууд огт нэвтрээгүй байсан тул үйлдвэрлэгчид өөрсдийн бодлого, багаж хэрэгслэлүүдээ хангалттай хурдан өөрчилж чадахгүй байв. Тун удалгүй бүтэцлэг хөтөлбөрлөлийн эрчимсэн сургалтууд зохион байгуулагдаж эхлэлээ. Ялангуяа IBM пүүс дотор. Хөтөлбөрлөлийн асуудлууд харанга дэлдлээ гэдгийг Америкийн Батлах Хамгаалах Хэлтэс хүртэл анхаарч эхлэв. БХХ өөрийн зүгээс төсөл санаачилснаар хэрэглээний өргөн хүрээ хамрахад тохиромжтой, дээд зэргийн бүтэлцэг хэл Ада мэндэллээ. Ингэснээр БХХ доторхи туурвил хөгжүүлэлт  зөвхөн Ада хэл дээр суурилах болсон нь өнөө ч хүчтэй хэвээр байна.        
  
Туурвил инженерчлэлийн товч түүх
1960-аад он ба Туурвил Инженерчлэлийн Үүсэл

When Computers Changed the World

1960-аад он ба Туурвил Инженерчлэлийн Үүсэл

- үргэлжлэл -

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

Тооцоолуурын эриний чухал цаг үе бол 1950-аад оны сүүл гэж би үздэг. Их сургууль болон судалгааны хүрээлэнгүүд өөрсдийн гэсэн аварга тооцоолууруудтай болов. Энэ үйл явц нь ихэвчлэн инженерийн болон байгалийн ухааны салбарт түлхүү анзаарагдаж байснаа тун удалгүй бизнесийн салбарт нэвтэрлээ. Лаборатори дотор хэдхэн хүн тооцоолуураа ээлжлэн ашиглахаар дугаарлан зогсдог байсан цаг хэдийнэ ард хоцорчээ. Цахилгааны инженерүүдийн хаалттай лабораториас урган төлжиж нийтийн талбарт гарснаар тооцоолуурын хэрэглээ, ялануяа тооцоолуурын хөтөлбөрлөл нь олны үйл хэрэг болон хувирлаа. Шинэ мэргэжил мэндлэв; гэхдээ аварга тооцоолуурууд өөрсдөө хаалттай хананы цаана нууцлаг хэвээр үлдэв. Хөтөлбөрлөгчид өөрсдийн хөтөлбөрөө тоолуур дээр авч ирэхэд түүнийг нь диспетчер хүлээн авч дараалалд оруулах бөгөөд үр дүн нь хэдэн цаг юмуу өдрийн дараа гарна. Тооцоолуур, хүн хоёрын хооронд ямар ч шууд харилцаа байсангүй.

Хөтөлбөрлөл нь ухааны ур сорих асар их тэсвэр, тэвчээр, зориг, эрмэлзлэл шаардсан амаргүй даалгавар хэмээн тооцогдож байлаа. Иймэрхүү ухаан сийлэх ажлыг тэтгэхийн тулд томъёолбор тэмдэглэлүүд бүтээв. Өнөөдөр бид тэднийг хөтөлбөрлөлийн хэлүүд гэж нэрлэдэг. Уг санаа нь тусгай зааварлагч кодын дарааллуудыг математикийн томъёонуудаар орлуулах явдал байлаа. Хамгийн анхны өргөн тархсан Фортран хэлийг IBM (Backus, 1957) гаргаж удалгүй Алгол (1958) болон түүний залгамжлагч нь 1960 онд мэндлэв. Тэр цагт тооцоолуур нь хадгалах, дамжуулах бус зөвхөн тооцоолох зориулалттай байсан тул тэдгээр хэл нь цэвэр математик тоогоор дагнана. 1962 онд Америкийн батлан хамгаалах хэлтсээс эрхлэн бизнесийн зориулалт бүхий Кобол хэлийг гаргажээ.

Тооцоолох чадал нэмэгдэхийн хэрээр хөтөлбөр болон хөтөлбөрлөгчийн эрэлт хэрэгцээ өслөө. Даалгаврууд улам бүр ээдрээтэй болсоор. Тооцоолуур хичнээн чадалтай байлаа ч түвэгтэй асуудал шийдэх гарц олдохгүй зовооно, хөтөлбөрлөл бол хүнд даалгавар гэдгийг аажмаар хүлээн зөвшөөрч эхлэв. Ганц аврал нь хөтөлбөрлөлийн "илүү сайн" хэлүүд, илүү олон "багажнууд", тэр бүү хэл автоматжуулалт хэмээн тооцогдож байлаа. Илүү сайн хэлүүд гэдэг нь хэрэглээний өргөн хүрээ хамарсан, "ярианы" хэлтэй ойр дөт бөгөөд илүү өргөн бололцоотой гэсэн санаа. Шинжлэх ухааны болон арилжааны ертөнцийг нэгтгэхээр PL/1 хэлийг зохиожээ. "Хүн бүрт хөтөлбөрлөх боломж олгосон PL/1-т талархлаа" гэх уриан дор түүнийг сурталчилж байв. Хөтөлбөрлөлийн хэлүүд болон тэдгээрийн эмхэтгүүрүүд нь тооцоолох ухааны тулгуур баганууд боллоо. Гэсэн ч тэдгээр нь тооцоолуурын үндсэн хэрэглээ болсон уламжлалт хоёр салбар болох математик болон электроникийн хүрээнээс халив. Америкт Тооцоолуурын Ухаан, Европт Мэдээлэлзүй хэмээн нэрлэгдэх цоо шинэ сургааль үүслээ.

1963 онд анхны хугацаа-товчлох тогтолцоо үүсэв (MIT, Stanford, McCarthy, DEC PDP-1). Үгүйлэгдэж байсан шууд харилцаа эргэн ирлээ. Тооцоолуур үйлдвэрлэгчид энэ санааг шүүрэн авч өөрсдийн аварга тооцоолох машинуудад зориулсан хугацаа-товчлох тогтолцоонуудыг сурталчилах болов. Багцлан боловсруулах тогтолцооноос хугацаа-товчлох тогтолцоо руу шилжих нь санасныг бодвол хамаагүй хэцүү болж таарлаа. Тогтолцоогоо сурталчилсан хэрнээ хугацаанд нь хүлээлгэн өгч чадахаа болив. Асуудал нь дэндүү нүсэр байжээ. "Ажил дээр нь" судалгаагаа явуулах боллоо. Цоо шинэхэн халуун сэдэв нь мульт боловсруулалт болон өрсөхүй хөтөлбөрлөлт байв. Бэрхшээлийнх нь улмаас томоохон пүүсүүд сүйрлийн ирмэгт туллаа. НАТО санхүүжүүлсэн 1968 оны бага хурал энэ сэдвээр хуралджээ (Garmisch-Partenkirchen, Germany). Хэдийгээр өмнө нь энэ талаар санал, шүүмжүүд үе, үе дэгдэж байсан боловч чухамдаа энэ бага хурлаар тулгарсан бэрхшээлээ нээлттэй хэлэлцэн ер бусын эелдэгээр хүлээн зөвшөөрч, улмаар туурвилын инженерчлэл ба туурвилын хямрал гэх нэр томъёо эргэлдэх болсон билээ.

Туурвил инженерчлэлийн товч түүх

Туурвил инженерчлэлийн товч түүх

Никлаус Вирт
2008.2.25

Хураангуй

Хөтөлбөрлөх Урлагийн талаархи хувийн төсөөллөө бид толилуулж байна. Бид 1960-аад оны түвшнээс нь эхлээд өнөөг хүртэлхи хөгжлийн замналаар нь мөшгих болно. Холимог тогтолцоо зохиомжлоход тулгарах саад бэрхшээлүүдийг эвсгээр хэлэлцсэн 1968 оны бага хурлаас хойш Туурвил Инженерчлэл гэх нэр томъёо дуулдах болжээ. Шийдлийн эрэл хайгууль эхэллээ. Энэ нь илүү сайн аргачлал, илүү сайн багаж хэрэгслэлүүд дээр төвлөрч байв. Хамгийн их анхаарал татсан нь ажилбарын, цогцолборын тэгээд тусагдахууны чиглэлийн хэв маягийг тусгасан хөтөлбөрлөлийн хэлүүд байв. Туурвил инженерчлэл нь тэдгээрийн үүсэл, хөгжилтэй нягт уялджээ. Түүнчлэн хөтөлбөрийн баримтжуулалт болон сорилыг цэгцлэн улмаар автоматжуулах хүчин чармайлтууд чухалд тооцогдож байлаа. Тиймээс задлан шинжлэх нотолгоо болон алдаагүйжлийн баталгаа нь сорилыг орлоно хэмээн тооцож байв.           

Хожим тооцоолох хүчин чадал эрчимтэй өссөн нь тооцооллыг улам түвэгтэй даалгаврууд гүйцэтгэхэд хэрэглэх боломжтой болголоо. Уг хандлага нь туурвил инженерчлэлийн хэрэгцээ шаардлагыг огцом нэмэгдүүлжээ. Хөтөлбөр болон тогтолцоонууд улам түвэгтэй болж гүйцэд ойлгох бараг боломжгүй боллоо. Тооцооллын нөөцүүд арвижин өртөг зардал хямдарснаар сайн зохиомжид тавих анхаарал халамж яалт ч үгүй сулрав. Ашиг хөөцөөлдсөн уралдааны золиос болж чанар хадуурав гэлтэй. Гэсэн ч үүнээс улбаатай чанарын доголдлыг бид тооцох учиртай. Бидний арчаагүйтэл удаан тоноглолоос бус харин бидний оюуны чадвараас эхтэй. Ихэнхи хөтөлбөрийг эрс сайжруулан, ашиглахад илүү найдвартай, хэмнэлттэй, тухлаг болгож болно гэдгийг бид бүхэн туршлагаасаа мэднэ.                 

Хөгжүүлэгч бол Үйлчлүүлэгч

Sun Microsystems компанийн Техникийн Захирал Tom Ball-тай хийсэн ярилцлага

Товчхон: Би бол Sun Microsystems компанийн Жава хөтөлбөрлөлийн хэлний багаж бүтээх ажлыг хариуцсан техникийн захирал хүн.

java.sun.com(JSC): Та бол Sun Microsystems компанид олон жил ажилласан хүн. Өнгөрсөн он жилүүдэд таны ажил хэрхэн өөрчлөгдсөн бэ?

Ball: Анх 1994 онд Sun компанид ажил, хөдөлмөрийн гараагаа эхэлснээс хойш Жава технологиор 12 жил дагнан ажиллажээ. Намайг JDK багт орох үед Жава хэл нь Oak нэрнээсээ ч салаагүй дөнгөж мэндэлж байсан бөгөөд миний бие 1.0 хувилбарт зориулсан анхны зүгшрүүлэгч ХХҮ /debugger API/ бүтээхийн зэрэгцээ AWT /Abstract Window Toolkit/ бүтээхэд ч өөрийн хувь нэмрээ оруулж явлаа. 1.1-ийн хувьд, Windows AWT хэрэгжилтийг /implementaion/ шинэчлэн бичиж AWT хөмрөгийн үзэгдлийн шинэ загвар зохиомжлоход оролцсон бөгөөд хожим үүнийгээ Swing болгон өргөтгөсөн юм. Хэрэглэгдэхүүний үйлчлэгч /application server/ багт зориулсан багаж хэрэгслэлийн архитектурчаар хэсэг зуур ажилласаны дараа Sun Laboratories дахь Jackpot төсөл дээр Жеймс Гослингтой /James Gosling/ дахин хамтран ажиллаж билээ.

Одоогоос гурван жилийн өмнө, Jackpot төслийн бүх гишүүд тухайн үедээ Хөгжүүлэгч Бүтээгдэхүүний Бүлэг /Developer Products Group/ хэмээн нэрлэгдэж байсан Хөгжүүлэгч Багажын Бүлэг /Developer Tools Group/ рүү шилжсэн түүхтэй. Тэнд байхдаа, javac эмхэтгүүрийг /compiler/ NetBeans Хөгжүүлэх орчинтой нэгтгэхээр бүтэн жил ноцолдсоны дараагаар, би Jackpot-ийн судалгааны үлгэр загвараа /research ptototype/ олон хэсэг NetBeans нэгтгэлүүд /module/ хэлбэрээр шинэчлэн бичсэн юм.

JSC: Sun компанид орохоосоо өмнө хаана, юу хийж байв?

Ball: Sun компанид орохоосоо өмнө, EO дахь PenPoint үйлдлийн систем хариуцсан системийн инженер, Metaphor дахь Patriot Partners төсөл болон Convergent Technologies дахь CTOS хариуцсан системийн инженерээр тус тус ажиллаж байлаа. Наяад оны дундуур Convergent нь Silicon Valley-ийн хувьд Тэнгисийн Хүчний үүрэг гүйцэтгэж байв, учир нь бид захиалагчиддаа зориулан шинэ тоноглол /hardware/, үйлдлийн систем, системийн болон сүлжээний туурвилыг /software/ зургаагаас есөн сарын дотор нийлүүлж байв.

Би тэнд ажиллаж байхдаа, үйлдлийн системийн бичил цөмийн /microkernel/ архитектур, үйлчилгээнд суурилсан /service-based/ олон зүтгүүртэй тархмал системд /multithreaded distributed system/ зориулсан асинхрон хэрэглэгдэхүүний зохиомж, Xerox PARC системийн MVC /Model-View-Controller/ зохиомж болон обьект хандлагат хөтөлбөрлөл зэргийг суралцсан юм. Энэ бол үнэхээрийн гайхалтай инженерийн баг байсан бөгөөд сургуульд сураад олж авахгүй олон зүйлийг би эндээс олж авсан бөлгөө. Би анхандаа мэргэжлийн хөгжимчин байсан нь надад тус болсон уу гэхээс ус болоогүй болов уу.

JSC: Jackpot төсөл гэж юу вэ?

Ball: Jackpot бол Жава эх код дотор ямар нэгэн байдлаар давтагдах хэв маяг /pattern/ хайж олоод олдсон хэвийн дагуу эх кодоо аль болох эвдэхгүйгээр үнэн зөв, найдвартай хувиргах зориулалттай технологи юм. Энэ нь шинэчилсэн javac ХХҮ /Хэрэглэгдэхүүн Хөтөлбөрийн Үүд - Application Programming Interface/, Жава эмхэтгүүрийн ХХҮ, JSR 269, Өргөмөл Товчлол Боловсруулах /Pluggable Annotation Processing/ ХХҮ, javac Tree ХХҮ, com.sun.source.tree болон com.sun.source.util зэрэг сан хөмрөгүүдийг өргөн ашигладаг.

Jackpot нь Жава 2, Стандарт Хувилгал 5.0 болон түүнээс дээш Хөрс дээр ажиллах хэдий ч эхийн бүх түвшинг дэмжинэ. Энэ бол жирийн нэг хувилгагч багаж /refactoring tool/ биш. Хувилгагч багажууд нь зөвхөн тухайлсан өөрчлөлт дээр төвлөрдөг. Jackpot нь төслийн хэмжээний хувиргалтууд дээр төвлөрдөг.

JSC: Jackpot Төсөл нь NetBeans Урланг нөхөн инженерчлэлийн гайхалтай боломжоор баяжуулсан нь дамжиггүй. Хөгжүүлэгчид энэ талаар юу ойлгох хэрэгтэй вэ?

Ball: Хамгийн гол нь Jackpot-ийн "хөдөлгүүр " нь хөгжүүлэгчдийн өмнө бүрэн нээлттэй, хүсвэл Жава хүсэлт болон хувилгалтыг /query and refactoring/ өөрөө хялбархан бичиж болно гэдгийг ойлгох хэрэгтэй. Хүмүүс зөвхөн бэлэн хүсэлтүүд болон нөхөн инженерийн бэлэн тушаалуудад анхаарлаа хандуулаад үүний цаана байгаа аварга том мөсөн уулыг анзаарахгүй орхигдуулах вий гэсэн болгоомжлол байна. Ер нь бол нөхөн инженерчлэлийн олон гайхалтай санаанууд бий. Тэдгээрийг бичих нь зугаатай төдийгүй ихээхэн цаг зав авдаггүй, тиймээс тун удахгүй бэлэн тушаалуудын багцаар үер буух болов уу.

Дүнсгэр Код Бичих нь

JSC: Сайн код бичих талаархи таны зөвлөмж?

Ball: Миний мөрдлөг болгохоор хичээдэг -- хамгийн сайн зөвлөмж гэвэл -- хэн нэг ухаантан хараад энд ямар ч тайлбар хэрэг алга, угаасаа л тодорхой гэж хэлэгдэхүйц тийм дүнсгэр код бичихийг аль болох чармайх хэрэгтэй. Зөвхөн ганц зүйл хийдэг, гэхдээ найдвартай, бичсэнийхээ дараа шууд мартлаа гэхэд хожим нь чимээгүй, нам гүм ажилладаг тийм код бичих хэрэгтэй.

Жишээлбэл, NetBeans урлан доторхи classfile нэгтгэл нь зөвхөн ганц л зүйл хийнэ: JVM .class файл уншаад JVM зүйлчлэлийн шаардлагад ойртуулсан ангиуд болгох явдал. Ийм ангиудад юуг ч өөрчлөх боломжгүй - тэд бол хувиршгүй ангиуд. Энд .class файлуудыг засварлах юмуу үүсгэх ямар ч боломж байхгүй бөгөөд түүний ямар ч анги нь JVM зүйлчлэлийг мэддэг дурын хүний хувьд учир битүүлэг оньсого төрүүлэх ёсгүй.

Уг нэгтгэл нь "дүнсгэр" учраас хэн нэгэн хүн зугаагаа гаргахаар эвдэх гэж оролдохгүй - зөвхөн JVM зүйлчлэл өөрчлөгдөх үед л шинэчлэгдэнэ - тиймээс олон жилийн турш тогтвортой байдлаа хадгалсаар ирсэн юм. Эгэл тулдаа маш хурдан бөгөөд ачаалал багатай, бас хувиршгүй /immutable/ учраас зүтгэх чадвартай /threadsafe/ болой. Тогтвортой бөгөөд дүнсгэр учраас түүнийг арчлах, сайжруулах гэж цаг заваа үрэх хэрэггүй, энэ хугацааг өөр төсөл дээр ажиллахад зарцуулах боломж олгосон явдал нь магадгүй хамгийн чухал чанар байх.

Өмнө бичсэн кодоо уншиж ажиллагааг нь ойлгохын тулд тодорхой хэмжээгээр төсөөлөл гаргах шаардлага гардаг нь олонтаа анзаарагддаг, тэгэхлээр тухайн код нэг л биш гэсэн үг. Чухам тийм учраас би хувилгагч багажны хэнээтэн болсон, учир нь тэдгээрийн зорилго нь кодын ажиллагааг өөрчлөхгүйгээр кодыг хялбарчлах, тодотгох явдал байдаг. Амьдралд ч тэр, хөтөлбөрлөлд ч тэр, цомхон байх нь илүү хэцүү. Би багаж ашиглахыг аль болох хичээдэг, тиймдээ ч багаж бүтээх асуудал миний санаанаас огт салдаггүй. Жишээлбэл, Sun Labs дахь Jackpot төсөл анхандаа нөхөн инженерчлэлийн багаж бүтээх зорилготой байгаагүй - түүний зорилго нь хөгжүүлэгчийн бүтээмжийг нэмэгдүүлэх чиглэлээр төрөл бүрийн жижиг туршилтууд хийх явдал байсан.

Жеймс Гослинг Хөгжүүлэгч Бүтээгдэхүүний Бүлгийн техникийн ерөнхий ажилтнаар томилогдож, харин би NetBeans Урлан төсөлд орсон, учир нь бидний хэн хэн маань нэг л дүгнэлтэнд хүрсэн: Хөгжүүлэгчийн бүтээмжийг хамгийн их нэмэгдүүлдэг зүйл бол сайн багаж. Jackpot бол гайхалтай метазагвар урлагч гэхээсээ илүү таны ажлын жагсаалт доторхи олон давтагддаг кодын өөрчлөлтийг арилгах багаж юм.

Тиймээс сайн Урлан олж ав -- миний хувьд эхлээд Emacs, дараа нь Visual C++ байв -- тэгээд хэрхэн ашиглахаа сайтар судал. Дараа нь долоо хоног тутам ч юмуу гарын авлагыг нь унших, эсвэл ХҮ (хэрэглэгчийн үүд - user interface)-ийг ухаад хэрэв сайн мэдэхгүй зүйл олдвол түүнийгээ нухаж өөрийн болгох хэрэгтэй. Хажуугаар нь өөр шинэ багаж юу байна гэдгийг эрэлхийлж байхад гэмгүй, магадгүй тушаалын мөрөөс ажилладаг, тэр ч байтугай таны сонгосон Урланг орлох илүү сайн багаж олдохыг үгүй гэх газаргүй. Сайн багаж нь таны олон хүнд хүчир ажлыг нугалахад үнэхээр тустай.

Жишээ нь бүх амьдралынхаа турш ХЗҮ (хэрэглэгчийн зурмал үүд - graphical user interface) хийж байсан хүний хувьд, маягт бүтээх, тэдэнтэй ноцолдож хамаг цагаа авахыг би үнэхээр их үзэн яддаг. Хэрвээ та миний өмнөөс маягт бичнэ гэвэл оронд нь танай байшингийн усны янданг цэвэрлэхээс би лав татгалзахгүй байлаа. Гэвч шинэчлэгдсэн Jackpot ХҮ нь богино хугацааны дотор олон тооны маягтууд хийх шаардлагыг миний өмнө тавив, тиймээс NetBeans доторхи шинэ маягт засварлагч болох Matisse-ийг ашиглахаас өөр зам олдоогүй юм. Түүнийг ашиглахад маш амар, хялбар байлаа. Одооноос та өөрийнхөө янданг цэвэрлэх боломжтой боллоо.

Эцэст нь, Урлангийнхаа зүгшрүүлэгч болон сувилагчийг /debugger and profiler/ тогтмол хэрэглэж занш - ямар ч print хэллэггүй, ямар ч учирлалгүй, зүгээр л хий. Нэг учраа олоод, хөтөлбөр чинь хэрхэн ажиллаж байгааг мэддэг болчихвол та илүү сайн хөтөлбөрлөгч боллоо гэсэн үг.

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

Кодын Хэмнэл Аялгуу

JSC: Та анхандаа мэргэжлийн хөгжимчин байсан гэсэн. Энэ нь таныг хөгжүүлэгч болоход нөлөөлөв үү? Код бичих, хөгжим тоглох хоёрын хооронд ижил төстэй зүйл бий юу?

Ball: Гарцаагүй бий, гэхдээ энэ бол зөвхөн миний бодол биш. Туурвилын инженерийн ямар ч байгууллагад ороод дурын хөгжүүлэгчээс хөгжмийн боловсролыг нь асуу. Бүтээлч баг дотор, ёс мэт ядаж гуравны нэг нь багадаа төгөлдөр хуур юмуу үлээвэр хөгжим тоглож сурсан, цөөн хэд нь олон хөгжим тоглож сурсан байдаг. Тоо, бичмэл аялгуу хоёр нь хоёулаа адилхан билэгдлийн хэл, аль аль нь тархины ойролцоо хэсгүүдийг хөгжүүлдэг.

Олон хүмүүс үүнийг мэддэггүй, гэхдээ JDK дахь Жава Sound-ийг хэрэгжүүлэгч нь хөгжимчин Thomas Dolby-ийн удирдсан жижиг компани байсан юм шүү. Тэр хэлэхдээ, "Тэр намайг Шинжлэх Ухаанаар Самууруулсан", гэхдээ JavaSoft-той ажиллахад гарсан инженерийн ярилцлагууд амжилттай болсоор ирсэн гэсэн юм.

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

Туурвих үеийн хөгжилтэй явдлууд

JSC: Хөгжүүлэгч хүний тань хувьд тохиолдсон хамгийн хөгжилтэй зүйл юу вэ?

Ball: Би ч хүн даапаалахдаа адтай дамшиг шиг байгаа юм. Unisys компани Convergent Technologies (CT)-ийг худалдан авах үед, олон жилийн турш бидний дээр гарах гэж оролдоод бүтэлгүйтсэн, манай OEM бүтээгдэхүүнийг "сайжруулах" учиртай инженерийн багийн магнай тэнийсэн юм: Бид тэдний шууд удирдлага доор орчихов. Үүнээс болоод манай ихэнхи чадварлаг тоглогчид ажлаа орхин сэтгэл санаа ч шалдаа буув. Засварлуур нь миний мэдэлд байсан учир бяцхан эсэргүүцэл болгох үүднээс тодорхой товчны дарааллаар дэлгэц дээр гарах хувилбарын дугаарын араас "CT forever!" гэсэн үг нэмэгдэж байх Зул сарын өндгөөр засварлуураа мялаасан юм.

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

Өнөөдөр ч гэсэн, хэрэв та засварлуурын маань бичвэр-хайх диалогыг гарган СТ гэж оруулбал хувилбарын дугаар дотор CT forever! гэсэн үг гарахыг харах болно. Гагцхүү товчлуур дарахад идэвхиждэг байсан нь л больсон.

Oak дурсамж

JSC: Oak багийн анхны гишүүнийхээ хувьд, Жава хөтөлбөрлөлийн хэлийг үндэслэх их тулааны дурсамжаасаа бидэнтэй хуваалцахгүй юу?

Ball: Bill Joy шургуу хөөцөлдсөний хүчээр техникийн багийнхны дэндүү эрсдэлтэй, хугацаа их авах онцлог гэж үзсэн хяналттай-гажуудлыг (checked-exception) нэвтрүүлэхээр болсон гэсэн яриа байдгийг би хувьдаа үнэн гэж боддог, маргааш нь үнэхээр тийм зүйл болсныг санаж байна. Урьд нь бүх гажуудлууд өнөөгийн RuntimeException яаж ажилладагтай адилхан ажиллаж байлаа. Тэгтэл Bill JVM-ийн хоёр гол инженерийг маш үнэтэй ресторанд дайлж, тэд тэр шөнөдөө уг онцлогийг нэмсэн гэдэг.

Хэлний анхны хувилбартаа нотолгоо /assertion/ оруулсан боловч хүчин чадлын асуудлаас болоод багийн бусад хүмүүсийнхээ шахалтаар авч хаясан хэмээн James Gosling надад хуучилж байлаа. Энэ лав үнэн байх, учир нь өгөгдлийн зогсохцэг /data breakpoint/ бий болгохын тулд ухварлуурын давталт дотор Boolean шалгалт хийдэг байх ёстой, тэгвэл debug дарцаг тавиад л түүнийг ондоо давталт дотор ажиллаж буй маягтай болгож болно гэдгийг JVM инженерүүдэд ойлгуулах гэж хэдэн долоо хоног зарцуулсан юм. Бид ямагт хүчин чадлыг чиглэлээ болгож байв.

JSC: Сайн код урлах түлхүүр юу вэ?

Ball: Сулхан гагнагдсан энгийн, жижиг ангиуд. Хичнээн хичээгээд ч ингэж хийж тэр бүр чаддаггүй, гэхдээ хийж чадсан үедээ сэтгэлийн асар их таашаал авдаг.

JSC: Мухардалд орсон үедээ та яадаг вэ?

Ball: Цаг хугацаанд даатгана. Зохиомжоо гүйцэд ойлгоогүй юмуу асуудлаа бүрэн тодруулаагүй үедээ мухардалд орох явдал бий, тэгвэл асуудлыг хүчээр шийдэх гэж зүтгэхийн оронд хэсэг хугацаа өнгөрөхийг хүлээх аваас илүү сайн шийдэл олох магадлал ихтэй.

Багаж бүтээхүй -- Хөгжүүлэгч бол Үйлчлүүлэгч

JSC: Багаж бүтээх талаархи таны бодол?

Ball: Туурвилын ихэнхи төслүүдийн хувьд, хөгжүүлэгч бол үйлчлүүлэгч биш, үйлчлүүлэгчид маань хөгжүүлэгчид биш учраас тэдний юу хүсэж буй хэрэгцээ нь биднийхтэй адил биш гэдгийг анхаарах нь чухал байдаг. Харин хөгжүүлэх багаж, магадгүй тооцоолуурын тоглоомын хувьд бол хөгжүүлэгч бол үйлчлүүлэгч! Зах зээлийн юмуу удирдлагын ажилтнуудаа бодвол та хэрэглэгчийнхээ хэрэгцээг илүү сайн ойлгоно гэсэн үг. Үүний дээр, таны хийж буй ажил бусад хүмүүст чухал, тэгээд ч бид бүгдээрээ бие биендээ сайрхахыг эрмэлздэг нь үнэн.

JSC: Жава технологийн багажуудыг ойрын жилүүдэд юу хүлээж байна?

Ball: Миний мөрөөдөл олон жилийн тэртээ мөхсөн, гэсэн ч фрэймуорк, багаж хоёрын аль аль нь бидний хамаг цагийг үрж буй хэвшмэл код бичих нүсэр ажлаас чөлөөлөх чиглэлээр улам хүчтэй замнаасай гэж би хүсдэг. Одоохондоо хэвшмэл кодтой эвлэрэхээс аргагүй, гэхдээ бүтээмжид үнэхээр хорлонтой.

JSC: Хөтөлбөрлөлийн Жава хэлээр ажиллах явцаа ажигласан хамгийн гайхалтай үзэгдэл тань?

Ball: 12 жил өнгөрсөн хэдий ч өнөө хэр уйдаагүй байгаа маань сонин. Энэ бол миний ажилласан ихэнхи төслүүдийг өөд нь татах зөв "хөшүүрэг" болж чадсан анхны хэл байлаа.

JSC: Хөтөлбөрлөхүйн юу нь танд хамгийн их таалагддаг вэ?

Ball: Бараагаа нийлүүлэх. Жинхэнэ ажил хийхдээ ашиглах учиртай жинхэнэ хэрэглэгчдийнхээ гар дээр очсон хойноо л аливаа төсөл эцэслэн хүчин төгөлдөр болдог.

JSC: Таны таашаалд нийцсэн Жава технологийн ном бий юу?

Ball: Яг сэтгэлд хүрэх ном бол байхгүй, гэхдээ Роберт Симмонсын бичсэн HardCore Java болон Жош Мариначи, Крис Адамсон хоёрын бичсэн Swing Hacks бол үнэхээр сэтгэл сэргээх сайн ном.

JSC: Хамгийн сүүлд нэмэгдсэн хэлний боломжуудаас аль нь амьдралд илүү өгөөжтэй болсон гэж та боддог вэ?

Ball: "Өгүүлбэрзүйн хачир" төдий, гэхдээ хамгийн таалагдсан шинэ боломж бол өргөтгөсөн for давталт. Хэр барагтаа буруутахааргүй цэвэрхэн код -- сайхан биш гэж үү?

JSC: Туурвил бүтээх ажлыг хөнгөвчлөхөд нээлттэй-эхийн нийгэмлэгүүдийн гүйцэтгэж буй үүрэг, ролийн талаар таны хуримтлуулсан туршлага юу байна?

Ball: gcc-ийг хог цуглуулах боломжтой болгон өргөтгөх асуудлаар Cygnus нийгэмлэгт хандаж байсан маань нээлттэй-эхийн нийгэмлэгтэй хамтран ажиллах анхны тохиолдол байлаа. Тухайн ажлын чанар үнэхээр гайхалтай байсан бөгөөд GPL шаардлага ёсоор өргөтгөл маягаар хийх санаа нь надад маш их таалагдсан. Жава альфа хувилбар гарахын өмнөхөн, хожим JavaSoft болон өргөжсөн FirstPerson бүлэгт нэгдсэн маань гэртээ ирснээс ялгаагүй санагдаж байв, учир нь би дахиад л эх кодоо гишүүддээ нээлттэй хуваалцдаг багийн нэг гишүүн болсон юм. Мэдээж хэрэг, Netbeans IDE урлангийн багийн гишүүн болно гэдэг нь юуны өмнө нийгэмлэгтээ хүчээ өгнө гэсэн үг.

Шинэ Хөгжүүлэгчдэд өгөх зөвлөмж

JSC: Шинээр ажлаа эхэлж буй Жава Хөгжүүлэгчдэд та юу хэлэхсэн бол?

Ball: Хөтөлбөрлөл гэдэг нь дархан, мужааны ажил хэвээр байна, тиймээс ахлах мэргэжилтнүүдтэй хэдийчинээ хамтран ажиллана, сургуульд үздэггүй олон зүйлийг тэднээс төдийчинээ ихээр сурах болно. Боломжтой бол нээлттэй-эхийн төсөлд оролцож өөрийгөө бусдад нээж, сорих хэрэгтэй. Гэхдээ сонирхолтой санагдсан төсөл бүхэн рүүгээ зүтгэ гэсэн үг биш. Зарим залуус хэтэрхий олон юм рүү үсчээд эцэстээ нэр хүндээ алддаг тал олонтаа ажиглагддаг.

Эцэст нь захихад, Жавагийн ямар ямар хамтлагууд байна гэдгийг тэдний хэлэлцүүлэг, блогуудаар нь дамжуулан судалж танилцаж байгаад дараа нь элсдэг байх хэрэгтэй. Манай бүлэг үнэхээр дажгүй шүү!

http://java.sun.com/developer/Meet-Eng/ball/

Comments

Java saihan hel shuu. Gehdee l tahir dutuu hun shig udaan. Uneheer sain program bichie gevel C heliig songooroo. (medeej assembler deer bichvel mash ih tsag zarcuulah tul) Tom project bol C++ -g. Tegeed diilehgui bol hyalbar bogood saihan bolomjtoi Java, C#-g ashiglahad bolno doo. Huuhduuded bol VB.Net saihan shuu.
Posted by hacker on 09/25/2006 05:34:34 PM

Миний мэдэхээр, олон жил Си хэлээр ноцолдсон хэд хэдэн нэртэй инженер Жава хэл рүү "урвасныг" санаж байна. Тэдний бодлоор, өнөөгийн Жава систем Си хэлнээс илүү хурдан, илүү хүчтэй гэнэ. Системийн түвшинд авч үзвэл Жава хэл илүү хүчтэй, илүү хурдтай гэдэг дээр миний санал нийлнэ. Харин жижиг сажиг асуудал дээр Си нь илүү хурдан байж болно.
Posted by surgalt on 09/26/2006 05:52:21 AM

When I first read "Java faster than C++ benchmark", I was sure that there was something wrong with it. After all, Java couldn't be faster that C++, right? What would be next? C++ faster than C? C faster than Assembler? After quite a while I've found some time to update the results using brand new JVMs and GCC versions. Benchmark environment The tests were performed on Linux 2.6, AMD Athlon(tm) XP 2500+ (Barton). No other load was placed on the machine during tests, run level 1 (single user mode) had been used. GNU C Library had optimizations for i686 (standard Debian package, this should be of benefit for both Java and C++). I compiled GCC myself from the standard release. Please note that the result of this benchmark (I am talking about "C++ faster than Java" result) is valid for GCC 3.4.4 and 4.0.3 as well, but GCC series 4.1.x is even faster than earlier GCCs. Testing conditions I've kept the original number of repetitions in all tests. Time was measured in the same way as in the original results, with one exception: the time used as benchmark result was elapsed real (wall clock) time used by the process. If we stick to the original method of measurement, the results will be incorrect and biased towards Java - because of threads used by the JVM. Wall clock time is better and more accurate if the machine operates under no load - as was the case here. Java Java was compiled with standard settings, using Java compiler from Sun in the same version as the JVM that was used later to do the actual benchmark. To run hash, heapsort and strcat tests I had to increase the heap size. It's pretty much standard practice for enterprise software, so I do not see it as a drawback of Java. C++ When looking at C++ code, I've noticed many performance problems, which probably may go unnoticed for people with strong Java background. In other words, to make this benchmark fair, I had to make some modifications to the original code. In doing so, I tried to make the code as close to the original as possible, even if my personal coding style is completely different. For C++ compilation, I've used the following options: -O2 -fomit-frame-pointer -finline-functions -march=athlon-xp I consider the first two options standard for compilation (all major Linux distributions, Linux kernel and many others use these two for compilation). -finline-functions is used to tell the compiler to guess which functions should be inlined (Java Server VM also does that, that's one of the reasons for which it performs better than Client VM). Athlon-XP - well, that's my machine. I could use pentium instead (which could be considered more standard), but it would not change the overall result - that, is C++ being the clear winner. So, let's get down to business, shall we?
Posted by zalit test ee gej on 09/26/2006 03:32:00 PM

Нэг жишээ дурдахад Жава хэлээр бүтээсэн Н2 гэдэг нэртэй Өгөгдлийн Сан Удирдах Систем нь 1МБ орчим хэмжээтэй бөгөөд хүчин чадлаараа MySQL-ээс хоёр дахин өндөр. Ер нь дутуу юм гэж байхгүй, харин ч мониторинг, найдвартай байдал гээд олон үзүүлэлтээрээ илүү. Гэтэл MySQL хэр том хэмжээтэй билээ. Ер нь томоохон систем бүтээхэд Жава хэл ашиглахаас татгалзах хэрэггүй гэж үздэг хүмүүсийн тоо улам бүр нэмэгдсээр байна. GlassFish гэж нэрлэгдсэн, Жава хэлээр бүтээгдсэн Үйлдлийн Систем хариугүй мэндлэхээр дуншиж байгааг бас хэлэх хэрэгтэй болов уу.
Posted by surgalt on 09/30/2006 05:32:17 AM

Unshihad yamarch hetsuu yum dee. Mongol ugiig haraad Englishtei ni tulgahaar shal oor utgatai.
Posted by coder on 10/12/2006 10:57:34 AM

Мэргэжлийн нэр томъёог орчуулахад их түвэгтэй. Зарим нэр томъёог яаж орчуулбал эвтэйхэн болох бол гэдэг талаар бодож л байна. Нэр томъёо нь олон талаараа олон дахин хэрэглэж байж хэвшүүлэх ёстой хэвшмэл хэллэг байдаг. Жишээ нь interface, debugger, application, compiler гэх мэт үгсийг жирийн англи хүн уншаад огт ойлгохгүй. Мэргэжлийн сургуульд нь сурч олон жил ажиллаж байж эдгээр үг ямар утгатай болохыг мэднэ. Зарим нь сургуулиа төгссөн хэрнээ үгийнхээ утгыг ойлгодоггүй. Тийм болохоор ийм үгийг монголоор хэлэхэд шууд хараад ойлгоход түвэгтэй байж болно. Ер нь бол хугацаа хэрэгтэй.
Posted by surgalt on 10/12/2006 12:04:24 PM

Хамгийн дээр бичсэн хакерт зориулж бичлээ. Java-г удаан гэх юм бол энэ дэлхий дээр хурдан ажилладаг хэл байхгүй юм байна л даа. Нилээд дээр би нэг бацаантай ярилцсан юм. Тэр бацаан өөрийгөө нилээд том хөгжүүлэгч гээд бодчихож, delphi дээр odbc-гээр холбоод нэг программ бичсэн болтой, java дээр нэг вэб туурвил маягийн юм бичсэн болтой, тэр ямар ч загвар байхгүй servlet дээр бүгдийг нь хийсэн зүгээр л кодинг дотроо холион бантан, ярилцаад үзэхэд ерөөсөө хоосон хонгио. Тэр бацааны зарим ярисан яриаг сонсговол: Би МуSQL дээр ажилладаг, Microsoft SQL for babies, php бол миа, жава бол гоё гэх жишээ нь ий. Дээрхи хакерийн яриаг уншаад гэнэт тэр бацаан санаанд орчихлоо. Java, C, C++ хооронд харьцуулна гэдэг бол сумо, жүдо, үндэсний бөхийн хэн нь мундаг вэ гэж харьцуулж байгаатай адилхан. Яг с хэл дээр дангаар нь бичдэг ажил гэх юм бол одоо зөвхөн систем админстратор, сүлжээнийнхэн, мөн системийн жаахан юм хийвэл бичих ийм л ажил байгаа байх. C++ гэдгийн тухайд одоо C++ дээр ямарваа ажлыг дангаараа бичдэг үлгэрийн далай байхын болисон. Нэг бол microsoft ийн Visual C++ дагана, нэг бол Borland C builder ийг дага. VB.net хүүхдүүдэд гэдгийн хувьд хэрэглээний программ хангамж, ӨСУС-тэй ажиллахад VB.net шиг хүчтэй программчиллын хэл байхгүй гэж хэлэх байна. 1-рт. Өөр өөр зорилгоор ашиглагддаг хэлнүүдийг битгий хооронд нь хольж хутгаад, харьцуулаад тэнэгтээд бай, миний дүү нар за юу. 2-рт программчиллын хэлнээс болж удаан хурдан нь мэдэгддэг тийм том систем одоохондоо та нар бичих болоогүй за юу, харин системээ зөв зохион байгуулж чадахгүй, буруу ашигласанаас чинь болж л систем чинь удаан ажиллаж байгаа байх. Үлгэрлэвэлээс сайн эзэмшиж чадвал мончоог барисан Хишгээ, сайн буудаж чаддаггүй тэгсэн мөртлөө автомат буу барисан Японыг дийлж болно.
Posted by khishgee on 10/13/2006 12:40:16 AM

Арай хатуудуулчих боллоо. Тэгэхдээ хатуу үг сонсоход аягүй ч биенд тустай.
Posted by khishgee on 10/13/2006 09:03:07 AM

Dajgui orchuulga bna. Ingehed ene appication - hereglegdehuun, program - hotolbor g.m orchuulga hiih hereg bsan yumuu. Ehendee bur oilgohgui bailaa shuu :)
Posted by Ott on 02/28/2007 07:33:25 AM

Хөтөлбөр гэдэг үгийн тухайд - энэ бол ямар нэгэн шинэ үг биш. Зурагтын хөтөлбөр гэдэг ч юмуу эсвэл ямар нэгэн зүйлийг хөгжүүлэх хөтөлбөр гэх хэллэг байдаг. Энд ямар нэгэн ажлын дэс дарааллын тухай яригдаж байна. Жишээ нь Үндэсний телевизийн даваа гаригын хөтөлбөр гэхэд эхлээд ийм нэвтрүүлэг гараад дараа нь тийм нэвтрүүлэг гэж явсаар эцэстээ тэр нэвтрүүлгээр дуусна гэх мэт. Малжуулах хөтөлбөр гэхэд л эхний жилд тэр, тэр аймгийн тэр, тэр суманд төчнөөн айлыг малжуулна, дараагийн жилд өөр бусад аймгийн тэр, тэр суманд төчнөөн айлыг малжуулна, ингээд тэдэн жилийн дараа нийт төчнөөн айлыг малжуулахад жил бүр ийм хэмжээний зардал гарна гэх мэтээр хийх ажлуудаа дэс дараалан зохиож бичнэ. Тооцоолуурын хөтөлбөр бичнэ гэдэг нь үүнээс ямар ч ялгаа байхгүй. Тийм болохоор зарим тохиолдолд хөтөлбөр, зарим тохиолдолд программ гэж будлиантуулж байснаас нэг мөсөн хөтөлбөр гээд хаана, хаанаа хэлээд заншвал зүгээр мэт. Хэрэглэгдэхүүний хувьд ч ялгаагүй. Тооцоолуурын хөтөлбөр бүхэн хэрэглэгдэхүүн байх албагүй. Зарим хөтөлбөрийг обьект болгож болдог. Ийм хөтөлбөрийг шинээр бичиж буй ямар ч хөтөлбөр дотор өгөгдлийн төрөл маягаар шууд юмуу эсвэл дахин тодорхойлж сайжруулах замаар ашиглаж болдог. Онцлог нь хэрэглэгдэхүүн хөтөлбөрийг ингэж ашиглахын тулд эх кодыг нь үзэж, харах шаардлага гардаггүй. Нэг ёсондоо .exe файлыг шууд юмуу эсвэл өөрчлөн сайжруулаад ашиглана гэсэн үг. Гэхдээ иймэрхүү маягийн боломж зөвхөн Жава хэлэнд байдаг. Хэрэглэгдэхүүн хөтөлбөр буюу товчоор хэрэглэгдэхүүн гэдэг маань сургууль, соёлын газар хэрэглэгддэг сургалтын хэрэглэгдэхүүн гэдэгтэй агаар нэг. Ерөөс хэрэглэгдэхүүн гэдэг үгийн утга нь өөрөө ямар нэгэн юманд ашиглагддаг, хэрэглэгддэг зүйл гэсэн санаа илэрхийлнэ. Гэхдээ нэг удаа ашиглаад хаядаг зүйлийг биш олон удаа, олон янзаар ашигладаг зүйлийг хэрэглэгдэхүүн гэсэн үгээр хэлдэг. Мэдээж энэ бүхэн бол цэвэр мэргэжлийн үг хэллэг. Жирийн англи хүн мэргэжлийн хүнээр тайлбарлуулахгүй л бол ийм үгийн утгыг уншаад ойлгохгүй. computer program, application гэж юу яриад байгаа юм болдоо л гэж бодно. Хэрвээ ийм үгийг нийтээрээ хэлээд хэвшчихвэл өөр хэрэг. Монголд иймэрхүү үгийг анхнаас нь монголоор хэлээд хэвшүүлчихвэл таньж мэдэхгүй англи үгнээс арай илүү ойлгомжтой болов уу.
Posted by surgalt on 04/02/2007 10:31:19 AM

Туурвил Хөгжүүлэлтийн хичээлийг Та хэрхэн явуулах ёстой вэ?

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

Мэдээллийн технологийн салбарт арав гаруй жил ажилласан гэлтгүйгээр, хүмүүсийг, ялангуяа шинэхэн төгсөгч оюутнуудыг ажилд авахад гардаг нийтлэг бэрхшээл надад бас л тохиолддог. Тооцоолуурын чиглэлээр төгсөгч оюутнуудын тооцоолуурын хөтөлбөр бичих чадвар жилээс жилд улам дордож байгаа гэдэгт үнэний ор бий гэж боддог. Гэтэл хамгийн гайхалтай нь энэ бол боловсролын тогтолцоо нь бүх түвшиндээ хоцрогдсон Бразиль улсад тулгарч буй бэрхшээл биш, ажилтан сонгон шалгаруулна гэдэг нь АНУ болон Европ дахь төслийн менежеруудын хувьд ч толгой өвтгөсөн хурц асуудал болсон хэвээр байна.

Би анхандаа шинээр гарч ирж байсан ашиглахад хялбар RAD /түргэвчилсэн/ хэрэгслэлүүдийг буруутгаж байлаа. Туурвил хөгжүүлэлт гэдэг нь ердөө л визуал самбар дээрээс ямар нэг бэлдэцийг /компонент/ хулганаар чирж, зөөхийн нэр, тиймээс код бичиж сурах албагүй гэсэн өнгөц ойлголт хүмүүсийг байлдан дагуулж эхэлж байв. "Энэ багажыг ашиглавал та заавал хөтөлбөрлөгч байх албагүй" хэмээн амалсан олон багаж төрөн гарч байсан Clipper-ийн эхэн үеийг би тодхон санаж байна. Шийдвэр гаргагчид болон олон сайн туурвил хөгжүүлэгчид иймэрхүү амлалтанд хэт итгэсний горыг бид одоо амсаж эхэлж байна.

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

Жава хэл заахаас сургалтаа эхлэх ёстой гэх юмуу Schema хэл үзэх ёстой гэж маргах нь үнэндээ ямар ч утгагүй. Жинхэнэ ясны туурвил хөгжүүлэгч хүн цамцаа сольж өмсдөг шиг амарханаар нэг хэлээс нөгөө рүү шилжиж чадна. Тооцоолуурын цуутай хэлүүд (ялангуяа Мэдээллийн Тогтолцоо бүтээх зориулалттай) ямагт богинохон настай байдаг. Нас эцэслэхдээ тухайн хэл нэг бол бараа сураггүй алга болно (яг Clipper шиг), эсвэл хэрэгцээгээ дагаад шал өөр, цоо шинэ хэл болон хувирна (өнөөгийн VB.Net шиг). Гэхдээ сүүлийн арван жил Жава бараг өөрчлөгдөөгүй шүү дээ хэмээн та мэтгэж мэднэ, гэвч хэрэв шинээр гарч буй бүх API, фреймуорк бүрийг судалж үзнэ гэвэл Жава үүсэхээс нь одоо хүртэл ашиглаж буй туурвил хөгжүүлэгч хүн дахиад нэг сургууль төгсөх дайны хугацаа зарна гэдгийг ойлгох болно.

Тэгэхлээр ямар хэл ашиглах нь сургалтанд тийм ч чухал биш. Харин юу заах нь чухал. Ихэнхи оюутнууд ажил олж авахын тулд суралцдаг, тиймээс ажлын зар дээр юу чухалчилсаныг чиг баримжаа болгодог нь нууц биш. Маш олон сургуулиуд Жава хэл заах болсон шалтгаан энэ. "Хүүхдийн тоглоомын" хэл ашиглан сургалт явуулаад, эсвэл эрэмбэлэх алгоритм маягийн уйтгартай жишээн дээр бөөн цаг зараад оюутнуудын идэвхи сонирхлыг хэзээ ч өдөөн татаж чадахгүй. Түүнчлэн ажил дээр гараад хийдэг гол ажил нь CRUD хэрэглэгдэхүүн байдаг атал, хүлээлгийн онол /queue theory/ мэтийн нарийн түвэгтэй тооны онолыг оюутнуудад заагаад бас нэмэргүй.

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

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

Энэ бүхний гол буруутан бол яах аргагүй багш нар. Миний мэдэх цөөхөн багш л бодит амьдралд хэрэг болох Обьект Хандалтат хөтөлбөрлөлийн арга техникүүд болон хүснэгтэн өгөгдлийн сангуудыг /relational databases/ хэрхэн оновчтой ашиглах талаар зааж чадна. Тэдний ихэнхи нь Turbo Pascal ч юмуу эсвэл оюутан ахуйдаа сурсан ямар нэг хэлээ өнөөг хүртэл ашигласаар байна. Албан шахалтаар ямар нэгэн шинэ зүйлүүд, жишээ нь Жава заах болмогц, тэдгээр багажийг ашиглахдаа тун тааруухан хөгжүүлэгч болохоо тэдгээр багш нар харуулдаг. Жава заахдаа (ердөө Обьект Хандалтат зохиомжийн хичээлийн нэг хэсэг байсан ч тэр) Struts, Hibernate, JSF болон оюутнуудын сонссон өөр бусад зүйлсийн талаар асуусан асуултанд хариулж чадахгүй бол тэр багш хэзээ ч оюутнууддаа хүндлэгдэхгүй.

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

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

Миний бодлоор бол диплом авахынхаа өмнө эмнэлэг дээр дадлага хийдэгтэй төстэй зүйлийг оюутнууд хийдэг байх ёстой. Чамбай, сайн туурвил туурвин бүтээхийн тулд яг юу сурах ёстойг сайтар ойлгож мэдэхийн тулд бодит амьдралд ойр туурвилын төсөл дээр хэдэн сарын турш ажлын бүтэн өдөр зарцуулан багаар хамтран ажиллахыг тэднээс шаардах хэрэгтэй. Ингэхдээ зөвхөн анхны хувилбар 1.0 гаргаснаар ажил нь дуусдаг байж болохгүй. Магадгүй цоо шинэ хэрэглэгдэхүүн бичих биш, харин төслөө сайжруулах юмуу эсвэл арчилгаа, тордолгоо хийдэг байвал илүү зохино.

Өндөр эрэлт хэрэгцээтэй байгаа шинэ залуу МТ инженерүүдийг яаралтай бэлдэхийн тулд тооцоолуурын чиглэлийн коллежууд сургалтынхаа хугацааг багасгах хандлага Бразиль улсад (АНУ болон бусад оронд бас адилхан уу?) хүчтэй илрэхийг би анзаардаг. Тооцоолуур судлахдаа дөрвөөс таван жил биш, ердөө л хоёр, гурван жил зарцуулна. Сургалтынхаа нийт хугацааны талыг нь хасна гэдэг юу гэсэн үг вэ? Мэдээж, энэ бол оюутнууд зайлшгүй сурах ёстой зүйлээ гүйцэд сурч чадахгүй гэсэн үг.

Яг л эмч нартай адил нарийн мэргэжлээр дагнан гүнзгий мэргэших ёстой чухал салбар бол тооцоолуурын салбар мөн гэж би боддог. Сайн DBA (Өгөгдлийн Сангийн Архитектурч) мэргэжилтэн болоход хичнээн хугацаа шаардагдах вэ? Сүлжээний-аюулгүй байдал хариуцсан экперт болоход? Эсвэл төхөөрөмжийн хөтлөгч /device driver/ бичих чадвартай үйлдлийн системийн түвшний хөгжүүлэгч болоход? Үйлдвэрлэл ч тэр, эрдмийн хүрээлэн ч тэр, аль аль нь ийм хэрэгцээ шаардлагыг ойлгохгүй байгаад хэргийн учир оршино. Туурвилын шилдэг багаж юмуу өндөр хүчин чадалтай тооцоолуур гарснаар туурвил хөгжүүлэгчдийн мэдлэгийн дутууг гүйцээнэ гэж итгэдэг. Байдал ийм байхад, сайн туурвил хөгжүүлэгч болохын тулд хүнд хүчир ажил хийж өөрийгөө зовоохын оронд ийм багаж ашиглах нь хавьгүй дээр гэдэгт оюутнууд хялбархан итгэх нь зүйн хэрэг.

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

Жич: Хөтөлбөрлөгчдийн ур чадварыг сайжруулах асуудал өдгөө дэлхийн аль ч орны хувьд хүнд асуудал болоод байгаа нь түгээмэл үзэгдэл. Үүнийг шийдэхэд харилцан эсрэг, тэсрэг үйлчлэлтэй хоёр хүчний тэнцвэрийн цэгийг зөв олж тогтоох явдал чухал болов уу. Туурвилын /софтвер/ хөгжил нь ямагт тоноглолын /хардвер/ хөгжлөөс ихээхэн хамааралтай байдаг. Тоноглол үнэтэй /санах ойн багтаамж, боловсруулах төхөөрөмжийн хурд, сүлжээний өгөгдөл дамжуулах зурвасын өргөн гэх мэт/ байх, эсвэл хямд төсөр байх нь туурвилын амьдрах тэс өөр өөр орчин, хөрсийг бүрдүүлнэ. Жишээ нь тооцоолуурын санах ойн багтаамж 1МБ - 4МБ, боловсруулагчийн хурд 20Мгц - 30Мгц байх үед ямар нэгэн обьект хөтөлбөрлөл, зургийн орчин эсвэл үзэгдэл боловсруулах загварын талаар санахын ч хэрэггүй. Гэтэл өнөөгийн боловсруулах төхөөрөмжүүд зөвхөн тоо юмуу бичвэр боловсруулах үйлдлүүд төдийгүй дуу, дүрс зэрэг мультмедиа үйлдлүүд хийх чадвартай, тэр ч бүү хэл олон зүтгүүрийн технологи /жишээ нь hyper-threading/ болон виртуалчлалын /зөвхөн виртуал санах ой төдийгүй виртуал машин, виртуал үйлдлийн систем/ технологи зэрэг уламжлалт үйлдлийн системийн хэрэгслэлүүдээр иж бүрэн тоноглогдох болоод байгаа нь туурвил хөгжүүлэх технологийг шинэлэг өнцгөөс харахыг шаардах боллоо. Иймэрхүү үйлдлүүд нь урьд цагт хөтөлбөрлөгч хүнээс ямагт ихээхэн анхаарал, болгоомжлол, цаг хугацаа, хүч шаарддаг байв. Одоо бол энэ бүхэн нь жирийн нэг хялбархан "үнэгүй" автомат үйлдэл болон хувирлаа. Энэ хандлагаа дагаад боловсролын байгууллагууд ч сургалтынхаа агуулгыг илүү хялбарчлах зам руу орсонд зарчмын хувьд нэг их буруу байхгүй.

Аливаа хялбарчлалын амин сүнс нь хийсвэрлэл байдаг. Жишээ нь морь, нохой, гахай, тахиа, хүн гэдэг юмс бүгдээрээ ялгаатай боловч үхэх, төрөх, хооллох, явах гэх мэт олон шинжээрээ төстэй. Энэ бүх нийтлэг шинжээр нь амьтан гэж цоо шинэ хийсвэр юм бодож олж болно. Яг үнэндээ амьтан гэж бодитой юм байхгүй боловч ганц үүнийг ашиглан морь, нохой, гахай, тахиа зэрэг олон бодит юмсыг маш хялбархан бүтээж болно. Ингэснээр жишээ нь боловсруулах төхөөрөмж дотор морь, нохой, гахай, тахиа мэт олон юм суулгахын оронд амьтан гэсэн ганцхан юм суулгах боломжтой болж маш их хэмнэлт гаргана. Үүний нэгэн адил, туурвилууд /нарийндаа бол төрөлжсөн, битүүмжлэгдсэн мэдлэгүүд/ хичнээн олон янз байлаа ч төрөх, үхэх, хооллох, амьсгалах гээд маш олон нийтлэг шинжтэй. Иймэрхүү шинжээр нь зүтгүүр /thread/, ажил үйл /process/ гэх мэт хийсвэр юмс бодож олоод үүнийгээ үйлдлийн системийн цөм дотор амилуулдаг байлаа. Харин өнөөдөр боловсруулах төхөөрөмжүүд маань улам бүр хийсвэр шинжтэй болон хувирч өөрчлөгдөж байна. Хийсвэр байна гэдэг нь цаанаа бол доторхи эд ангиуд нь хоорондоо тодорхой эмх цэгцээр зангидагдсан, нарийн нийлмэл, цогц бүхэллэг шинжтэй байна гэсэн үг. Үүнийгээ дагаад тоноглол маань атомлог шинжээсээ молекуллаг шинж рүү ойртоно. Тэгэхлээр урьд нь удаан, үнэтэй, бараг урлаг гэж тооцогддог байсан зүйлс тоноглолын түвшинд шилжснээр хямдхан, өндөр хурдтай, бараг үнэгүй зүйл болон хувирч байна. Энэ нь асар их хөдөлмөр хөнгөвчилнө. Товчхондоо, бид одоо нэг ёсондоо шилжилтийн үедээ явж байна.

Миний энд хэлэх гэсэн гол санаа бол өнгөрсөн технологитой хэт зууралдах нь өндөр эрсдэлтэй гэдэг утгаараа хүмүүс уламжлалт технологиос дайжих үйл явц явагдаж байгаа бөгөөд энэ нь мэдлэгийн тодорхой хоосон орон зай, хомсдол бий болгож байгаа нь илт. Тэгэхлээр хэсэг хугацаанд энэ хоосон орон зай дээр тоглох бодит боломж бидэнд байна гэсэн үг. Энэ бол үүлэн чөлөөний нар. Миний бодлоор хуучныг хадгалан шинээс хоцрохгүй байх хамгийн шилдэг арга бол чихний эмч, дотрын эмч, элэгний эмч гэдэг шиг тодорхой салбараар дагнан мэргэших явдал. Зөвхөн энэ нөхцөлд л шинэ, хуучныг оновчтой холбож чадна. Орчин үеийн автомат хэрэгслэлүүд ч яг ингэж дагнан хөгжиж байгаа. Дээрхи тэмдэглэлийг бичсэн хүн ч иймэрхүү санааг хэлэх гэсэн юм болов уу хэмээн таамаглаж байна.

Comments

gaihaltai. denduu goyo. naiz mini bicheed baigaarai
Posted by khishgee on 07/26/2006 12:44:51 AM

Их сургуульд программчиллын хэл заана гэдэг бол жаахан сонин асуудал. Угаасаа university гэдэг үгийг хараад л юу заах ёстой вэ гэдгээ сайн санацгаах хэрэгтэй болов уу. Их сургуульд голдуу акедимик шинж чанартай, суурь боловсролыг заах хэрэгтэй, харин төгссөний дараа тэр хүн программчиллын хэлнүүдийг бол ёстой цамцаа солих адил сурна гэдэгтэй үнэхээр санал нийлж байна. Ямар ч байсан намайг КтМС-д сурж байхад хэлийг чухалчилж авч үздэггүй байсан, ерөөсөө заадаг ч үгүй байлаа. Зааж байгаа хэл нь зүгээр бэлэг тэмдгийн чанартай паскал, с++ гэх мэт. Эдгээр хэлийг ашиглаж хэрэглэгдэхүүн зохиоход төвөгтэй, зүгээр массив эрэмблэх, фибоначийн тоо олох энэ тэрийг л хийдэг байв. Тэгтэл ажил дээр гарахад тэр оюутанд тийм юм хэрэггүй. SQL Server, delphi, Visual basic л хэрэгтэй, тийм учраас оюутны чихэнд эдгээр үгнүүд ямар сонсголонтой сонсогддог гээч. Гол хичээлдээ дургүй болдог үндсэн шалтгаан энэ. Нөгөө талаар ажил олгогч ч гэсэн энэ чанарыг л харж ажилд авна. Тэр оюутны обьект хандалтат хэлний мэдлэг ч, өгөгдлийн сангийн зохистой зохион байгуулах ч, падлий байхгүй харин SQL хэл сайн мэдээд DDL, DML, DCL ээр query бичиж чадаж байвал маш их үнэлэгдэнэ. Энэ л жинхэнэ манай сургалтын системийг алж байна даа
Posted by khishgee on 09/17/2006 02:11:56 AM

Таны зохиосон Туурвил Хэрэглэгдэхүүн гэдэг үгнүүд таалагдаад байгаа болохоор блог дээрээ ашиглаад эхэлсэн шүү. Дургүйцэхгүй биздээ. Тависаныхаа дараа хэлж байгаад уучлаарай. Хэхэ
Posted by khishgee on 09/17/2006 02:14:47 AM

Тэгтэл яг үнэндээ системийн шинжилгээ, өгөгдлийн сангийн зохион байгуулалт, үйлдлийн системийн онол, программчиллын хэлний бүтэц зэрэг акедимик хичээлүүд л оюутанд жинхэнэ мэдлэгийг олгож чадна. Анх ажилд орох үедээ муу байсан ч яваандаа эдгээрийг сурсан оюутнууд чангарч ирдэг гэдгийг би анзаарсан юм. DML, DCL, DDL ашиглан query бичихийг ном хараад амаархан сурч болно. Харийн дээр дурдсан хичээлүүдийг зөвхөн эрдэмтэн багш нарын заах арга зүй, мэдлэгээр л олж чадах болов уу
Posted by khishgee on 09/17/2006 02:23:58 AM

Tanii bichsen temdegleliig unshaad unendee sain oilgosongui. (2 unshlaa) Herev tsag zav bolomjtoi bol "Orshil - Asuudal - Ornol - Dugnelt" gesen helbereer dahiad neg bicheerei. Minii oilgosnoor ta hicheel herhen yavuulah ve gesen asuudliin dor, surgaltiin programiin tuhai hamruulaad yariad baih shig baina. End bichsneer ta surgaltiin hotolboroos sort -iin arga geh metiin "amidrald hereg boldoggui" zuilsiig hasaad OOP taliig iluu zaaya gej heleh geed baih shig baina. Yeronhii sanaag tani demjij baina. Harin minii bodloor, ih surguuli gedeg bol hamgiin elementar yumiig oyutnuuddaa hurgeh yostoi. IT world ruu orson bol medeh shaardlagatai basic medlegiig zaah yostoi gesen ug. Hicheel zaadag hunii huvid oyutnuudad sonirholtoi sonirholgui sanagdah ni asuudal baij boloh yum. Gehdee ted suraltssnii etsest hen negen ni ter hetsuu onoliig sursandaa bayarlalaa geh odor irne gej bodoj baina. Bas ter hetsuu onoliig surahguigeer hooloo olj idej bolno. Negen zuil. Bachelor gedeg bol hen negend mergejiliin ondor medleg chadvar ogoh bish, suuri medleg ogdog tuhai salbariin anhan shatnii surgalt yum. Herev to code bichih MT engineer beldeh gej baigaa bol anhnaasaa surguulid surgah shaardlaga ch baihgui. Harin IT -iin yanz buriin mergejiliin hun beldeh gej baigaa bol tedgeeriin suuriig l zaaj ogoh yavdal yum. Daraa ni network administrator bolno uu, DBA bolno uu, magadgui Computer Science-aar sudalgaa hiigeed Turing shagnal avah hun ch garch bolno. Bachelor bol edgeeriin ali ch chigleleer yavsan undsen suuri medlegtei boloh yostoi yum. Bas negen zuil. Odoogiin ondor chadvariin tools -iig ashiglaval programiig hen ch bichne. Harin professional programmer, amatuer programmer -iin hoorondoh yalgaa yu ve gedgiig oyutnuuddaa oilguulj baih heregtei yum. Ter uyed CRUD -aas gadna, DBMS deh indexing esvel suljeenii huleeltiin onol zergiig hen sain medej baigaagaas iheehen yalgaa garah bolno. Tegeheer gol ni suuria zaaj ogoh yostoi yum. Harin bie daaltiin yavtsad pascal zaana uu, C++ zaana uu .NET Framework zaana uu, hamaagui. Bagsh ch edgeeriin buren medeh albagui. Yutai ch onoogiin baidliig dugneed shuumjleltei taliig gargaj irj shinechleh talaar ooriin sanaagaa bichsend ih bayarlalaa. Tand amjilt husie! ps: Ingehed ta ali surguuliin bagsh bilee?
Posted by Negen IT engineer on 11/23/2006 09:00:17 AM

Нэг зүйлийг тодруулахад энэ бол миний бичсэн тэмдэглэл биш, харин коллежид багшилж байсан нэг хөтөлбөрлөгч нөхрийн бичсэн хувийн тэмдэглэлийн орчуулга юм. Сургууль төгсөгчид яагаад ажилдаа тэнцэхгүй байна, яагаад хичээлээ сонирхохгүй, мэргэжилдээ хайнга хандаж байна, үүнд хэн буруутай вэ гэхчлэн үзэл бодлоо илэрхийлсэн байна. Жирийн нэг бразиль хүний үзэл бодол. Харин энэ асуудлаар баримтлах миний хувийн үзэл бодол арай өөр байж мэднэ. Яг нарийндаа, өнөө цагт ямар ч хөтөлбөрийн систем бүтээлээ гэхэд ямар нэгэн зүйлийг шинээр сэтгээд, бодож бясалгаад, нухаад байх шаардлага бараг байхгүй. Юуг, хэрхэн, яаж шийдэх вэ гэдэг үндсэн жор нэгэнт хэвшиж тогтсон. Харин тэдгээрийг хооронд нь хэрхэн хялбарханаар холбож угсрах вэ гэдэг дээр гол асуудал байх шиг байна. Вэбээр жишээлье. Та ямар ч вэб хуудас нэмлээ, хаслаа, өөрчиллөө гэсэн энэ нь ажиллаж буй бусад хэсэгтээ бараг нөлөө үзүүлэхгүй. Үүний тулд олон юм уншиж судлаад байх ч шаардлага байхгүй. Задгай, тогтвортой, уян хатан орчин. Гэтэл өнөөгийн хөтөлбөрийн системд ийм чанар бий юу? Байхгүй. Хамгийн энгийн зүйл хийхийн тулд маш олон журам, зааврыг мөрдөх, судлах, тооцох хэрэгтэй болно. Яльгүй алдаа гаргахад л юунд ч хүргэж мэднэ. Суурь нь ийм байсаар байтал дээр дээрээс нь улам олон юм нэмээд хүн ойлгохын аргагүй түвэгтэй юм бий болгосоор байна. Харин энэ бүхнийг цэгцэлж журамлах цаг, завтай хүн байдаггүй бололтой. Эцсийн эцэст үүнээсээ одоо бүгд залхаж эхэлж байх шиг байна. XML дээр суурилсан Web 2.0 технологи гээд байгаа нь энэ тамаас гарах гарц хайж буй нэг хэлбэр юм болов уу. Яваандаа тооцоолуурын үнэ өртөг буурч, хүчин чадал нэмэгдэхийн хэрээр Web 2.0 технологи илүү эрчимтэй хөгжинө. Тэр цагт л системийг өргөтгөн сайжруулах, эд анги нэмэж, хасах нь гипер холбоос /hyper link/ маягийн амар хялбар болох байх. Өнөөдөр ямар нэгэн логик, алгоритм бичнэ гэхээсээ илүү нэг юмыг нөгөө юмтай холбох гэж хамаг цаг хугацаа, нервээ барж байгаа нь хэнд ч тодорхой. Үүнд ямар нэгэн сургууль, багш, оюутан, эсвэл компанийг буруутгах нь илүүц юм болов уу. Миний хувийн бодол гэвэл иймэрхүү байна.
Posted by surgalt on 11/23/2006 11:04:04 AM

Энд бичигдсэн зүйл төдий олон хүнд хүрэхнүй байна шүүдээ. Тиймч болохоор энд бичсэн зүйл эндээл байгаад хэдхэн хүн саналаа хэлэхээр болчихдог биш зүйл биш байхаа . Энэ асуудлаар үнэхээр санаа зовж явдаг хүн бол өөрийн мессенжерийн хаягийн тусламжтайгаар аль болох бүх хүнд тараахыг уриалж байна. Дамжуулаад байгаараа . Ингэвэл олон хүнд юм бодогдуулах байхаа
Posted by NewStudent on 12/02/2006 11:24:34 AM

Sanalaa helsend bayarlalaa. Yutai ch hunii yum orchuulj bichsen bol hoishid ter tuhaigaa bichij baihiig husie. Tanii sanaa bish gedgiig ch oilgoloo. Harin ene tuhai ta ooroo yag yu gej bodoj baigaagaa iluu todorhoi bichvel ih busad hund ch hureh bolov uu.
Posted by Negen IT engineer on 12/13/2006 03:43:54 PM

Хөгжүүлэгч буюу Хөтөлбөрлөгч

Нөхөр буюу Дайсан

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

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

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

Харин Майкрософт хамтлаг шал өөр соёлтой. Тэднийг Майкрософт Хөтөлбөрлөгчдийн Сүлжээ гэх биш, харин Майкрософт Хөгжүүлэгчдийн Сүлжээ гэж нэрлэдэг.

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

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

Хатуу төмөр дэвсгэртэй, нэг ёсондоо цехийн дамжлагаар хүмүүжсэн хүмүүс үүнийг барагтай бол ойлгохгүй. Тэдний бодлоор, туурвил хөгжүүлнэ гэдэг нь цэвэр механик үйл явц.

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

Амжилттай ажиллахын тулд, юмыг хэрхэн шийдэх талаар өргөн цар хүрээнд харах чадварыг хөгжүүлэгч хүн эзэмшсэн байх ёстой. Тухайн систем юу хийх талаархи ерөнхий ойлголтыг шийдвэр гаргагчид хянаж чаддаг байх ёстой гэдэг боловч өндөр хурдацтай өөрчлөгдөн буй технологийн хөгжил болон туурвил хөгжүүлэх үйлдвэрлэл дэхь арга техникийн хувьслын нөлөөгөөр хөгжүүлэлт хэрхэн хийгдэх ёстой талаар оновчтой шийдвэр гаргахад шийдвэр гаргагчдын ур чадвар яалт ч үгүй дутдаг. Тэд, тухайлбал, хөгжүүлэлтэнд туслах юмуу хурдасгахад ямархуу гуравдагч /third party/ технологи хэрэглэх нь илүү ашигтай вэ гэдэг талаар ухаалаг шийдвэр гаргаж чаддаггүй. Иймэрхүү болон өөр бусад олон асуудлууд дээр хөгжүүлэгч хүмүүс нь өөрсдийгөө шийдвэр гаргагчид хэмээн үздэг хүмүүсээс илт давуу шийдвэр гаргах чадвартай байдаг.

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

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

Шилдэг хүмүүсийг өөрийн байгууллагаасаа дайжихад хүргэж буйгаар тэд бас давхар хохирол амсана. Авъяаслаг хүмүүс хөгжүүлж буй системийнхээ талаар шийдэл гаргах боломжоо хумиулан зөвхөн механик эрэг шургийн үүрэг гүйцэтгэхийг тэсвэрлэж чаддаггүй. Энэ бол зөвхөн сэтгэлзүйн дарамт төдий үзэгдэл биш - энэ нь тухайн хүн цааш ахиж дэвжихэд нь бас хөнөөлтэй. Хэрвээ тэд хөгжүүлэлттэй холбоотой бүх төрлийн хариуцлага үүрэх явдлаас чөлөөлөгдвөл ирээдүйд гарах олон боломжууд тэдний өмнө хаагдана.

Техникийн Ахлах Ажилтан (ТАА) гэдэг ухагдахуун анх гарч моодонд орж байхад нь би үүнийг бүх талаараа дэмжиж байлаа. Учир нь ТАА нь технологийн асуудлыг шийдэх тал дээр байгууллагуудад үнэхээр тус дэм үзүүлнэ гэдэгт итгэж байв. Гэвч харамсалтай нь ТАА-тай нягт хамтран ажиллах явцдаа хийсэн хувийн дүнгэлтээс харахад тэд хөгжүүлэлтийг хурдасгах биш харин сааруулах хүчин зүйл болох нь элбэг байсныг дурдах хэрэгтэй. Эндээс ажигласан нэг зүйл гэвэл туурвил хөгжүүлэгч бид мэтийн хүмүүсийг тэдний өөрсдийнх нь хэлээр ердөө л "хөтөлбөрлөгч" гэж үздэг нь төслийг амжилтанд хүргэхэд томоохон саад бэрхшээл учруулдаг гол хүчин зүйл болж байгаа юм.

http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=239

Жич: Төсөл хугацаандаа амжин дуусаж чадах эсэх нь удирдлага, зохион байгуулалт буюу менежмент хэр сайн муу байхаас шалтгаална гэсэн үзэл санаа дэлхий дахинаа түгээмэл тархсан байдаг. Энэ нь туурвил /software/ хөгжүүлэх үйл явц бол цехийн шат дамжлагаар явагддаг цэвэр механик шинжтэй үйл ажиллагаа, энэ үйл ажиллагаанд тавих хөндлөнгийн хяналтыг сайжруулснаар амжилтанд хүрч болно гэсэн итгэл үнэмшил дээр суурилдаг. Хөндлөнгийн хяналтыг сайжруулах ажлын хүрээнд нэг өдөр, нэг долоо хоног, эсвэл нэг сарын хугацаанд бичигдэх кодын мөрийн тоонд хяналт тавих (гол төлөв хэдийчинээ олон мөр код бичнэ, төдийчинээ сайн гэж үзэх), түгээмэл гарах алдааны статистик бүртгэл хөтлөн мэдлэгийн сан бүрдүүлэх гэх мэт ажлууд ордог. Уг нь бол зөв санаа.

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

Тэр тусмаа өнөөдрийн гол асуудал нь мэдлэгийн сан байгуулах явдал биш, харин мэдлэгийн сан яаж байгуулахгүй байх ёстой вэ гэсэн эсрэг утга руугаа тэмүүлж байна. Бид хэдийчинээ өнгөрснөөсөө хурдан салж чадна, цаг үетэйгээ төдийчинээ хурдан зохицож чадна. Мэддэг зүйлээсээ хурдан татгалзаж салж чаддаг байх хэрэгтэй. Учир нь бидний мэддэг зүйл маань урагш хөгжихөд маань маш том саад учруулдаг. Шинэ технологи нь ямагт хуучнаасаа татгалзах, өмнөхөө үгүйсгэх замаар цааш хөгждгийг санацгаая.

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

Хэдэн жилийн дараа, эсвэл хэдэн сарын дараа кодоо дахин эргэж харахад тулах цэг хэрэгтэй, тэр тулах цэг нь кодын тайлбарууд, баримтууд, гарсан алдаанууд, түүнийг шийдсэн шийдлүүд гэх мэт олон зүйлийг хамарсан мэдлэгийн сан байна гэдэг. Буруу биш. Гэхдээ өнөөгийн software re-engineering tools хангалттай өндөр түвшинд кодонд дүн шинжилгээ, задаргаа хийн шаардлагатай бол кодыг автоматаар шинэчлэн бичиж бас чадна. Үүнд маш бага хугацаа орно. Энэ салбарт өнөөдөр AI буюу хиймэл оюун ухааныг өргөн ашиглаж байна. Ийм багажуудын үнэ ханш ч өдөр ирэх тусам бууж байгаа. Хэрвээ бид цаг үеийнхээ асуудалтай хэт их зууралдаж цаг алдвал, хэрвээ бид мэддэг зүйлээсээ хурдан татгалзаж чадахгүй бол шинэ үеийн технологиудад бут цохигдох магадлал өндөр бий гэдгийг дашрамд тэмдэглэх нь зүйтэй болов уу.

Асуудлыг бүрэн олж харахын тулд маш өргөн хүрээнд сэтгэх шаардлага бий. Энэ удаад үүгээр өндөрлөе. Дараа өөр олон асуудлуудыг хөндсөн блог тэмдэглэл олж орчуулах болов уу хэмээн найдъя.

Жишээ нь agile development tools-ын талаар хэзээ нэгэн цагт дурдах хэрэг гарах болов уу, энэ нь ерөнхийдөө туршилт + сорилт + continuity + integration маягийн багаж гэж төсөөлж байна. Зарчмын хувьд урьдчилан төлөвлөх, хяналт тавихаас аль болох татгалзах чиг хандлагатай, хувь хүний эрх, эрх чөлөө, хариуцлага маш өндөр байхыг шаардсан өөрөө өөрийгөө хянах тогтолцоо гэж ойлгож байна. Ойрын ирээдүй иймэрхүү дүр төрхтэй болох болов уу, тиймээс бид ч бас энэ чиг хандлага руу аажмаар дөхөх ёстой юм болов уу гэж бодож байна.

Алдаатай дайн зарлах биш, харин алдаатай ойртон нөхөрлөх аргачлалд суурилсан хөгжүүлэлтийг өөрөөр test driven development гэдэг. Өөгүй тогтолцоо хэзээ ч ажилладаггүй гэсэн инженерийн алтан дүрэм байдгийг энэ дашрамд дурдаад тэмдэглэлээ өндөрлөе.