5/23/2016

Эхлэн суралцаж буй програм хангамж болон систем инженерүүдэд өгөх зөвлөгөө


/*
 Иляагийн блогоос уншсан зүйлээ өөрийн ойлгосоноор орчуулан мөн өөрт байгаа ажлын тушлагаас нэмж бичлээ. Би өөрөө ч эхлэн суралцагчдийн нэг. Хэрэг болох нэгэнд нь хэрэг болсон гэж найдья.
*/

Хувь хүнээс хамаарах хүчин зүйл

Bug буюу алдаа
Програм хангамжид bug гарах нь зайлшгүй тохиолддог зүйл. Үүнийг хүлээн зөвшөөрөх хэрэгтэй. Хөгжүүлэлтийн үйл явцад маш олон төрлийн bug тохиолдоно. Энэ асуудлыг шийдэх хамгийн сайн шийдэл нь зөв хөгжүүлэлтийн процесс юм. Тэрхүү процесс нь доорхи зүйлсийг багтаасан байх шаардлагатай.
  • Автоматжуулсан тест - Програм хангамж бүтээгдэхүүн болох үед bug гарах боломжийг багасгадаг. Хөгжүүлэлтийн явцад тестэнд өртөөгүй bug байж болох  бөгөөд бүтээгдэхүүний үе шат нь тестийн үе шатаас нэлээдгүй ялгаатай байдаг. Энэ нь зарим алдаа бүтээгдэхүүн болсон үед урган гарч ирдэг ба үүнийг зайлшгүй хянаж байх хэрэгтэй гэсэн үг юм. Автоматжуулсан тест нь доорхи асуудлуутай тэмцэхэд туслана
    • Тестүүдийг гараар оруулж, гараар үр дүнг шалгадагтайгаас болж хөгжүүлэлт удаашрах
    • Гар аргаар тестлээд их хэмжээний алдаа гарч ирэх
    • Муу кодчилол, бараг шинээр эхлэх нь хамаагүй дээр болсон тохиолдлыг эрт илрүүлдэг
  • Аажмаар шинэ хувилбар байршуулах (gradual deployment) - Дэлгэрэнгүйг эндээс
  • Хяналт - Ажиллаж буй программын алдааг илрүүлэх. Программын үзүүлэлтүүд, сүлжээний ачаалал, нөөцийн хэрэглээ гэх мэт шаардлагай үзүүлэлтүүдийг хянах хийх. Энэ нь аажмаар хувилбар үүсгэх (gradual deployment)-тэй сайн хослодог.
  • Гүйцэтгэлийн саатал болон алдааг ажиллаж буй кодноос илрүүлэх, debug хийх. Дэлгэнэгүйг эндээс. (Ялангуяа Metrics гэсэн гарчигийг сайн хараарай)
  • Автоматжуулсан эмчилгээ буюу rollback - Бага зэрэг зальхай, найдвар муутай арга. Бас болгоомжтой ашиглах хэрэгтэй. Жишээ нь: Системд  хамгийн сүүлд суурльлуулсан хувилбар алдаатай эсвэл хэт их ачаалладаг, удаан ажиллагаатай байвал автоматаар алдаагүй өмнөх хувилбарыг сэргээн суурьлуулна гэсэн үг юм. 
Зөв хөгжүүлэлтййн процессруу чиглэх нь бүтээгдэхүүнийг бэлэн болохоос өмнө bug-ийг багасгаж bug засахад зарцуулах хугацааг хэмнэх давуу талтай.

Аль хэдийн шийдсэн боловч ...
А гэх асуудалыг зөвхөн М гэсэн шийдлээр шийдэх ёстой гэж үү? А асуудлыг К тооны шийдлээр шийдэх боломжтой боловч тэдгээр K тооны шийдлээс М нь хамгийн оновчтой байсан учраас сонгогдсон байж болох юм. Гэвч А асуудлын нөхцөл өөрчлөгдөх үед М оновчтой шийдэл хэвээр үлдэж чадах уу? Нөхцөлөөс хамаарч Б шийдэл илүү оновчтой байж болно.
Иймд асуудлыг нэг тогтсон арга барилаар шийдэхээс өмнө өөр шийдэл таний нөхцөлд илүү оновчтой байж болох тухай ахин бодож үзэхэд илүүдэхгүй.

Хялбарчилсан V.S. Хөнгөвчилсөн
Хялбарчилсан: Маш богинохон товч бөгөөд тодорхой ганц мөр код
Хөнгөвчилсөн: Фреймворкоос зуу зуун функц дуудаж ажиллуулах ганц мөр код

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

Тээнгэлзэж бай
Ямар нэгэн ажил хийж байхдаа доорхи бодлуудыг эргэцүүлж байгаарай. Хэдийгээр тийм ч хамааралтай бус дэмий зүйл шиг боловч, бодоод үзэхэд илүүдэхгүй
  • Энэ ажил миний төлөвлөснөөс илүү чармайлт, цаг хугацаа шаардах болно
  • Үр дүнд нь гарах код системийг илүү ойлгоход бэрх болгоно. Мөн арчилгаа, засвар хийх үед хар дарсан зүүд л гэсэн үг
  • Энэ хэсэг нь бараг л хэрэгцээгүй, ер нь хэзээ ч ашиглагдахгүй
Мэргэжилтнүүд nice-to-have буюу програмд байхад дажгүй зүйлээс аль болох зайлс хийдэг. Мэдээж зайлшгүй оруулах албагүй үед.




Код

Кодын давхардалт (duplicate)
Өөрийн бичсэн кодыг олон дахин битгий хуул. Copy+paste хийхээс зайлс хийх хэрэгтэй.
  • Давхардсан код нь илүү их засварлалт шаарддаг
  • Хэзээ нэг өдөр давхардсан кодтой хэсэгт өөрчлөлт оруулах шаардлагатай болдог
  • Тушлагатай хөгжүүлэгч кодыг чинь хараад "үгүй ээ, үгүй" гэж хэлнэ
  • Маш ховор нөхцөлд ашиглах нь оновчтой байх боловч ихэнхдээ таний шийдвэрээс хамаарна. Хэрэв оновчтой биш гэж бодож байвал, битгий хуул

Кодын дахин хэрэглээ
Харин үүнийг аль болох хэрэгжүүлэх хэрэгтэй. Энэ нь фреймворк, сан, класс, функц зэргүүд орно. Эдгээрийг зөв боловсруулж, сайн хэрэглэх нь бүтээмжийг эрс дээшлүүлдэг. Гэхдээ хэрэглэхээсээ өмнө заавал documentation -ийг нь унших цаг гаргах хэрэгтэй. Ингэх нь архитектур, функциональ байдал, чадамж, хязгаар зэргийг ойлгуулдаг. Уншихгүйгээр функцуудын ажиллагааг махчилан ойлгох эсвэл тодорхой код харж ойлгоно гэдэг хэтэрхий хүчир бөгөөд цаг алдсан ажил. Үүний оронд унших нь цаг хэмнэхээс гадна өөртөө оруулах маш сайн хөрөнгө оруулалт болох юм.
Хэрэв үүнийг өөрөө хөгжүүлж байгаа бол кодны documentation -ийг маш сайн хийж өгөх хэрэгтэй.  Програмчлалын хэлүүдэд стандарт documentation хөгжүүлэх загварууд байдаг жишээ нь.
  • Java: Javadoc
  • C/C++: DOC++/Doxygen
  • Python: Pydoc гэх мэт
Мэдээж заавал эдгээрийг дагаж мөрдөх албагүй. 

Кодчилох хэв маяг
Өөрийн гэсэн нэг хэв маягийг сонгоод түүндээ туушдаа байх хэрэгтэй. Зарим тохиолдолд олон программисттуудтай хамтарч ажиллах үед баримтлах дундын стандарт нь таний кодчилох хэв маягт нөлөөлж болох ч энэ нь үндсэн хэв маягт төдийлөн нөлөөлөхгүй ба дасан цохицож болохоор жижиг зүйл.
Маш ховор тохиолдолд зарим программистууд уламжлалт keyboard -ний QWERTY байршилийг бус DVORAK байршилийг ашигладаг. Учир нь QWERTY байршил нь 10 хуруугаар өгүүлбэр, эх бичихэд зориулагдсан байдаг ба код бичихэд зохимжтой бус гэж үздэг. Кодчилолд өргөн ашигладдаг тэмдэгтүүд болох " ' [ ( { < ; зэрэгүүд нь бүгд баруун гар талд бас нэг доор шавж байршсан байдаг.

Систем болон кодын комплекс үнэлгээ
Аль болох энгийн хялбар кодчилохыг эрмэлзэх хэрэгтэй. Замбраагүй, ойлгомж муутай кодчилсон систем нь доорхи сөрөг нөлөөтэй.
  • Арчилгаа хийхэд төвөгтэй
  • Нэмж кодчилоход хэцүү
  • Алдаа их гардаг
  • Алдааг хайж илрүүлэхэд хэцүү
Нарийн төвөгтэй байх, ойлгомжгүй замбраагүй байх хоёр ялгаатай зүйл. Зарим үед асуудлыг шийдвэрлэхийг тулд зайлшгүй нарийн төвөгтэй (комплекс) код бичих шаардлагтай үе бий. Харин кодчилох үед будилаантай, ойлгомжгүй, замбраагүй байна гэдэг муу програм хангамжийн архитектур, муу зохиомж эсвэл муу хөгжүүлэлттийн үр дагавар. Мэргэжлийг программистуудыг аль болох энгийнээр бичиж, илүү цэгцтэй код гаргаж авдаг.


Мэдлэг ур чадвар

Доорхи мэдлэгүүдийг эзэмшсэн байх хэрэгтэй.

Онолын мэдлэг:
  • O тэмдэгэлгээ (математик функц, алгоритмын хязгаарыг дүрслэх)
  • Нийтлэг өгөгдлийн бүтцүүд. Хэрхэн хэрэгжүүлдэг тухай
  • Нийтлэг алгоритмууд, мөн тэдгээрийн хугацаа болоод санах ойн үнэлгээ
  • Асуудал шийдэх(Бодлого бодох) парадигм
  • CPU юу хийдэг. Хэрэглэж буй CPU чинь ямар opcode -той эсэх.
  • Compiler болон compilation гэж юу болох
  • Interpreter гэж юу болох
  • Кернел гэж юу болох. Үйлдлийн системийн үйл ажиллагаа  
Онолыг мэдлэгүүдүүд нь хугацаа өнгөрөх тусам өгөөжөө өгдөг. Хурдацтайгаар шинэ технологид суралцаж, сайжруулахад маш хэрэгтэй ба цаашлаад амжилттай мэргэжилтэн/эксперт болоход түлхэц болно.
Практик мэдлэг:
  • Хоорондоо ялгаатай, тэс ондоо ядаж гурван програмчлалын хэл сурсан байх. C/Java, python, lisp гэсэн гурван хэлийг санал болгож байна. Хэдийгээр lisp хэл дээр ажил олдохгүй ч чамайг илүү сайн программист болгох болно. Яагаад гэдгийг эндээс ушаарай
  • Компьютерийн сүлжээ, интернет, протоколууд хэрхэн ажилладаг болхыг мэддэг байх
  • Үүлэн тооцооллын тухай ойлголтууд 
Практик мэдлэг бол гүйцэтгэлийн хэмжүүр. Таний гүйцэтгэл хэр өндөр түвшинд байна энэ нь танийг тийм түвшиний практик мэдлэгтэйг харуулдаг.

Багаж, хэрэгслүүд
Мэргэжилтэн болхыг хүсэж байвал багажтайгаа ажиллах туршлагатай байх хэрэгтэй. Төсөөл дөө: Ажлынхаа нэлээдгүй цагийг зүгээр л текст(ер нь бол код) засварлахыг тулд өнгөрөөж байна гэж. Үүний оронд хөгжүүлэлтийн орчны хэрэгцээт коммандуудыг сурсан бол ажлын бүтээмжийг 10-20 хувь дээшлүүлнэ. Ухаалаг байдлаар ажиллахын тулд багжаа сайн эзэмших хэрэгтэй.

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

1 comment :