Курсын оюутнуудад зориулан бэлтгэсэн нийтлэлийн орчуулга OTUS боловсролын төсөлд.
Та моно репозиторийг сонгох хэрэгтэй, учир нь энэ нь танай багт сурталчлах зан үйл нь ил тод байдал, хамтын хариуцлага, ялангуяа багууд өсөхөд хүргэдэг. Аль ч тохиолдолд та багаж хэрэгсэлд хөрөнгө оруулалт хийх хэрэгтэй болно, гэхдээ анхдагч үйлдэл нь таны тушаалууд дээр таны хүссэн үйлдэл байвал илүү дээр юм.
Бид яагаад энэ тухай яриад байгаа юм бэ?
Мэтт Клейн уг нийтлэлийг бичсэн (орчуулагчийн тэмдэглэл: Хабре дээрх орчуулга ). Би Мэттэд дуртай, би түүнийг маш ухаалаг гэж бодож байна, та түүний үзэл бодлыг унших хэрэгтэй. Тэрээр анх санал асуулгыг Twitter дээрээ нийтэлсэн:
Орчуулга:
Энэ шинийн нэгний өдөр би монорепозиторууд ямар хөгийн юм бэ гэж маргах гэж байна. 2019 он нам гүмхэн эхэллээ. Үүнтэй холбогдуулан би танд санал асуулга санал болгож байна. Том фанатууд хэн бэ? Дэмжигчид:
- Монорепо
- Rust
- Буруу санал асуулга / хоёулаа
Миний хариулт бол "Би тэр хоёрын аль аль нь юм." Зэв нь мансууруулах бодис болох талаар ярихын оронд монорепозиторын талаар яагаад буруу гэж бодож байгааг харцгаая. Өөрийнхөө тухай бага зэрэг. Би тогооч програм хангамжийн ерөнхий захирал. Бид 100 орчим инженертэй, 11-12 жилийн өмнөх кодын суурьтай, үндсэн 4 бүтээгдэхүүнтэй. Энэ кодын зарим нь polyrepository-д (миний эхлэлийн байрлал), зарим нь монорепозиторт (миний одоогийн байрлал) байна.
Эхлэхээсээ өмнө: миний энд хийсэн аргумент бүр хоёр төрлийн хадгалах газарт хамаарна. Миний бодлоор нэг төрлийн хадгалах газрыг нөгөөгөөсөө сонгох техникийн шалтгаан байхгүй. Та ямар ч аргыг үр дүнтэй болгож чадна. Би энэ тухай ярихдаа баяртай байна, гэхдээ нэг нь нөгөөгөөсөө давуу байдгийн зохиомол техникийн шалтгааныг сонирхдоггүй.
Мэттийн хэлсэн үгийн эхний хэсэгтэй би санал нэг байна:
Учир нь масштабаар монорепозитор нь polyrepository-ийн шийддэг бүх асуудлыг шийдэх боловч нэгэн зэрэг таныг кодоо нягт холбохыг албадаж, хувилбарын хяналтын системийн өргөтгөх чадварыг нэмэгдүүлэхийн тулд гайхалтай хүчин чармайлт шаарддаг.
Та монорепозитор эсвэл полирепозитор сонгосон эсэхээс үл хамааран ижил асуудлыг шийдэх хэрэгтэй болно. Та хэрхэн хувилбаруудыг гаргадаг вэ? Та шинэчлэлтэд ямар хандлагатай байдаг вэ? Хоцрогдсон нийцтэй байдал? Төслийн хоорондын хамаарал? Ямар архитектурын хэв маягийг хүлээн зөвшөөрдөг вэ? Та барих, турших дэд бүтцээ хэрхэн удирддаг вэ? Жагсаалт эцэс төгсгөлгүй юм. Мөн та өсч томрох тусам бүгдийг нь шийдэх болно. Үнэгүй бяслаг байхгүй.
Мэттийн аргумент нь миний хүндэтгэдэг олон инженерүүдийн (мөн менежерүүдийн) хуваалцсан үзэл бодолтой төстэй гэж би бодож байна. Энэ нь бүрэлдэхүүн хэсэг дээр ажиллаж буй инженер эсвэл бүрэлдэхүүн хэсэг дээр ажиллаж буй багийн үүднээс тохиолддог. Та дараах зүйлсийг сонсдог:
- Кодын сан нь том хэмжээтэй - Надад энэ бүх хог хэрэггүй.
- Надад хэрэггүй энэ бүх хог хаягдлыг шалгах ёстой учраас шалгахад илүү хэцүү байдаг.
- Гадны хамааралтай ажиллах нь илүү хэцүү байдаг.
- Надад өөрийн виртуал хувилбарын хяналтын систем хэрэгтэй байна.
Мэдээжийн хэрэг, эдгээр бүх оноо үндэслэлтэй. Энэ нь хоёуланд нь тохиолддог - полирепозиторт би бүтээхэд хэрэгтэй зүйлээс гадна өөрийн гэсэн хог хаягдалтай байдаг ... Надад өөр хог хэрэгтэй байж магадгүй юм. Тиймээс би "зүгээр л" төслийг бүхэлд нь шалгах хэрэгслүүдийг бий болгодог. Эсвэл би дэд модулиудтай хуурамч монорепозитор үүсгэдэг. Бид өдөржингөө үүн дээр алхаж болно. Гэхдээ Мэттийн аргумент үндсэн шалтгааныг орхигдуулсан гэж би бодож байна, би үүнийг монорепозиторыг дэмжсэн.
Энэ нь харилцаа холбоог өдөөж, асуудлыг харуулдаг
Бид агуулахуудыг салгахдаа де факто зохицуулалт, ил тод байдлын асуудал үүсгэдэг. Энэ нь бидний багуудын тухай бодох арга барилтай (ялангуяа хувь хүний гишүүд тэдний тухай боддог) тохирч байна: бид тодорхой бүрэлдэхүүн хэсгийг хариуцдаг. Бид харьцангуй тусгаарлагдмал байдлаар ажилладаг. Хил хязгаарыг миний баг болон бидний ажиллаж байгаа бүрэлдэхүүн хэсгүүдэд тогтоосон.
Архитектур илүү төвөгтэй болж байгаа тул нэг баг үүнийг ганцаараа удирдах боломжгүй болсон. Маш цөөхөн инженерүүд бүхэл бүтэн системийг толгойдоо суулгадаг. Та B, C, D багууд ашигладаг хуваалцсан А бүрэлдэхүүн хэсгийг удирдаж байна гэж бодъё. А баг нь дахин засварлаж, API-г сайжруулж, дотоод хэрэгжилтийг өөрчилж байна. Үүний үр дүнд өөрчлөлтүүд нь буцаж нийцэхгүй байна. Та ямар зөвлөгөө өгөх вэ?
- Хуучин API ашигладаг бүх газрыг олоорой.
- Шинэ API ашиглах боломжгүй газрууд бий юу?
- Та бусад бүрэлдэхүүн хэсгүүдийг эвдэхгүй байхын тулд засч, шалгаж чадах уу?
- Эдгээр багууд яг одоо таны өөрчлөлтийг шалгаж чадах уу?
Эдгээр асуултууд нь хадгалах сангийн төрлөөс хамааралгүй гэдгийг анхаарна уу. Та B, C, D багийг олох хэрэгтэй. Та тэдэнтэй ярилцаж, цагийг олж, тэдний тэргүүлэх чиглэлийг ойлгох хэрэгтэй. Наад зах нь бид чамайг тэгнэ гэж найдаж байна.
Хэн ч үүнийг хийхийг үнэхээр хүсэхгүй байна. Энэ нь хараал идсэн API-г засахаас хамаагүй бага хөгжилтэй юм. Энэ бүхэн хүнлэг, замбараагүй юм. Полирепозиторид та зүгээр л өөрчлөлт хийж, тухайн бүрэлдэхүүн хэсэг дээр ажиллаж байгаа хүмүүст (магадгүй B, C эсвэл D биш) хянуулахаар өгөөд цааш үргэлжлүүлж болно. B, C, D багууд одоо байгаа хувилбараараа үлдэх боломжтой. Тэд таны суут чадварыг ухаарах үед шинэчлэгдэх болно!
Монорепозиторийн хувьд хариуцлагыг анхдагч байдлаар шилжүүлдэг. А баг бүрэлдэхүүнээ сольж, болгоомжтой байхгүй бол тэр даруй B, C, D-г эвддэг. Энэ нь Б, С, D нар А-гийн үүдэнд гарч ирэхэд А баг яагаад чуулганыг эвдсэнийг гайхаж байна. Энэ нь А-д миний дээрх жагсаалтыг алгасаж болохгүй гэдгийг заадаг. Тэд юу хийх гэж байгаагаа ярих ёстой. B, C, D хөдөлж чадах уу? Хэрэв B ба C боломжтой бол D нь хуучин алгоритмын үйл ажиллагааны гаж нөлөөтэй нягт холбоотой байсан бол яах вэ?
Дараа нь бид энэ байдлаас хэрхэн гарах талаар ярих ёстой.
- Олон дотоод API-г дэмжих ба D-г ашиглахаа болих хүртэл хуучин алгоритмыг хуучирсан гэж тэмдэглэнэ.
- Хуучин интерфэйстэй, шинэ интерфэйстэй олон хувилбарыг дэмжинэ.
- B, C, D нэгэн зэрэг хүлээн авах хүртэл А-ийн өөрчлөлтийг гаргахыг хойшлуул.
Бид 1, хэд хэдэн API сонгосон гэж бодъё. Энэ тохиолдолд бидэнд хоёр ширхэг код байна. Хуучин ба шинэ. Зарим тохиолдолд нэлээд тохиромжтой. Бид хуучин кодыг дахин шалгаж, хуучирсан гэж тэмдэглэж, D багтай устгах хуваарийг тохиролцдог. Поли болон моно хадгалах газруудад үндсэндээ адилхан.
Олон хувилбар гаргахын тулд бидэнд салбар хэрэгтэй. Одоо бид хоёр бүрэлдэхүүн хэсэгтэй - A1 ба A2. В, С багууд A2, D багууд A1-г ашигладаг. D-г урагшлуулахаас өмнө аюулгүй байдлын шинэчлэлт болон бусад алдааг засах шаардлагатай байж болох тул бид бүрэлдэхүүн бүрийг гаргахад бэлэн байх шаардлагатай. Polyrepository-д бид үүнийг сайн мэдэрдэг урт насалдаг салбар дотор нууж болно. Монорепозиторид бид кодыг шинэ модульд үүсгэхийг албаддаг. D баг "хуучин" бүрэлдэхүүнд өөрчлөлт оруулах шаардлагатай хэвээр байх болно. Бидний төлж буй зардлыг хүн бүр эндээс харж болно - одоо бид хоёр дахин их кодтой болсон бөгөөд A1 болон A2-д хамаарах аливаа алдааны засварууд хоёуланд нь хамаарах ёстой. Полирепозитор дахь салбарлах аргыг ашигласнаар энэ нь интоорын пикийн ард нуугддаг. Давхардал байхгүй учраас өртөг багатай гэж үзэж байгаа. Практик талаас нь харахад зардал нь адилхан: та тэдгээрийн аль нэгийг нь устгах хүртэл хоёр үндсэндээ ижил кодын баазыг бүтээж, суллаж, хадгалах болно. Үүний ялгаа нь монорепозитортой бол энэ өвдөлт шууд бөгөөд харагдахуйц байдаг. Энэ нь бүр ч муу, бас сайн хэрэг.
Эцэст нь бид гурав дахь цэг дээр ирлээ. Суллах саатал. А-ын хийсэн өөрчлөлт нь А багийн амьдралыг сайжруулах боломжтой. Чухал, гэхдээ яаралтай биш. Бид зүгээр л хойшлуулж болох уу? Полирепозиторид бид үүнийг түлхэж олдворыг бэхлэнэ. Мэдээж бид үүнийг D багт хэлж байна. Та гүйцэх хүртлээ хуучин хувилбар дээрээ байгаарай! Энэ нь таныг хулчгар дүрд тоглоход хүргэдэг. D баг улам хуучирсан хувилбарыг ашиглаж байгааг үл тоомсорлон А баг бүрэлдэхүүн хэсэг дээрээ үргэлжлүүлэн ажилласаар байна (энэ бол D багийн асуудал, тэд тэнэг). Үүний зэрэгцээ, D баг А багийн кодын тогтвортой байдалд хайхрамжгүй ханддаг талаар муу ярьдаг. Сарууд өнгөрдөг. Эцэст нь, D баг шинэчлэх боломжийг судлахаар шийдсэн боловч А-д зөвхөн илүү их өөрчлөлтүүд байна. А баг хэзээ, хэрхэн D эвдсэнээ бараг санахгүй байна. Шинэчлэлт нь илүү өвдөлттэй бөгөөд удаан үргэлжлэх болно. Энэ нь үүнийг тэргүүлэх ач холбогдол бүхий стекээс доош илгээдэг. А-д аюулгүй байдлын асуудал тулгардаг тэр өдрийг хүртэл биднийг салбар болгохыг албаддаг. А баг цаг хугацааг ухрааж, D тогтвортой байсан цэгийг олж, тэнд байгаа асуудлыг засч, түүнийг суллахад бэлэн болгох ёстой. Энэ бол хүмүүсийн хийдэг бодит сонголт бөгөөд хамгийн муу нь. Бид бие биенээ үл тоомсорлож чадвал энэ нь A болон D багуудын аль алинд нь ашигтай юм шиг санагддаг.
Монорепозиторийн хувьд гурав дахь нь үнэхээр сонголт биш юм. Та нөхцөл байдлыг хоёр аргын аль нэгээр нь шийдвэрлэхээс өөр аргагүй болно. Та хоёр гаргах салбартай байх зардлыг харах хэрэгтэй. Хоцрогдсон нийцтэй байдлыг эвдэх шинэчлэлтүүдээс өөрийгөө хамгаалж сур. Гэхдээ хамгийн чухал нь: Та хэцүү яриа өрнүүлэхээс зайлсхийж чадахгүй.
Миний туршлагаас харахад багууд томрох үед бүхэл бүтэн системийг санаж байх боломжгүй болсон бөгөөд энэ нь хамгийн чухал хэсэг юм. Та систем дэх зөрчилдөөний харагдах байдлыг сайжруулах ёстой. Багуудыг бүрэлдэхүүн хэсгүүдээс нь холдуулж, бусад баг болон хэрэглэгчдийн ажлыг хардаг болгохын тулд та идэвхтэй ажиллах ёстой.
Тийм ээ, та polyrepository-ийн асуудлыг шийдэхийг оролддог хэрэгслүүдийг үүсгэж болно. Гэхдээ томоохон аж ахуйн нэгжүүдэд тасралтгүй хүргэлт, автоматжуулалтыг зааж байсан миний туршлага надад үүнийг хэлж байна: нэмэлт хэрэгсэл ашиглахгүйгээр анхдагч зан байдал нь таны харахыг хүлээж буй зан төлөв юм. Полирепозиторын анхдагч үйлдэл бол тусгаарлалт бөгөөд энэ бол бүх зүйл юм. Монорепозиторын үндсэн зан үйл бол хамтын хариуцлага, ил тод байдал юм. Аль ч тохиолдолд би барзгар ирмэгийг тэгшлэх хэрэгсэл бүтээх болно. Удирдагчийн хувьд би monorepository сонгох бүрдээ миний хүсч буй соёлыг бэхжүүлэх хэрэгсэл хэрэгтэй бөгөөд соёл нь өчүүхэн шийдвэр, багийн өдөр тутмын ажлаас үүсдэг.
Зөвхөн бүртгэлтэй хэрэглэгчид санал асуулгад оролцох боломжтой. , гуйя.
Хамгийн том фанатууд хэн бэ? Дэмжигчид:
-
Монорепо
-
Rust
-
Буруу санал асуулга / хоёулаа
33 хэрэглэгч санал өгсөн. 13 хэрэглэгч түдгэлзсэн.
Эх сурвалж: www.habr.com