Сайн уу найзуудаа. Хичээл эхлэхийг угтан , уламжлал ёсоор хэрэгтэй материалын орчуулгыг тантай хуваалцдаг.
Програм хангамж нь өдөр тутмын даалгавруудыг шийдвэрлэхийн зэрэгцээ улам бүр төвөгтэй болж байна. Марк Андрессений нэгэнтээ хэлсэнчлэн энэ нь дэлхийг иддэг.
Үүний үр дүнд программуудыг боловсруулж, хүргэх арга зам нь сүүлийн хэдэн жилийн хугацаанд эрс өөрчлөгдсөн. Эдгээр нь олон тооны зарчмуудыг бий болгосон тектоник масштабын шилжилтүүд байв. Эдгээр зарчмууд нь баг бүрдүүлэх, дизайн хийх, боловсруулах, эцсийн хэрэглэгчдэд таны програмыг хүргэхэд тустай болох нь батлагдсан.
Зарчмуудыг дараах байдлаар нэгтгэн дүгнэж болно. програм нь жижиг хэмжээтэй, вэб дээр суурилсан, хөгжүүлэгч төвтэй архитектуртай байх ёстой. Эдгээр гурван зарчмыг бодолцсоноор та эцсийн хэрэглэгчдэд хурдан бөгөөд найдвартай хүргэх, хялбархан өргөжүүлэх, өргөтгөх боломжтой, бат бөх, төгсгөл хүртэлх програмыг бий болгож чадна.
Санал болгож буй зарчмууд бүр нь хэд хэдэн талтай бөгөөд эдгээр зарчим нь арчлахад хялбар, ашиглахад хялбар найдвартай програмуудыг хурдан хүргэх эцсийн зорилгод хэрхэн хувь нэмэр оруулдгийг харуулахын тулд хэлэлцэх болно. Энэ нь юу гэсэн үг болохыг тодруулахын тулд бид зарчмуудыг эсрэг заалттай нь холбон авч үзэх болно, "Та үүнийг ашиглаж байгаа эсэхээ шалгаарай. жижиг зарчим".
Энэхүү нийтлэл нь таныг орчин үеийн хэрэглээг бий болгоход санал болгож буй зарчмуудыг ашиглахад түлхэц өгөх бөгөөд энэ нь байнга өсөн нэмэгдэж буй технологийн стекийн нөхцөлд дизайн хийхэд нэгдсэн арга барилыг бий болгоно гэж найдаж байна.
Эдгээр зарчмуудыг хэрэгжүүлснээр та програм хангамж хөгжүүлэх сүүлийн үеийн чиг хандлагын давуу талыг олж авах болно програм боловсруулах, хүргэх, сав ашиглах (жишээлбэл, ) болон контейнер зохион байгуулах хүрээ (жишээ нь, ), микро үйлчилгээний хэрэглээ (Микросервис Архитектурыг оруулаад и бичил үйлчилгээний програмуудад зориулагдсан.
Орчин үеийн програм гэж юу вэ?
Орчин үеийн програмууд? Орчин үеийн стек? "Орчин үеийн" гэж яг юу гэсэн үг вэ?
Ихэнх хөгжүүлэгчид орчин үеийн програм юунаас бүрдэх талаар ерөнхий ойлголттой байдаг тул энэ ойлголтыг тодорхой тодорхойлох шаардлагатай байна.
Орчин үеийн программ нь React JavaScript номын сангийн хэрэглэгчийн интерфэйс, Android эсвэл iOS гар утасны програм эсвэл өөр API-д холбогддог апп гэх мэт олон үйлчлүүлэгчийг дэмждэг. Орчин үеийн программ гэдэг нь өгөгдөл эсвэл үйлчилгээ үзүүлдэг тодорхойгүй тооны үйлчлүүлэгчийг хэлнэ.
Орчин үеийн програм нь хүссэн өгөгдөл, үйлчилгээнд хандах API-г өгдөг. API нь өөрчлөгдөөгүй, тогтмол байх ёстой бөгөөд тодорхой үйлчлүүлэгчийн тусгай хүсэлтэд зориулж бичээгүй байх ёстой. API нь HTTP(S) дээр ашиглах боломжтой бөгөөд GUI эсвэл CLI-д байгаа бүх функцэд хандах боломжийг олгодог.
Өгөгдөл нь JSON гэх мэт нийтлэг хүлээн зөвшөөрөгдсөн, харилцан ажиллах боломжтой форматтай байх ёстой. API нь RESTful API эсвэл GraphQL гэх мэт тохиромжтой интерфэйсийг хангадаг гэх мэт объект, үйлчилгээг цэвэр, эмх цэгцтэй байдлаар харуулдаг.
Орчин үеийн программууд нь орчин үеийн стек дээр бүтээгдсэн бөгөөд орчин үеийн стек нь ийм программуудыг дэмждэг стек юм. Энэхүү стек нь хөгжүүлэгчдэд HTTP интерфэйстэй програм үүсгэх, API төгсгөлийн цэгүүдийг цэвэрлэх боломжийг олгодог. Сонгосон арга нь таны аппликейшнд JSON форматаар өгөгдлийг хялбархан хүлээн авч, илгээх боломжийг олгоно. Өөрөөр хэлбэл, орчин үеийн стек нь арван хоёр хүчин зүйлийн хэрэглээний элементүүдтэй тохирч байна .
Энэ төрлийн стекийн түгээмэл хувилбарууд дээр тулгуурладаг , , , , и . Микро үйлчилгээний архитектур дурдсан хэл бүрт хэрэгжсэн орчин үеийн стекийн жишээг харуулж байна.
Бид зөвхөн микро үйлчилгээний хандлагыг дэмжихгүй гэдгийг анхаарна уу. Та нарын олонхи нь хувьсан өөрчлөгдөх шаардлагатай цул програмуудтай ажиллаж байхад зарим нь өргөжин тэлж, микро үйлчилгээний програмууд болж хөгжиж буй SOA програмуудтай ажиллаж байна. Зарим нь сервергүй програмууд руу шилжиж байгаа бөгөөд зарим нь дээр дурдсан хослолуудыг хэрэгжүүлж байна. Нийтлэлд дурдсан зарчмууд нь эдгээр систем бүрт цөөн хэдэн өөрчлөлт оруулан хамаарна.
Зарчмууд
Одоо бид орчин үеийн хэрэглээний программ болон орчин үеийн стек гэж юу болох талаар нийтлэг ойлголттой болсон тул орчин үеийн программыг хөгжүүлэх, хэрэгжүүлэх, хадгалахад танд сайн үйлчлэх архитектур, хөгжлийн зарчмуудыг судлах цаг болжээ.
Зарчмын нэг нь "жижигхэн программ хийх" мэт сонсогдож байна, зүгээр л нэрлэе жижиг зарчим. Олон тооны хөдөлгөөнт хэсгүүдээс бүрдсэн гайхалтай нарийн төвөгтэй програмууд байдаг. Хариуд нь жижиг, салангид бүрэлдэхүүн хэсгүүдээс програм бүтээх нь түүнийг бүхэлд нь зохион бүтээх, засвар үйлчилгээ хийх, ажиллахад хялбар болгодог. (Бид "энгийн болгодог" биш "хялбаршуулдаг" гэж хэлснийг анхаарна уу).
Хоёрдахь зарчим нь бид хөгжүүлэгчдийн бүтээмжийг нэмэгдүүлэхийн зэрэгцээ тэдгээрийг хөгжүүлж буй онцлогт нь анхаарлаа төвлөрүүлэхэд нь туслахын зэрэгцээ тэдгээрийг хэрэгжүүлэх явцад дэд бүтэц болон CI/CD-ийн асуудлаас ангижруулах явдал юм. Товчхондоо бидний арга барил хөгжүүлэгчид дээр төвлөрсөн.
Эцэст нь таны програмын бүх зүйл сүлжээнд холбогдсон байх ёстой. Сүүлийн 20 жилийн хугацаанд бид сүлжээнүүд илүү хурдацтай болж, программууд илүү төвөгтэй болж, сүлжээний ирээдүй рүү чиглэсэн томоохон алхмуудыг хийсэн. Бидний өмнө дурдсанчлан орчин үеийн программыг олон янзын үйлчлүүлэгчид сүлжээнд ашиглах ёстой. Сүлжээний сэтгэлгээг архитектурт ашиглах нь маш сайн үр өгөөжтэй байдаг жижиг зарчим хандлагын тухай ойлголт, хөгжүүлэгч рүү чиглэсэн.
Хэрэв та хэрэглээний программ зохиох, хэрэгжүүлэхдээ эдгээр зарчмуудыг баримталж чадвал бүтээгдэхүүнээ боловсруулах, хүргэх тал дээр маргаангүй давуу талтай болно.
Эдгээр гурван зарчмыг илүү нарийвчлан авч үзье.
жижиг зарчим
Хүний тархи их хэмжээний мэдээллийг нэгэн зэрэг хүлээн авахад хэцүү байдаг. Сэтгэл судлалд танин мэдэхүйн ачаалал гэдэг нэр томьёо нь мэдээллийг санах ойд хадгалахад шаардагдах нийт оюуны хүчин чармайлтыг хэлдэг. Хөгжүүлэгчдийн танин мэдэхүйн ачааллыг багасгах нь нэн тэргүүний зорилт бөгөөд энэ нь бүх програмын одоогийн цогц загвар, хөгжүүлж буй функцуудыг толгойдоо байлгахын оронд асуудлыг шийдвэрлэхэд анхаарлаа төвлөрүүлэх боломжийг олгодог.
Дараах шалтгааны улмаас програмууд задардаг.
- Хөгжүүлэгчдийн танин мэдэхүйн ачааллыг бууруулах;
- Туршилтыг хурдасгах, хялбаршуулах;
- Хэрэглээний өөрчлөлтийг хурдан шуурхай хүргэх.
Хөгжүүлэгчдийн танин мэдэхүйн ачааллыг бууруулах хэд хэдэн арга байдаг бөгөөд эндээс жижиг байх зарчим хэрэгждэг.
Тиймээс танин мэдэхүйн ачааллыг бууруулах гурван арга байна:
- Шинэ функцийг боловсруулахдаа тэдний анхаарах ёстой цаг хугацааг багасга - хугацаа богино байх тусам танин мэдэхүйн ачаалал бага байх болно.
- Нэг удаагийн ажил гүйцэтгэх кодын хэмжээг багасгах - код бага - ачаалал бага.
- Програмд нэмэлт өөрчлөлт оруулах үйл явцыг хялбарчлах.
Хөгжлийн хугацааг багасгах
Арга зүй болсон цаг үе рүүгээ буцъя waterfall Энэ нь боловсруулах үйл явцын стандарт байсан бөгөөд програмыг боловсруулах эсвэл шинэчлэхэд зургаан сараас хоёр жил хүртэлх хугацаа нийтлэг байсан. Ерөнхийдөө инженерүүд эхлээд бүтээгдэхүүний шаардлага (PRD), системийн лавлагааны баримт бичиг (SRD), архитектурын зураг төсөл гэх мэт холбогдох баримт бичгүүдийг уншиж, эдгээр бүх зүйлийг нэг танин мэдэхүйн загвар болгон нэгтгэж, тэдгээрийн дагуу кодлож эхэлдэг. Шаардлага, улмаар архитектур өөрчлөгдөхийн хэрээр танин мэдэхүйн загварын шинэчлэлийн талаар бүхэл бүтэн багийг мэдээлэхийн тулд нухацтай хүчин чармайлт гаргах шаардлагатай болсон. Ийм хандлага нь хамгийн муугаар бодоход ажлыг зүгээр л саажилттай болгож болзошгүй юм.
Програм боловсруулах үйл явцад гарсан хамгийн том өөрчлөлт нь agile аргачлалыг нэвтрүүлсэн явдал байв. Арга зүйн үндсэн шинж чанаруудын нэг agile давтагдах хөгжил юм. Энэ нь эргээд инженерүүдийн танин мэдэхүйн ачааллыг бууруулахад хүргэдэг. Хөгжлийн багаас програмыг нэг урт мөчлөгт хэрэгжүүлэхийг шаардахын оронд agile Энэ арга нь танд хурдан турших, ашиглах боломжтой бага хэмжээний код дээр анхаарлаа төвлөрүүлэхийн зэрэгцээ санал хүсэлтийг хүлээн авах боломжийг олгодог. Аппликэйшний танин мэдэхүйн ачаалал зургаан сарын хугацаанаас хоёр жилийн хугацаа руу шилжсэн бөгөөд том програмын талаар илүү бүдэг бадаг ойлгоход чиглэсэн хоёр долоо хоногийн нэмэлт эсвэл функцийг өөрчлөхөд асар их хэмжээний үзүүлэлтүүд багтсан.
Томоохон программаас анхаарлаа хоёр долоо хоногийн спринтээр дуусгах боломжтой жижиг функцууд руу шилжүүлж, дараагийн спринтээс нэгээс илүүгүй онцлогийг анхаарч үзэх нь чухал өөрчлөлт юм. Энэ нь бидэнд хөгжлийн бүтээмжийг нэмэгдүүлэхийн зэрэгцээ байнга хэлбэлздэг танин мэдэхүйн ачааллыг бууруулах боломжийг олгосон.
Арга зүйд agile Эцсийн хэрэглээ нь анхны концепцийн бага зэрэг өөрчлөгдсөн хувилбар байх тул хөгжлийн эцсийн цэг нь хоёрдмол утгатай байх ёстой. Зөвхөн тодорхой спринт бүрийн үр дүн нь тодорхой бөгөөд нарийн байж болно.
Жижиг кодын баазууд
Танин мэдэхүйн ачааллыг бууруулах дараагийн алхам бол кодын баазыг багасгах явдал юм. Дүрмээр бол орчин үеийн програмууд нь асар их байдаг - хүчирхэг, байгууллагын программ нь олон мянган файл, хэдэн зуун мянган мөр кодоос бүрдэх боломжтой. Файлуудыг хэрхэн зохион байгуулж байгаагаас хамааран код болон файлуудын хоорондын холбоос, хамаарал нь тодорхой эсвэл эсрэгээр байж болно. Ашигласан номын сангууд болон дибаг хийх хэрэгслүүд нь номын сан/багц/модуль болон захиалгат кодыг хэр сайн ялгаж байгаагаас шалтгаалан дибаг хийх кодын гүйцэтгэл нь өөрөө асуудалтай байж болно.
Аппликешны кодын ажиллах сэтгэлгээний загварыг бий болгоход асар их цаг хугацаа шаардагдах бөгөөд дахин нэг удаа хөгжүүлэгчид танин мэдэхүйн томоохон ачааг үүрнэ. Энэ нь ялангуяа их хэмжээний кодтой, функциональ бүрэлдэхүүн хэсгүүдийн хоорондын харилцан үйлчлэл тодорхой тодорхойлогдоогүй, функциональ хил хязгаарыг үл хүндэтгэдэг тул анхаарал татахуйц объектуудын тусгаарлалт нь ихэвчлэн бүдгэрч байдаг цул кодын суурийн хувьд энэ нь ялангуяа үнэн юм.
Инженерүүдийн танин мэдэхүйн ачааллыг бууруулах үр дүнтэй аргуудын нэг бол микро үйлчилгээний архитектур руу шилжих явдал юм. Микро үйлчилгээний арга барилд үйлчилгээ бүр нэг багц функц дээр төвлөрдөг; үйлчилгээний утга нь ихэвчлэн тодорхойлогддог бөгөөд ойлгомжтой байдаг. Үйлчилгээний хил хязгаар нь бас тодорхой байдаг - үйлчилгээтэй харилцах нь API-ээр дамждаг тул нэг үйлчилгээгээр үүсгэсэн өгөгдлийг нөгөө рүү хялбархан дамжуулах боломжтой гэдгийг санаарай.
Бусад үйлчилгээнүүдтэй харилцах нь ихэвчлэн REST ашиглах гэх мэт энгийн бөгөөд цэвэр API дуудлагуудыг ашигладаг цөөн хэдэн хэрэглэгчийн үйлчилгээ болон цөөн тооны үйлчилгээ үзүүлэгчийн үйлчилгээнүүдээр хязгаарлагддаг. Энэ нь инженерийн танин мэдэхүйн ачаалал эрс багассан гэсэн үг юм. Хамгийн том сорилт бол үйлчилгээний харилцан үйлчлэлийн загвар болон гүйлгээ гэх мэт зүйлс олон үйлчилгээнд хэрхэн явагддагийг ойлгох явдал хэвээр байна. Үүний үр дүнд бичил үйлчилгээг ашиглах нь кодын хэмжээг багасгаж, үйлчилгээний хил хязгаарыг тодорхой тодорхойлж, хэрэглэгчид болон үйлчилгээ үзүүлэгчдийн хоорондын харилцааны талаархи ойлголтыг өгөх замаар танин мэдэхүйн ачааллыг бууруулдаг.
Өсөн нэмэгдэж буй жижиг өөрчлөлтүүд
Зарчмын сүүлчийн элемент жижиг байдал өөрчлөлтийн менежмент юм. Хөгжүүлэгчдийн хувьд кодын баазыг (өөрсдийнх нь, хуучин код ч байж магадгүй) хараад "Энэ бол новш юм, бид бүгдийг дахин бичих хэрэгтэй" гэж хэлэх нь онцгой сорилт юм. Заримдаа энэ нь зөв шийдвэр, заримдаа тийм биш юм. Энэ нь дэлхийн загварын өөрчлөлтийн ачааллыг хөгжүүлэлтийн багт үүрдэг бөгөөд энэ нь эргээд танин мэдэхүйн асар их ачаалалд хүргэдэг. Инженерүүд спринтийн үеэр хийж болох өөрчлөлтүүддээ анхаарлаа төвлөрүүлж, шаардлагатай функцийг аажмаар боловч цаг тухайд нь гаргах нь дээр. Эцсийн бүтээгдэхүүн нь урьдчилан төлөвлөсөн бүтээгдэхүүнтэй төстэй байх ёстой, гэхдээ үйлчлүүлэгчийн хэрэгцээнд нийцүүлэн зарим өөрчлөлт, туршилттай байх ёстой.
Кодын том хэсгийг дахин бичих үед бусад системийн хамаарал гарч ирдэг тул өөрчлөлтийг хурдан хүргэх боломжгүй байдаг. Өөрчлөлтийн урсгалыг хянахын тулд та функцийг нуух аргыг ашиглаж болно. Зарчмын хувьд энэ нь уг функцийг үйлдвэрлэж байна гэсэн үг боловч орчны хувьсагчийн тохиргоо (env-var) эсвэл бусад тохиргооны механизмыг ашиглах боломжгүй байна. Хэрэв код нь чанарын хяналтын бүх процессыг давсан бол далд төлөвт үйлдвэрлэлд орж болзошгүй. Гэсэн хэдий ч, энэ стратеги нь тухайн функцийг эцэст нь идэвхжүүлсэн тохиолдолд л ажиллана. Үгүй бол энэ нь зөвхөн кодыг эмх замбараагүй болгож, бүтээмжтэй ажиллахын тулд хөгжүүлэгчийн шийдвэрлэх шаардлагатай танин мэдэхүйн ачааллыг нэмэх болно. Өөрчлөлтийн удирдлага болон нэмэлт өөрчлөлтүүд нь хөгжүүлэгчдийн танин мэдэхүйн ачааллыг боломжийн түвшинд байлгахад тусалдаг.
Инженерүүд нэмэлт функцийг хялбархан нэвтрүүлсэн ч олон бэрхшээлийг даван туулах шаардлагатай болдог. Удирдлагын зүгээс багийн үндсэн чиг үүрэгт анхаарлаа төвлөрүүлэхийн тулд шаардлагагүй ачааллыг багасгах нь ухаалаг хэрэг болно. Хөгжлийн багт туслахын тулд та гурван зүйлийг хийж болно:
- Арга зүйг ашиглах
agileбагийн үндсэн шинж чанарууд дээр анхаарлаа төвлөрүүлэх цаг хугацааг хязгаарлах. - Програмаа олон микро үйлчилгээ болгон хэрэгжүүлээрэй. Энэ нь хэрэгжүүлэх боломжуудын тоог хязгаарлаж, танин мэдэхүйн ачааллыг ажил дээрээ байлгах хил хязгаарыг бэхжүүлэх болно.
- Том, төвөгтэй биш харин нэмэлт өөрчлөлтийг илүүд үз, кодын жижиг хэсгүүдийг өөрчил. Нэмэгдсэн даруйд харагдахгүй байсан ч өөрчлөлтүүдийг хэрэгжүүлэхийн тулд онцлог нуухыг ашиглана уу.
Хэрэв та ажилдаа жижиг байх зарчмыг хэрэгжүүлбэл танай хамт олон илүү аз жаргалтай байх болно, шаардлагатай боломжуудыг хэрэгжүүлэхэд илүү анхаарч, чанарын өөрчлөлтийг илүү хурдан гаргах болно. Гэхдээ энэ нь ажил нь илүү төвөгтэй болж чадахгүй гэсэн үг биш юм, заримдаа эсрэгээр шинэ функцийг нэвтрүүлэх нь хэд хэдэн үйлчилгээг өөрчлөхийг шаарддаг бөгөөд энэ үйл явц нь цул архитектуртай ижил төстэй байдлаас илүү хэцүү байж болно. Ямар ч тохиолдолд жижиг хандлагын ашиг тус нь үнэ цэнэтэй юм.
Эхний хэсгийн төгсгөл.
Удахгүй бид орчуулгын хоёрдугаар хэсгийг нийтлэх бөгөөд одоо та бүхний сэтгэгдлийг хүлээж, та бүхнийг урьж байна. , өнөөдөр 20.00 цагт болох юм.
Эх сурвалж: www.habr.com