Хэрхэн САЙН ХӨГЖҮҮЛЭГЧ болох вэ?

2B | +1% better 2day | c.002

--

Өмнөх дугаараар КОД гэж юу болох, хэн бичих, яагаад код бичиж сурах нь танд хэрэгтэй талаар бичсэн бол энэ удаа жинхэнэ “coder” буюу ХӨГЖҮҮЛЭГЧ нарт болон компьютерын чиглэлээр сурч буй оюутан залуустаа зориулж санаж явахад илүүдэхгүй байх хэмээн өөрийн туршлага, үзэл бодлоосоо хуваалцахаар шийдлээ.

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

“Програм нь хамгийн гол нь хүн уншихад зориулж, хажуугаар нь машин гүйцэтгэх боломжтойгоор бичигдэх ёстой” — Хал Абелсон

Түр хүлээгээрэй, энэ дээр юу юу гээд хэлчихвээ? Код бичих чинь машинаар ямар нэг юмыг хийлгэх гэж л бичдэг биз дээ” гэж бодож байвал та яг одоогийн байдлаар “NEWBIE” төвшин дээр байгаа бололтой. Би ч бас анхлан суралцаж байхдаа “compile” л амжилттай болвол бүх юм дууссан мэт ойлгодог байсан.

Ихэнх хүмүүс КОД-ыг хамгийн гол нь “машин”-д зориулан бичдэг гэж эндүүрдэг. Харин үнэн хэрэгтээ бид код бичихдээ бусад хөгжүүлэгч нарт эсвэл ирээдүйн өөртөө (future self) зориулж бичдэг. Учир нь ойлгоход хэцүү хирнээ “ажилладаг” код болон хэн ч хараад шууд ойлгож чадах “тэнэг” код хоёрын хооронд тэнгэр газар шиг ялгаа бий.

Тэгвэл “САЙН ХӨГЖҮҮЛЭГЧ” болохын тулд яах ёстой вэ?

  1. MVC — загварыг ойлгох
  2. Coding Principle — дагаж мөрдөх
  3. Comment — хэрэгцээт үед бичих
  4. Test code — бичиж занших
  5. Linter — ашиглаж сурах
  6. Бусадтай сайн харилцах
  7. Бусдаас тусламж авах
  8. Юмыг бүхлээр нь харах
  9. Тасралтгүй суралцах

дээрх жагсаалтыг ойлгон хэрэгжүүлж чадвал та зүгээр нэг “programmer” биш жинхэнэ “developer” болох бөгөөд цаашлаад “software engineer” болоход асуудалгүй байх буй заа гэж мөхөс би хувьдаа бодном.

1. MVC гэж юу вэ?

Model, View, Controller архитектурын загвар нь аппликэйшнийг гурван хэсэгт салган хөгжүүлэлт хийдэг бөгөөд сүүлийн үед вэб хөгжүүлэлтэд түлхүү хэрэглэгдэж байгаа архитектурын загвар юм.

  • Model — мэдээллийг хадгалах
  • View — хэрэглэгчид мэдээллийг харуулах
  • Controller — хэрэглэгчээс зааварчилгаа авах

гэж салгасан байх бөгөөд тус тусад нь байлгаснаар coupling буюу модулиудын харилцан хамаарлыг багасгадаг. “Loose Coupling” түүний давуу тал болон “High Coupling”-г яаж илрүүлэх талаар мэдэхийг хүсвэл энэ холбоосоор орж үзээрэй.

2. Coding Principle гэж юу вэ?

Кодлох зарчим нь програмын загвар, кодын бичилт болон хэрэгжүүлэлтийг сайжруулахын тулд хэрэглэдэг зааварчилгаа, мөрдөх зарчим юм.

Хамгийн энгийн бөгөөд чухал зарчмуудаас дурдвал KISS, DRY, YAGNI болон Boy Scout Rule гэж байдаг.

  • Keep It Simple Stupid : Ихэнх систем нь нарийн төвөгтэй бүтэцтэй (complex) байснаас илүү энгийн байлгавал харьцангуй сайн ажилладаг
  • Don’t Repeat Yourself : Нэг зорилготой функц нь эх код дотор зөвхөн нэг л газар байх хэрэгтэй
  • You Ain’t Gonna Need It : Хэрэгцээ гараагүй л бол ирээдүйд зориулж код бичих хэрэггүй
  • Boy Scout Rule : Эх код дотор өөрчлөлт оруулах үед өмнө байснаас нь илүү цэвэрхэн болгож засах хэрэгтэй

Эдгээрээс гадна SOLID буюу дараачийн төвшний гэж хэлж болохоор кодлох зарчим бас бий. Кодлох зарчмуудын талаар илүү ихийг мэдэхийг хүсвэл энэ холбоосоор орж богино тайлбарыг сонирхоорой.

3. Comment-ийг хэзээ бичих вэ? (тайлбар)

Хэрвээ KISS, DRY, YAGNI, SOLID зарчмуудыг сайн мөрдсөн бол эх код дотор “comment” бичих шаардлага тэр бүр гараад байхгүй. Гэхдээ заавал бичих ёстой бол аль болох товч, тодорхой байх хэрэгтэй. Учир нь тайлбар нь өөрөө байнгын арчилгаа шаардах ба шинэчлэл хийгдээгүй тайлбар нь тэр чигээрээ төөрдөг ой л гэсэн үг.

Code never lies, comments sometimes do.” — Ron Jeffries

Сайн бичсэн код нь өөрөө тайлбар болдог болохоор хэрвээ танд “comment” бичих шаардлага гарвал энэ нь магадгүй таны код дахин сайжруулах (simplify) хэрэгтэй байгааг илэрхийлж байж болох юм.

4. Тест код яагаад хэрэгтэй вэ?

Тест код бичээгүй програм нь өөрөө хэзээ ч дэлбэрч болзошгүй “тэсрэх бөмбөг” байдаг. Мэдээж тест код бичсэнээр

  • Програмыг тестлэх үйл явцыг автоматжуулах (цаг хэмнэх)
  • Өргөн хүрээнд, найдвартай шалгах (гар тестээс илүү баталгаатай)
  • Алдааг эрт олох (сүүлд олсон алдааг засах өртөг их байдаг)
  • Чанар болон гүйцэтгэлийг хэмжих (quality & performance)

зэрэг олон талаар ашигтай байдаг ч хамгийн чухал нэг зүйл нь ХӨГЖҮҮЛЭГЧ өөрөө бичсэн кодоо тестлэх үед кодоо сайжруулах, хэрхэн зөв техникийг ашиглахыг сайн сурч авах боломж юм.

5. Linter гэж юу вэ, хэрхэн хэрэглэх вэ?

Код бичихэд бид “кодлох зарчим” дагахаас гадна олон хөгжүүлэгчид нэг төсөл дээр ажиллахад гардаг түгээмэл асуудал бол “formatting” байдаг.

Хүн болгон өөр өөрийн гэсэн арга барилаар бичих ба хамгийн оптимал, стандартын дагуу код бичихийн тулд linter” ашиглах нь хурдан бөгөөд, үр өгөөж өндөртэй арга юм.

Linter” нь

  • Бичиглэлийн алдаа (syntax error)
  • Боломжит алдааг урьдчилан анхааруулах (potential error)
  • Бичгийн хэвшлийн алдаа (styling error)
  • Автоматаар засах (--fix)

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

6. Би САЙН код бичдэг, надад бусадтай харилцах тийм чухал гэж үү?

Хэдий та маш САЙН “coder” байлаа ч юу хийх ёстойгоо эхлээд мэдэх хэрэгтэй болох нь зайлшгүй. Хөгжүүлэгчид доорх зүйлсийг өдөр тутам хийж байдаг.

  • Бичиг баримт унших, бэлтгэх
  • Асуулт асуух, лавлах
  • Бусдад тайлбарлах, заах

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

Санаж явах зүйлс:

  • Бусдыг сонсож сурах (харилцаа гэдэг нь ээлжилж ярих)
  • Тойруулж ярихгүй байх (цаг үрэх)
  • Товч бөгөөд тодорхой мэдээлэл өгөх (Be concise but specific)
  • Цэгцтэй бөгөөд энгийнээр бичих (KISS зарчим бас энд ч ашиглаж болно)
  • Бусдад шүүмжлэлт хэлэхдээ хэрхэн зөвөөр ойлгуулах, шүүмжлэлийг зөвөөр хүлээж авах

7. Бусдаас хэзээ тусламж хүсэх вэ?

Мэдээж шинэхэн ажилтан эсвэл шинэ технологи сурч байх үед асуух асуулт олон гарч ирдэг. Гэхдээ асуулт болгоныг Documentation болон Tutorial-уудаас ойлгож авах боломж байдаггүй. Тэр үед та бусад туршлагатай хөгжүүлэгч нараас тусламж хүсэх хэрэгтэй болно. Тэгвэл бусдаас тусламж хүсэхдээ анхаарвал зохих хэдэн зүйл байдаг.

  1. Өөрөө оролдож үзэх
    * Typo шалгах
    * Debugger хэрэглэх
    * Өөр хэл дээр ижил төстэй зүйл хайх
  2. Асуултуудыг болж өгвөл нэгтгэх (олон удаа асуухгүйн тулд)
    * Гарч ирсэн асуудлуудыг нэгтгэн асуух (явцдаа өмнөх зарим асуултын хариуг олох тал бий)
    * Нэг даалгаврыг хийх нийт цагийн 25% хүртэл өөрөө оролдох
  3. Боломжит хариулт хувилбар гаргаж ирэх
    * Юу юу туршиж үзсэн, ямар үр дүн гарсан
    * Ямар боломж байгаа талаар

8. Хэрхэн асуудлыг ТОМООР харах вэ?

Алдааг олж засах нь зөвхөн тухайн асуудлыг шийдэхээр зогсох учиргүй.

  • Асуудал яагаад асуудал гарсан
  • Өөр ямар хэсгүүдтэй холбоотой болох
  • Яавал асуудал дахиж гарахгүй байх (тухайн асуудал болон засвараас үүдэн гарах)

зэргийг цогцоор нь харан шийдэх нь чухал байдаг.

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

“Don’t just fix the bug, fix all possibility of it ever happening again.”

9. Тасралтгүй суралцах гэдэг боломжтой юу?

Технологийн эрин үед бүх зүйлийг сурах гэдэг нь өөрөө хэзээ ч биелэгдэшгүй даваа. Гэсэн хэдий ч та компьютероо шинэчилдэг шигээ өөрийгөө шинэчлэхгүй бол тун удахгүй “Windows XP” мэт болох вий. Зарим хүмүүс нэг бол бүх зүйлийг мэддэг юм шиг хирнээ юуг ч төгс эзэмшээгүй эсвэл зөвхөн нэг л зүйлийг сайн сурах гэсэн хоёрхон сонголт л байдаг гэж боддог тал бий. Гэвч юу СУРСАН гэдгээсээ илүү ЯАЖ сурах, хаанаас мэдээллийг олж авах, хэрхэн үр ашигтай хэрэглэх аргыг эзэмшсэн байх нь нэг зүйлийг төгс эзэмшсэнээс илүү гэж би боддог.

Хэрвээ та

  • Documentation уншиж, ашиглаж чаддаг
  • Google ахаас хүссэнээ хайж олоод судалчихдаг
  • Ямар нэг зүйлээс хэрэгтэйг нь авч өөртөө шингээж чаддаг бол

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

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Kent Beck

Дүгнээд хэлэхэд код бичихдээ зүгээр нэг ажилладаг биш, өөрөө сайн ойлгож системээ бүхлээр нь харан бичих хэрэгтэй бөгөөд бичсэн код нь

  • Уншигдах байдал (Readability) — хэн ч хараад ойлгох
  • Өргөтгөх боломж (Extensibility) — өөрчлөлт оруулах боломж
  • Засварлах боломж (Maintainability) — авч явахад хялбар
  • Модультой байх чанар (Modularity) — хэсэгчлэн дахин ашиглах

шинжүүдийг агуулсан байвал сайн код болсныг илтгэх байх гэж би бодож байна.

Үүнээс гадна код бичих Waterfall, Agile, Test Driven Development (TDD), Feature Driven Development (FDD), Pair Programming гэх мэт хөгжүүлэлтийн аргууд байдаг. Дараачийн сэдвээрээ (Кодлох зарчим | 2B | +1% better 2day | c.003) эдгээрээс ишлэл татан ярилцацгаая.

--

--

Билигүн.Б (Програмч аав)
2B +1% better 2day

I am who I am... || өөрийнхөөрөө байхаас ичихгүй