นักพัฒนาส่วนหน้าควรระบุรูปแบบ JSON สำหรับนักพัฒนาส่วนหลังหรือไม่

17

ฉันใช้บทบาทส่วนหน้าในโครงการ ฉันควรระบุเพื่อนร่วมทีม back-end ของฉันในรูปแบบที่แน่นอนของ JSON ที่ PHP ของพวกเขากลับไปที่ JavaScript ของฉันหรือไม่

ตัวอย่างเช่นฉันควรบอกพวกเขาว่าพวกเขาควรใช้รูปแบบคล้ายกับที่อธิบายไว้ที่นี่:

วิธีที่เหมาะสมในการจัดโครงสร้าง JSON สำหรับการใช้งานส่วนหน้า

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

— LazerSharks
แหล่งที่มา

10

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

— Doug T.

นั่นทำให้รู้สึก!

— LazerSharks

4

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

— gnasher729

2

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

— Steve Jessop

42

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

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

— grahamparks
แหล่งที่มา

1

นั่นทำให้รู้สึก! สงสัยว่าเกิดอะไรขึ้นในโลกแห่งการพัฒนา

— LazerSharks

5

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

— AE

9

คุณควรมีส่วนร่วมในการกำหนดรูปแบบและโครงสร้างของ JSON อย่างชัดเจน ฉันเห็นมันบ่อยกว่าที่วิศวกร front-end ผู้ใช้ API เป็นคนที่รู้ว่าโครงสร้างข้อมูลควรเป็นอย่างไร

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

— aludvigsen
แหล่งที่มา

3

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

หากคุณอยู่ในทีมเล็ก ๆ ให้หลีกเลี่ยงเผด็จการ: มีการประชุมอย่างรวดเร็วกับทุกคนเพื่อใช้โปรโตคอล

ทีมขนาดกลางอาจต้องการมีตัวแทนที่ทำงานออกโปรโตคอล

ทีมขนาดใหญ่และ / หรือทีมที่มีองค์กรที่ซับซ้อนควรมีคนมิดเดิลแวร์เฉพาะเพื่อควบคุมโปรโตคอล

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

ฉันขอแนะนำให้ทดสอบทั้งไคลเอนต์และฝั่งเซิร์ฟเวอร์และการทดสอบระบบเพื่อให้แน่ใจว่าสอดคล้องกับเอกสาร

อาจดูเหมือนงานมาก แต่การทำผิดเล็กน้อยที่นี่อาจมีราคาแพงและใช้เวลามาก

— Jeffery Thomas
แหล่งที่มา

อามีความสุขที่ได้เรียนรู้ว่ามีโลกทั้งใบที่อุทิศให้กับเรื่องนี้ ฉันคิดว่าแง่มุมนี้ดูเหมือนว่ายางเข้ามาถึงถนนจริงๆในแง่ของการแบ่งระหว่าง front-end และ back-end

— LazerSharks

1

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

คุณรู้ว่ามีคำว่า "ถ้าคุณต้องการที่จะไปคนเดียวอย่างรวดเร็วถ้าคุณต้องการที่จะไปด้วยกัน"

— Glassfish
แหล่งที่มา