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


71

หนึ่งในเพื่อนร่วมทีมของฉันคือแจ็คของการซื้อขายทั้งหมดในร้านค้าไอทีของเราและฉันเคารพความเข้าใจของเขา

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

ในบางครั้งเขาได้ทำการปรับปรุงโค้ดของฉันที่มีอายุ 3 เดือนขึ้นไปโดยไม่จำเป็น

ทำให้ฉันรำคาญด้วยเหตุผลบางประการ:

  1. ฉันไม่ได้รับโอกาสแก้ไขข้อผิดพลาดเสมอไป
  2. เขาไม่ได้ใช้เวลาถามฉันว่าฉันพยายามทำอะไรเมื่อเขาสับสนซึ่งอาจส่งผลต่อการทดสอบหรือการเปลี่ยนแปลงของเขา
  3. ฉันไม่คิดว่ารหัสของเขาจะอ่านได้เสมอ
  4. กำหนดเวลาไม่ใช่ปัญหาและภาระงานปัจจุบันของเขาไม่ต้องการงานใด ๆ ในโครงการของฉันนอกเหนือจากการตรวจสอบการเปลี่ยนแปลงรหัสของฉัน

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

ฉันกลัวว่าฉันจะก้าวร้าวเมื่อฉันขอให้เขาอธิบายการเปลี่ยนแปลงของเขากับฉัน

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

เพิ่มการชี้แจง:

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

20
คุณใช้ git, CVS หรือ TFS สำหรับการซื้อรหัสใหม่หรือไม่? เพียงย้อนกลับความมุ่งมั่นของเขา เขาจะได้รับมันในที่สุด :)

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

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

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

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

คำตอบ:


81

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

สำหรับฉันการหลีกเลี่ยงความขัดแย้งในสถานการณ์นี้มีสองสิ่ง:

  1. มารยาท การพูดคุยกับใครบางคนเกี่ยวกับรหัสของเขา / เธอช่วยให้นักพัฒนารู้ว่าคุณสนใจและคุณสามารถพูดคุยในฐานะผู้เชี่ยวชาญที่เติบโตขึ้น

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

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


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

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

7
@Jesslyn ถ้าเขาทำเพื่อคุณโอกาสที่เขาทำกับทุกคน ฉันสงสัยว่าใครจะนับว่าเป็นคุณ (ถ้าเขาไม่ทำเพื่อทุกคนคุณอาจมีปัญหาแตกต่างกัน)
606723

3
@tgkprog: (1) แน่นอนว่าการได้รับคำติชมจากคนอื่นนั้นสำคัญมากและฉันได้เรียนรู้บางอย่างจากการดูรหัสของผู้อื่น แต่ (2) ถ้าคุณต้องการเรียนรู้จากกันและกันคุณควรแนะนำการเปลี่ยนแปลงและหารือกัน . เพียงแค่เปลี่ยนสิ่งที่สุ่มเพราะคุณคิดว่ารหัสจะดีกว่าหลังจากการเปลี่ยนแปลงไม่ใช่วิธีที่ถูกต้อง มีวิธีที่ดีกว่าเช่นการตรวจสอบโค้ดโดยใช้เครื่องมือตรวจสอบ
Giorgio

2
ใช่ฉันคิดว่าเมื่อฉันได้แก้ไขรหัสอื่น ๆ ก่อนถึงเส้นตายเวลา 23.00 น. แต่ถึงอย่างนั้นก็จะส่งจดหมายไปยังทีมเพื่อให้พวกเขาสามารถตรวจสอบได้รวมถึง QA ของเรา ....
tgkprog

86

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

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

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

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

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

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

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

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

PS "ความเป็นเจ้าของรหัส" เป็นคำที่คลุมเครือถกเถียงกันอย่างต่อเนื่องและมันหมายถึงสิ่งที่แตกต่างกันสำหรับคนที่แตกต่างกัน คุณสามารถค้นหาคอลเลกชันที่ยอดเยี่ยมที่สุดของที่แตกต่างกัน (และบางครั้งถือ) ความคิดเห็นเกี่ยวกับC2


7
+1 และมากกว่าถ้าฉันทำได้ คำตอบที่ยอดเยี่ยมซึ่งระบุวิธีที่ดีที่สุดในการปรับปรุงกระบวนการดังกล่าว
Waldfee

2
ใช่ OP ต้องการเครื่องมือตรวจสอบรหัสเพื่อให้คุณสามารถตรวจสอบรหัสได้ด้วยกันไม่ใช่แค่ใครบางคนเปลี่ยนรหัสเพราะพวกเขารู้สึกเหมือนมัน เราเพิ่งเริ่มใช้smartbear.com/products/software-development/code-reviewที่ทำงาน
Juan Mendes

19

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

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


5
+1 สำหรับการชี้ให้เห็นข้อเท็จจริงที่สำคัญ: อาจมีความเป็นเจ้าของทีมและ (1) ทั้งหมดเป็นผู้รับผิดชอบ (2) ทุกคนสามารถเปลี่ยนรหัสได้หรือมีความเป็นเจ้าของส่วนบุคคลและ (1) เจ้าของโมดูลรับผิดชอบ (2) การเปลี่ยนแปลงทุกอย่างจะต้อง ได้รับการอนุมัติจากเจ้าของโมดูล บ่อยครั้งที่ความสับสนเกิดขึ้นเมื่อสมาชิกในทีมคาดว่าจะรับผิดชอบโมดูล แต่สมาชิกอาวุโสรู้สึกว่ามีสิทธิ์ที่จะทำการเปลี่ยนแปลงรหัสแบบสุ่ม กล่าวอีกนัยหนึ่งต้องหลีกเลี่ยงสถานการณ์ "ความรับผิดชอบโดยไม่มีอำนาจ"
Giorgio

4

ไม่ว่าจะเป็นการแก้ปัญหาทั้งหมด แต่คุณอาจลองเพิ่มความคิดเห็นเพิ่มเติมลงในซอร์สโค้ดของคุณ

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

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

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


3
เด็กชายที่อาจทำให้สับสน ลองนึกภาพ - การเพิ่มความคิดเห็นที่ระบุ "รหัสนี้ยังไม่สมบูรณ์" จากนั้นลืมที่จะลบมันเมื่อคุณกรอกรหัส
riwalk

1
@ Stargazer712, สับสนมากกว่ามีรหัสไม่สมบูรณ์ในสาขาหรือไม่
606723

นั่นคือสิ่งที่ชั้นวางมีไว้สำหรับ อย่าตรวจสอบในรหัสที่ไม่สมบูรณ์
riwalk

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

1
พวกเขาถูกเรียกว่าสิ่งที่ต้องทำพวกเขาได้รับรหัสการทำงานตลอดเวลา
Juan Mendes

4

ทุกคนโดยปริยาย 'เป็นเจ้าของรหัสของตัวเอง' โดยไม่คำนึงถึงการเมืองกฎหมายหรือเศรษฐศาสตร์ - เป็น 'ธรรมชาติของสิ่งต่าง ๆ ' - โดยธรรมชาติคุณจะรู้สึกถึงความเชื่อมโยงส่วนตัวกับงานของคุณเอง

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

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

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


1
นอกเหนือจากข้อความเริ่มต้น (มีทีมที่ยอมรับความเป็นเจ้าของทีมและทีมอื่น ๆ ที่ยอมรับความเป็นเจ้าของส่วนบุคคล) ฉันพบว่าการสังเกตในคำตอบนี้ตกลง (+1 สำหรับสิ่งนี้): ฉันได้สังเกตเห็นว่าการใช้รหัสร่วมกัน ตำแหน่งของสมาชิกภายในทีมโดยการแก้ไขรหัสโดยพล ดังนั้นฉันไม่เข้าใจ downvotes มันจะดีถ้าผู้ลงคะแนนสนใจที่จะอธิบาย
Giorgio

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

1
@Jesslyn - ฉันคิดว่าฉันถูก downvoted เพราะคำพูดของฉัน "ทุกคนโดยปริยาย 'เป็นเจ้าของรหัสของตัวเอง'" นี่เป็นคำถามเชิงปรัชญาไม่ใช่คำถามเชิงนโยบาย :-)
เวกเตอร์

1
@ Mikey: "ทุกคนโดยปริยาย 'เป็นเจ้าของรหัสของตัวเอง'" แน่นอนเรื่องนี้อาจเป็นเรื่องของการถกเถียงกัน โปรแกรมเมอร์ที่ไม่ได้ประกอบอาชีพอิสระมักจะเซ็นสัญญาที่ระบุว่าพวกเขาไม่ได้เป็นเจ้าของซอร์สโค้ด นอกเหนือจากนี้ฉันคิดว่าผู้เขียนรหัสนั้นเป็นคนที่เข้าใจรหัสได้ดีที่สุดและถ้ามีคนอื่นเปลี่ยนรหัสจากนั้นผู้เขียนหรือนักพัฒนาคนที่สองจะไม่เข้าใจรหัส 100%
Giorgio

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

1

หากคุณเขียนรหัสฉันควรตรวจสอบมัน

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

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


0

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

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

(มีคำตอบที่แตกต่างกันโดยสิ้นเชิงถ้าเป็นในที่ทำงาน. การแลกเปลี่ยนข้อมูลการหาวิธีที่ถูกต้องในการตรวจสอบโค้ดนั้นเป็นเรื่องง่าย

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