เมื่อใดที่จะแยกโครงการในโครงการย่อยหลายโครงการ


30

ฉันอยากรู้ว่ามันเหมาะสมหรือไม่ที่จะแบ่งโครงการที่ฉันทำงานในที่เก็บสองแห่งแทนที่จะเป็นหนึ่งโครงการ

จากสิ่งที่ฉันสามารถพูดได้:

  • ส่วนหน้าจะถูกเขียนเป็น html + js
  • แบ็กเอนด์ใน. net
  • แบ็กเอนด์ไม่ได้ขึ้นอยู่กับส่วนหน้าและส่วนหน้าไม่ได้ขึ้นอยู่กับส่วนแบ็คเอนด์
  • ส่วนหน้าจะใช้ API พักผ่อนหย่อนใจดำเนินการในแบ็กเอนด์
  • ส่วนหน้าสามารถโฮสต์บนเซิร์ฟเวอร์ HTTP ใด ๆ คงที่

ณ ตอนนี้ที่เก็บมีโครงสร้างนี้:

ราก:

  • ส่วนหน้า / *
  • แบ็กเอนด์ / *

ฉันคิดว่ามันเป็นความผิดพลาดที่ทำให้โครงการทั้งสองอยู่ในที่เก็บเดียวกัน เนื่องจากโปรเจ็กต์ทั้งสองไม่มีการขึ้นต่อกันระหว่างกันดังนั้นจึงควรอยู่ในที่เก็บแต่ละรายการและหากจำเป็นต้องมีที่เก็บพาเรนต์ที่มีซับโดเลชัน

ฉันได้รับแจ้งว่าไม่มีประโยชน์และเราจะไม่ได้รับประโยชน์ใด ๆ จากการทำเช่นนั้น

นี่คือข้อโต้แย้งของฉัน:

  • เรามีสองโมดูลที่ไม่ได้พึ่งพากัน
  • การมีประวัติแหล่งที่มาของทั้งสองโครงการในระยะยาวอาจทำให้สิ่งต่าง ๆ ซับซ้อน (ลองค้นหาในประวัติของบางสิ่งในส่วนหน้าในขณะที่คุณมีครึ่งหนึ่งของข้อผูกพันที่ไม่เกี่ยวข้องกับข้อบกพร่องที่คุณกำลังมองหา)
  • ความขัดแย้งและการรวม (สิ่งนี้ไม่ควรเกิดขึ้น แต่การมีคนกดไปที่แบ็กเอนด์จะบังคับให้ผู้พัฒนารายอื่นดึงการเปลี่ยนแปลงด้านหลังเพื่อผลักดันการเปลี่ยนแปลงส่วนหน้า)
  • นักพัฒนาซอฟต์แวร์หนึ่งรายอาจใช้งานได้เฉพาะในแบ็กเอนด์ แต่จะต้องดึงส่วนหน้าหรือวิธีอื่น ๆ เสมอ
  • ในระยะยาวเมื่อถึงเวลาต้องปรับใช้ ในบางวิธีส่วนหน้าสามารถปรับใช้กับเซิร์ฟเวอร์แบบคงที่หลายตัวในขณะที่มีเซิร์ฟเวอร์ส่วนหลังหนึ่งตัว ในทุกกรณีผู้คนจะถูกบังคับให้โคลนทั้งแบ็กเอนด์ด้วยหรือเพื่อให้สคริปต์ที่กำหนดเองเพื่อผลักดันให้เซิร์ฟเวอร์ทั้งหมดส่วนหน้าเท่านั้นหรือเพื่อลบแบ็กเอนด์ ง่ายกว่าเพียงแค่กด / ดึงเฉพาะส่วนหน้าหรือส่วนหลังกว่าทั้งสองอย่างหากจำเป็นต้องใช้เพียงส่วนเดียว
  • อาร์กิวเมนต์ตัวนับ (หนึ่งคนอาจทำงานกับทั้งสองโครงการ), สร้าง repo ตัวที่สามด้วย submodule และพัฒนาด้วย ประวัติแยกออกจากกันในแต่ละโมดูลและคุณสามารถสร้างแท็กที่เวอร์ชันแบ็กเอนด์ / ส่วนหน้าทำงานร่วมกันได้อย่างแท้จริง การมีส่วนหน้า / แบ็กเอนด์ร่วมกันใน repo หนึ่งไม่ได้หมายความว่าพวกเขาจะทำงานร่วมกัน มันเป็นเพียงการรวมประวัติศาสตร์ทั้งสองเป็น repo ใหญ่
  • มีส่วนหน้า / แบ็กเอนด์เป็น submodules จะทำให้สิ่งต่าง ๆ ง่ายขึ้นถ้าคุณต้องการที่จะเพิ่มอิสระในโครงการ ในบางกรณีคุณไม่ต้องการให้สิทธิ์การเข้าถึงฐานข้อมูลเต็มรูปแบบ การมีโมดูลขนาดใหญ่หนึ่งโมดูลจะทำให้สิ่งต่างๆยากขึ้นหากคุณต้องการ จำกัด สิ่งที่ "บุคคลภายนอก" สามารถมองเห็น / แก้ไขได้
  • การแนะนำบั๊กและแก้ไขบั๊กฉันได้แทรกบั๊กใหม่ในส่วนหน้า จากนั้นมีคนแก้ไขข้อผิดพลาดในแบ็กเอนด์ ด้วยที่เก็บเดียวการย้อนกลับก่อนที่ข้อผิดพลาดใหม่จะย้อนกลับแบ็กเอนด์ซึ่งอาจทำให้แก้ไขได้ยาก ฉันต้องโคลนแบ็กเอนด์ในโฟลเดอร์ต่าง ๆ เพื่อให้แบ็กเอนด์ทำงานได้ในขณะที่แก้ไขบั๊กในส่วนหน้า ... จากนั้นพยายามที่จะรวมสิ่งต่าง ๆ เข้าด้วยกัน ... การมีที่เก็บสองอันจะไม่เจ็บปวดเพราะการย้าย HEAD ของ repo ไม่ต้องเปลี่ยนอีก และการทดสอบแบ็กเอนด์รุ่นต่าง ๆ จะไม่เจ็บปวด

ใครบางคนสามารถให้ข้อโต้แย้งเพิ่มเติมแก่ฉันเพื่อโน้มน้าวใจพวกเขาหรืออย่างน้อยก็บอกฉันว่าทำไมมันไม่มีจุดหมาย (ซับซ้อนกว่า) เพื่อแบ่งโครงการออกเป็นสองส่วน โครงการนี้เป็นโครงการใหม่และโค้ดเบสมีอายุสองสามวันจึงไม่สามารถแก้ไขได้เร็วเกินไป

คำตอบ:


23

ที่ บริษัท ของฉันเราใช้ที่เก็บ SVN แยกต่างหากสำหรับทุกองค์ประกอบของระบบ ฉันสามารถบอกคุณได้ว่ามันน่าหงุดหงิดอย่างมาก กระบวนการสร้างของเรามีสิ่งที่เป็นนามธรรมมากมาย

เราทำสิ่งนี้กับ Java ดังนั้นเราจึงมีกระบวนการสร้างอย่างหนักด้วยการรวบรวม javac, การรวบรวม JibX, การตรวจสอบ XML และอื่น ๆ

สำหรับเว็บไซต์ของคุณอาจไม่ใช่เรื่องใหญ่หากคุณไม่ "สร้างมัน" (เช่น vanilla PHP)

ลดขนาดเพื่อแยกผลิตภัณฑ์ออกเป็นหลาย ๆ ที่เก็บ

  1. การจัดการงานสร้าง - ฉันไม่สามารถเช็คเอาต์รหัสเรียกใช้สคริปต์บิลด์ที่มีในตัวและมีผลิตภัณฑ์ที่รันได้ / ติดตั้งได้ / ปรับใช้ได้ ฉันต้องการระบบบิลด์ภายนอกที่ออกไปหา repos หลาย ๆ ตัวรันสคริปต์ build ภายในหลายตัวจากนั้นรวบรวมสิ่งประดิษฐ์
  2. ติดตามการเปลี่ยนแปลง - ดูว่าใครเปลี่ยนแปลงอะไรเมื่อใดและเพราะเหตุใด หากการแก้ไขข้อบกพร่องในส่วนหน้าต้องมีการเปลี่ยนแปลงแบ็กเอนด์ตอนนี้มี 2 เส้นทางที่แตกต่างกันสำหรับฉันที่จะอ้างอิงกลับไปในภายหลัง
  3. การดูแลระบบ - คุณต้องการเพิ่มจำนวนบัญชีผู้ใช้นโยบายรหัสผ่านและอื่น ๆ ที่ต้องจัดการเป็นสองเท่าหรือไม่?
  4. การผสาน - คุณสมบัติใหม่มีแนวโน้มที่จะเปลี่ยนรหัสเป็นจำนวนมาก ด้วยการแบ่งโครงการของคุณออกเป็นหลาย ๆ ที่เก็บคุณกำลังคูณจำนวนของการรวมที่ต้องการ
  5. การสร้างสาขา - ข้อตกลงเดียวกันกับการแยกสาขาเพื่อสร้างสาขาคุณต้องสร้างสาขาในที่เก็บแต่ละแห่ง
  6. การติดแท็ก - หลังจากทดสอบโค้ดของคุณสำเร็จแล้วคุณต้องการติดแท็กเวอร์ชันสำหรับการเปิดตัว ตอนนี้คุณมีหลายแท็กที่จะสร้างหนึ่งในแต่ละพื้นที่เก็บข้อมูล
  7. ยากที่จะหาบางสิ่งบางอย่าง - ส่วนหน้า / ส่วนหลังอาจตรงไปตรงมา แต่ก็กลายเป็นความชันที่ลื่น หากคุณแบ่งออกเป็นโมดูลมากพอนักพัฒนาอาจต้องตรวจสอบว่าโค้ดบางส่วนอยู่ในการควบคุมซอร์สหรือไม่

เคสของฉันค่อนข้างสุดขีดเนื่องจากผลิตภัณฑ์ของเราแบ่งเป็น repos ที่แตกต่างกัน 14 อันและ repo แต่ละอันจะถูกแบ่งออกเป็น 4-8 โมดูล ถ้าฉันจำได้เรามีที่ไหนสักแห่งราว ๆ 80 แพคเกจ "บางอย่าง" ซึ่งทุกอย่างจะต้องมีการตรวจสอบเป็นรายบุคคลแล้วประกอบ

กรณีของคุณที่มีแบ็กเอนด์ / ส่วนหน้าอาจมีความซับซ้อนน้อยกว่า แต่ฉันก็ยังแนะนำต่อไป

ตัวอย่างสุดโต่งอาจเป็นข้อโต้แย้งที่น่าดึงดูดใจหรือต่อต้านอะไรก็ได้ :)

เกณฑ์ที่ฉันจะใช้ในการตัดสินใจ

ฉันจะพิจารณาแยกผลิตภัณฑ์ออกเป็นที่เก็บซอร์สโค้ดหลายแหล่งหลังจากพิจารณาปัจจัยต่อไปนี้:

  1. Build - ผลลัพธ์ของการสร้างแต่ละองค์ประกอบผสานเข้าด้วยกันเพื่อสร้างผลิตภัณฑ์หรือไม่ เช่นเดียวกับการรวมไฟล์. class จากพวงของส่วนประกอบลงในไฟล์. jar หรือ. war
  2. การปรับใช้ - คุณจบลงด้วยองค์ประกอบที่ได้รับการปรับใช้ร่วมกันเป็นหนึ่งหน่วยหรือหน่วยที่แตกต่างกันที่ไปยังเซิร์ฟเวอร์ที่แตกต่างกัน? ตัวอย่างเช่นสคริปต์ฐานข้อมูลไปที่เซิร์ฟเวอร์ DB ของคุณในขณะที่จาวาสคริปต์ไปที่เว็บเซิร์ฟเวอร์ของคุณ
  3. การเปลี่ยนแปลงร่วม - พวกเขามักจะเปลี่ยนแปลงบ่อยหรืออยู่ด้วยกันไหม? ในกรณีของคุณพวกเขาอาจเปลี่ยนแปลงแยกต่างหาก แต่ก็ยังบ่อย
  4. ความถี่ในการแตกแขนง / รวมเข้าด้วยกัน - ถ้าทุกคนเช็คอินที่ลำตัวและกิ่งก้านเป็นของหายากคุณอาจหนีไปได้ หากคุณแยกสาขาและรวมบ่อยครั้งสิ่งนี้อาจกลายเป็นฝันร้าย
  5. ความว่องไว - หากคุณต้องการพัฒนาทดสอบปล่อยและปรับใช้การเปลี่ยนแปลงตามช่วงเวลา (อาจเป็นกับ SaaS) คุณสามารถทำได้โดยไม่ต้องเสียเวลาอันมีค่าไปกับกิ่งไม้และ repos หรือไม่?

ข้อโต้แย้งของคุณ

ฉันไม่เห็นด้วยกับข้อโต้แย้งส่วนใหญ่ของคุณสำหรับการแยกนี้ ฉันจะไม่โต้แย้งพวกเขาทั้งหมดเพราะคำตอบที่ยาวนานนี้จะได้นานขึ้น แต่มีบางอย่างที่โดดเด่น:

เรามีสองโมดูลที่ไม่ได้พึ่งพากัน

ไม่ใช่ความรู้สึก หากคุณนำแบ็กเอนด์ออกไปส่วนหน้าของคุณจะทำงานหรือไม่ นั่นคือสิ่งที่ฉันคิดว่า.

การมีประวัติแหล่งที่มาของทั้งสองโครงการในระยะยาวอาจทำให้สิ่งต่าง ๆ ซับซ้อน (ลองค้นหาในประวัติของบางสิ่งในส่วนหน้าในขณะที่คุณมีครึ่งหนึ่งของข้อผูกพันที่ไม่เกี่ยวข้องกับข้อบกพร่องที่คุณกำลังมองหา)

หากรูทโปรเจ็กต์ของคุณแตกออกเป็น frontend / และ backend / คุณสามารถดูประวัติของลำดับชั้นเหล่านั้นได้อย่างอิสระ

ความขัดแย้งและการรวม (สิ่งนี้ไม่ควรเกิดขึ้น แต่การมีใครบางคนผลักไปที่แบ็กเอนด์จะบังคับให้ผู้พัฒนารายอื่นดึงการเปลี่ยนแปลงด้านหลังเพื่อผลักดันการเปลี่ยนแปลงส่วนหน้า) ผู้พัฒนารายหนึ่งอาจทำงานได้เฉพาะบนแบ็กเอนด์เท่านั้น รอบ

การแยกโครงการของคุณเป็น repos ต่างๆไม่ได้แก้ปัญหานี้ ความขัดแย้งส่วนหน้าและความขัดแย้งส่วนหลังยังคงทำให้คุณมีความขัดแย้ง 2 ข้อไม่ว่าจะเป็นพื้นที่เก็บข้อมูล 1 ครั้งคูณด้วย 2 ข้อขัดแย้งหรือ 2 ที่เก็บข้อมูล 1 ครั้ง บางคนยังต้องการแก้ไขพวกเขา

หากข้อกังวลคือ 2 repos หมายถึงส่วนหน้า dev สามารถผสานรหัสส่วนหน้าในขณะที่ส่วนหลัง dev ผสานรหัสด้านหลังคุณยังสามารถทำได้ด้วยที่เก็บเดียวโดยใช้ SVN SVN สามารถผสานได้ทุกระดับ อาจเป็นข้อ จำกัด ทางคอมไพล์หรือปรอท (คุณติดแท็กทั้งคู่ดังนั้นไม่แน่ใจว่า SCM ที่คุณใช้)?

ในทางกลับกัน

จากทั้งหมดที่กล่าวมาฉันได้เห็นกรณีที่การแยกโครงการออกเป็นหลายโมดูลหรือที่เก็บทำงาน ฉันยังสนับสนุนมันอีกครั้งสำหรับโครงการเฉพาะที่เรารวม Solr เข้ากับผลิตภัณฑ์ของเรา แน่นอนว่าการทำงานบนเซิร์ฟเวอร์ที่แยกต่างหากจะเปลี่ยนเฉพาะเมื่อเซ็ตการแก้ไขเกี่ยวข้องกับการค้นหา (ผลิตภัณฑ์ของเราทำมากกว่าการค้นหา) มีกระบวนการสร้างแยกต่างหากและไม่มีการสร้างรหัสหรือการสร้างสิ่งประดิษฐ์ร่วมกัน


การดูแลในทุกสิ่งเป็นแม่ของฉันมักจะพูดว่า ...
วิลเลียมเพน

ในฐานะของการเขียนของฉันฉันเขียนส่วนหน้าโดยไม่ต้องแบ็กเอนด์ ฉันเลียนแบบแบ็กเอนด์ด้วยไฟล์ json และฉันอาจเลียนแบบได้อย่างสมบูรณ์ด้วย indexedDB ในเบราว์เซอร์ ดังนั้นใช่แบ็กเอนด์เป็นเพียงเซิร์ฟเวอร์ที่ให้บริการ json มันอาจถูกแทนที่ด้วยอะไรก็ได้ตราบใดที่ข้อมูลที่ได้รับสอดคล้องกับ API ทั้งสองโครงการใช้ระบบบิลด์ที่แตกต่างกัน สรุปแล้วมันค่อนข้างคล้ายกับการมีเว็บไซต์และแอพมือถือ android การเพิ่มแอปพลิเคชันมือถือภายในที่เก็บเว็บเซิร์ฟเวอร์
Loïc Faure-Lacroix

นอกจากนี้หากยังไม่ชัดเจนส่วนแบ็คเอนด์และส่วนหน้าไม่ใช่ส่วนต่อประสานผู้ใช้ / ผู้ดูแลระบบ แต่ส่วนหน้าเป็นเพียงอินเตอร์เฟส ajax และแบ็กเอนด์ให้บริการ json ผู้ใช้และบทบาทได้รับการจัดการแตกต่างกันและส่วนติดต่อผู้ดูแลระบบจะอยู่ในส่วนหน้า แนวคิดก็คือการแยกทั้งสองส่วนออกและป้องกันไม่ให้สร้างจาวาสคริปต์ HTML เพื่อโหลดเซิร์ฟเวอร์ที่สร้างขึ้น HTML เซิร์ฟเวอร์ควรให้บริการ json หรือ xml เท่านั้น
Loïc Faure-Lacroix

1
จากนั้นคุณไม่มีปัญหาเกี่ยวกับการสร้างหรือการปรับใช้ดังนั้นอาจเป็นไปได้ แต่อีกครั้งหากคุณทำการเปลี่ยนแปลงครั้งสำคัญคุณอาจต้องเปลี่ยน API ซึ่งมีผลต่อทั้งส่วนหน้าและส่วนหลังดังนั้นคุณจะแตกแขนงสองครั้งผสานสองครั้งติดแท็กสองครั้งเป็นต้น แต่ตราบใดที่มันยังคงอยู่เพียงสองครั้ง เปลี่ยนเป็น 3 ... 4 ... 12 ... 20 อาจไม่ใช่ความคิดที่ไม่ดี
Brandon

แม้ว่า API จะเปลี่ยนแปลงด้วยการกำหนดเวอร์ชันที่เหมาะสม แต่ก็เป็นไปได้ที่จะสร้างเวอร์ชันสาขาสำหรับแต่ละส่วนหน้าที่รองรับเวอร์ชัน API แบ็คเอนด์ควรมีความเข้ากันได้ "ย้อนกลับ" บางอย่างและทำให้ API เก่าทำงานได้นานที่สุด
Loïc Faure-Lacroix

3

ข้อโต้แย้งบางอย่างของคุณใช้ได้แล้ว แต่บางข้อก็ไม่ถูกต้อง

เรามีสองโมดูลที่ไม่ได้พึ่งพากัน

ที่จริงไม่จริงทั้งหมด เพื่อให้สามารถสื่อสารได้ทั้ง front-end และ back-end จำเป็นต้องมีอินเตอร์เฟสทั่วไป (คำอธิบาย) นั่นทำให้มันเป็นข้อโต้แย้งที่อ่อนแอในความโปรดปรานของการมีทั้งในที่เก็บข้อมูลทั่วไป แต่มีเพียงข้อโต้แย้งที่อ่อนแอเพราะมันไม่ได้ทำให้แตกต่างกันมาก

การมีประวัติแหล่งที่มาของทั้งสองโครงการในระยะยาวอาจทำให้สิ่งต่าง ๆ ซับซ้อน (ลองค้นหาในประวัติของบางสิ่งในส่วนหน้าในขณะที่คุณมีครึ่งหนึ่งของข้อผูกพันที่ไม่เกี่ยวข้องกับข้อบกพร่องที่คุณกำลังมองหา)

นี่คืออาร์กิวเมนต์ปลอม หากคุณต้องการค้นหาวิธีแก้ไขข้อผิดพลาดเฉพาะคุณค้นหาในตัวติดตามบั๊กที่การคอมมิทมีการแก้ไข และถ้าคุณต้องการที่จะรู้ว่าส่วนหนึ่งของรหัสมีการพัฒนาอย่างไรคุณจะดูประวัติของไฟล์เดียว ไม่ว่าในกรณีใดการมีไฟล์อื่นอาจมาจากโมดูลอื่นในที่เก็บไม่ควรทำให้ซับซ้อนในทางใดทางหนึ่ง

ความขัดแย้งและการรวม (สิ่งนี้ไม่ควรเกิดขึ้น แต่การมีคนกดไปที่แบ็กเอนด์จะบังคับให้ผู้พัฒนารายอื่นดึงการเปลี่ยนแปลงด้านหลังเพื่อผลักดันการเปลี่ยนแปลงส่วนหน้า)

นี่คืออาร์กิวเมนต์ปลอม ฉันไม่ทราบว่า VCS (ครึ่งดี) ใด ๆ ที่คุณต้องการซิงโครไนซ์พื้นที่เก็บข้อมูลทั้งหมดก่อนที่คุณจะสามารถยืนยัน / ผลักดันการเปลี่ยนแปลงของคุณ ในที่สุดคุณจำเป็นต้องซิงโครไนซ์โฟลเดอร์ที่มีไฟล์ที่เปลี่ยนแปลง (และมักจะเป็นแค่ไฟล์เอง)

นักพัฒนาซอฟต์แวร์รายหนึ่งอาจทำงานได้เฉพาะแบ็กเอนด์ แต่จะต้องดึงแบ็กเอนด์หรือวิธีอื่น ๆ อยู่เสมอ

นี่คืออาร์กิวเมนต์ปลอมเช่นเดียวกับก่อนหน้านี้

ในระยะยาวเมื่อถึงเวลาต้องปรับใช้ ในบางวิธีส่วนหน้าสามารถปรับใช้กับเซิร์ฟเวอร์แบบคงที่หลายตัวในขณะที่มีเซิร์ฟเวอร์ส่วนหลังหนึ่งตัว ในทุกกรณีผู้คนจะถูกบังคับให้โคลนทั้งแบ็กเอนด์ด้วยหรือเพื่อให้สคริปต์ที่กำหนดเองเพื่อผลักดันให้เซิร์ฟเวอร์ทั้งหมดส่วนหน้าเท่านั้นหรือเพื่อลบแบ็กเอนด์ ง่ายกว่าเพียงแค่กด / ดึงเฉพาะส่วนหน้าหรือส่วนหลังกว่าทั้งสองอย่างหากจำเป็นต้องใช้เพียงส่วนเดียว

ขึ้นอยู่กับว่าผู้คนมองเห็นว่าการปรับใช้จะเสร็จสิ้นซึ่งอาจเป็นอาร์กิวเมนต์ที่ถูกต้อง หากการปรับใช้จะทำได้โดยการคลายไฟล์ zip / tarbal บนเซิร์ฟเวอร์ดังนั้นไม่สำคัญว่าที่เก็บของคุณจะถูกจัดระเบียบอย่างไร หากการปรับใช้จะกระทำโดยการเช็กเอาต์ (ส่วนหนึ่งของ) ที่เก็บบนเซิร์ฟเวอร์ดังนั้นจึงเป็นความคิดที่ดีที่จะใช้ที่เก็บแยกต่างหากสำหรับโมดูลที่ปรับใช้แยกต่างหาก

อาร์กิวเมนต์ตัวนับ (หนึ่งคนอาจทำงานกับทั้งสองโครงการ), สร้าง repo ตัวที่สามด้วย submodule และพัฒนาด้วย ประวัติแยกออกจากกันในแต่ละโมดูลและคุณสามารถสร้างแท็กที่เวอร์ชันแบ็กเอนด์ / ส่วนหน้าทำงานร่วมกันได้อย่างแท้จริง การมีส่วนหน้า / แบ็กเอนด์ร่วมกันใน repo หนึ่งไม่ได้หมายความว่าพวกเขาจะทำงานร่วมกัน มันเป็นเพียงการรวมประวัติศาสตร์ทั้งสองเป็น repo ใหญ่

นี่เป็นข้อโต้แย้งที่ถูกต้อง แต่ไม่รุนแรง

มีส่วนหน้า / แบ็กเอนด์เป็น submodules จะทำให้สิ่งต่าง ๆ ง่ายขึ้นถ้าคุณต้องการที่จะเพิ่มอิสระในโครงการ ในบางกรณีคุณไม่ต้องการให้สิทธิ์การเข้าถึงฐานข้อมูลเต็มรูปแบบ การมีโมดูลขนาดใหญ่หนึ่งโมดูลจะทำให้สิ่งต่างๆยากขึ้นหากคุณต้องการ จำกัด สิ่งที่ "บุคคลภายนอก" สามารถมองเห็น / แก้ไขได้

นี่เป็นอาร์กิวเมนต์ที่ถูกต้อง

การแนะนำบั๊กและแก้ไขบั๊กฉันได้แทรกบั๊กใหม่ในส่วนหน้า จากนั้นมีคนแก้ไขข้อผิดพลาดในแบ็กเอนด์ ด้วยที่เก็บเดียวการย้อนกลับก่อนที่ข้อผิดพลาดใหม่จะย้อนกลับแบ็กเอนด์ซึ่งอาจทำให้แก้ไขได้ยาก

นั่นเป็นอาร์กิวเมนต์ปลอมเพราะมันหมายถึงว่าหลังจากการแก้ไขข้อผิดพลาดสองรายการเป็นหนึ่งโมดูลคุณจะไม่สามารถย้อนกลับหนึ่งรายการแรกได้ VCS ที่เหมาะสมเพียงครึ่งหนึ่งจะอนุญาตให้คุณย้อนกลับไปเกี่ยวกับการคอมมิชชันเก่า ๆ ใด ๆ (แม้ว่ามันจะหมายถึงการที่คุณทำการคอมมิทใหม่ที่ย้อนกลับการเปลี่ยนแปลงเหล่านั้น

ฉันต้องโคลนแบ็กเอนด์ในโฟลเดอร์ต่าง ๆ เพื่อให้แบ็กเอนด์ทำงานได้ในขณะที่แก้ไขบั๊กในส่วนหน้า ... จากนั้นพยายามที่จะรวมสิ่งต่าง ๆ เข้าด้วยกัน ... การมีที่เก็บสองอันจะไม่เจ็บปวดเพราะการย้าย HEAD ของ repo ไม่ต้องเปลี่ยนอีก และการทดสอบแบ็กเอนด์รุ่นต่าง ๆ จะไม่เจ็บปวด

นี่เป็นข้อโต้แย้งที่ดีทีเดียว การมีที่เก็บข้อมูลสองแห่งทำให้ง่ายต่อการทดสอบสถานการณ์ที่การปรับใช้ front-end-back-end และอาจกลายเป็น (เล็กน้อย) จากการซิงค์


พูดตามจริงแล้วข้อโต้แย้งปลอมส่วนใหญ่สามารถแก้ไขได้ด้วยสาขา สาขาสำหรับส่วนหน้าและสาขาสำหรับส่วนหลัง หลักสำหรับการซิงค์ แต่ในบางวิธีการจัดการสาขาเช่นนั้นทำให้สิ่งต่าง ๆ ซับซ้อนกว่าการมีสอง repos
Loïc Faure-Lacroix

1
@Sybiam: ที่จริงแล้วพวกมันเป็นข้อโต้แย้งปลอมเพราะพวกเขาไม่ได้เน้นปัญหาที่อาจเกิดขึ้นกับการใช้พื้นที่เก็บข้อมูลเดียวแม้ว่าการเปลี่ยนแปลงทั้งหมดจะทำกับลำต้น / หลัก
Bart van Ingen Schenau

ฉันคิดว่าคำวิจารณ์ของคุณถูกต้อง ฉันไม่คิดว่าเป็นประเด็นคำถาม
sylvanaar

2

โพสต์นี้ค่อนข้างเก่า แต่ฉันต้องการมีส่วนร่วม ในขณะที่แบ็คเอนด์ของคุณไม่รู้เกี่ยวกับฟรอนต์เอนด์ส่วนหน้าจำเป็นต้องมีคำขอที่ตรงกับ API ของแบ็กเอนด์ หากคุณพิจารณา back-end ของคุณเป็น REST API คุณสามารถกำหนดไฟล์ส่วนต่อประสานเช่นส่วนติดต่อ YAML ขณะนี้มี 3 โครงการจริง ๆ ซึ่งคุณสามารถแบ่งเป็น repos ต่าง ๆ ได้ตามที่เห็นสมควร

  • นิยาม API
  • Back-end
  • Front-end

นิยาม API คือการพึ่งพาในอีกสองโครงการสมมติว่าคุณใช้ Maven เป็นเครื่องมือฉีดพึ่งพา จากนั้นขึ้นอยู่กับว่าคุณต้องการทำเวอร์ชันอย่างเคร่งครัด คุณสามารถชนรุ่นของโครงการคำจำกัดความ API ทุกครั้งที่คุณทำการเปลี่ยนแปลงเพื่อให้แน่ใจว่าโครงการอยู่ในสถานะที่เข้ากันได้เสมอ แต่ต้องใช้ค่าใช้จ่ายมากขึ้นหรือคุณสามารถใช้บางอย่างเช่น SNAPSHOTS ใน maven และทำรุ่นเมื่อคุณ มีความสุขกับอินเทอร์เฟซที่มีค่าใช้จ่ายน้อย แต่คุณมักจะมีความไม่ลงรอยกัน แต่ตราบใดที่คุณบังคับใช้ข้อกำหนด API ในส่วนหน้าและส่วนหลังคุณจะสามารถแยกโครงการออกเป็นส่วน ๆ ได้

ปัญหาเหล่านี้เพิ่มเติมเกี่ยวกับการจัดการการพึ่งพา แม้ว่าโครงการจะไม่แยกออกและอยู่ในที่เก็บเดียวกันมันค่อนข้างง่ายสำหรับเว็บไซต์ที่จะอยู่ในสถานะที่ส่วนหน้าและส่วนหลังไม่ซิงค์กัน วิธีเดียวที่จะหยุดสิ่งนี้ได้จริงๆคือการกำหนดสัญญาระหว่างทั้งสอง แต่คุณต้องการทำในลักษณะที่ไม่ทำให้การใช้งานของ front-end และ back-end ไม่เหมือนกับการใช้รหัสในส่วนติดต่อแทน ของการใช้งานในการเขียนโปรแกรม OO

นอกจากนี้เพื่อจัดการกับคำวิจารณ์อย่างดีว่าสิ่งนี้สร้างค่าใช้จ่ายในการดูแลรักษาไฟล์ส่วนต่อประสานนี้ตัวอย่างเช่นการวางผังสามารถแม้แต่สร้างรหัสสมบูรณ์สำหรับภาษาการเขียนโปรแกรมและกรอบงานต่าง ๆ เช่น JAX-RS ดังนั้นคุณสามารถสร้างอินเทอร์เฟซในเทคโนโลยีที่คุณเลือกจากนั้นใช้อินเทอร์เฟซนี้ นอกจากนี้ยังเพิ่มเอกสารที่ดีมากให้กับแบ็คเอนด์ของคุณทำให้นักพัฒนา Front-End สามารถทำงานของพวกเขาได้ง่ายขึ้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.