Кодын чанар
Software code quality
Програм хангамжын чанар олон хүчин зүйлээс хамаардаг боловч хөгжүүлэлтийн хамгийн эцсийн бүтээгдэхүүн бол код юм. Мэдээж баримтжуулалт, бүтээгдэхүүнтэй холбоотой сургалт гэх мэт бусад баримт бичгүүдийг хийдэг боловч хамгийн гол зүйл маань код л билээ. Бидний хийсэн код хир чанартай байгаагаас бүх юм шалтгаална. Кодын чанарыг ойлгомжтой бичлэгтэй, алдааг шалгах, арчилгаа хийхэд амар байдал, энгийн логик, санах ой болон CPU ашиглалт зэрэг үзүүлэлтүүдээр хэмждэг. Алдаатай, чанар муутай, дутуу дулимаг код бүх ажлыг нурааж төслийг зогсоох үүд болж ч болно. Ийм учраас кодын чанарыг сахин хамгаалах төрөл бүрийн арга замыг програм зохиогчид хайсаар иржээ. Ингээд кодын чанарыг дээшлүүлэх, код дотор байгаа хорхойг(bug) түүх, ан цавыг арилгах түгээмэл аргуудын талаар авч үзье.
Код доторх алдааг шалгах хамгийн түгээмэл арга бол тест хийх байдаг. Бичсэн код маань яг миний бодсоноор ажиллаж байна уу? гэдгийг шалгадаг тестийг Unit Test(UT) гэдэг. UT нь код доторх функц бүрийг нэг бүрчлэн шалгах зорилготой. Миний бичсэн хэсгийн код бусад хүмүүсийн бодсоноор ажиллаж байна уу?(бусад хүмүүсийн бичсэнтэй кодтой зохицож) гэдгийг шалгаж үнэмших тестийг Integration Test(IT) гэнэ. IT -ээр системийн бүрэлдэхүүн хэсгүүд нийлүүлж хоорондоо зөв харилцаж чадаж байгаа эсэхийг шалгах зорилготой. Харин бидний хийсэн систем маань гадаад орчинтой зөв харилцаж байгааг шалгах зорилготой тестийг System Test (ST) гэдэг. Эцсийн тест буюу манай бүтээгдэхүүн хэрэглэгчийн төсөөлж байгаагаар ажиллаж чадаж байна уу? гэдэгийг шалгах тестийг Acceptance Test(AT), заримдаа User Test, заримдаа Operational Test ч гэдэг. Ингэхээр маш олон төрлийн тестийг янз бүрийн хүмүүс янз бүрийн нөхцөлд хийх нь. Гэхдээ тэстээр програм хангамжын бүх алдааг олж засна гэж байдаггүйг хэлэх хэрэгтэй. Учир нь боломжит бүх тестийг хийх боломжгүй тул тест дутуу хийгдэж болно. Мөн тухайн тестийн орчин нөхцөлд илрэхээргүй цаг хугацаанаас хамааралтай алдаа байж болохыг үгүйсгэхгүй. Тэгэхээр тест хийх процесст өөрт нь чанарын асуудал тавигдах нь. Тестийн чанарыг янз бүрийн үзүүлэлтээр хэмждэг боловч хамгийн түгээмэл арга нь кодын мөрийн тоог тухайн кодыг тестлэх тестүүдийн тоонд харьцуулсан харьцаа байдаг. Тэгээд 1000 мөр кодод(1KLOC) 60-70 тест харгалзаад тэдгээр тэстээс 5-10 алдаа илэрч байвал тестийг боломжын гэж тооцно гэх зэрэг тооцоо гаргадаг. Энэ тоо мэдээж ямар хэл дээр бичигдсан програм гэдэгээс хамаарч янз янз, мөн хөгжүүлэлтийн баг бүрийн хувьд өөр өөр. Ер нь бол тест маань кодын функц бүрийн доторх салаа мөчир бүрийг хамарч байх ёстой бөгөөд ингэж чадвал код дотор тестэд хамрагдахгүй мөр үлдэхгүй тул тестийн чанар сайжирна. Гэхдээ ингэж тестэлж чадсан ч алдаа байж л байдаг.
Тестээр илэрдэггүй алдааг олох, мөн кодын ойлгомжтой байдал зэрэг бусад чанарт нөлөөлөх хүчин зүйлсийг сайжруулах зорилгоор тест хийхийн өмнө кодыг мөр бүрээр нь шүүж хянах үйлдлийг Code Review(Кодын шүүмж) гэдэг. Кодын шүүмжээр ихэвчлэн функц хувьсагчийн нэршил, тайлбар гэх мэт кодын сахилгатай холбоотой дутагдлыг илрүүлэхээс гадна санах ойн цоорхой, буфер дүүргэлт, deadlock үүсэх нөхцөл зэрэг нууцлал ба найдвартай ажиллагаатай холбоотой алдааг илрүүлэхийг зорьдог. Мэдээж эдгээр төрлийн алдааг илрүүлсний дараа код дээр засаад зогсохгүй ирээдүйд иймэрхүү алдааг гаргахгүй байх талаар бодолцоно. Кодын шүүмж нь тестээр илэрдэггүй ноцтой алдаануудыг илрүүлэх шилдэг арга боловч кодын хэмжээ их үед бүх кодыг шүүнэ гэдэг боломжгүй байдаг.
Дээрх аргатай нилээд төстэй боловч илүү нарийн зохион байгуулалттай дэг журам дор хийгддэг харьцангуй үр дүнтэй Code inspection(Кодын үзлэг) гэдэг аргачлалын талаар дэлгэрэнгүй авч үзье. Сайн хийгдсэн кодын үзлэг нийт алдааны 90 хувийг илрүүлдэг гэсэн тооцоо бий. Гэхдээ хамгийн гол нь жирийн тестээр илэрдэггүй алдаануудыг олдогтоо байгаа юм. Кодын шүүмжээс ялгагдах онцлогууд нь нарийн мэргэшсэн хүмүүсээр хийгддэг, мөн хатуумжын тодорхойлолт(hardware specification) болон үзлэгийн жагсаалт(inspection checklist) заавал байх ёстой. Бас нэг хүнд 300-аас дээш мөр код өгдөггүй(код доторх тайлбар орохгүй цэвэр код). Үзлэг хийгдэх ёстой кодын хэсгүүд болон хэзээ үзлэг хийгдэх тов, үзлэг хийх заавар, хатуумжын тодорхойлолт, үзлэгийн жагсаалт зэрэг баримтуудыг үзлэг хийх хүмүүст тарааж өгнө. Үзлэгийг шүүмж шиг нэг өрөөнд цуглаж хийдэггүй. Үзлэгт бэлтгэх хугацаа буюу үзлэгийн тов хүртэл алдаа доголдлыг илрүүлэх гол үйл явц болдог. Үзлэгчинд ингэж хугацаа өгөх нь үзлэгийг чанартай хийхэд нөлөөлөх нэг хүчин зүйл юм. Товлосон хугацаа болоход илэрсэн алдаа дутагдлуудыг нийлүүлж ангилаад үзлэгийн тайлан бэлддэг. Энэ бэлдсэн тайлангаа бүх багаараа хэлэлцэж засварлах ажлыг кодыг бичсэн хүнд онооно. Ингэж аль болох олон хүнийг тайланд оролцуулах нь мэдлэг хуваалцах, алдаан дээрээ суралцах бололцоог бий болгож байгаа хэрэг. Үзлэгийн жагсаалтад маш олон зүйлийн алдааны тохиолдлууд байж болно. Тухайлбал C хэл дээрх кодын хувьд түгээмэл гардаг 600 орчим алдааны төрөл байдаг байна. Жишээ нь :
if (a = b)
дээрх код хэлний дүрмийн хувьд алдаагүй боловч үнэн хэрэгтээ програмист:
if (a == b)
гэх гээд алдаатай бичсэн байж болно. Иймэрхүү алдаануудыг статик шинжилгээний багажууд(static analysis tools) амархан илрүүлдэг. Статик шинжилгээ гэдэг нь програмыг ажиллуулалгүйгээр эх кодыг шинжилдэг аргыг хэлдэг. Түгээмэл статик шинжилгээний багажууд дунджаар 350-400 орчим төрлийн алдааг илрүүлдэг. Бусад багаж хэрэгслээр илрэхээргүй алдааг үзлэгчин нүдээрээ олно. Гэхдээ ийм багажуудыг хэрэглэх нь кодын үзлэгийн ажлыг үлэмж хөнгөвчилж өгч байгаа юм. Багаж хэрэгсэл нь өөрийн жагсаалтад байгаа алдааг найдвартай олох учраас үзлэгийн жагсаалтад байж нүдээр хайх алдааны тоог хэд дахин цөөрүүлнэ. Тогтмол тооны алдаа илрүүлдэг багажууд байхаас гадна шинээр алдааны төрлийг тодорхойлж нэмж өгөх боломжтой багаж хэрэгслүүд ч байна. Мөн хүний хайх зарим алдааг хангалттай өндөр магадлалтайгаар тодорхойлж чаддаг ухаалаг статик шинжилгээний багажууд сүүлийн үед гарч эхэлж байна. Иймэрхүү багажууд нь ажиллаж байх үед(runtime) гарч болох алдаануудыг ч олдог. Тухайлбал массивын индэкс хэтрэх(array index out of bounds) боломж, санах ойн халилтын(overflow) алдаанууд гэх мэтийг хамгийн муу тохиолдлуудыг тооцож үзэх замаар олдог. Жишээ нь:
short = short |* short
// short тоог short тоогоор үржүүлээд short-д хадгалах үйлдэл
дээрх тохиолдолд хоёр үржвэр бага тохиолдолд хэвийн боловч үржвэрүүдийн аль нэг нь хангалттай их, тухайлбал short ийн дээд хязгаарт ойрхон үед асуудал үүсэх магадлалтай. Ухаалаг статик шинжилгээний багаж бол иймэрхүү алдааг илрүүлж харуулах ба үзлэгчин энэ тохиолдолд үнэхээр асуудал үүсч болох уу үгүй юу гэдгийг нягтлаад хэрэв үнэхээр хэвийн биш бол алдааны жагсаалтдаа оруулах юм. Иймэрхүү хэрэгслүүдийн нэг жишээ нь FindBugs. Энэ хэрэгсэлд өөрийн суурь алдааны хэлбэрүүд(bug patterns) байхаас гадна хэрэглэгч өөрийн алдааны хэлбэрийг тодохойлж өгөх боломжтой. Ингэж хэлбэрийг нь тодорхойлж багажид оруулах боломжгүй алдаануудыг үзлэгчин өөрөө хайна. Мөн өгөгдлийн урсгал зөв эсэх, дизайныг код дээр зөв бүрэн хэрэгжүүлсэн эсэх, кодын сахилга бат зэргийг үзлэгчин шалгадаг. Гэхдээ үзлэгчин зөвхөн үзлэгийн жагсаалтад байгаа алдааг хайх биш өөрийн мэдлэг чадварын хүрээнд бусад алдааг ч олохыг зорих ёстой. Хэрвээ жагсаалтад байхгүй алдаа олдвол түүнийгээ ерөнхийлөн тодорхойлоод үзлэгийн жагсаалтад нэмнэ. Ингэж үзлэгийн жагсаалт өөрөө сайжирдаг. Иймэрхүү аргаар үзлэгийн жагсаалт ашиглаад гарцыг сайжруулах аргыг кодын шатнаас гадна системийн хөгжүүлэлтийн бусад үе шатуудад ч хэрэглэдэг.
Чанартай, алдаагүй систем байгуулах формал арга(formal methods) бол хамгийн найдвартай нь гэж тооцогддог. Формал аргаар хөгжүүлж байгаа код математик үүднээс батлагдсан байх учраас код доторх алдаанд санаа зовох явдалгүй байдаг. Гэвч формал аргаар системийг хөгжүүлэхэд онол практикийн нилээд өндөр хэмжээний мэдлэг туршлага шаардахаас гадна томоохон системийг формал аргаар хөгжүүлэхэд зарим хязгаарлалтууд гарч ирдэг. Иймд одоогоор дайн байлдааны(mission critical) болон хүний аминд аюул учирч болох(life critical) системүүдийг энэ аргыг хэрэглэж хийдэг. Гэхдээ сүүлийн жилүүдэд энэ аргачлалаар хийгдэх системийн тоо нэмэгдэж байгаа бөгөөд ирээдүйд энэ найдвартай аргыг хаа сайгүй өргөн хэрэглэдэг болно гэдэгт итгэлтэй байдаг.
Холбоосууд: