Рефактор хийхээсээ өмнө

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

Рефактор хийх гэдэг нь …

Гэхдээ та, тийм үйлдэл хийхээсөө өмнө доор өгүүлэх зүйлсийн талаар сайн бодож, тунгаавал өөрийн болон бусдын цаг (мөн шаналал) -г ихээхэн хэмнэж болох юм:

• Шинэчлэн зохион байгуулах ажлаа эхлүүлэх хамгийн зөв алхам бол одоо байгаа коод болон тэрхүү коодонд зориулан бичигдсэн тестээ ямар ч өөрчлөлтгүйгээр, яг тэр чигээр нь авах юм. Дараа нь энэ байгаа байдлаараа ямар давуу талтай, сул талтай вэ гэдгийг нь сайн судлаж, ямар алдаанаас нь зайлсхийхийн зэрэгцээ ямар давуу талыг нь хадгалж үлдэх ёстойг тогтоох хэрэгтэй. Бид бүгдээрээ л одоо байгаа системээс илүү сайныг хийж чадна гэж боддог. Тэгээд рефактор хийдэг. Гэтэл үр дүн өмнө байснаасаа сайжрахгүй юмуу, бүр муугаар болвол, улам дорддог нь цөөнгүй. Үүний шалтгаан бол, бид одоо байгаа системийнхээ алдаанаас сайн суралцаж чадаагүйгээс болдог.
• Бүх коодоо шинээр бичих гэж адгахаас зайлсхий. Аль болох их коодыг дахин ашиглах нь хамгийн зөв шийдэл болдог. Харахад хичнээн царай муутай ч гэсэн хуучин коод бол аль хэдийн туршигдсан, хянагдсан байдаг. Хуучин коодыг хэрэглэхгүй хаяна гэдэг нь, ялангуяа жинхэнэ (production) орчинд бол хэдэн сар, жилээр туршигдсан, ажиллагаа нь жигдэрсэн, таны анзаараа ч үгүй элдэв янзын алдааг нь зассан коодоо хаяж байна гэсэн үг. Хэрэв үүнийг тооцохгүй бол хуучин дээрээ аль хэдийн засагдсан байсан өнөөх л нэг сонин алдааг дөнгөж бичсэн шинэ коод дээр чинь дахин гаргах нөхцөл болно. Энэ бол хэдэн сар, жилээр ч хэмжигдэж болох маш их цаг, хичээл зүтгэл, мэдлэгийг дэмий үрсэн хэрэг юм.
• Олон жижиг жижиг өөрчлөлт нэг том өөрчлөлтөөс илүү дээр байдаг. Бага багаар хийсэн өөрчлөлтийн дараа хэрэглэгчдээс ирэх санал, коодонд хийгдэх туршилтанд суурилан, системд ирэх нөлөөлөллийг тохируулж, зөөлөн байлгах боломжтой. Нэг доор хийсэн том өөрчлөлтийн дараа хэдэн зуун тестэнд зэрэг зэрэг алдаа гарахыг харах тоглоом биш. Энэ нь хөгжүүлэгчдийг сэтгэлээр унагаж, дарамтанд оруулан, улмаар муу шийдвэр гаргахад хүргэдэг. Харин үүний эсрэг, цөөн хэдэн алдаа гарвал түүнийг засах, шийдэхэд хялбар.
• Өөрчлөлт бүрийн дараа хуучин тест алдаагүй ажиллаж байх нь маш чухал. Хэрэв хуучин тест нь шинээр нэмэгдсэн коодын өөрчлөлтийг хамрахгүй байвал шинэ тест нэмэх нь зөв. Хуучин коодонд хамаарах тестийг сайн нягтлахгүйгээр устгаж болохгүй. Өнгөц харахад тэдгээр хуучин тестүүд чиний шинэ коодонд хэрэггүй юм шиг байсан ч яагаад энэ тест бичигдэх болсон бэ гэдгийн шалтгааныг бүр гүнзгий судлаж үзвэл зүйтэй.
• Хувь хүний сонголт, эгогоо хойш тавьж сур. Хэрэв ямар нэг зүйл эвдрээгүй л бол яагаад засах ёстой билээ? Коодын хэв загвар, бүтэц нь чиний таашаалд нийцэхгүй байх нь өөрчлөн шинэчлэх шалтгаан болох ёсгүй. Өмнөх хөгжүүлэгчийн хийснээс илүү сайныг хийж чадна шүү дээ гэсэн чиний бодол ч рефактор хийх бодитой шалтгаан болохгүй.
• Шинээр гарсан технологи дангаараа рефактор хийх шалтгаан болж болохгүй. Одоогийн байгаа коод шинээр гарсан технологиос хоцрогдчихлоо, шинэ хэл, шинэ фрэймворк хуучнаасаа илүү сайн ажиллана гэсэн хоосон найдлага бол рефактор хийх хамгийн муу шалтгаануудын нэг нь. Зардал болоод үр дүнгийн харьцуулсан судалгаа хийж, ажиллагаа, засварлах боломж, бүтээмж зэрэг нь хуучнаасаа илэрхий дээр гэдэг нь харагдаагүй л бол шинээр гарсан ямар ч хэл, ямар ч багажийг тоохгүй орхисон нь дээр.
• Хүн бүр алдаа гаргадгийг санаж яв. Шинэчлэл, өөрчлөлт хийвэл хуучнаасаа дээрдэнэ, бүр ядаж хуучин шигээ сайн болно гэсэн баталгааг байнга өгөхгүй. Өөрчлөлт нь бүтэлгүйтсэн олон тохиолдлыг би харж байсан. Заримд нь оролцож ч байсан. Хэрэв бүтэлгүйтвэл тун онцгүй байдаг. Гэхдээ бид хүн л юм чинь алдаж болно шүү дээ.

Ражит Атапату

https://www.linkedin.com/in/rajith-muditha-attapattu/

Randoli компанийн үүсгэн байгуулагч, CTO (Chief Technology Officer)