ส่วนหน้าสุดก่อนหรือหลังสุดก่อน ในสองข้อไหนที่เป็นระบบการออกแบบที่ดี?

ฉันมีลูกค้าตอนนี้ต้องการให้ฉันพัฒนาระบบการลงทะเบียนของโรงเรียน ตอนนี้เป็นครั้งแรกที่ฉันมีความท้าทายแบบนี้ ซอฟต์แวร์ที่ผ่านมาส่วนใหญ่ที่ฉันสร้างไม่ซับซ้อน

ฉันรู้ว่าพวกคุณส่วนใหญ่ได้สร้างซอฟแวร์ที่ซับซ้อนฉันแค่ต้องการคำแนะนำของคุณเกี่ยวกับเรื่องนี้ ฉันควรออกแบบส่วนหน้าหรือส่วนหลังก่อนหรือไม่

ขอบคุณ!

นี่คือข้อสรุปของบทความที่ฉันพบในอินเทอร์เน็ตเมื่อไม่นานมานี้ แค่ต้องการแบ่งปัน

http://www.skitoy.com/p/front-end-vs-back-end-developers-my-take/157

นักพัฒนา Front-End และ Back-End (ใช้ของฉัน)

ส่วนตัวของฉัน

เป็นเรื่องของการฝึกอีกครั้งการสรุปทั่วไปของโรคหลอดเลือดสมองในวงกว้าง:

นักพัฒนาส่วนหน้า

• โดยทั่วไปแล้วจะไม่มีระดับ CS หรือมีระดับ CS จากโรงเรียนชั้นที่ 3
• ทำงานในภาษาที่คล้ายกับพื้นฐาน (ดู PHP เป็นพื้นฐาน)
• มีทักษะการมองเห็นในการแปลงเอกสาร Photoshop เป็น CSS / HTML / ฯลฯ
• มีความอดทนสูงสำหรับการเขียนโปรแกรมซ้ำเนื่องจากภาษาฟรี

นักพัฒนาส่วนหลัง

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

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

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

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

ที่กล่าวมาหากเป็นโครงการขนาดใหญ่ที่คุณต้องพิจารณาฮาร์ดแวร์เซิร์ฟเวอร์หรือความสามารถของซอฟต์แวร์ใด ๆ ที่คุณใช้ (เช่นฐานข้อมูลที่คุณใช้) คุณควรมีความคิดที่ดีเกี่ยวกับส่วนนั้นก่อน

ซอฟต์แวร์มีหลายมิติดังนั้น front-vs-simplistic สุดเหวี่ยงจึงเป็นคำถามที่ไม่ดีและเป็นเรื่องยากมากที่จะให้คำตอบที่สมเหตุสมผลและมีประโยชน์

มุมมองหนึ่งคือโครงสร้างแบบคงที่ของข้อมูล มีอย่างน้อยสามมิติในมุมมองนี้: เลเยอร์สถาปัตยกรรม ("front-to-back") ใช้เคสและนักแสดงรวมถึงต้นทุนหรือความเสี่ยงของการใช้งาน

มุมมองเดียวคือโครงสร้างแบบไดนามิกของการประมวลผล มุมมองนี้มีอย่างน้อยสามมิติ

มุมมองที่สามคือองค์ประกอบทางสถาปัตยกรรมซึ่งแบ่งเป็นเลเยอร์ตามธรรมชาติรองรับการใช้เคสและมีค่าใช้จ่ายและความเสี่ยง

ฉันสามารถไปต่อได้ แต่ประเด็นคือ

นักพัฒนา Front-End และ Back-End (ใช้ของฉัน)

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

• ใช้เคสและนักแสดง

• โมเดลข้อมูลโลจิคัลเพื่อสนับสนุนเคสการใช้งานเหล่านั้น

• กระบวนการที่ทำขึ้นเป็นส่วนหนึ่งของกรณีการใช้งาน

• ส่วนประกอบที่คุณจะใช้เพื่อสร้างองค์ประกอบทางตรรกะและการประมวลผลของกรณีการใช้งาน

นี่คือเหตุผลที่คนส่วนใหญ่บอกว่าคุณต้องย่อยสลายระบบของคุณตามเรื่องราวของผู้ใช้หรือกรณีการใช้งาน

ไม่ทำภาพรวมทั่วไปเกี่ยวกับคนที่จะทำการพัฒนา

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

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

แต่ไม่ว่าคุณจะทำอะไรอย่าปล่อยให้การออกแบบของคนใดคนหนึ่งสั่งการออกแบบของอีกคนหนึ่ง ความบ้าคลั่งแบบนั้น

รับเครื่องมือในการให้ devs ของคุณสร้างสิ่งที่พวกเขาต้องการสำหรับลูกค้าของคุณไม่ว่าพวกเขาจะเปลี่ยนใจกี่ครั้งก็ตาม จากนั้นสร้างมันขึ้นมาตามข้อมูลจำเพาะและ rejigger จนกระทั่ง cusses ตัวน้อยมีความสุขในที่สุด

นอกจากนี้การเปรียบเทียบส่วนหน้า devs กับส่วนท้าย devs ในปี 2008 เป็นเวลานานแล้วในเว็บปี เพื่อความสนุกสนานฉันต้องการแก้ไข / เพิ่มบางสิ่งกับเกาลัดเก่านั้นเนื่องจากเราได้เชื่อมโยงคำถามเข้าด้วยกัน แต่หวังว่าจะฝังเคล็ดลับภายใน:

นักพัฒนาส่วนหน้า

โดยทั่วไปแล้วจะไม่มีระดับ CS หรือมีระดับ CS จากโรงเรียนชั้นที่ 3

โชว์มือ มีกี่คนที่ได้รับการศึกษาระดับปริญญา CS ได้รับการสอนวิธีปฏิบัติที่ดีที่สุดในส่วนหน้า? หรือวิธีการไม่ยุ่งกับ JavaScript? หรือวิธีจัดการกับปัญหา CSS จาก IE6-IE9 อุตสาหกรรมตำราเรียนซึ่งดำเนินการด้านวิชาการมีความเกียจคร้านและป่องอ้วนที่จะจัดการกับเทคโนโลยีที่เปลี่ยนแปลงตลอดเวลาดังนั้นจึงได้รับความสนใจอย่างจริงจังในวิทยาลัย นี่เป็นสิ่งที่ยอดเยี่ยมมากสำหรับคนที่ชอบออกแรงช้าเหมือนตัวเอง

ทำงานในภาษาที่คล้ายกับพื้นฐาน (ดู PHP เป็นพื้นฐาน)

เพราะ PHP เป็นเทคโนโลยีของลูกค้า? หรือเพราะ JavaScript ซึ่งได้รับแรงบันดาลใจมาจาก Scheme นั้นมีความเหมือนกันมากกว่ากับ Basic แล้ว Visual Basic ซึ่งตอนนี้ไม่ได้มีความกังวลต่อเนื่องในส่วนหน้าและไม่เคยเป็นจริง แต่ยังมีให้สำหรับเว็บแอพพลิเคชัน. NET บล็อกนี้เปรียบเทียบนักพัฒนาเว็บโอเพ่นซอร์สที่เรียนรู้ด้วยตนเองกับนักพัฒนาเว็บ CS Grad โดยใช้เทคโนโลยีที่เป็นที่นิยมขององค์กร ณ จุดนี้ฉันคิดว่า ฉันวิ่งเข้าหาไม่ได้และมีความสามารถในการแบ่งเท่า ๆ กันทั้งสองด้านของการต่อสู้นั้น แต่เขาก็ยังคงอยู่ที่ OT

มีทักษะการมองเห็นในการแปลงเอกสาร Photoshop เป็น CSS / HTML / ฯลฯ

ให้ความสำคัญกับรายละเอียดมากกว่า "ทักษะการมองเห็น" ซึ่งค่อนข้างกว้าง เราทุกคนไม่ได้มีทักษะการออกแบบที่สวยงามใด ๆ แต่ใช่พวกเราส่วนใหญ่ต้องเรียนรู้สิ่งนี้ในระดับจูเนียร์และเป็นเรื่องสำคัญอย่างยิ่งที่จะต้องเขียน UI ที่ดีซึ่งไม่ได้ใช้ JS hammers เมื่อ scalpels CSS จะทำ

มีความอดทนสูงสำหรับการเขียนโปรแกรมซ้ำเนื่องจากภาษาฟรี

นี่คือเหตุผลที่คุณต้องการชิ้นที่ฉันพูดถึงก่อนหน้านี้ในสถานที่แรก เราส่งผ่านปุ่มกดที่คุณผลิต / ดึงสินค้า เราบรรจุและส่งมอบพวกเขา ไม่มีเหตุผลใดที่สิ่งเหล่านี้จะผูกพันกันอย่างแน่นหนา นอกจากนี้จริงๆแล้วการพิมพ์ที่เข้มงวดไม่ควรเข้าไปยุ่งกับกระบวนการวนซ้ำหากคุณไม่สนใจ OOP ซึ่งคนส่วนใหญ่ที่ชอบดูถูกดูแคลนเกี่ยวกับภาษาที่ไม่มีเทคนิคในการเรียนจริง ๆ แล้วโดยทั่วไปแล้ว แต่ถึงแม้ว่าพวกเขาจะเหม็นปลายด้านหน้าต้องการเพียงจุดเข้าถึงที่คาดเดาได้และคุณสามารถทำสิ่งที่ heck คุณต้องการใน back end ตราบใดที่คุณไม่ทำอะไรโง่ ๆ เช่นเขียนจาวาสคริปต์แบบไดนามิกที่ไม่ใช่ JSON หรือ ผูกพฤติกรรมแบ็คเอนด์ที่ประสบความสำเร็จไว้กับโครงสร้าง HTML อย่างแน่นหนาว่าเป็น "เพียงแค่นั้น" * แก้ไอ * java devs * / แก้ไอ *

ไม่มีคำตอบที่ถูกต้องสำหรับสิ่งนี้ วิธีการอย่างใดอย่างหนึ่งอาจดี (และไม่ดี) ในบางสถานการณ์

ฉันแนะนำให้คุณพิจารณาวิธีการของ TDD โดยที่การทดสอบ (การยอมรับและหน่วย) นำไปสู่

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

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

สำหรับวิธีนี้แนะนำให้อ่านจะเติบโตซอฟต์แวร์เชิงวัตถุ, Guided โดยการทดสอบ

API ก่อน

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

ใช้ร่วมกับวิธีการวนซ้ำและควรมีลักษณะเช่นนี้:

1. ออกแบบ API อย่างง่าย
2. ทั้งสองทีมพัฒนาและทดสอบตาม API
3. การทดสอบบูรณาการ
4. แสดงให้กับลูกค้าและรับข้อเสนอแนะ
5. ปรับปรุง API และทำซ้ำ

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

เข้าใจถึงความคาดหวังด้านความปลอดภัยอย่างเต็มที่และสิ่งที่กฎหมายกำหนด ไม่แน่ใจว่าเป็นโรงเรียนประเภทใด แต่ข้อมูลนักเรียนมักจะต้องมีการรักษาความลับ

หากนักเรียนที่มีศักยภาพกำลังป้อนข้อมูลบนเว็บไซต์การออกแบบกราฟิกจะเป็นปัญหามากขึ้น

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

จากนั้นคุณสามารถเริ่มรับข้อมูลที่เก็บอยู่ในฐานข้อมูล

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

ขยายความคิดเห็นของฉัน:

ก่อนรวบรวมความต้องการจากนั้นเปลี่ยนพวกเขาเป็น Use Cases & design

ก่อนมานิยามฐานข้อมูลโดยละเอียด ฉันไม่สนหรอกว่าลูกค้าจะไม่คลุ้มคลั่งหรือเปล่าฉันบังคับให้พวกเขานั่งลงและมองดู - และลงชื่อมัน ) ก่อนดำเนินการต่อ

คุณจะเริ่มต้นด้วย FE โดยไม่ต้องเป็นอย่างไร FE เพื่ออะไร ??? กำหนดฐานข้อมูลของคุณ !! นั่นคือสิ่งที่ FE ดำเนินการ

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

อย่างไรก็ตามฉัน 1) เน้นว่านี่เป็นเพียงการเยาะเย้ยถากถางสำหรับการสนทนาปลาโลมาและ 2) จงใจทำให้มันน่าเกลียดแต่ก็ใช้งานได้เพื่อให้ผู้ที่ไม่เข้าใจสามารถพิศมัยและบอกให้ฉันทำกล่องอินพุตตรง 400px กว้าง & พื้นหลังสีฟ้าอ่อน

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