มาตรฐานสำหรับวิธีที่นักพัฒนาทำงานกับเวิร์กสเตชันของตนเอง


18

เราเพิ่งเจอหนึ่งในสถานการณ์เหล่านั้นซึ่งบางครั้งเกิดขึ้นเมื่อนักพัฒนาไม่สบายสำหรับโครงการกลางสองสามวัน

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

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

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

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

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

หรือคุณขอให้ผู้พัฒนาปฏิบัติตามมาตรฐานในพื้นที่นี้ - การใช้ไดเรกทอรีเฉพาะมาตรฐานการตั้งชื่อบันทึกบนวิกิหรืออะไรก็ตาม และถ้าเป็นเช่นนั้นมาตรฐานของคุณครอบคลุมอะไรพวกเขาเข้มงวดแค่ไหน

หรือมีวิธีแก้ไขปัญหาอื่นที่ฉันขาดไป

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

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


8
-1 สำหรับการไป Gestapo บนศูนย์บัญชาการของโปรแกรมเมอร์
systemovich

17
รอนักพัฒนาที่สองรู้รหัสผ่านของนักพัฒนาคนแรกได้อย่างไร
TheLQ

12
+1 สำหรับคำถามที่ยอดเยี่ยม "Going gestapo" ไม่เกี่ยวข้องกับสภาพแวดล้อมขององค์กรในความคิดของฉันเนื่องจากนักพัฒนาทำงานให้กับ บริษัท ดังนั้นจึงยกเลิกสิทธิ์การเข้าถึงเครื่องของพวกเขา คุณต้องการความเป็นส่วนตัวใช้ฮาร์ดแวร์ของคุณเอง
Gary Rowe

4
หากนักพัฒนาสามารถได้รับการติดต่อเพื่อขอรหัสผ่านทำไมคุณไม่ถามเขาว่าเป็นเวอร์ชั่นปัจจุบันหรือไม่
เบ็น L

2
@ แกรี่: อะไรนะ ไม่นั่นเป็นเรื่องไร้สาระที่สมบูรณ์ (และอันตรายมาก) มันเป็นช็อต looong (ทั้งเหตุผลและถูกกฎหมาย) จากการทำงานให้กับ บริษัท เพื่อให้สิทธิส่วนบุคคลเพื่อความเป็นส่วนตัว ฉันจะไม่เรียกการกระทำของจอนว่า“ กำลังจะไป Gestapo” (แม้กระทั่งก่อนที่เขาจะอธิบายเพิ่มเติม) แต่บางครั้งบริษัท ก็ต้องไป Gestapo และนี่เป็นสิ่งที่จำเป็นต้องได้รับการป้องกันและต่อสู้ในทุกระดับ ฉันพูดได้เพียงเยอรมนี แต่ที่นี่คุณจะมีสิทธิความเป็นส่วนตัวบางอย่างแม้กระทั่งเมื่อทำงานบนฮาร์ดแวร์ บริษัท ที่เป็นเจ้าของ
Konrad Rudolph

คำตอบ:


64

" ถ้ามันไม่ได้อยู่ในการควบคุมแหล่งที่มามันก็ไม่มีอยู่ "

นี่คือหนึ่งในสองสามสิ่งในอาชีพของเราที่ฉันเป็นคนดื้อรั้น ด้วยเหตุผลดังต่อไปนี้:

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

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

นอกจากนี้ยังมีการตรวจสอบทุกอย่างก่อนที่คุณจะไปในวันหยุดเป็นผู้ได้รับมอบอำนาจ

TL; DR version : การได้เห็นเวิร์กสเตชั่นของผู้คนในรูปแบบที่ไม่ดี แทนที่จะพยายามปลูกฝังวัฒนธรรมในการทำให้มันง่ายต่อการเข้าไปในเวิร์กสเตชันของผู้คนเพื่อค้นหาสิ่งที่เราต้องการมันเป็นแนวทางปฏิบัติที่ดีกว่าในการส่งเสริมวัฒนธรรมของการใช้แหล่งควบคุมที่สมเหตุสมผลและการเช็คอินเป็นประจำ อาจเป็นไปได้ว่าเช็คอินปกติมากเกินไปและงานละเอียดเมื่ออยู่ในขั้นตอนที่สำคัญของโครงการ


10
+1: บางคนป่วยไปยุ่งอยู่กับเวิร์กสเตชันของพวกเขาอาจจะมีค่าใช้จ่ายมากกว่ามูลค่า บุคคลหนึ่งหายไปแล้ว ตอนนี้อีกคนกำลังเสียเวลาพยายามคิดว่าเกิดอะไรขึ้น ฝันร้ายการจัดการขนาดใหญ่โดยไม่มีค่า จนกว่าจะอยู่ในการควบคุมแหล่งที่มามันไม่เคยมีอยู่
S.Lott

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

เมื่อคุณพูดถึงการปล่อยคุณหมายถึงการปล่อยสำหรับการสร้างหรือการปล่อยให้กับผู้ใช้?
JeffO

2
@Murph: หากมีการเปลี่ยนแปลงเกิดขึ้นที่ใดที่หนึ่งทุก ๆ วันจำนวนงานสูงสุดที่สามารถถูกวางผิดที่นั้นคือมูลค่าของ X days และนั่นเป็นความจริงไม่ว่าผู้พัฒนาจะไม่สามารถหลีกเลี่ยงได้นานนัก สิ่งที่ต้องทำคือมีนโยบายเกี่ยวกับการตรวจสอบบ่อยครั้งเพียงพอเพื่อให้ปริมาณงานที่สูญหายอยู่ในขอบเขตที่ยอมรับได้
David Thornley

1
@ David ความคิดเห็นของฉันคือการตอบกลับของ @ S.Lott - ในแง่ของการโต้แย้งเกี่ยวกับ "หลงทาง" เรียงลำดับของ ฉันต้องการที่จะปรมาณูในแง่ของการเปลี่ยนแปลงที่สมบูรณ์ (ฉันเริ่มเข้าใจว่าเหตุใดการลดความน่าสนใจจึงเป็นเรื่องที่น่าสนใจ) - ดังนั้นฉันจึงเห็นว่า "มุ่งมั่นที่จะบันทึก" เป็นปัญหา (ในกรณีทั่วไปและขาด ของการเทียบเท่าการรีบูต) และในกรณีใด ๆ ควรมีการสำรองข้อมูลเวิร์กสเตชันอัตโนมัติทุกวันค่อนข้างแตกต่างจากการควบคุมเวอร์ชัน
Murph

22

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

วิธีนี้ไม่มีใครจำเป็นต้องเข้าถึงเวิร์กสเตชันของนักพัฒนาคนอื่น

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


1
คุณจะรวมสาขาบ่อยครั้งเพียงใด ทุกครั้งที่คุณรู้สึกว่ามั่นคง?
Jon Hopkins

2
@ Jon Hopkins: "Releasable" ง่ายต่อการจัดการมากกว่า "Stable" releasable รวมถึงเสถียรภาพและเจ้าของผลิตภัณฑ์พร้อมสำหรับมัน และคุณจะทำการประมวลผลแบบสาขาเพื่อปล่อยจำนวนมาก สาขาสู่เสถียรภาพมีศักยภาพมากเกินไปสำหรับผู้กระทำและการสนทนา "ทำงานเพื่อฉัน"
S.Lott

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

1
-1 เพราะสิ่งนี้ไม่ได้กล่าวถึงสถานการณ์เช่น "ฉันรู้สึกไม่สบายจริง ๆ ฉันกำลังจะกลับบ้านตอนนี้อืมดีกว่าทำแค่ 30 นาทีในการเตรียมการดังนั้นฉันจึงไม่ทำลายโครงสร้างเมื่อฉันตกลง"
Gary Rowe

2
@Murph Checkins เป็น 'ลำตัว' หรือการฉีด (สิ่งที่คุณต้องการเรียก) ควรเกิดขึ้นเมื่อคุณอธิบาย อย่างไรก็ตามไม่มีอะไรผิดปกติหากมีนักพัฒนา 'บันทึกงานของพวกเขาในตอนท้ายของวัน' โดยมอบหมายให้สาขาส่วนบุคคล (แม้ว่าจะง่ายกว่านี้มากกับ git หรือ mercurial กว่ากับ SVN) และเปรียบเทียบกับการบังคับใช้แนวทางในการตั้งค่าเวิร์คสเตชั่นของนักพัฒนา (ซึ่งเป็นจุดเริ่มต้นของเรา) มันเป็นวิธีการแก้ปัญหาอย่างจริงจัง
กริช

6

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

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

น่าเสียดายที่พวกเขาไม่รู้ว่ากำลังทำอะไรและลบต้นแบบที่ฉันได้ทำในสองเดือนที่ผ่านมา

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

แต่อย่ายุ่งกับเวิร์กสเตชันของผู้คน

ป.ล. เรามีแบบแผนสำหรับโครงสร้างไดเรกทอรี แต่เหตุผลหลักคือการมีอยู่ของทั้งประวัติศาสตร์ / การตั้งค่า - วางไว้ที่อื่นและมันจะไม่รวบรวม


3
@Murph: ไป "ป่วย" พร้อมกับความต้องการเร่งด่วนที่จะได้รับบางสิ่งบางอย่างจากระบบของเขาเป็นสถานการณ์ที่หายากจริงๆ อาจไม่คุ้มค่ากับความพยายามในการสร้างมาตรฐานใด ๆ

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

3
ไม่มีการสำรองข้อมูลในต้นแบบนั้นหรือไม่
JeffO

2
@ ผู้พัฒนาศิลปะทำไมคุณไม่ทำงานในสาขาของระบบการกำหนดเวอร์ชัน

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

6

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

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

ฉันคิดว่าการประชุมบางอย่างดี แม้ว่าฉันจะเห็นด้วยกับบ๊อบบี้เมื่อเขาพูด

"ถ้ามันไม่ได้อยู่ในการควบคุมแหล่งที่มามันก็ไม่มีอยู่"

นอกจากนี้การเพิ่มประโยชน์ให้กับพื้นที่ทำงานโปรแกรมเมอร์ใด ๆ อาจเป็นไดรฟ์ hot-swap SATA ด้านหน้าอ่าวที่เก็บโครงการทั้งหมดและการพัฒนา วิธีนี้หากเกิดปัญหาดังกล่าวขึ้นพนักงานสามารถดึงการเปลี่ยนแปลงของแหล่งที่มาใหม่ให้กับโครงการได้อย่างง่ายดายโดยไม่จำเป็นต้องลงชื่อเข้าใช้เวิร์กสเตชันของนักพัฒนา


"... มันไม่มีอยู่" สำหรับคนอื่น ๆ นั่นคือ

4

ส่วนแรกของคำถามของคุณระบุปัญหาการสื่อสารภายในทีมของคุณอย่างชัดเจน คุณได้ลองเล่นstandups ทุกวันแล้วหรือยัง?

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

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

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

ในระหว่างการประชุมนำเสนอปัญหาและถามอย่างชัดเจนว่าทีมสามารถปรับปรุงสถานการณ์ได้อย่างไร

(การทั้งหมด) ทีมงานตัดสินใจว่าจะทำอย่างไร


2

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

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

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


1
มันจะช่วยได้อย่างไร คำถามจะยังคงมีอยู่เราเพียงแค่พูดถึงว่าสาขาใดในพื้นที่เก็บข้อมูล DVCS ท้องถิ่นของเขาแทนที่จะเป็นพื้นที่ทำงาน
Jon Hopkins

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

@ จอน - ฉันคิดว่าประเด็นคือสาขาที่หลากหลายของเขาจะอยู่ในสิ่งที่จะรวมการทำงานที่สร้างไว้ภายในแทนที่จะเป็นเพียงไดเรกทอรีที่กระจัดกระจายของไฟล์ นอกจากนี้การพาเขาขึ้นไปบน DVCS จะเป็นโอกาสฝึกอบรม
Dan Ray

1
@Dan - แต่สาขาเหล่านั้นบางส่วนเป็นจุดจบของการพิสูจน์แนวคิดสิ่งต่าง ๆ ที่มีรหัสการดีบักที่หลากหลายซึ่งคุณไม่ต้องการรวมเข้าด้วยกันเวอร์ชันเก่ากว่า ข้อเท็จจริงที่ว่าคุณมีฟังก์ชั่นการผสานไม่ได้ช่วยอะไรเมื่อคุณไม่รู้ว่าควรผสานอะไร
Jon Hopkins

@ จอน - ฉันเดาว่าเป็นเรื่องจริง อาจจะมีเพียงไม่ฟื้นตัวจากใครบางคนมุ่งมั่นที่จะทำให้เป็นระเบียบ
Dan Ray

2

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

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

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


2

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

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

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

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

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


1
ฉันพูดโดยเฉพาะในคำถามเพื่อสันนิษฐานว่าบุคคลนั้นไม่สามารถติดต่อได้
Jon Hopkins

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

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

@Murph จากนั้นบังคับใช้กฎของ "กระทำบ่อย - ในสาขา" และผลักดันไปยังศูนย์กลางอย่างน้อยทุกวัน

1

ดังนั้นคุณจะรับมือกับสถานการณ์เช่นนี้ได้อย่างไร

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

หรือคุณขอให้ผู้พัฒนาปฏิบัติตามมาตรฐานในพื้นที่นี้ - การใช้ไดเรกทอรีเฉพาะมาตรฐานการตั้งชื่อบันทึกบนวิกิหรืออะไรก็ตาม

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

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