Миний баримталдаг “зарчим”

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

Өмнөх дугаараараа хэрхэн сайн хөгжүүлэгч байх талаар ярьсан бол өнөөдөр илүү нарийвчлан зөвхөн код бичих талаар бичихээр шийдлээ. Доорх жагсаалт нь бүрэн төгс хувилбар биш бөгөөд гагцхүү миний баримтлахыг хичээдэг “КОДЛОХ ЗАРЧИМ”-уудаас түүвэрлэн авсан хэсэг юм. Хэрвээ таны мөрддөг зарчимтай таарахгүй эсвэл энэ дотор байхгүй байвал саналаа сэтгэгдэл дээр бичиж үлдээгээрэй.

1. Нэршил (Naming)

Класс, Метод, Хувьсагч болон Тогтмолуудад нэр өгөхдөө шууд хараад юунд ашиглагдаж байгаа нь ойлгогдохоор бөгөөд хэтэрхий товчилсон эсвэл хэт урт байлгахаас татгалзах хэрэгтэй.

Өгөгдсөн тоонуудын нийлбэрийг түр зуур хадгалдаг хувьсагчийг нэрлэх сонголтууд
- Хэт богино : tmpR
- Тохиромжтой : tempResult
- Огт тохироогүй : immutableSum
- Хэт урт : temporaryResultHoldingVariable

Жишээ болгож түгээмэл хэрэглэгддэг “naming convention”-ыг орууллаа :

• Класс (class) — UpperCamelCase
• Метод (method)— lowerCamelCase
• Хувьсагч (variable)— lowerCamelCase
• Тогтмол (constant) — CAPITALS_CAPITALS
• Багц (package) — lowercase.lowercase.lowercase

Eclipse — дээр миний хэрэглэдэг “CheckStyle” нэмэлт хэрэгсэл (plugin).

2. Формат (Formatting)

Бичсэн код нь хүнд ойлгогдохоор байх нь сайн ажилладаг байхаас дутахааргүй чухал байдаг. “Linter” болон “Beautifier” хэрэглэх нь кодыг харагдцын хувьд цэгцтэй болгож, уншигдах байдлыг хялбарчлах бөгөөд дараа нь засах хүнд ч амархан байх болно.

“Tab” уу эсвэл “space” үү, “comment”-ийг хэзээ бичих, нэг мөр кодын хамгийн их байж болох тоо, мөр хооронд зай авах эсэх гэх мэт энгийн боловч хамгийн чухал зүйлсийг бичлэгийн форматыг янзлах үед огтхон ч мартаж болохгүй.

VS Code — дээр миний хэрэглэдэг “Beautify”, “ESLint”, “RuboCop” нэмэлт хэрэгслүүд (plugins).

3. Тууштай байх (Consistency)

Sometimes we must sacrifice quality and quantity for consistency.

Чанар болон тоо чухал байдаг ч заримдаа “тууштай” байх нь илүү чухал байдаг. Таны мөрддөг арга барил эсвэл тухайн ажиллаж байгаа төсөл дээр хэрэглэж байгаа “Formatting”, “Naming convention”-г байнга дагаж мөрдвөл шинээр бичсэн код нь хуучин кодоос ялгархааргүй ижил стандартынх байх болно. Хамгийн энгийн нэг жишээ бол догол мөр (indentation) авахдаа “tabs” эсвэл “space” хэрэглэх юм. Алийг нь хэрэглэх нь мэдээж таны сонголт. “Space”-ийг хэрэглэлээ гээд би таныг “ Richard Hendriks” шиг шүүмжлэхгүй. Гэхдээ сонгосон сонголтдоо ҮНЭНЧ байх хэрэгтэй гэдгийг сануулмаар байна.

“Consistency”-ийн талаар богинохон боловч сонирхолтой нэгэн нийтлэл.

4. Энгийн бөгөөд тэнэг байлгах (KISS)

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

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” — Antoine de Saint-Exupery

5. Өөрийгөө давтахгүй байх (DRY)

Хэрвээ нэг хэсэг кодыг хуулж өөр газар хэрэглэж байгаа бол дараа нь хэзээ нэгэн цагт өөрчлөлт орох үед олон газар засвар орох хэрэгтэй болно. Энэ нь үргэлж эрсдэлийг дагуулж байдаг. Дан ганц засварын үед гарч болох алдаа, дутуу орхилтоос гадна эх кодын хэмжээ ихсэх, засвар орох үед их цаг үрэх зэрэг асуудлууд “DRY” кодлох зарчмыг дагаагүйгээс болж үүсдэг.

“DRY” кодлох зарчмын талаар илүү ихийг эндээс.

6. Чамд “энэ” хэрэг болохгүй (YAGNI)

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

Хэрвээ та Ванга эмээгийн ач зээ л биш бол юу хэрэгтэйг урьдчилан тааж илүү зүйл хийхгүй байхыг зөвлөе.

7. S.O.L.I.D (SOLID)

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

• S (SRP — Single Responsibility Principle)
  - Нэг класс нь нэг л зүйлийг хийх ёстой.
• O (OCP — Open/Closed Principle)
  - Объект нь өргөтгөлд нээлттэй боловч, өөрчлөлтөд хаалттай байх хэрэгтэй.
• L (LSP — Liskov’s Substitution Principle)
  - Уламжилсан класс нь үндсэн (эцэг) классаа орлох боломжтой.
• I (ISP — Interface Segregation Principle)
  - Хэрэглэгч нь өөрт хэрэгцээгүй методоос хүчээр хамааралтай байх нь буруу зүйл.
• D (DIP —Dependency Inversion Principle)
  - Дээд төвшний модуль нь доод төвшний модулиос хамаарч болохгүй. Харин хоёулаа хийсвэрлэлээс хамаарна.

Төгсгөлд нь дүгнэхэд хөгжүүлэгч та дээрх зарчмуудыг дагаж мөрдөн зөвхөн хэрэгтэй цагт нь, шаардлагын дагуу, илүү зүйлгүй бөгөөд эх код дотор нэг л газарт байрлах S.O.L.I.D код бичихийг эрмэлзвэл зохилтой.

Ингэж чадвал таны бичсэн програм маргаангүй
* Уншигдах байдал (Readability)
* Өргөтгөх боломж (Extensibility)
* Цаашид авч явахад амар (Maintainability)
* Модульлаг байдал(Modularity)
гэсэн чанаруудыг агуулсан “тэнэг” код байх болно гэдэгт би итгэж байна.

Иш татсан холбоосууд :

• Naming convention confusion
• Naming convention practices
• Wiki 1 — Principles wiki
• Wiki 2 — Self documenting code
• Story 1 — Top 9 qualities of code
• Story 2 — 10 Basic programming principles
• Story 3 — The Principles of Good Programming
• Story 4 — The Principles of Good Programming and benefits
• Story 5 — From STUPID to SOLID Code
• Болон нийтлэл дотор холбоосууд