คุณติดตามชั้นเรียนและฟังก์ชั่นที่ทีมของคุณเขียนไว้ได้อย่างไร?


43

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

มีวิธีปฏิบัติที่เฉพาะเจาะจงในการบันทึกสิ่งเหล่านี้หรือไม่? คุณทำให้พวกมันหาง่ายได้อย่างไร?

หากทีมของคุณไม่มีเอกสารดังกล่าวคุณจะรู้ได้อย่างไรว่าล้อของคุณมีอยู่แล้ว?

แก้ไข:

ทั้งหมด แต่หนึ่งในคำตอบที่เกี่ยวข้องกับสถานการณ์ในอุดมคติดังนั้นขอสรุปการแก้ปัญหาเหล่านั้น: เอกสาร & การสื่อสาร; wikis, stand-up meetings เป็นต้นสิ่งเหล่านี้ล้วน แต่เป็นสิ่งที่ยอดเยี่ยม แต่พวกเขาต้องพึ่งพาโปรแกรมเมอร์ที่มีเวลา (และทักษะ) ในการเขียนเอกสารและเข้าร่วมการประชุมและจดบันทึกและจดจำทุกสิ่ง

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

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

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

มีความคิดใด ๆ เพิ่มเติมในหลอดเลือดดำนี้ ... สำหรับนักพัฒนาซอฟต์แวร์ที่ต้องทำงานโดดเดี่ยวและกดดัน?


5
ฉันจะขยายคำถามเพื่อถามในระดับที่มากขึ้นบางทีใน บริษัท ที่มีพนักงานมากกว่า 100 คนคุณจะทำเช่นเดียวกันได้อย่างไร วิธีปฏิบัติที่ดีที่สุดที่สามารถทำได้เพื่อหลีกเลี่ยงการทำซ้ำของงานที่ทำไปก่อนหน้าคืออะไร?
Asaf

1
@ Asaf - ฉันสงสัยว่าคำตอบที่ถูกต้องนั้นขึ้นอยู่กับขนาดของประชากร - สิ่งที่ใช้ได้กับร้านค้า 5 คนจะไม่ทำงานที่ 50 และสิ่งที่ใช้ได้กับ 50 จะไม่ทำงานสำหรับ 500 คำตอบสำหรับทุกคนยินดีต้อนรับ
Dan Pichelman

3
นี่เป็นคำถามที่ยอดเยี่ยม!
Rocklan

4
กฎหมายของ Conway : "องค์กรที่ออกแบบระบบ ... ถูก จำกัด ให้ผลิตงานออกแบบซึ่งเป็นสำเนาของโครงสร้างการสื่อสารขององค์กรเหล่านี้"
Mark Rushakoff

2
@ นาธานเฮย์ฟิลด์: นั่นเป็นวิธีแก้ปัญหาที่อาจใช้งานได้ 1 dev และในระดับ 2 แต่ไม่ใช่สำหรับ 20 หรือ 100 และแม้ว่าฉันจะทำงานคนเดียว
Doc Brown

คำตอบ:


29

ห้องสมุด กรอบ การควบคุมเวอร์ชัน

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

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


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

2
ผมคิดว่าระยะทางเทคนิคเป็นBBOM
zzzzBov

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

3
@Caleb: ใจเย็น ๆ อ่านโพสต์ของฉันอย่างสมบูรณ์ จุดของฉันคือ: การคัดลอกรหัสจากที่อื่นบิดและรวมเข้ากับห้องสมุดทีมไม่จำเป็นต้องนำคุณสู่ "เส้นทางสู่ความหายนะ" เมื่อคุณมีสอง libs ที่มีฟังก์ชันการทำงานที่ทับซ้อนกันและสองทีมที่แต่ละคนรับผิดชอบในการดูแล lib ของพวกเขาสถานการณ์ก็ไม่เลว นั่นไม่สมบูรณ์แบบเนื่องจากทีมหนึ่งอาจทำงานบางอย่างได้อีกทีมหนึ่งก็เช่นกัน แต่บางครั้งข้อดีที่ทีมเหล่านั้นยังคงทำงานได้อย่างอิสระเมื่อเทียบกับการทำงานสองครั้ง
Doc Brown

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

13

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

ส่วนที่ยากคือการให้ทุกคนในทีมของคุณดูแลรักษา Wiki นั้นตลอดเวลา แต่เอกสารประเภทอื่น ๆ ประสบปัญหาเดียวกัน

รหัสบางอย่างของคุณอาจดีพอที่จะใส่ลงในไลบรารีที่ใช้ซ้ำได้ ทำให้ง่ายต่อการค้นหารหัสอีกครั้งในภายหลัง


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

@Caleb การสื่อสารเป็นส่วนที่ยาก
jk

@jk - ปัญหาการสื่อสารถูกรวมหากคุณไม่มีการควบคุมแหล่งที่กล่าวถึงใน C
JeffO

3
@Caleb: คำถามของ OP ไม่ได้เกี่ยวกับการเผยแพร่รหัสคำถามเกี่ยวกับการสื่อสารและการค้นหาในภายหลัง
Doc Brown

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

7

การเป็น บริษัท ที่มีพนักงาน 700 คนภายในทีมต่างกันระหว่าง 2 ถึง 20 คนนี่คือประสบการณ์ของฉัน

ในระดับทีม

เรามี "การประชุมที่ยอดเยี่ยม" ทุกวันประมาณ 15-20 นาที เราสามารถแบ่งปันความรู้ทั่วไปอย่างรวดเร็วเช่น "ฉันทำฟังก์ชั่นนี้เมื่อวานนี้มันสั่นสะเทือนอย่างหนัก"

เรามีวิกิต่อโครงการ ซึ่งหมายความว่าเราสามารถแบ่งปันข้อมูล (ด้านเทคนิค) เกี่ยวกับสิ่งที่ทำในโครงการรวมถึงคลาส / ฟังก์ชันที่กำหนดเองที่มีอยู่แล้วภายใน

ในระดับตัวแทน

ในระดับตัวแทนเรามีเครื่องมือ 4 อย่าง:

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

ในระดับ บริษัท

ในระดับ บริษัท มีการจัดระเบียบมากขึ้น

วิกิพีเดียระดับตัวแทนเป็นส่วนหนึ่งของวิกิของ บริษัท

และวิกินั้นก็แยกตามเทคโนโลยี ดังนั้นทุกคนสามารถปรับปรุงได้ค้นหาผ่านและให้ชีวิตกับวิกิ

นอกจากนี้ยังมีรายชื่อรับเมลที่เราสามารถสมัครรับข้อมูลได้ ทุกคนในเอเจนซี่สามารถสมัครสมาชิกได้และคนส่วนใหญ่ติดตามเทคโนโลยีอย่างน้อยหนึ่งหรือสองคนจริงๆแล้วคนส่วนใหญ่ติดตาม 5-10 คน

และ VCS นั้นแน่นอนว่าเป็นระบบการแบ่งปันรหัสที่ดีที่สุด

ข้อสรุป

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


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

6

ทุกอย่างมาลงที่การสื่อสาร

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

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

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


1
ฉันจะย้ายแนวคิด "ทั่วไป" ขึ้นอีกเล็กน้อยในคำตอบของคุณ
JeffO

4

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


1
ถ้าอย่างนั้น 4 ปีและอีก 600 ฟังก์ชั่นในภายหลังเมื่อคุณต้องการที่จะจำได้ว่าหนึ่งฟังก์ชั่นที่ทำเวลา? ส่วนหนึ่งของปัญหา OP กำลังพยายามจดจำทุกสิ่งที่ถูกสร้างขึ้นในขณะที่สิ่งนี้ดีในขั้นต้นมันจะไม่ค้างในช่วงเวลาหนึ่งเดือนหรือสองเดือน
RhysW

2

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


0

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

TL; DR: การตรวจสอบโค้ดสำหรับทุกการเช็คอิน


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

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