เป็นเรื่องปกติหรือไม่ที่จะแยกแบ็คเอนด์และฟรอนต์เอนด์ออกเป็นสองตำแหน่งในโครงการพัฒนาเว็บไซต์

เมื่อเริ่มต้นเว็บมันเป็นเรื่องปกติหรือไม่ที่จะมีวิศวกรที่ทำงานในส่วนหน้าและส่วนหลังของฟีเจอร์ หรือมีวิศวกรแยกระหว่างแบ็คเอนด์และฟรอนเอนด์หรือไม่?

ข้อใดมีประโยชน์มากกว่าและในสถานการณ์ใด

ข้อเสียที่ฉันสังเกตเห็นเกี่ยวกับการมีวิศวกรหนึ่งคนที่รับผิดชอบคุณสมบัติทั้งหมดคือคน ๆ นั้นอาจมีความแข็งแกร่งเป็นพิเศษในการพัฒนาส่วนหน้าหรือส่วนหลัง แต่ไม่ใช่ทั้งสองอย่างดังนั้นบางครั้งจึงมีความเร็วและคุณภาพลดลง

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

อะไรคือวิธีปฏิบัติทั่วไปที่ดีที่สุดสำหรับการจัดสรรแบ็กเอนด์ / ทรัพยากรด้านวิศวกรรมในการเริ่มต้นในระยะแรก ๆ ? แล้วมันจะเปลี่ยนไปอย่างไรเมื่อมันโตขึ้น?

นี่คือภูมิปัญญาของฉันจากประสบการณ์ 14 ปี:

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

คำตอบที่ดีที่สุดมาจาก @Shark แต่เฉพาะส่วนสุดท้ายเท่านั้น "ขึ้นอยู่กับ" จากประสบการณ์ของฉัน ~ 16 ปีหรือมากกว่านั้นฉันเห็นตัวเลือกทั้งสองพยายามในการกำหนดค่าที่หลากหลาย เป็นนักพัฒนาสแต็คเต็มรูปแบบด้วยตัวเองนี่คือสิ่งที่ฉันได้เรียนรู้:

* (BE = Back End, FE = Front End)

Caveats ทั่วไปของการพัฒนา Stack Stack:

1. แนวทางการพัฒนาแบบ Agile (เป็นกลยุทธ์ที่ใช้กันทั่วไปในปัจจุบัน) แนะนำการพัฒนาคุณลักษณะโดยที่ฟีเจอร์นี้เป็นเพียงชัคอันมีค่าเดียวของการทำงานจากมุมมองของลูกค้า จากมุมมองนี้คุณควรให้ผู้พัฒนาใช้ทั้งสองอย่าง

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

3. ใช้กฎการสื่อสาร n (n-1) / 2 จาก Mythical Man-Month และคุณจะเห็นว่าคุณสมบัติการแยกในสองส่วนระหว่างคนสองคนจะเพิ่มภาระงานโดยรวมของคุณ ได้รับกฎนั้นนำไปใช้กับคุณสมบัติเช่นกัน แต่การแบ่งสแต็กเป็นสองเท่าของปริมาณการสื่อสาร

4. นักออกแบบจะแก้ปัญหาของนักพัฒนา พ.ศ. ไม่สามารถสร้างอินเทอร์เฟซที่น่าสนใจตั้งแต่เริ่มต้น สิ่งนี้จะถือว่าพวกเขารู้อย่างน้อย html & css และสามารถสร้างอินเทอร์เฟซที่ตรงกับภาพหน้าจอที่สร้างโดยนักออกแบบ

5. โดยทั่วไปแล้วฟีเจอร์จะเป็นส่วนประกอบที่แยกได้ซึ่งมีปฏิสัมพันธ์กับคุณสมบัติอื่นน้อยมาก นี่ไม่ใช่กรณีเสมอไป แต่โดยทั่วไปแล้วจุดติดต่ออยู่ที่ระดับต่ำเช่นฐานข้อมูลหรือระบบไฟล์ ดังนั้นจึงไม่มีอะไรมากที่จะป้องกันไม่ให้นักพัฒนาเต็มสแต็คนำคุณลักษณะของพวกเขาไปใช้ แต่ถ้านักพัฒนา FE ต้องรอให้นักพัฒนา BE ทำงานให้เสร็จมันจะเพิ่มความล่าช้ามากขึ้นในการสูญเสียประสิทธิภาพในจุดที่ 3

6. Web2.0 ทำให้เห็นความแตกต่างระหว่าง FE และ BE ได้ดียิ่งขึ้น ด้วยกรอบงาน MVC และแอปพลิเคชันทั้งหมดที่สร้างขึ้นบนฝั่งไคลเอ็นต์จึงต้องมีความรู้เรื่อง BE อย่างมากในการใช้งานแอปพลิเคชัน FE ที่ปลอดภัยและมีประสิทธิภาพ

7. สิ่งสำคัญที่สุดของฉันที่มีต่อการปฏิบัตินี้คือมันจำกัดความสามารถของทุกคนที่เกี่ยวข้องในโครงการ แม้ว่านี่จะเป็นวิธีปฏิบัติทั่วไปในต้นปี 2000 แต่ก็มีความจำเป็นเนื่องจากการค้นหานักพัฒนาที่สามารถทำทั้งสองอย่างนั้นค่อนข้างยาก (หมดจดเพราะความเป็นคนใหม่ไม่ใช่เพราะความยากลำบากในการเรียนรู้ทั้งสองอย่าง) สิ่งที่เหลืออยู่ของการฝึกฝนคือ ทศวรรษต่อมาเรายังมี "นักพัฒนาเว็บ" ที่ไม่รู้จัก CSS

8. Gripe ที่ใหญ่เป็นอันดับสองของฉันคือมันสามารถแบ่งกลุ่มทีมพัฒนาได้อย่างง่ายดาย นักพัฒนา FE สร้างบั๊กหลังจากแก้ไขโค้ด BE และโหวตทีมเพื่อ จำกัด การพัฒนาข้ามสแต็ก ในขณะที่ความคิดเห็นและการศึกษารหัสสามารถแก้ไขปัญหาคนกลายเป็นดินแดนแทน

ประโยชน์ / กรณีการใช้งานของการพัฒนา Stack Stack:

1. API ของ RESTful นั้นสมบูรณ์แบบสำหรับการวิเคราะห์นี้เนื่องจากไม่มี FE บ่อยครั้งที่ บริษัท จะทำงานกับ RESTful API ก่อนจากนั้นจึงพัฒนาเว็บแอปพลิเคชันของพวกเขาขึ้นมา ในกรณีนี้มีกรณีที่ดีในการรักษาทีม BE ให้ความสำคัญกับรุ่นใหญ่ต่อไปในขณะที่ FE กำลังจบแอปพลิเคชัน แต่อันตรายของการปั่นยังคงมีอยู่ - โดยเฉพาะอย่างยิ่งหากข้อมูลใหม่ที่ค้นพบในระยะ FE dev ต้องมีการดัดแปลง BE API แบบไม่สำคัญ

2. ปริมาณงานที่ไม่สมดุลระหว่าง FE & BE ก็เป็นกรณีที่ดีสำหรับการสร้างทีม FE เท่านั้น นี่เป็นสถานการณ์ที่อาจเกิดจากการพัฒนาหลักผ่านแอปพลิเคชันเดสก์ท็อปและ บริษัท พยายามที่จะพัฒนาเว็บอินเตอร์เฟส 'lite'

3. ฝึกอบรมนักพัฒนาใหม่ / รุ่นจูเนียร์ หากคุณกำลังจ้างฝึกงานหรือผู้พัฒนารุ่นเยาว์และมีความกังวลเกี่ยวกับการทิ้งไว้ในส่วนลึกมันเป็นตัวเลือกที่ดีในการลงทุนค่าใช้จ่ายในการสื่อสาร / การรวมเข้ากับระบบการพัฒนาแบบเพื่อน

ความกังวลเกี่ยวกับคำตอบที่ยอมรับของ @ Ralf ในหน้านี้:

1. ประเด็นแรกคือตัวหนา - และจะล้มเหลวอย่างรวดเร็วหากคุณไม่มี "ทีมจัดระเบียบตัวเองที่ดี" แม้ว่าคุณจะมีทีมนั้นอยู่ในความสนใจของคุณและพวกเขาที่จะผลักดันขอบเขตของพวกเขา และทีมจัดระเบียบตนเองที่ดีนั้นไม่ได้มีแรงจูงใจให้ทำเช่นนั้นเสมอไป

2. จุดที่สองของคุณผิด การพัฒนาเว็บสมัยใหม่ต้องใช้รหัส FE ที่มีประสิทธิภาพความปลอดภัยความปลอดภัยแบบอะซิงโครนัสการพิสูจน์ XSS ข้ามเบราว์เซอร์และการพัฒนาอย่างรวดเร็ว เป้าหมายไม่สามารถแข่งขันกับ BE ได้อย่างเท่าเทียมกัน

3. ประเด็นที่สามก็เป็นข้อสมมติฐานที่ไม่ดีเช่นกันการพัฒนา FE สามารถเริ่มต้นด้วย html / css / js ที่บริสุทธิ์โดยไม่ต้องมีงานรากฐาน จากตรงนั้นเป็นเพียงความพยายามเล็กน้อยที่จะแยกย่อยเป็นเทมเพลตสำหรับการเรนเดอร์ BE บ่อยครั้งที่การเริ่มต้นทำงานกับ FE นั้นดีที่สุดเพราะจะทำให้ผู้มีส่วนได้ส่วนเสียรู้สึกอบอุ่นและคลุมเครือเพื่อดูความก้าวหน้าทางสายตา

สรุป:

หากคุณเป็นผู้เริ่มต้นและคุณไม่มีเวลาหรือเงินจำนวนมากในการเขียนอย่าจ้าง FE หรือเป็นนักพัฒนาเท่านั้น จ้างนักพัฒนาเว็บระดับสูงและนักออกแบบ / นักออกแบบที่ดีและพวกเขาจะทำให้ใบสมัครของคุณปิดเร็วที่สุด พวกเขามีค่าใช้จ่ายมากกว่า แต่ก็มีประสิทธิภาพมากกว่าและคุณจะต้องน้อยกว่า

ฉันคิดว่าคำถามนั้นผิด

ผู้ที่เพิ่งเริ่มต้นทั้งหมดที่ฉันเข้าร่วมไม่มีสถาปัตยกรรม FE-BE เท่านั้น

ที่เพิ่งเริ่มต้นส่วนใหญ่ฉันรู้ว่ามี:

• หลัก - ผลิตภัณฑ์จริงที่แสดงถึงส่วนต่อประสาน
• UI - BE และ FE BE ใช้ API ของ Core

API นั้นไร้สัญชาติและเยาะเย้ยอย่างง่ายดาย - โดยไม่ต้องใช้ Core Developer นรกถ้าฉันต้องเริ่มต้นโครงการตั้งแต่เริ่มต้นฉันอาจเริ่มต้นด้วย UI ทั้งหมดที่ใช้งานได้จริงกับ mocks - ซึ่งเหมาะสำหรับการนำเสนอ ความคิดเห็นส่วนใหญ่เกิดจาก UI ลูกค้าทราบเพิ่มเติมว่า - (ขึ้นอยู่กับกลุ่มเป้าหมายของคุณ)

ตัวอย่างเช่น - Google Search มีองค์ประกอบหลักที่รวบรวมข้อมูลเว็บจัดทำดัชนีเป็นต้นและ Google UI เป็นโลกที่แตกต่างอย่างสิ้นเชิง หลักนี้สามารถรองรับการค้นหาที่ไม่ใช่ WWW ได้อย่างง่ายดายในขณะที่ UI ไม่สามารถทำได้

วิธีนี้ UI ของคุณ "สามารถเสียบได้" และคุณมีข้อกังวลมากมาย

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

ภาษาต่างกัน คุณอาจต้องการนักพัฒนา C สำหรับองค์ประกอบหลัก - และคุณจะโอเคถ้ามันทำงานบนระบบปฏิบัติการเดียวซึ่งเป็นที่ UI จะถูกเขียนในภาษา Cross OS

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

Open Source UI - หนึ่งในประโยชน์ที่ยิ่งใหญ่ที่สุดของการแยกทั้งสองคือคุณสามารถเปิดแหล่ง UI ของคุณ โครงการ UI ต้องการการสนับสนุนโอเพ่นซอร์ส

ฉันไม่สามารถจินตนาการนักพัฒนา UI ที่ไม่สามารถเข้าใจคุณสมบัติทั้งหมด sessionได้ คุณรู้ - ที่คุณเข้าสู่ระบบและอยู่ในระหว่างการร้องขอที่แตกต่างกัน จริงพวกเขาอาจรู้จัก PHP และไม่ใช่ Java .. แต่แนวคิด BE ควรชัดเจน (เช่นใช้คุกกี้เข้ารหัส) อุปสรรคด้านภาษาเฉพาะนั้นผิด - นักพัฒนาทุกคนควรเต็มใจทำงานในทุกภาษา ใครจะคิดว่าพวกเขาจะเขียน BE ใน JavaScript เมื่อสองสามปีก่อน

หากคุณมีทีม 3 ทีม: Core, BE และ FE มันเป็นการสิ้นเปลืองทรัพยากร แล้ว DB ล่ะ คุณควรจะมี DBA หรือไม่ เหตุใดนักพัฒนา พ.ศ. ควรรู้จัก DB และนักพัฒนา FE ไม่รู้จัก BE และ DB ไม่มีขีด จำกัด

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

ดังนั้นผลลัพธ์จึงเป็น BE ที่บางมากใน UI ที่นักพัฒนา FE ทุกคนสามารถพัฒนาได้ หากคุณมี BE อย่างหนาใน UI คุณอาจจำเป็นต้องมีฟังก์ชั่น API บางอย่างใน Core

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

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

ยังมีคำถามอยู่ - FE และควรเป็นโครงการเดียวกันหรือไม่ คุณควรสังเกตสิ่งต่อไปนี้

• ทรัพยากรคงที่จะให้บริการที่ดีที่สุดจากเซิร์ฟเวอร์หน้า เนื่องจากเซิร์ฟเวอร์ Front-End (เช่น nginx) มีประสิทธิภาพมากและเนื่องจากคุณสามารถใช้ Cache สำหรับทรัพยากรแบบคงที่คุณสามารถจัดการด้วยการปรับใช้ทรัพยากรแบบคงที่เพียงครั้งเดียว (ซึ่งควรเป็นเนื้อหา HTML ทั้งหมด, JS, CSS, รูปภาพ)
• รหัสแบ็กเอนด์ไม่มีสินค้าฟุ่มเฟือยเหมือนกันดังนั้นคุณต้องมีระบบแบบกระจายซึ่งจัดการโดยเซิร์ฟเวอร์หน้า
• รหัส FE นั้นจะนำกลับมาใช้ใหม่กับเทคโนโลยีใหม่ทั้งหมดที่รองรับ JavaScript ตอนนี้คุณสามารถเขียนแอปพลิเคชันเดสก์ท็อปและมือถือด้วย JavaScript
• กระบวนการสร้างแตกต่างอย่างสิ้นเชิง - และยังสามารถรวมการส่งแพตช์การอัพเกรดการติดตั้งและอื่น ๆ

ฉันสามารถไปต่อได้ แต่ฉันหวังว่ามันชัดเจนว่าฉันคิดว่า BE และ FE ควรเป็นทีมเดียวกัน แต่อาจมีโครงการที่แตกต่างกัน

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

มันคือทั้งหมดที่ให้และรับ แต่อย่าปล่อยให้ความร่วมมือของนักพัฒนาสองคนทำให้คุณลังเล มีวิธีการทดลองและจริงเพื่อเพิ่มประสิทธิภาพการผลิตสูงสุดระหว่างนักพัฒนาและนักออกแบบ

ในคำอื่น ๆ ... มันขึ้นอยู่กับ