Техник өр гэдэг нь дараа сайжруулан засахаар, яг одоо хурдан үр дүнд хүрэхийн тулд бичигдэж буй код юм. Техник өр нь бусад төрлийн өртөй зарчмын хувьд адил. Жишээ нь байр худалдаж авахтай харьцуулья. Ихэнх хүн шууд байр авах санхүүгийн чадамжгүй тул банкнаас зээл авдаг. Дараагийн 15–30 жилд энэхүү өрөө нэмэлт хүүгийн хамтаар төлөх бөгөөд чадахгүй бол байраа алдана.
Техник өр яг үүнтэй адил. Хөгжүүлэгчид бүтээгдэхүүнээ илүү хурдан хөгжүүлэх боломжтой болох боловч ирээдүйд хөгжүүлэх процес илүү удаашрах болно. Тухайн асуудлыг эхний байдлаар шийдэхэд зарцуулснаас илүү цагийг өрөө төлж барагдуулахад зарцуулах болно.
Софтвер инженерийн асуудлуудыг оновчтой шийдвэрлэхэд ихэвчлэн урьдчилсан хөрөнгө оруулалт ихээр шаарддаг. Аливаа үр дүнд хүрэхийн тулд их хэмжээний код бичдэг ба энэ үед яавал илүү найдвартай, томруулж болохоор(scalable) код бичих нь тодорхойгүй байдаг.
Техник өр нь цаашдын хөгжүүлэлтэнд хүндрэл авчрах ба мөн урт хугацааны өсөлтөд саад болж болзошгүй. Гэвч ихэнх старт апууд техник өр тавих шаардлагатай учирдаг. Олонх нь богино хугацааны өсөлтөд хүрэх шат болгон өр тавьдаг байна. Тиймээс техник өрийг заавал буруу зүйл мэтээр харах хэрэггүй.
Техник өр нь зүгээр нэг хийсвэр ойлголт төдий зүйл биш. Үүнийг бодитоор дүрслэн харуулж болно. Жишээ нь алгоритмын хүндрэлийг дүрсэлдэг Big О аргачлалыг ашиглая. Кодын бааз нэмэгдэх тусам шинэ код бичихэд нэмэгдэх хүндрэлийг тооцоолбол:
Цэнхэр O(n) шугмаас дээш байгаа бүхнийг техник өр гэж ойлгож болно. Үүнээс дүгнэвэл техник өр нь код нэмэгдэх тусам шинэ код бичих процесийг хүндрүүлдэг байна.
Цэнхэр шугмаас доош байгаа шийдэл нь ихэвчлэн хийсвэрлэл, дундын сан болон бусад хөгжүүлэлтийг хөнгөвчлөх зорилготой шийдлүүдийг агуулдаг. Эдгээр шийдлүүд нь янз бүрийн хамрах хүрээтэй байна. Дотоод хяналтын монитор зэрэг зөвхөн нэг төсөлд зориулсан шийдлээс гадна React эсвэл Docker(эдгээр шийдлийг төсөл бүр дээр шинээр бичдэг бол хичнээн хүндрэлтэй байх бол?) зэрэг өргөн хэрэглээний шийдлүүд байж болно.
Графикт дүрсэлснээр техник өр үүсгэх нь эхэн үедээ зөв сонголт ба энэхүү хэсгийн хэрэглээ нэмэгдвэл хурдан рефактор хийх ёстой болох нь. Хурдан санаагаа буулгаад болж байвал олон iteration сайжруулалтуудыг хийх нь ихэнхи старт апуудад тохиромжтой зарчим болно.
Эхлээд шийдлийнхээ санааг олоод дараа нь хэрхэн олон iteration -ы дагуу сайжруулж болох санааг олох хэрэгтэй. Шинэ модуль бичихдээ O(n²) хүндрэлтэй байхаар бичээд (техник өр хэлбэрээр), дараа нь дахин сайжруулж O(n) болон O(log n) хүндрэл рүү авчирч болно. O(log n)шийдэл нь нэг хөгжүүлэгч эсвэл жижиг хэмжээний багийн үр дүнг том багийн олон давталттай хүрсэн үр дүнд хүрэх боломжыг олгоно гэсэн үг шүү дээ.
Компани тодорхой хэмжээний кодын бааз үүссэний дараа “scalability threshold” (зурган дээрээс харна уу) цэгт хүрэх болно. Энэ үед хэрэгтэй багажуудыг хөгжүүлэх нь шинэ код нэмэхэд үүсэх хүндрэлээс хялбар болж эхэлнэ гэсэн үг. Тиймээс цөөн хүн бага чармайлтаар үр дүнд хүрч болох шийдлүүдийг кодчилж эхлэх хэрэгтэй.
Онолын хувьд шугаман O(n) шийдэл нь техник өр үүсгэхгүй. Шинэ хүн цаг нэмээд түүнтэй тэнцэх үр дүнг аваад байж болно. Амьдрал дээр гэхдээ ийм байдаггүй байна. Цаг хугацаа, хүний нөөц, хүний хүсэл тэмүүлэл зэрэг нь хязгаарлагдмал нөөц юм. Хүний нөөц тодорхой хэмжээнд хүрсэний дараа нэмэгдүүлэхэд хэцүү болдог. Хөгжүүлэгчид төвөгтөй процессийг тогтмол давтах нь бас том асуудал болно.
Техник өр үүсгэх зөв үе нь?
Үйлчлүүлэгчид танай код ямар нь байх нь хамаагүй зүйл юм. Тэд зүгээр л бүтээгдэхүүн хүсч байгаа. Хэзээ ч хэрэглээнд нэвтрүүлээгүй, алдаа нь тодорхой болоогүй “төгс” модулийн дэргэд хэрэглэгчид хэрэг болох хэд хэдэн муухан бичигдсэн модулууд харьцуулшгүй үнэ цэнэтэй зүйл юм.
Гол нь техник өрөөс үүсэх давуу тал нь өрөөсөө илүү байх хэрэгтэй. Өр тавьж авсан бүхэн чинь өр болон түүн дээр нэмэгдэх “хүү”-ээс илүү үнэ цэнийг үүсгэж байх ёстой.
Техник өр нь залхуурах шалтаг байж болохгүй. Урт хугацааны алсын хараатай чинь зохицох тактик байх ёстой. Старт апууд хурдан хөдөлж санаагаа хурдан туршиж үзээд гол асуудлыг ойлгосны дараа сайжруулж scalable шийдлүүдийг хайх хэрэгтэй. Тэгээд эцэст нь өрөө төлөх ёстой.
Техник өр маш олон тохиолдолд ашигтай зүйл байж болно. Фэйсбүүкийн үндсэн зарчим “move fast and break things”. Техник өр үүсгэх нь Фэйсбүүкийн амжилтын зайлшгүй хэсэг байсан ба Гүүглэтэй харьцуулахад кодын чанар хичнээн гамшигийн байсан талаар эндээс уншиж болно. Гол нь тэд үүсгэсэн өрнөөсөө илүү хурдан scale хийж чадаж байсан тул амжилтанд хүрчээ.
Мэдээж техник өр хэзээ үүсгэх вэ гэдгийг мэдэхэд туршлага хэрэгтэй. Эдгээр өрийг төлж барахгүй дампуурал болгохгүйн тулд communication хэрэгтэй. Маш олон тохиолдолд техник өр нь урагшаа явах хамгийн зөв зам байх болно.
Эх Сурвалж Б. Билгүүн
