ການ​ແປ​ບົດ​ຄວາມ​ທີ່​ໄດ້​ກະ​ກຽມ​ສໍາ​ລັບ​ນັກ​ຮຽນ​ຫຼັກ​ສູດ​ "ການປະຕິບັດແລະເຄື່ອງມື DevOps" ໃນໂຄງການການສຶກສາ OTUS.

ທ່ານຄວນເລືອກ monorepository ເພາະວ່າພຶດຕິກໍາທີ່ມັນສົ່ງເສີມໃນທີມງານຂອງທ່ານແມ່ນຄວາມໂປ່ງໃສແລະຄວາມຮັບຜິດຊອບຮ່ວມກັນ, ໂດຍສະເພາະໃນເວລາທີ່ທີມງານເຕີບໂຕ. ໃນກໍລະນີໃດກໍ່ຕາມ, ທ່ານຈະຕ້ອງລົງທຶນໃນເຄື່ອງມື, ແຕ່ມັນກໍ່ດີກວ່າຖ້າພຶດຕິກໍາເລີ່ມຕົ້ນແມ່ນພຶດຕິກໍາທີ່ທ່ານຕ້ອງການໃນຄໍາສັ່ງຂອງທ່ານ.

ເປັນຫຍັງພວກເຮົາເວົ້າເລື່ອງນີ້?

Matt Klein ຂຽນບົດຄວາມ "Monorepos: ກະລຸນາຢ່າ!"  (ຫມາຍເຫດຂອງຜູ້ແປພາສາ: ການແປພາສາໃນ Habré "Monorepositories: ກະລຸນາຢ່າ"). ຂ້ອຍມັກ Matt, ຂ້ອຍຄິດວ່າລາວສະຫລາດຫຼາຍແລະເຈົ້າຄວນອ່ານທັດສະນະຂອງລາວ. ໃນເບື້ອງຕົ້ນລາວໄດ້ລົງຄະແນນສຽງໃນ Twitter:

ການແປພາສາ:
ມື້ປີໃຫມ່ນີ້, ຂ້າພະເຈົ້າຈະໂຕ້ຖຽງກ່ຽວກັບວິທີ monorepositories ridiculous ແມ່ນ. ປີ 2019 ເລີ່ມຕົ້ນຢ່າງງຽບໆ. ໃນຈິດໃຈນີ້, ຂ້າພະເຈົ້າສະເຫນີໃຫ້ທ່ານສໍາຫຼວດ. ໃຜເປັນແຟນໃຫຍ່? ຜູ້ສະຫນັບສະຫນູນ:
- Monorepo
- rust
- ແບບສຳຫຼວດບໍ່ຖືກຕ້ອງ / ທັງສອງ

ຄໍາຕອບຂອງຂ້ອຍແມ່ນ, "ຂ້ອຍແມ່ນທັງສອງຄົນເຫຼົ່ານັ້ນ." ແທນທີ່ຈະເວົ້າກ່ຽວກັບວິທີການ Rust ເປັນຢາເສບຕິດ, ໃຫ້ເບິ່ງວ່າເປັນຫຍັງຂ້າພະເຈົ້າຄິດວ່າລາວຜິດກ່ຽວກັບ monorepositories. ເລັກນ້ອຍກ່ຽວກັບຕົວທ່ານເອງ. ຂ້ອຍເປັນ CTO ຂອງ Chef Software. ພວກເຮົາມີວິສະວະກອນປະມານ 100 ຄົນ, ພື້ນຖານລະຫັດກັບຄືນໄປບ່ອນປະມານ 11-12 ປີ, ແລະ 4 ຜະລິດຕະພັນຕົ້ນຕໍ. ບາງລະຫັດນີ້ຢູ່ໃນ polyrepository (ຕໍາແຫນ່ງເລີ່ມຕົ້ນຂອງຂ້ອຍ), ບາງອັນແມ່ນຢູ່ໃນ monorepository (ຕໍາແຫນ່ງປະຈຸບັນຂອງຂ້ອຍ).

ກ່ອນທີ່ຂ້ອຍຈະເລີ່ມຕົ້ນ: ທຸກໆການໂຕ້ຖຽງທີ່ຂ້ອຍເຮັດຢູ່ທີ່ນີ້ຈະໃຊ້ກັບທັງສອງປະເພດຂອງ repositories. ໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ, ບໍ່ມີເຫດຜົນດ້ານວິຊາການວ່າເປັນຫຍັງທ່ານຄວນເລືອກປະເພດຂອງ repository ໃນໄລຍະອື່ນ. ທ່ານສາມາດເຮັດໃຫ້ວິທີການເຮັດວຽກໃດໆ. ຂ້ອຍຍິນດີທີ່ຈະເວົ້າກ່ຽວກັບມັນ, ແຕ່ຂ້ອຍບໍ່ສົນໃຈກັບເຫດຜົນດ້ານວິຊາການປອມວ່າເປັນຫຍັງຫນຶ່ງແມ່ນດີກວ່າຄົນອື່ນ.

ຂ້າພະເຈົ້າຕົກລົງເຫັນດີກັບສ່ວນທໍາອິດຂອງຈຸດຂອງ Matt:

ເນື່ອງຈາກວ່າໃນຂະຫນາດ, monorepository ຈະແກ້ໄຂບັນຫາດຽວກັນທັງຫມົດທີ່ polyrepository ແກ້ໄຂ, ແຕ່ໃນເວລາດຽວກັນບັງຄັບໃຫ້ທ່ານສົມທົບລະຫັດຂອງທ່ານຢ່າງແຫນ້ນຫນາແລະຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມຢ່າງບໍ່ຫນ້າເຊື່ອເພື່ອເພີ່ມຂະຫນາດຂອງລະບົບການຄວບຄຸມເວີຊັນຂອງທ່ານ.

ທ່ານຈະຕ້ອງແກ້ໄຂບັນຫາດຽວກັນບໍ່ວ່າທ່ານຈະເລືອກ monorepository ຫຼື polyrepository. ເຈົ້າປ່ອຍການປ່ອຍອອກມາແນວໃດ? ວິທີການປັບປຸງຂອງທ່ານແມ່ນຫຍັງ? ຄວາມເຂົ້າກັນໄດ້ໃນດ້ານຫຼັງ? ການຂຶ້ນກັບໂຄງການຂ້າມ? ຮູບແບບສະຖາປັດຕະຍະກໍາໃດທີ່ຍອມຮັບ? ທ່ານຈັດການໂຄງສ້າງພື້ນຖານການກໍ່ສ້າງແລະການທົດສອບແນວໃດ? ບັນຊີລາຍຊື່ແມ່ນບໍ່ມີທີ່ສິ້ນສຸດ. ແລະເຈົ້າຈະແກ້ໄຂພວກມັນທັງຫມົດເມື່ອທ່ານເຕີບໂຕ. ບໍ່ມີເນີຍແຂງຟຣີ.

ຂ້າພະເຈົ້າຄິດວ່າການໂຕ້ຖຽງຂອງ Matt ແມ່ນຄ້າຍຄືກັນກັບທັດສະນະທີ່ແບ່ງປັນໂດຍວິສະວະກອນຫຼາຍຄົນ (ແລະຜູ້ຈັດການ) ທີ່ຂ້ອຍເຄົາລົບ. ນີ້ເກີດຂື້ນຈາກທັດສະນະຂອງວິສະວະກອນທີ່ເຮັດວຽກກ່ຽວກັບອົງປະກອບຫຼືທີມງານທີ່ເຮັດວຽກກ່ຽວກັບອົງປະກອບ. ເຈົ້າໄດ້ຍິນສິ່ງຕ່າງໆເຊັ່ນ:

• codebase ແມ່ນ bulky - ຂ້າພະເຈົ້າບໍ່ຕ້ອງການຂີ້ເຫຍື້ອທັງຫມົດນີ້.
• ມັນຍາກກວ່າທີ່ຈະທົດສອບ ເພາະວ່າຂ້ອຍຕ້ອງທົດສອບຂີ້ເຫຍື້ອທັງໝົດທີ່ຂ້ອຍບໍ່ຕ້ອງການ.
• ມັນເປັນການຍາກກວ່າທີ່ຈະເຮັດວຽກກັບການຂຶ້ນກັບພາຍນອກ.
• ຂ້ອຍຕ້ອງການລະບົບການຄວບຄຸມເວີຊັນ virtual ຂອງຂ້ອຍເອງ.

ແນ່ນອນ, ຈຸດທັງຫມົດເຫຼົ່ານີ້ແມ່ນສົມເຫດສົມຜົນ. ນີ້ເກີດຂຶ້ນໃນທັງສອງກໍລະນີ - ໃນ polyrepository ຂ້າພະເຈົ້າມີ junk ຂອງຕົນເອງ, ນອກເຫນືອໄປຈາກຫນຶ່ງທີ່ຈໍາເປັນສໍາລັບການກໍ່ສ້າງ ... ຂ້າພະເຈົ້າຍັງອາດຈະຕ້ອງການ junk ອື່ນໆ. ສະນັ້ນຂ້າພະເຈົ້າ "ພຽງແຕ່" ສ້າງເຄື່ອງມືທີ່ກວດສອບໂຄງການທັງຫມົດ. ຫຼືຂ້ອຍສ້າງ monorepository ປອມທີ່ມີ submodules. ພວກເຮົາສາມາດຍ່າງໄດ້ຕະຫຼອດມື້. ແຕ່ຂ້າພະເຈົ້າຄິດວ່າການໂຕ້ຖຽງຂອງ Matt ຂາດເຫດຜົນຕົ້ນຕໍ, ເຊິ່ງຂ້າພະເຈົ້າໄດ້ swung ຂ້ອນຂ້າງຫຼາຍໃນເງື່ອນໄຂຂອງ monorepository:

ມັນ provokes ການສື່ສານແລະສະແດງໃຫ້ເຫັນບັນຫາ

ໃນເວລາທີ່ພວກເຮົາແຍກ repositories, ພວກເຮົາສ້າງບັນຫາ de facto ຂອງການປະສານງານແລະຄວາມໂປ່ງໃສ. ນີ້ສອດຄ່ອງກັບວິທີທີ່ພວກເຮົາຄິດກ່ຽວກັບທີມ (ໂດຍສະເພາະວິທີທີ່ສະມາຊິກແຕ່ລະຄົນຄິດກ່ຽວກັບພວກເຂົາ): ພວກເຮົາຮັບຜິດຊອບຕໍ່ອົງປະກອບທີ່ແນ່ນອນ. ພວກເຮົາເຮັດວຽກຢູ່ໃນຄວາມໂດດດ່ຽວພີ່ນ້ອງ. ຂອບເຂດໄດ້ຖືກແກ້ໄຂຢູ່ໃນທີມງານຂອງຂ້ອຍແລະອົງປະກອບທີ່ພວກເຮົາກໍາລັງເຮັດວຽກ.

ເມື່ອສະຖາປັດຕະຍະກໍາສັບສົນຫຼາຍ, ທີມງານຫນຶ່ງບໍ່ສາມາດຈັດການມັນຢ່າງດຽວໄດ້. ວິສະວະກອນຈໍານວນຫນ້ອຍຫຼາຍມີລະບົບທັງຫມົດຢູ່ໃນຫົວຂອງພວກເຂົາ. ສົມມຸດວ່າເຈົ້າຈັດການອົງປະກອບ A ທີ່ໃຊ້ຮ່ວມກັນໂດຍທີມ B, C, ແລະ D. ທີມ A ກໍາລັງປັບປຸງ, ປັບປຸງ API, ແລະຍັງມີການປ່ຽນແປງການປະຕິບັດພາຍໃນ. ດັ່ງນັ້ນ, ການປ່ຽນແປງບໍ່ເຂົ້າກັນໄດ້ກັບຫຼັງ. ເຈົ້າມີຄຳແນະນຳອັນໃດແດ່?

• ຊອກຫາສະຖານທີ່ທັງຫມົດທີ່ API ເກົ່າຖືກນໍາໃຊ້.
• ມີບ່ອນໃດທີ່ບໍ່ສາມາດໃຊ້ API ໃໝ່ໄດ້ບໍ?
• ທ່ານສາມາດແກ້ໄຂແລະທົດສອບອົງປະກອບອື່ນໆເພື່ອໃຫ້ແນ່ໃຈວ່າພວກມັນບໍ່ແຕກບໍ?
• ທີມງານເຫຼົ່ານີ້ສາມາດທົດສອບການປ່ຽນແປງຂອງເຈົ້າໄດ້ໃນຕອນນີ້ບໍ?

ກະລຸນາຮັບຊາບວ່າຄຳຖາມເຫຼົ່ານີ້ແມ່ນບໍ່ຂຶ້ນກັບປະເພດບ່ອນເກັບມ້ຽນ. ທ່ານຈະຕ້ອງຊອກຫາທີມ B, C ແລະ D. ທ່ານຈະຕ້ອງສົນທະນາກັບພວກເຂົາ, ຊອກຫາເວລາ, ເຂົ້າໃຈຄວາມສໍາຄັນຂອງພວກເຂົາ. ຢ່າງຫນ້ອຍພວກເຮົາຫວັງວ່າທ່ານຈະ.

ບໍ່ມີໃຜຢາກເຮັດອັນນີ້ແທ້ໆ. ນີ້ແມ່ນຄວາມມ່ວນຫນ້ອຍກວ່າພຽງແຕ່ແກ້ໄຂ API ທີ່ບໍ່ດີ. ມັນທັງຫມົດຂອງມະນຸດແລະ messy. ໃນ polyrepository, ທ່ານພຽງແຕ່ສາມາດເຮັດການປ່ຽນແປງ, ໃຫ້ມັນກັບຄົນທີ່ເຮັດວຽກກ່ຽວກັບອົງປະກອບນັ້ນ (ອາດຈະບໍ່ B, C ຫຼື D) ສໍາລັບການທົບທວນຄືນ, ແລະດໍາເນີນການຕໍ່ໄປ. ທີມ B, C ແລະ D ສາມາດຢູ່ກັບສະບັບປະຈຸບັນຂອງພວກເຂົາສໍາລັບໃນປັດຈຸບັນ. ພວກເຂົາເຈົ້າຈະໄດ້ຮັບການປັບປຸງໃຫມ່ເມື່ອພວກເຂົາຮັບຮູ້ເຖິງຄວາມສະຫຼາດຂອງເຈົ້າ!

ໃນ monorepository, ຄວາມຮັບຜິດຊອບຈະຖືກປ່ຽນໂດຍຄ່າເລີ່ມຕົ້ນ. ທີມ A ປ່ຽນແປງອົງປະກອບຂອງເຂົາເຈົ້າແລະ, ຖ້າບໍ່ລະມັດລະວັງ, ທັນທີ B, C ແລະ D. ນີ້ເຮັດໃຫ້ B, C ແລະ D ສະແດງໃຫ້ເຫັນເຖິງປະຕູຂອງ A, ສົງໄສວ່າເປັນຫຍັງທີມ A ທໍາລາຍການຊຸມນຸມ. ນີ້ສອນ A ວ່າພວກເຂົາບໍ່ສາມາດຂ້າມບັນຊີລາຍຊື່ຂອງຂ້ອຍຂ້າງເທິງ. ພວກເຂົາຕ້ອງເວົ້າກ່ຽວກັບສິ່ງທີ່ເຂົາເຈົ້າຈະເຮັດ. B, C ແລະ D ສາມາດເຄື່ອນຍ້າຍໄດ້ບໍ? ຈະເປັນແນວໃດຖ້າ B ແລະ C ສາມາດ, ແຕ່ D ແມ່ນກ່ຽວຂ້ອງຢ່າງໃກ້ຊິດກັບຜົນກະທົບຂ້າງຄຽງຂອງພຶດຕິກໍາຂອງ algorithm ເກົ່າ?

ຫຼັງຈາກນັ້ນ, ພວກເຮົາຕ້ອງເວົ້າກ່ຽວກັບວິທີທີ່ພວກເຮົາຈະອອກຈາກສະຖານະການນີ້:

1. ຮອງຮັບ APIs ພາຍໃນຫຼາຍອັນ, ແລະຈະໝາຍ algorithm ເກົ່າເປັນ depreced ຈົນກ່ວາ D ສາມາດຢຸດໃຊ້ມັນໄດ້.
2. ສະ​ຫນັບ​ສະ​ຫນູນ​ສໍາ​ລັບ​ການ​ອອກ​ຫຼາຍ​ສະ​ບັບ​, ຫນຶ່ງ​ທີ່​ມີ​ການ​ໂຕ້​ຕອບ​ເກົ່າ​, ຫນຶ່ງ​ທີ່​ມີ​ໃຫມ່​.
3. ຊັກຊ້າການປ່ອຍການປ່ຽນແປງຂອງ A ຈົນກ່ວາ B, C, ແລະ D ສາມາດຍອມຮັບໄດ້ພ້ອມກັນ.

ໃຫ້ເວົ້າວ່າພວກເຮົາໄດ້ເລືອກ 1, APIs ຫຼາຍອັນ. ໃນກໍລະນີນີ້ພວກເຮົາມີສອງຊິ້ນຂອງລະຫັດ. ເກົ່າແລະໃຫມ່. ຂ້ອນຂ້າງສະດວກໃນບາງສະຖານະການ. ພວກເຮົາກວດເບິ່ງລະຫັດເກົ່າກັບຄືນ, ໝາຍວ່າມັນບໍ່ຖືກນຳໃຊ້, ແລະຕົກລົງໃນຕາຕະລາງການລຶບກັບທີມງານ D ໂດຍຫຼັກແມ່ນຄືກັນສຳລັບບ່ອນເກັບມ້ຽນ poly ແລະ mono.

ເພື່ອປ່ອຍຫລາຍລຸ້ນ, ພວກເຮົາຕ້ອງການສາຂາ. ໃນປັດຈຸບັນພວກເຮົາມີສອງອົງປະກອບ - A1 ແລະ A2. ທີມ B ແລະ C ໃຊ້ A2 ແລະ D ໃຊ້ A1. ພວກເຮົາຕ້ອງການທຸກອົງປະກອບເພື່ອກຽມພ້ອມສໍາລັບການປ່ອຍຕົວເພາະວ່າການປັບປຸງຄວາມປອດໄພແລະການແກ້ໄຂຂໍ້ບົກພ່ອງອື່ນໆອາດຈະຕ້ອງການກ່ອນທີ່ D ສາມາດກ້າວໄປຂ້າງຫນ້າ. ໃນ polyrepository, ພວກເຮົາສາມາດຊ່ອນນີ້ຢູ່ໃນສາຂາທີ່ມີອາຍຸຍາວນານທີ່ມີຄວາມຮູ້ສຶກດີ. ໃນ monorepository, ພວກເຮົາບັງຄັບໃຫ້ລະຫັດຖືກສ້າງຂຶ້ນໃນໂມດູນໃຫມ່. ທີມ D ຈະຍັງຄົງຕ້ອງປ່ຽນແປງອົງປະກອບ "ເກົ່າ". ທຸກຄົນສາມາດເຫັນຄ່າໃຊ້ຈ່າຍທີ່ພວກເຮົາກໍາລັງຈ່າຍຢູ່ທີ່ນີ້ - ຕອນນີ້ພວກເຮົາມີລະຫັດສອງເທົ່າ, ແລະການແກ້ໄຂຂໍ້ບົກພ່ອງໃດໆທີ່ໃຊ້ກັບ A1 ແລະ A2 ຕ້ອງໃຊ້ກັບທັງສອງ. ດ້ວຍວິທີການແຕກງ່າຢູ່ໃນ polyrepository, ນີ້ແມ່ນເຊື່ອງໄວ້ຢູ່ຫລັງ cherry-pick. ພວກເຮົາພິຈາລະນາຄ່າໃຊ້ຈ່າຍຕ່ໍາເພາະວ່າບໍ່ມີການຊໍ້າຊ້ອນ. ຈາກຈຸດປະຕິບັດຕົວຈິງ, ຄ່າໃຊ້ຈ່າຍແມ່ນຄືກັນ: ທ່ານຈະສ້າງ, ປ່ອຍ, ແລະຮັກສາສອງ codebases ທີ່ຄືກັນຈົນກ່ວາທ່ານສາມາດລຶບຫນຶ່ງໃນນັ້ນ. ຄວາມແຕກຕ່າງແມ່ນວ່າດ້ວຍ monorepository ຄວາມເຈັບປວດນີ້ແມ່ນໂດຍກົງແລະເຫັນໄດ້. ນີ້ແມ່ນຮ້າຍແຮງກວ່າເກົ່າ, ແລະນັ້ນກໍ່ດີ.

ສຸດທ້າຍ, ພວກເຮົາມາຮອດຈຸດທີສາມ. ປ່ອຍຄວາມລ່າຊ້າ. ມັນເປັນໄປໄດ້ວ່າການປ່ຽນແປງທີ່ເຮັດໂດຍ A ຈະຊ່ວຍປັບປຸງຊີວິດຂອງທີມ A. ທີ່ສໍາຄັນ, ແຕ່ບໍ່ຮີບດ່ວນ. ພວກເຮົາສາມາດຊັກຊ້າໄດ້ບໍ? ໃນ polyrepository, ພວກເຮົາຍູ້ອັນນີ້ເພື່ອ pin ປອມ. ແນ່ນອນພວກເຮົາກໍາລັງບອກເລື່ອງນີ້ກັບທີມງານ D. ພຽງແຕ່ຢູ່ໃນສະບັບເກົ່າຈົນກວ່າທ່ານຈະຈັບໄດ້! ນີ້ເຮັດໃຫ້ເຈົ້າສາມາດຫຼິ້ນຄົນຂີ້ຕົວະ. ທີມ A ຍັງສືບຕໍ່ເຮັດວຽກກ່ຽວກັບອົງປະກອບຂອງພວກເຂົາ, ບໍ່ສົນໃຈຄວາມຈິງທີ່ວ່າທີມ D ກໍາລັງໃຊ້ເວີຊັນທີ່ລ້າສະໄຫມຫຼາຍຂຶ້ນ (ນັ້ນແມ່ນບັນຫາຂອງທີມ D, ພວກເຂົາໂງ່). ໃນຂະນະດຽວກັນ, ທີມ D ເວົ້າບໍ່ດີກ່ຽວກັບທັດສະນະຄະຕິທີ່ບໍ່ສົນໃຈຂອງທີມ A ຕໍ່ກັບຄວາມຫມັ້ນຄົງຂອງລະຫັດ, ຖ້າພວກເຂົາເວົ້າກ່ຽວກັບມັນທັງຫມົດ. ເດືອນຜ່ານໄປ. ສຸດທ້າຍ, ທີມງານ D ຕັດສິນໃຈເບິ່ງຄວາມເປັນໄປໄດ້ຂອງການປັບປຸງ, ແຕ່ A ພຽງແຕ່ມີການປ່ຽນແປງຫຼາຍ. ທີມ A ຈື່ໄດ້ບໍ່ວ່າເວລາໃດ ຫຼືວິທີການທີ່ເຂົາເຈົ້າແຕກ D. ການຍົກລະດັບແມ່ນເຈັບປວດຫຼາຍ ແລະຈະໃຊ້ເວລາດົນກວ່າ. ເຊິ່ງສົ່ງມັນລົງຕື່ມອີກໃນ stack ບູລິມະສິດ. ຈົນກ່ວາມື້ທີ່ພວກເຮົາມີບັນຫາຄວາມປອດໄພໃນ A ທີ່ບັງຄັບໃຫ້ພວກເຮົາເຮັດສາຂາ. ທີມ A ຕ້ອງກັບຄືນໄປໃນເວລາ, ຊອກຫາຈຸດໃນເວລາທີ່ D ມີຄວາມຫມັ້ນຄົງ, ແກ້ໄຂບັນຫາຢູ່ທີ່ນັ້ນ, ແລະເຮັດໃຫ້ມັນກຽມພ້ອມສໍາລັບການປ່ອຍຕົວ. ນີ້ແມ່ນທາງເລືອກ de facto ທີ່ປະຊາຊົນເຮັດ, ແລະມັນແມ່ນຮ້າຍແຮງທີ່ສຸດ. ມັນເບິ່ງຄືວ່າດີສໍາລັບທັງທີມ A ແລະທີມ D ຕາບໃດທີ່ພວກເຮົາສາມາດບໍ່ສົນໃຈກັນແລະກັນ.

ໃນ monorepository, ທີສາມແມ່ນແທ້ໆບໍ່ແມ່ນທາງເລືອກ. ເຈົ້າຖືກບັງຄັບໃຫ້ຈັດການກັບສະຖານະການໃນຫນຶ່ງໃນສອງວິທີ. ທ່ານຈໍາເປັນຕ້ອງເບິ່ງຄ່າໃຊ້ຈ່າຍຂອງການມີສອງສາຂາການປ່ອຍ. ຮຽນ​ຮູ້​ທີ່​ຈະ​ປົກ​ປັກ​ຮັກ​ສາ​ຕົນ​ເອງ​ຈາກ​ການ​ປັບ​ປຸງ​ທີ່​ເຮັດ​ໃຫ້​ຄວາມ​ເຂົ້າ​ກັນ​ໄດ້​ກັບ​ຄືນ​ໄປ​ບ່ອນ​. ແຕ່ສໍາຄັນທີ່ສຸດ: ທ່ານ​ບໍ່​ສາ​ມາດ​ຫຼີກ​ເວັ້ນ​ການ​ມີ​ການ​ສົນ​ທະ​ນາ​ທີ່​ຫຍຸ້ງ​ຍາກ​.

ໃນປະສົບການຂອງຂ້ອຍ, ເມື່ອທີມໃຫຍ່, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຮັກສາລະບົບທັງຫມົດຢູ່ໃນໃຈ, ແລະນັ້ນແມ່ນສ່ວນທີ່ສໍາຄັນທີ່ສຸດ. ທ່ານຕ້ອງປັບປຸງການເບິ່ງເຫັນຄວາມຂັດແຍ້ງໃນລະບົບ. ທ່ານຕ້ອງເຮັດວຽກຢ່າງຫ້າວຫັນເພື່ອໃຫ້ທີມງານເບິ່ງຫ່າງຈາກອົງປະກອບຂອງພວກເຂົາແລະເບິ່ງການເຮັດວຽກຂອງທີມງານແລະຜູ້ບໍລິໂພກອື່ນໆ.

ແມ່ນແລ້ວ, ທ່ານສາມາດສ້າງເຄື່ອງມືທີ່ພະຍາຍາມແກ້ໄຂບັນຫາ polyrepository. ແຕ່ປະສົບການຂອງຂ້ອຍການສອນການຈັດສົ່ງຢ່າງຕໍ່ເນື່ອງແລະອັດຕະໂນມັດໃນວິສາຫະກິດຂະຫນາດໃຫຍ່ບອກຂ້ອຍວ່າ: ພຶດຕິກໍາເລີ່ມຕົ້ນໂດຍບໍ່ມີການນໍາໃຊ້ເຄື່ອງມືເພີ່ມເຕີມແມ່ນພຶດຕິກໍາທີ່ເຈົ້າຄາດວ່າຈະເຫັນ. ພຶດຕິກໍາເລີ່ມຕົ້ນຂອງ polyrepository ແມ່ນການໂດດດ່ຽວ, ນັ້ນແມ່ນຈຸດທັງຫມົດ. ພຶດຕິກໍາເລີ່ມຕົ້ນຂອງ monorepository ແມ່ນຄວາມຮັບຜິດຊອບຮ່ວມກັນແລະຄວາມໂປ່ງໃສ, ນັ້ນແມ່ນຈຸດທັງຫມົດ. ໃນທັງສອງກໍລະນີ, ຂ້າພະເຈົ້າຈະສ້າງເຄື່ອງມືທີ່ຈະກ້ຽງອອກແຄມ rough. ໃນຖານະເປັນຜູ້ນໍາ, ຂ້າພະເຈົ້າຈະເລືອກເອົາ monorepository ທຸກໆຄັ້ງເພາະວ່າເຄື່ອງມືຕ້ອງການເສີມສ້າງວັດທະນະທໍາທີ່ຂ້ອຍຕ້ອງການ, ແລະວັດທະນະທໍາແມ່ນມາຈາກການຕັດສິນໃຈນ້ອຍໆແລະການເຮັດວຽກປະຈໍາວັນຂອງທີມງານ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ໃຜເປັນແຟນບານທີ່ໃຫຍ່ທີ່ສຸດ? ຜູ້ສະຫນັບສະຫນູນ:

• Monorepo

• rust

• ແບບສຳຫຼວດບໍ່ຖືກຕ້ອງ / ທັງສອງ

ຜູ້ໃຊ້ 33 ຄົນລົງຄະແນນສຽງ. 13 ຜູ້ໃຊ້ງົດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com