วิธีจัดการกับวิธีการที่ยังไม่ได้ใช้งานซึ่งจะทำโดยผู้ร่วมโปรแกรม?


45

นี่เป็นคำถามเกี่ยวกับวิธีการทำงานเป็นทีม

เมื่อไม่นานมานี้ฉันทำงานโครงการเขียนโปรแกรม Java ขนาดใหญ่กว่า ~ 80 คลาสกับทีมงาน 6 คน แต่มีเพียง 4 คนเท่านั้นที่ทำงานกับโค้ดอย่างต่อเนื่อง เราแจกจ่ายงานที่ต้องทำก่อนเวลาและในบางจุดฉันจำเป็นต้องเรียกวิธีการที่ยังไม่ได้นำมาใช้โดยหนึ่งในโปรแกรมเมอร์ร่วมของฉัน วิธีที่แนะนำในการจัดการกับสิ่งนี้คืออะไร?

ตัวเลือกที่ฉันเห็นแม้ว่าฉันจะไม่ชอบพวกเขาจริงๆ:

  1. เขียนตัวเอง//TODOและทบทวนบรรทัดของรหัสนี้ในภายหลังเพื่อตรวจสอบว่าวิธีการที่ได้รับการดำเนินการในระหว่างนี้

  2. ขอให้สมาชิกในทีมที่สอดคล้องกันในการดำเนินการว่าในขณะนี้

  3. การเปิดใช้งาน runtimeException แบบกำหนดเองพร้อมคำอธิบายที่ชัดเจนเกี่ยวกับสิ่งที่ยังไม่ได้ใช้งาน (อย่างน้อยเราไม่ต้องค้นหาเป็นเวลานานเพื่อค้นหาว่ามีอะไรขาดหายไป)

  4. การเพิ่มวิธีการที่จำเป็นในชั้นเรียนของพวกเขาและเขียนพวกเขา//TODOในเนื้อหาของข้อความอาจส่งข้อความด่วนเกี่ยวกับการเปลี่ยนแปลงนั้นให้พวกเขา (ตอนนี้ไม่ใช่ปัญหาของฉันอีกต่อไป แต่อาจทำให้เกิดข้อขัดแย้งในการรวมที่น่ารำคาญได้หากพวกเขาใช้วิธีนี้ในระหว่างนี้)

  5. การกำหนดคลาสหรืออินเทอร์เฟซแบบนามธรรมสำหรับทุกสิ่งก่อนเขียนโค้ดที่ใช้งานได้จริง (ทำงานได้ไม่ดีนักเนื่องจากอินเทอร์เฟซเหล่านี้มักจะเปลี่ยนไป)


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

8
@Eehoric มีหลายครั้งที่ฉันเจอสถานการณ์ที่มีฟีเจอร์ใหม่ที่ค่อนข้างใหญ่ที่จะต้องพัฒนาภายในระยะเวลาอันสั้นและเช่นอินเทอร์เฟซผู้ใช้ตรรกะทางธุรกิจและเลเยอร์ API จะต้องถูกแบ่งออกเป็นงานต่าง ๆ เพื่อทำงานพร้อมกัน ไม่เช่นนั้นจะไม่มีวันครบกำหนด นั่นคือสิ่งที่บุคคลที่ทำงานกับ UI ควรประกาศวิธีการเข้าถึงข้อมูลและคำสั่งไปยัง BL เป็นอินเทอร์เฟซและให้คนอื่นทำงานกับการใช้งานในขณะที่ทำงานกับ UI เท่านั้น
Andy

15
@DavidPacker สิ่งที่คุณอธิบายไม่ใช่วิธีเดียวในการแก้ไขปัญหานั้น คุณสมบัติชิ้นเล็ก ๆ ทั้งหมดเป็นโซลูชั่นที่ดีกว่าชิ้นส่วนแนวตั้งโดยแต่ละคนทำงานแยกส่วน
ร่าเริง

3
@Ehorhor ฉันไม่สามารถตกลงกับคุณมากขึ้น เมื่อเป็นไปได้เราจะไปกับการลอกคุณสมบัติใหม่ที่ซับซ้อนของชิ้นส่วนที่ไม่สำคัญ (เช่นที่จะปรับปรุง UX เท่านั้น แต่ไม่จำเป็นทันที) น่าเศร้าที่บางครั้งตัวเลือกที่คุณกล่าวถึงไม่สามารถลอกคุณสมบัติได้ นักธุรกิจบอกว่าทำ ดังนั้นในขณะที่คะแนนของคุณมั่นคงมีความเป็นไปได้ที่จะมีคนบางคนและจะต้องเผชิญกับสถานการณ์ที่ต้องมีการแบ่งฟีเจอร์บางอย่างเพื่อตอบสนองความต้องการของธุรกิจ
Andy

2
สิ่งที่เกี่ยวกับการพูดคุยกับเขาว่าเขาต้องการที่จะจัดการกับมันได้หรือไม่
Aganju

คำตอบ:


5

มันเป็นคำถามที่น่าสนใจและคำตอบอาจง่ายกว่าที่คุณคิด

เพียงแค่ใส่เขียนการทดสอบที่ตรวจสอบสมมติฐานของคุณ มันไม่สำคัญว่าคุณจะดำเนินการหรือโปรแกรมเมอร์เพื่อนของคุณ

คำตอบที่ยาว

ตัวเลือกใด ๆ ที่คุณทำรายการค่อนข้างแฝงและต้องการให้คุณกลับมาใหม่และทบทวนรหัส (หากมีอยู่) ไม่ช้าก็เร็ว

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

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

  1. TDD - การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ - สิ่งนี้จะช่วยให้แน่ใจว่าคุณอธิบายเจตนาของคุณและทดสอบอย่างเพียงพอ นอกจากนี้ยังช่วยให้คุณมีความเป็นไปได้ที่จะจำลองหรือวิธีการและชั้นเรียนปลอม (รวมถึงโดยใช้อินเทอร์เฟซ) ที่ยังไม่ได้ใช้งาน รหัสและการทดสอบจะยังคงรวบรวมและอนุญาตให้คุณทดสอบรหัสของคุณเองโดยแยกรหัสเพื่อนโปรแกรมเมอร์ของคุณ (ดู: https://en.wikipedia.org/wiki/Test-driven_development )

  2. ATDD - การพัฒนาที่ได้รับการยอมรับการทดสอบ - สิ่งนี้จะสร้างลูปรอบนอก (รอบลูป TDD) ซึ่งช่วยให้คุณทดสอบคุณสมบัติโดยรวม การทดสอบเหล่านี้จะเปลี่ยนเป็นสีเขียวเมื่อมีการใช้งานคุณลักษณะทั้งหมดดังนั้นจึงให้ตัวบ่งชี้อัตโนมัติเมื่อเพื่อนของคุณทำงานเสร็จ ค่อนข้างเรียบร้อยถ้าคุณถามฉัน

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

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

หากคุณต้องการได้รับเพิ่มเติมในหัวข้อนั้นตรวจสอบลิงค์ต่อไปนี้:


103

ขอต้นขั้ว

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


25
^^ นี่ หากคุณใช้อินเทอร์เฟซอย่างถูกต้องคุณไม่ควรใช้งานจนกว่าคนอื่นจะเขียนเสร็จ
Robert Harvey

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

1
น่าเสียดายที่ Java ไม่มีไฟล์ส่วนหัว ในโลก C / C ++ คุณสามารถทำงาน API ของคุณและเขียนส่วนหัวทั้งหมดของคุณก่อนการขาดการใช้งานจึงกลายเป็นปัญหาสำหรับตัวเชื่อมโยง (การทำให้เข้าใจง่ายเล็กน้อย ABI จำเป็นต้องคงที่เช่นกันเพื่อให้เป็นเพียงตัวเชื่อมโยง)
Wes Toleman

16
@WesToleman อย่างน่าประหลาดใจหนึ่งในสิ่งที่ฉันชอบเกี่ยวกับ Java คือมันไม่มีไฟล์ส่วนหัว "อินเตอร์เฟส" ที่ Robert และ corsiKa พูดถึงเติมบทบาทนั้นอย่างสมบูรณ์ คุณต้องทำงานกับ API ของคุณก่อนเขียนอินเทอร์เฟซและการขาดการนำไปปฏิบัติที่เป็นรูปธรรมไม่ใช่ปัญหาสำหรับคอมไพเลอร์
GrandOpener

1
@WesToleman มันทำงานได้ดีสำหรับคุณหรือไม่? ในหูของฉันที่ฟังดูเหมือนตกแบบน้ำและฉันเดาว่าคุณต้องอัปเดตอินเทอร์เฟซให้มากขึ้นเมื่อคุณรู้ว่าคุณได้ "พารามิเตอร์สำคัญ" ที่ผิดพลาด?
netigger

6

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

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


คุณควรขอAPIสำหรับฟังก์ชั่นนั้นซึ่งจะส่งผลให้หนึ่งหรือมากกว่าหนึ่งอินเตอร์เฟส อาจเป็นความคิดที่ดีที่จะทำสิ่งนี้ร่วมกันเนื่องจากคุณจะต้องใช้อินเทอร์เฟซนี้เพื่อให้คุณสามารถออกแบบกรณีทดสอบเบื้องต้นตามอินพุตของคุณ การใช้งานจริงนั้นสามารถเกิดขึ้นได้ในภายหลัง (รวมถึงการเปลี่ยนแปลง API ที่เป็นไปได้)
Thorbjørn Ravn Andersen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.