Кодноос цааших зүйлс

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

Нэг талын харилцаа

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

Инженерүүд хоорондын харилцааны хамгийн түгээмэл хэлбэр (кодноос өөрөөс нь гадуур) бол кодын тайлбар (comments) юм. Миний хувийн ажиглалтаар бол маш олон кодын тайлбарууд хэрэггүй байдаг. Гэхдээ заавал тийм байх албагүй! Сайн тайлбарууд нь кодонд өөрт нь илэрхийлэгдэх боломжгүй зүйлсийг тайлбарладаг: ажиллагааны явцыг бус (үүнийг код өөрөө харуулдаг), харин яагаад тухайн үйлдлийг заавал ийм аргаар хийснийг заадаг. Эдгээр нь олон цагийн төөрөгдлийг хэмнэдэг бол муу тайлбар нь кодонд чимээ нэмж, эсвэл бүр буруу тийш чиглүүлдэг.

Бараг үргэлж хэрэг болдог тайлбарын төрлүүд:

TODO-нууд: Дуусаагүй эсвэл цэгцлээгүй кодыг тэмдэглэхдээ бусад хүмүүс юу үлдсэн болон яагаад хойшлуулсныг ойлгох хангалттай тайлбарыг үлдээх хэрэгтэй. “TODO: оновчтой болгох” гэвэл хэрэгцээгүй; харин “TODO: энэ O(n²) давталт нь n<100 үед зүгээр ажиллах боловч хэмжээ томорвол индексжүүлэлт шаардлагатай” гэвэл бодитой ажил болно.
Эх сурвалж: Код нь ямар нэгэн эрдэм шинжилгээний өгүүллээс алгоритм ашигласан, өөр газраас код хуулбарласан, эсвэл баримт бичигт заасан ажиллагааг хэрэгжүүлсэн бол гадаад эх сурвалжуудын холбоосыг оруулж өгөх. Байнгын холбоосуудыг ашиглаж, эх сурвалжаас зөрж байгаа хэсэг байвал тэмдэглээрэй.
Зөв ажиллагааны нотолгоо: Энгийн бус код яагаад зөв үр дүн гаргаж байгааг тайлбарлах. Код нь алхмуудыг харуулдаг бол тайлбар нь тэдгээр алхмууд яагаад зөв ажиллаж байгааг тайлбарлана.
Хүнд хэцүү туршлагаар сурсан сургамжууд: Хэрэв та ямар нэгэн зүйлийн алдааг засах гэж 30-аас олон минут зарцуулсан бөгөөд шийдэл нь илт харагдахааргүй байвал түүнийг баримтжуулаарай. Таны өмнөх хувилбар үүнийг хэрэгтэйг мэдээгүй шиг дараагийн уншигчид ч бас мэдэхгүй.
Тогтмол утгуудын учир шалтгаан: Учир нь тодорхойгүй тоонууд (magic numbers) тайлбар шаарддаг. Яагаад 1492 гэж? Яагаад 16 бит гэж? Энэ утгыг санамсаргүй сонгосон уу, тестээр тогтоосон уу, эсвэл зөв ажиллахад заавал шаардлагатай уу? “Санамсаргүй сонгосон” гэдэг нь ч хэрэгтэй мэдээлэл юм.
Гол тулгуур шийдвэрүүд: Хэрэв зөв ажиллагаа нь маш энгийн мэт харагдах хэрэгжүүлэлтийн деталь дээр тулгуурлаж байвал (жишээ нь, “дор давталтын эрэмбэ чухал тул заавал BTreeSet байх ёстой”) үүнийг тодорхой зааж өгөөрэй.
“Яагаад болохгүй вэ” гэдэг шалтгаан: Хэрэв та илт харагдаж буй хялбар аргыг зориудаар алгасч өөр арга сонгосон бол яагаад гэдгийг нь тайлбарла. Эс бөгөөс өөр хэн нэгэн дараа нь түүнийг “засаж” сайжруулах гээд кодыг эвдэх болно.

README файлууд (танай төсөлд байгаа биз дээ?) нь хөгжүүлэгчидтэй холбогдох хамгийн эхний цэг юм. Сайн README файл дараах дөрвөн асуултад шууд хариулдаг: Энэ юу хийдэг вэ? Би яагаад үүнийг анхаарах ёстой вэ? Үүнийг хэрхэн ашиглах вэ? Үүнийг хэрхэн суулгах вэ? Яг энэ дарааллаар байна. Үүнийг юүлүүр шиг зохион байгуул: хамгийн дээр нь ганц мөр тайлбар болон магадгүй ажиллагааны зураг/бичлэг байрлуулж, хүмүүс хэдхэн секундэд өөрт хэрэгтэй эсэхээ шийдэх боломж олгоод, доошлох тусам гүнзгийрүүлэн бичээрэй. Суулгах заавраас өмнө хэрхэн ашиглахыг харуул — хүмүүс суулгах алхмуудад цаг зарахаас өмнө юу авч байгаагаа харахыг хүсдэг.

Коммит мессежүүд нь ихэвчлэн орхигддог өөр нэг төрлийн “бусдад зориулж бичих” зүйл юм. Тэдгээрийг ихэвчлэн “fixed blah” эсвэл “added foo” гэж бичдэг бөгөөд зарим тохиолдолд энэ нь хангалттай байж болох ч кодын сан яагаад ингэж хөгжсөн тухай түүхэн баримт болж үлддэгийг мартаж болохгүй. Хэн нэгэн (үүнд та ч багтана!) ойлгомжгүй өөрчлөлтийг ойлгох гээд git blame ажиллуулах үед сайн коммит мессеж тэдэнд хариулт өгөх ёстой.

Ерөнхийдөө коммитын бие хэсэг нь дараах асуултад хариулах хэрэгтэй:

Ямар асуудлын улмаас энэ өөрчлөлтийг хийх шаардлагатай болсон бэ?
Өөр ямар хувилбаруудыг авч үзсэн бэ?
Үүний үр дагавар болон сонголтын харьцаа нь юу вэ?
Энэ хандлагын талаар гайхаж магадгүй зүйл нь юу вэ?

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

Нарийн төвөгтэй өөрчлөлтүүдийн хувьд Асуудал → Шийдэл → Үр дагавар гэсэн бүтцийг дагах нь тустай: Эхлээд тулгарсан асуудал эсвэл хязгаарлалтыг бичиж, дараа нь юу өөрчлөгдсөн болон дизайны гол шийдвэрүүдийг тайлбарлаж, эцэст нь гарсан үр дагавруудыг (эерэг ба сөрөг) жагсаана. Тэрхүү сүүлийн хэсэг нь маш чухал; бодит инженерчлэлд сонголтуудын хоорондын тэнцвэрийг хадгалах хэрэг гардаг бөгөөд тухайн сонголтыг зориудаар хийсэн гэдгийг баримтжуулах нь дараагийн хөгжүүлэгчдийг таныг асуудлыг анзаараагүй гэж бодохоос сэргийлдэг.

LLM-үүд нь коммит мессеж бичихэд тустай байж болно. Гэхдээ хэрэв та зүгээр л өөрчлөлтөө харуулаад коммит мессеж бичихийг хүсвэл LLM нь зөвхөн “юу” өөрчлөгдсөнийг л харах бөгөөд “яагаад” гэдгийг харах боломжгүй юм. Үр дүнд нь гарсан мессеж зөвхөн тайлбарласан шинжтэй (бидний хүсэж байгаагийн эсрэг!) байх болно. Хэрэв та өөрчлөлтөө хийхийн тулд анхнаасаа LLM ашиглаж байсан бол тухайн ярианы цонхондоо коммит мессеж бичихийг хүсэх нь илүү сайн сонголт байдаг. Учир нь таны LLM-тэй хийсэн яриа өөрчлөлтийн талаарх маш баялаг нөхцөл байдлыг агуулж байдаг! Үгүй бол, эсвэл үүн дээр нэмээд, LLM-дээ “яагаад” гэдэгт төвлөрсөн коммит мессеж хүсэж байгаагаа хэлж, хэрэгтэй нөхцөл байдлыг танаас асуухыг зааж өгөх хэрэгтэй. Ингэснээр та кодлогч агентын хувьд нөхцөл байдлыг “унших” MCP хэрэгсэл шиг ажиллаж байна гэсэн үг юм.

Өөрчлөлт тань нарийн төвөгтэй болох тусам коммитуудаа логик хэсгүүдэд хуваагаарай (git add -p нь таны туслах болно). Коммит бүр бие даан ойлгогдож, хянагдах боломжтой нэг л цэгцтэй өөрчлөлтийг илэрхийлэх ёстой. Кодын бүтцийн өөрчлөлтийг шинэ боломжуудтай бүү холь, эсвэл хамааралгүй алдааны засваруудыг хамт коммит хийж болохгүй. Энэ нь аль өөрчлөлт ямар асуудлыг зассаныг ойлгоход хэцүү болгож, таны кодын хяналтыг удаашруулна. Мөн нь git bisect ашиглах үед танд давуу тал олгодог боловч энэ талаар өөр нэг удаа ярилцъя.

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

Хамтын ажиллагаа

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

Хувь нэмэр оруулах

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

Жишээлбэл, сайн алдааны тайлан нь асуудлыг ойлгож, дахин гаргахад шаардлагатай бүх мэдээллээр хангаснаар арчлагчийн цагийг хэмнэдэг:

Орчин (Environment): Үйлдлийн систем, хувилбарын дугаар, холбогдох тохиргоо
Хүлээгдэж байсан үр дүн болон бодитоор гарсан үр дүн
Дахин гаргах алхмууд: Тодорхой байх. “Товчлуур дээр дарах” гэхийн оронд “Админ эрхээр нэвтэрсэн үед /settings хуудасны Submit товчлуур дээр дарах” гэвэл илүү тустай.
Таны хийж үзсэн зүйлс: Энэ нь ижил төстэй зөвлөмжүүд давтагдахаас сэргийлж, таныг өөрөө тодорхой судалгаа хийснийг харуулна.

Хэрэв та аюулгүй байдлын цоорхой (security vulnerability) олвол түүнийг нийтэд ил бүү тавиарай. Эхлээд төслийг хариуцагчдад хувиараа мэдэгдэж, түүнийг засахад хангалттай хугацаа өгөх хэрэгтэй. Олон төслүүдэд үүнд зориулсан SECURITY.md файл эсвэл ижил төстэй хуудас байдаг.

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

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

Хэрэв танд шууд хариу өгөхгүй бол арчлагчид нь ихэвчлэн хязгаарлагдмал цаг завтай сайн дурынхан байдгийг санаарай. Хариу хүлээж байгаа бол хэдэн долоо хоногийн дараа эелдгээр асуух нь зүгээр боловч өдөр бүр шавдуулах нь зохимжгүй. Үүнтэй адилаар “me too” (би ч бас) гэсэн сэтгэгдлүүд, эсвэл зүгээр л терминалын гаралт хуулж тавьсан алдааны мэдээллүүд нь асуудлыг шийдвэрлэхэд тус болохоосоо илүү ачаалал үүсгэдэг.

Хэрэв та кодын хувь нэмэр оруулахыг хүсэж байвал төслийн хувь нэмэр оруулах заавартай танилцах хэрэгтэй. Ихэнх төслүүд CONTRIBUTING.md файлтай байдаг — үүнийг дагаарай. Мөн жижиг зүйлээс эхлэхийг зөвлөж байна; бичгийн алдаа засах эсвэл баримт бичгийг сайжруулах нь төслийн үйл явцыг сурахад маш сайн анхны алхам болдог.

Төслийн ашиглаж буй лицензийг шалгаарай. Учир нь таны оруулсан код мөн адил тэр лицензээр зохицуулагдах болно. Ялангуяа copyleft лицензүүдийг (GPL гэх мэт) анхаарах хэрэгтэй бөгөөд энэ нь уламжлагдан гарсан програмыг мөн нээлттэй эх байхыг шаарддаг тул таны ажилладаг компанид нөлөөлж болзошгүй! Илүү мэдээллийг choosealicense.com-оос авах боломжтой.

Та татах хүсэлт (Pull Request буюу PR) нээхээр шийдсэн бол хамгийн түрүүнд зөвхөн оруулахыг хүсэж буй өөрчлөлтөө тусгаарласан эсэхийг баталгаажуул. Хэрэв таны PR өөр олон хамааралгүй зүйлсийг зэрэг өөрчилж байвал хянагч түүнийг цэвэрлэхийг шаардаж буцаах магадлалтай. Энэ нь git коммитоо утгын хувьд холбоотой хэсгүүдэд хуваахтай адил зарчим юм.

Зарим тохиолдолд, хэрэв олон өөрчлөлтүүд хоорондоо ялгаатай мэт харагдавч нэг функцийг ажиллуулахад бүгд шаардлагатай бол бүх өөрчлөлтийг багтаасан том PR нээж болно. Гэхдээ энэ тохиолдолд коммитуудын цэгцтэй байдал маш чухал бөгөөд ингэснээр арчлагчид өөрчлөлтийг “коммит бүрээр нь” хянах боломжтой болно.

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

Бид төслийг салгаж (fork) авахын оронд анхны хандлага болгон upstream (үндсэн) төсөл рүү шууд хувь нэмрээ оруулахыг зөвлөж байна. Салгаж авахыг (лиценз нь зөвшөөрч байвал) зөвхөн таны оруулахыг хүсэж буй өөрчлөлт үндсэн төслийн хамрах хүрээнээс гадуур байгаа тохиолдолд л ашиглах нь зүйтэй. Хэрэв та форк хийж авбал анхны төслийг дурдахаа бүү мартаарай!

Хиймэл оюун ухаан нь зөв мэт харагдах код болон PR-ийг маш хурдан үүсгэх боломжийг олгож байгаа ч энэ нь таныг өөрийн оруулж буй кодоо ойлгох үүргээс чөлөөлөхгүй. Өөрөө тайлбарлаж чадахгүй хиймэл оюуны үүсгэсэн кодыг илгээх нь арчлагчдад тэр кодын зохиогч нь ч ойлгохгүй байгаа кодыг хянах, цаашид арчлах нэмэлт дарамтыг үүсгэдэг. Алдааг илрүүлэх болон засах/шинэ боломж хөгжүүлэхэд хиймэл оюун ашиглах нь зүгээр боловч та өөрөө хянах үүргээ биелүүлж, түүнийгээ чанартай хувь нэмэр болгож цэгцлэх хэрэгтэй бөгөөд энэ ажлыг (хэдийнэ ачаалал нь хэтэрсэн) арчлагчдад үлдээж болохгүй.

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

PR дээр санал хүсэлт хүлээн авахдаа таны код бол та биш гэдгийг санаарай! Хянагчид таныг хувь хүний үүднээс шүүмжлээгүй, харин кодыг илүү сайн болгохыг хичээж байгаа юм. Санал нийлэхгүй байвал тодруулах асуулт асуу — үүний үр дүнд та эсвэл тэд шинэ зүйл сурч болох юм.

Хянах (Reviewing)

Та кодын хяналтыг (code review) зөвхөн ахлах хөгжүүлэгчид хийдэг гэж бодож магадгүй ч танаас бодож байснаас тань хамаагүй эрт код хянахыг хүсэх бөгөөд таны өнцөг маш үнэ цэнэтэй байх болно. Шинэ нүдээр харахад туршлагатай хөгжүүлэгчдийн орхигдуулсан зүйлсийг олж харах боломжтой байдаг бөгөөд кодыг сайн мэдэхгүй хүний асуултууд нь ихэвчлэн баримтжуулах эсвэл хялбарчлах шаардлагатай далд таамаглалуудыг ил болгодог.

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

Сайн код хянах нь цаг хугацааны явцад хөгжүүлдэг ур чадвар боловч дараах зөвлөмжүүд үүнийг илүү хурдан сайжруулахад тусална:

Хүнийг биш, кодыг хяна: “Энэ функц ойлгомжгүй байна” гэх нь “Та ойлгомжгүй код бичжээ” гэхээс хамаагүй дээр.
Бодитой санал хүсэлтийг илүүд үз: “Эдгээр глобал хувьсагчдыг тохиргооны dataclass-аар сольж болох уу” гэвэл “Энд глобал хувьсагч битгий ашигла” гэхээс илүү засахад хялбар байна.
Шаардахын оронд асуулт асуу: “Энд X нь null байвал яах вэ?” гэж асуух нь “Null тохиолдлыг зохицуул” гэхээс илүүтэй хэлэлцүүлэг өрнүүлэхэд тустай.
Учир шалтгааныг тайлбарла: “Энд тогтмол утга ашиглахыг бодоорой” гэхийн оронд “Орчноос хамаарч timeout-ийг хялбар өөрчлөх боломжтой болгохын тулд энд тогтмол утга ашиглахыг бодоорой” гэвэл илүү тустай.
Шийдвэрлэх шаардлагатай асуудал болон зөвлөмжилсөн зүйлсийг заагла: Заавал өөрчлөх шаардлагатай зүйл болон хувийн үзэмжийн асуудал хоёрыг тодорхой зааж өгөөрэй.
Сайн хэсгийг нь сайшаа: Ухаалаг шийдэл эсвэл цэвэрхэн хэрэгжүүлэлтийг тэмдэглэх нь урам зориг өгч, цаашид юуг үргэлжлүүлэн хийх ёстойг зохиогчид ойлгуулдаг.
Хэзээ зогсохоо мэд: Хувь нэмэр оруулагчдад хязгааргүй цаг зав байхгүй тул бүх жижиг зүйл дээр цаг үрэх нь үргэлж зөв байдаггүй. Гол зүйлсдээ анхаарлаа хандуулж, жижиг зүйлсийг дараа нь өөрөө засаж сайжруулах талаар бодоорой.

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

Боловсрол

Инженерүүдийн хувьд бид код бичихээс бусад цагаа асуулт асуух эсвэл хариулахад (эсвэл хоёуланг нь хослуулан) зарцуулдаг; хамтран ажиллах үед, хамт олонтойгоо ярилцахдаа эсвэл суралцах явцдаа. Зөв асуулт асуух нь зөвхөн сайн тайлбарладаг хүмүүсээс бус, хэнээс ч суралцах боломжийг олгодог чадвар юм. Julia Evans-ийн бичсэн “How to ask good questions” болон “How to get useful answers to your questions” гэсэн гайхалтай нийтлэлүүдийг уншихыг зөвлөж байна.

Дараах зөвлөгөөнүүд маш үнэ цэнэтэй байдаг:

Өөрийн ойлголтоо эхэлж хэл: Өөрийн мэдэж байгаа зүйлээ хэлээд “энэ зөв үү?” гэж асуу. Энэ нь хариулж буй хүнд таны мэдлэгийн цоорхойг олоход тусалдаг.
Тийм/Үгүй гэж хариулах асуулт асуу: “X нь үнэн үү?” гэж асуух нь сэдвээс хазайсан урт тайлбараас сэргийлж, ихэвчлэн хэрэгтэй нэмэлт тайлбарыг дагуулдаг.
Тодорхой бай: “SQL join хэрхэн ажилладаг вэ?” гэвэл хэтэрхий ерөнхий байна. “LEFT JOIN нь баруун талын хүснэгтэд тохирох утга байхгүй мөрүүдийг багтаадаг уу?” гэвэл хариулахад хялбар.
Ойлгохгүй байгаагаа хүлээн зөвшөөр: Мэдэхгүй нэр томьёо гарвал яриаг нь таслан асуухаас бүү ай. Энэ нь сул дорой байдлыг биш, харин өөртөө итгэлтэй байдлыг харуулдаг. Үүнтэй адилаар, хэрэв тэд танаас хариултыг нь мэдэхгүй асуулт асуувал “Би мэдэхгүй байна” гэж хэлээд, магадгүй “гэхдээ миний бодлоор…” эсвэл “гэхдээ би олж мэдэж чадна” гэж нэмэх нь хамгийн зөв арга юм.
Дутуу хариултыг бүү хүлээж ав: Бүрэн ойлгох хүртлээ үргэлжлүүлэн тодруулж асуу.
Бага зэрэг судалгаа хийж үз: Бага зэрэг судалгаа хийх нь илүү чиглэсэн асуулт асуухад тусална (хэдийгээр хамт олон дундаа чөлөөтэй асуух нь зүгээр байдаг ч).

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

Энэхүү зөвлөгөө нь LLM-тэй харилцахад ч яг адилхан хамаарна гэдгийг анхаарна уу!

Хиймэл оюуны ёс зүй (AI etiquette)

Програм хангамжийн инженерчлэлд LLM болон AI-ийн хэрэглээ нэмэгдэхийн хэрээр нийгмийн болон мэргэжлийн хэм хэмжээнүүд бүрэлдсээр байна. Бид агентлаг кодчилол лекцээр тактикийн олон асуудлыг авч үзсэн боловч тэдгээрийг ашиглах илүү “зөөлөн” талуудыг ч бас хэлэлцэх нь зүйтэй.

Нэгдүгээрт, хэрэв хиймэл оюун таны ажилд чухал хувь нэмэр оруулсан бол үүнийгээ ил тод дурд. Энэ нь ичих асуудал биш — харин үнэнч байх, зөв хүлээлт үүсгэх, мөн хийгдсэн ажилд тохирох хяналтыг хийхэд тустай юм. Мөн хиймэл оюуныг ажлынхаа ямар хэсэгт ашигласнаа хэлэх нь зүгээр — “би үүнийг бүхэлд нь хиймэл оюунаар хийлгэсэн” болон “би өөрөө нөөцлөх хэрэгсэл бичээд, вэб хэсгийн дизайныг хийхэд LLM ашигласан” гэх хоёрын хооронд маш том ялгаа бий. Жишээлбэл, бид энэхүү лекцийн тэмдэглэлийг бичихэд, үүнд найруулга засах, санаа олох, болон кодын хэсэг, дасгалуудын эхний нооргийг гаргахад LLM-ийг ашигласан болно.

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

Хэрэв та хийж буй ажлаасаа суралцах зорилготой байгаа бол бүх ажлыг эсвэл ихэнхийг нь хиймэл оюунаар хийлгэх нь сурах зорилгыг тань үгүйсгэдэг гэдгийг анхаарна уу; та тухайн ажлын талаар сурахаас илүү промпт бичих (болон магадгүй хиймэл оюуны гаралтыг хянах) талаар л сурч хоцрох болно. Ялангуяа суралцах явцад үр дүн нь бус, сурах үйл явц өөрөө чухал байдаг тул “шийдлийг хурдан олохын тулд” хиймэл оюун ашиглах нь буруу хандлага юм.

Үүнтэй холбоотой өөр нэг асуудал бол ажлын ярилцлага болон бусад шалгалтууд юм. Эдгээр нь LLM-ийн биш, харин таны мэдлэг, чадварыг үнэлэх зорилготой байдаг. Өнөө үед олон компаниуд ярилцлагын явцад хэрхэн ашиглаж байгааг нь ажиглах нөхцөлтэйгөөр (өөрөөр хэлбэл, тэд таны уг хэрэгслийг ашиглах чадварыг бас үнэлж байгаа гэсэн үг!) LLM болон бусад хиймэл оюуны хэрэгслийг ашиглахыг зөвшөөрдөг болсон ч тэд цөөнх хэвээр байна. Хэрэв та тухайн даалгаварт хиймэл оюун ашиглаж болох эсэхэд эргэлзэж байвал асууж тодруулаарай!

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

Дасгалууд

Олон нийтэд танигдсан нээлттэй эхийн төслийн (жишээ нь, Redis эсвэл curl) эх кодыг судалж үзээрэй. Лекцээр дурдсан тайлбарын жишээнүүдийг олж хараарай: хэрэгцээтэй TODO, гадаад баримт бичиг рүү хийсэн холбоос, зайлсхийсэн аргыг тайлбарласан “яагаад болохгүй вэ” гэсэн тайлбар, эсвэл хүнд хэцүүгээр сурсан сургамж. Хэрэв тэрхүү тайлбар байхгүй байсан бол юу алдагдах байсан бэ?
Өөрийн сонирхож буй нээлттэй эхийн төслиг сонгоод түүний сүүлийн коммитуудын түүхийг шалгаарай (git log). Өөрчлөлт яагаад хийгдсэнийг тайлбарласан сайн мессежтэй нэг коммит болон зөвхөн юу өөрчлөгдсөнийг заасан сул мессежтэй нэг коммитыг олж харьцуулаарай. Сул мессежтэй коммитын хувьд өөрчлөлтийг шалгаж үзээд (git show <hash>), Асуудал → Шийдэл → Үр дагавар гэсэн бүтцийн дагуу илүү сайн коммит мессеж бичихийг оролдоорой. Үйл явдлын дараа шаардлагатай нөхцөл байдлыг дахин олж цуглуулахад хэр их ажил ордог болохыг анзаараарай!
GitHub дээрх 1000-аас олон одтой гурван төслийн README файлыг харьцуулаарай. Тэдгээр нь бүгд адилхан тустай байна уу? Таны хувьд хэрэггүй чимээ мэт санагдсан хэсгүүдийг ажиглаж, ирээдүйд өөрөө README бичихдээ сургамж болгоорой.
Өөрийн ашигладаг төслийн нээлттэй асуудлыг олоорой (боломжтой бол “good first issue” эсвэл “help wanted” шошготойг сонгож болно). Тэрхүү асуудлыг лекц дээр дурдсан шалгуураар үнэлээрэй: уг асуудал арчлагчийн цагийг хэмнэсэн, алдааг илрүүлэхэд шаардлагатай бүх мэдээллийг агуулж байна уу, эсвэл үндсэн асуудлыг олохын тулд арчлагч нь асуудал нээсэн хүнээс олон удаа тодруулах асуулт асуух шаардлагатай харагдаж байна уу?
Өөрийн ашиглаж байсан програм хангамж дээр тулгарч байсан алдааг (эсвэл асуудлын сангаас нэгийг) санаарай. Хамгийн жижиг бөгөөд дахин ажиллуулах боломжтой жишээ үүсгэж дадлагажаарай: алдаатай шууд холбоогүй бүх зүйлийг хасаж, зөвхөн алдааг харуулах хамгийн жижиг хувилбарыг үлдээгээрэй. Юуг хассан болон яагаад гэдгээ тэмдэглэн бичээрэй.
Өөрийн мэддэг төслийн дээр нэгтгэгдсэн, дотроо маш олон хяналтын сэтгэгдэл бүхий (зөвхөн “LGTM” биш) татах хүсэлт (PR)-ийг олж уншаарай. Хяналтын явцыг судалж үзээд, бүх сэтгэгдлүүд адилхан үр дүнтэй байж чадсан уу? Хэрэв та тэр PR-ийн зохиогч байсан бол эдгээр сэтгэгдлүүдийг хүлээж авахад ямар сэтгэгдэл төрөхөөр байна вэ?
Өөрийн мэддэг технологийн хүрээнд Stack Overflow-оос өндөр үнэлгээтэй хариулт бүхий нэг асуултыг олж хараарай. Дараа нь хаагдсан эсвэл маш бага (хасах) үнэлгээтэй өөр нэг асуултыг олно уу. Тэдгээрийг лекцээр өгсөн зөвлөмжүүдтэй харьцуулаарай; аль асуулт нь илүү сайн хариулт авах байсныг урьдчилан тааварлах боломжтой байсан уу?

Энэ хуудсыг засварлах.

Лиценз: CC BY-NC-SA.