หวังว่าฉันจะช่วยคุณได้เล็กน้อยหรืออย่างน้อยก็ชี้คุณในทิศทางที่ถูกต้อง!
แม้ว่าจะเป็นข้อจำกัดความรับผิดชอบ แต่ก็เป็นหัวข้อใหญ่ - และเป็นเรื่องที่ฉันคิดว่าต้องใช้เวลา " ถูกโยนเข้า " เพื่อทำความเข้าใจอย่างลึกซึ้ง ที่กล่าวว่าฉันจะให้รวดเร็วของทั้งสองประเด็นสำคัญ:
- การควบคุมรหัสและแหล่งที่มา
- การสื่อสารและเคล็ดลับบางประการ
เกี่ยวกับโครงการ OOP โดยเฉพาะ - ฉันไม่สามารถเห็นปัญหามากเกินไปเฉพาะ OOP ที่ไม่ปรากฏที่อื่น
ที่จริงแล้วฉันคิดว่าการเขียนโปรแกรมแบบ OOP นั้นเหมาะกับการพัฒนาทีมอย่างไม่น่าเชื่อ หลักสำคัญประการหนึ่งของ OOP คือฉันไม่ควรรู้รายละเอียดทั้งหมดเกี่ยวกับวัตถุทุกอย่างที่ฉันโต้ตอบด้วย: ฉันแค่ต้องรู้ว่ามันสามารถทำอะไรได้บ้างและฉันจะทำมันอย่างไร
abstractions ที่ OOP สามารถให้นั้นยอดเยี่ยมในทีม
การควบคุมแหล่งที่มา
จะต้องมีสถานที่ส่วนกลางสำหรับโครงการที่จะจัดเก็บและหนึ่งที่ช่วยให้นักพัฒนาหลายคนสามารถเข้าถึง codebase ได้ตลอดเวลา นี่คือที่ที่ระบบเช่น Git (หรือ SVN) เข้ามาเล่น
ฉันสามารถพูดได้เฉพาะเกี่ยวกับ Git โดยเฉพาะเนื่องจากฉันไม่เคยใช้ SVN - แต่ฉันรวบรวมพวกมันเหมือนกัน แต่มีคำศัพท์ต่างกัน
การใช้ Git ฉันสามารถสร้างที่เก็บที่มีซอร์สโค้ดทั้งหมดสำหรับโครงการที่กำหนดแล้วอนุญาตให้ทีมของฉันเข้าถึงที่เก็บได้ สำหรับทุกคุณสมบัติหรือการแก้ไขข้อผิดพลาดที่เกิดขึ้นจากนั้นผู้พัฒนาแต่ละคนสามารถสร้าง"สาขา"ของตัวเองซึ่งหมายถึงการพัฒนาสามารถเกิดขึ้นได้บนเส้นทางคู่ขนาน
เมื่อคุณสมบัติหรือการแก้ไขเสร็จสมบูรณ์ก็สามารถ " ผสาน " กลับไปที่ฐานรหัสของโครงการหลัก " ความขัดแย้ง " ใด ๆ ที่สามารถตรวจพบโดย Git และแก้ไขในระดับแหล่งที่มาโดยนักพัฒนาที่รับผิดชอบ
ฉันไม่แน่ใจว่าคุณจะเคยใช้ Git มาก่อนหรือไม่ แต่มันอาจดูค่อนข้างซับซ้อนในตอนแรก แต่ต้องขอบคุณความนิยมที่ผ่านมา (ในส่วนของGithub ) มีบทเรียนและแหล่งข้อมูลมากมาย
หากคุณไม่เคยใช้มันมาก่อนฉันแนะนำให้สมัครกับ GitHub และให้ความรู้สึกแบบนั้น! (อีกทางหนึ่งBitbucketเป็นทางเลือกที่คล้ายกัน แต่ช่วยให้คุณมีที่เก็บส่วนตัวฟรี)
Git Flowเป็นกระบวนการทำงานตาม Git ที่ยอดเยี่ยมซึ่งมีประโยชน์อย่างเหลือเชื่อสำหรับทีม เช่นเดียวกับ Git โดยทั่วไปเมื่อคุณทำงานกับมันมาระยะหนึ่งมันก็ยากที่จะจินตนาการว่าจะทำงานเป็นทีมโดยที่ไม่มีมัน!
คมนาคม
เมื่อคุณผ่านพ้นอุปสรรคทางเทคนิคทั้งหมดแล้วคุณจะพบกับปัญหาพื้นฐานที่ทำให้เกิดภัยพิบัติในโครงการส่วนใหญ่ (ด้านเทคนิคหรือไม่) - และนั่นคือการสื่อสาร
ทีมงานทั้งหมดต้องระวังว่าใครกำลังทำอะไรเมื่อพวกเขาทำอะไรและมีผลกระทบอะไร
ความรับผิดชอบจะต้องกำหนดไว้อย่างชัดเจน
นี่เป็นสิ่งที่ชัดเจน แต่โครงการส่วนใหญ่จะใช้ระบบจองตั๋วบางรูปแบบ - เมื่อมีการบันทึกคุณสมบัติหรือข้อบกพร่องใด ๆ จากนั้นมอบหมายให้กับเจ้าหน้าที่เฉพาะราย ( JIRA , Unfuddleเป็นต้น) บ่อยครั้งที่สิ่งเหล่านี้สร้างขึ้นในระบบควบคุมแหล่งที่มาซึ่งทำให้ชีวิตง่ายขึ้นเล็กน้อย (BitBucket และ GitHub ให้การติดตามปัญหาสำหรับที่เก็บ Git ที่โฮสต์กับพวกเขา)
สิ่งนี้จะหยุดหรือช่วยป้องกันอย่างน้อยนักพัฒนาโดยบังเอิญทำงานกับปัญหาเดียวกัน
นี่ไม่ใช่การแก้ไขที่สมบูรณ์แม้ว่า คุณยังต้องตรวจสอบให้แน่ใจว่านักพัฒนาซอฟต์แวร์ทราบเกี่ยวกับความรับผิดชอบของนักพัฒนาซอฟต์แวร์อื่น ๆ ฉันรู้ว่าในอดีตที่ฉันได้แก้ไขปัญหาอื่น ๆ ที่ฉันได้พบในการแก้ไขข้อผิดพลาดเฉพาะเพราะมันสมเหตุสมผล (" อืมฉันอยู่ที่นี่แล้วนี่สามารถทำได้กับผู้ปรับโครงสร้างและบางทีฉันสามารถตรวจสอบปัญหาอื่น ๆ ได้ ") จากนั้นฉันต้องขออภัยผู้พัฒนารายอื่นเนื่องจากพวกเขากำลังทำงานกับปัญหาอื่น ๆ ที่ฉันได้ทำ คงที่ - เสียทั้งเวลาของเรา
โดยทั่วไปปัญหาเหล่านี้สามารถแก้ไขได้โดย ...
การประชุมปกติ
วิธีการจัดการ / พัฒนาโครงการบางอย่างกำหนดวิธีการสื่อสารที่เฉพาะเจาะจงหรือช่วงเวลาการประชุม โดยทั่วไปแล้วระบบที่มีประสิทธิภาพที่สุดที่ฉันเคยเห็นคือการประชุมช่วงเช้าซึ่งทุกคนในทีมจะทำสิ่งที่พวกเขากำลังทำอยู่ - ถ้าคุณ จำกัด สิ่งนี้กับสมาชิกในทีมพัฒนาเท่านั้นและมีแนวทางที่ชัดเจนเกี่ยวกับสิ่งที่ เพื่อสื่อสารแล้วสิ่งเหล่านี้จะมีประสิทธิภาพอย่างเหลือเชื่อ ฉันพยายามเสมอที่จะ:
ฉันกำลังทำงานกับ X
เพื่อให้บรรลุ / แก้ไข Y
ซึ่งเกี่ยวข้องกับการแก้ไข / แก้ไข Z
สมาชิกในทีมคนอื่นสามารถรับได้ทันที " เฟอร์กัสกำลังแก้ไขข้อผิดพลาดนั้นซึ่งถูกบันทึกไว้เมื่อวันก่อนอย่างไรก็ตามนั่นหมายความว่าเขากำลังทำงานกับโค้ดบางอย่างที่ฉันต้องดู - ฉันจะตรวจสอบกับเขาก่อนจะทำการเปลี่ยนแปลงใด ๆ "
การประชุมทางสถาปัตยกรรม
ฉันเพิ่งทำงานกับทีมที่ยอดเยี่ยมที่มี "การแชทด้วยเทคโนโลยี " รายปักษ์ที่จะกล่าวถึงปัญหาที่ใหญ่กว่า / สถาปัตยกรรม สมาชิกทุกคนในทีมมีเวลาที่จะเข้าใจปัญหาที่ใหญ่กว่าที่เผชิญอยู่ในโครงการและสามารถหารือเกี่ยวกับการแก้ไขที่อาจเกิดขึ้น
ฉันชอบสิ่งนี้มากฉันไม่ได้มีส่วนร่วมเท่าที่ฉันค่อนข้างใหม่สำหรับโครงการ - แต่การได้ฟังการอภิปรายทำให้ฉันมีความเข้าใจอย่างถ่องแท้ ไม่นานฉันก็เข้าใจโครงการและสไตล์การคิดของแต่ละคน
การสื่อสารเป็นปัญหาหนึ่งที่สามารถทำให้ทีมใด ๆผิดหวัง ทางเทคนิคหรือไม่ถ้าคนไม่ได้ตระหนักถึงภาพรวมแล้วมีโอกาสมากขึ้นที่พวกเขาจะล้มเหลว
ปัญหาอื่น ๆ
เป็นการดีที่จะให้ทุกคนมีการกำหนดค่าหรือสไตล์เดียวกันเมื่อทำงานเป็นทีม ฉันหมายถึงอะไร
องค์ประกอบ
หากคุณกำลังทำงานกับโปรเจ็กต์ Java - บางทีรับรอง (สำหรับสภาพแวดล้อมการพัฒนาอย่างน้อยก็ไม่ควรทดสอบ) เวอร์ชัน JVM เป็นเรื่องธรรมดาในหมู่ทีมอาจเป็นความคิดที่ดี? จากนั้น IDEs ช่วยอย่างมากหากทั้งทีมใช้EclipseหรือNetBeansหรือ IDE ที่คุณเลือก
ในโครงการเว็บอาจเป็นไปได้ว่านักพัฒนาทั้งหมดต้องการสแต็กเฉพาะ ด้วยApacheหรือPHPเฉพาะรุ่น
การคิดถึงปัจจัยเช่นนี้ทำให้ทีมสามารถ "เจล" ได้เร็วขึ้นในใจของฉัน
สไตล์
แท็บเทียบกับช่องว่าง? CamelCaseหรือ spacing_with_underscores? คำถามเล็ก ๆ น้อย ๆ เหล่านี้อาจเกิดขึ้นเมื่อคุณทำงานคนเดียวเมื่อคุณทำงานกับทีมที่ใหญ่กว่าคุณต้องการที่จะมุ่งสู่สไตล์ที่เหมือนกัน
ในความเป็นจริงคุณไม่ควรจริงๆจะสามารถที่จะบอกได้ว่าใครเขียนเฉพาะส่วนของรหัส - คุณก็ควรจะรู้ว่ามันเป็น
นี่คือเหตุผลที่โครงการโอเพนซอร์สหลายแห่งเผยแพร่แนวทาง / รูปแบบสไตล์ชี้นำซอร์สโค้ดอย่างเปิดเผยสำหรับแนวคิดของสิ่งที่มีอยู่ให้ดูที่Google StyleGuidesสำหรับโครงการโอเพ่นซอร์สของตนเอง
งานและการทดสอบหน่วย
สิ่งนี้ไม่ได้ จำกัด อยู่เพียงแค่ทีม แต่ฉันจะสัมผัสสิ่งนี้อย่างรวดเร็วด้วยเหตุผลหนึ่งประการ: มันทำให้ชีวิตทีมง่ายขึ้นมาก
หากคุณมีเวิร์กโฟลว์ที่ซับซ้อนที่มีการพึ่งพาจำนวนมากหรือกระบวนการสร้างแบบยาว - บ่อยครั้งที่มีประโยชน์ในการทำให้สิ่งนี้เป็นแบบอัตโนมัติโดยใช้ตัวช่วยงาน สำหรับโครงการเว็บGruntJSนั้นยอดเยี่ยม แต่มาจาก Java ฉันว่าApache Antอาจจะค่อนข้างคล้ายกัน
ในฐานะบุคคลที่ฉันใช้GruntJSเพื่อสร้างเว็บไซต์ของฉันก่อนที่จะนำไปใช้กับเซิร์ฟเวอร์ FTP ของฉัน - คำสั่ง Grunt เดียวคือทั้งหมดที่ฉันต้องการสำหรับ CSS / Sassของฉันที่จะรวบรวมและย่อขนาดสินทรัพย์ของฉันจะถูกบีบอัดแล้วอัปโหลดไฟล์ของฉัน
ในฐานะสมาชิกในทีมฉันสามารถใช้ GruntJS เพื่อตรวจสอบว่าฉันไม่ได้ทำการทดสอบใด ๆ - และฉันยังไม่ได้แนะนำข้อบกพร่องใด ๆ โดยไม่ได้รับรู้อย่างเต็มที่เกี่ยวกับส่วนอื่น ๆ ของโครงการ แน่นอนว่านี่เป็นส่วนเพิ่มเติมของผลประโยชน์ที่ทำให้ฉันเป็นผู้พัฒนารายบุคคล
ฉันยังสามารถใช้มันเพื่อให้ฉันสามารถโคลนโครงการโดยใช้แพ็คเกจควบคุมแหล่งแฟนซี (Git) ของฉัน - และเรียกใช้คำสั่งเดียวเพื่อติดตั้งการอ้างอิงทั้งหมดของฉัน นี่เป็นข้อดีอย่างมากเนื่องจากเวลาที่ใช้ในการพัฒนาผู้พัฒนาใหม่ให้อยู่ในตำแหน่งที่พวกเขาสามารถเริ่มพัฒนาได้จริง ๆ นั้นมีขนาดค่อนข้างใหญ่
เอกสาร
โครงการที่ดีที่สุดที่ฉันเคยเห็นมีเอกสาร (และมักจะมากเกินไป) มุ่งเป้าไปที่นักพัฒนา เอกสารประเภทนี้อาจอธิบายสิ่งต่าง ๆ เช่น:
1. สภาพแวดล้อมการพัฒนา:
"ขณะนี้เรากำลังปรับใช้กับเซิร์ฟเวอร์ที่ใช้งานLAMP stack เนื่องจากผู้พัฒนาดังกล่าวควรกำหนดเป้าหมายเวอร์ชันที่อธิบายไว้"
2. กระบวนการทำงาน
"คุณสมบัติทั้งหมดจะต้องได้รับการพัฒนาบนสาขา 'feature / *' และรวมเข้ากับสาขา 'การทดสอบ' ก่อนที่จะถูกพิจารณาว่าพร้อมวางจำหน่ายแล้ว"
3. ความรับผิดชอบในทีม:
"สำหรับปัญหาฐานข้อมูลให้คุยกับ Steve สำหรับปัญหาของแพลตฟอร์มให้คุยกับ David"
4. A " ไปป์ไลน์ " สำหรับอนาคต
เมื่อพัฒนารหัสใหม่โปรดจำไว้ว่า ณ เดือนมิถุนายน 2014 เราต้องการนำรหัสxดั้งเดิมมาใช้อาจต้องได้รับการตรวจสอบอีกครั้งก่อนที่สิ่งนี้จะเกิดขึ้น "
ตัวอย่าง
มันอาจคุ้มค่าที่จะดูกระบวนการทำงานของโครงการโอเพนซอร์ซเพื่อทำความเข้าใจว่ามันทำงานอย่างไรไม่ว่าจะเป็นโครงการที่จัดตั้งขึ้นมาด้วยเวิร์กโฟลว์ของตัวเอง
คำเตือนสุดท้าย
หากคุณพบว่าตัวเองทำงานในทีมที่สามารถทำสิ่งเหล่านี้ได้อย่างถูกต้อง .. คุณจะเกลียดการอยู่ที่อื่น .. ! นำไปจากฉันเมื่อคุณได้ประสบการณ์ที่ดีของทีมแล้วก็ประเด็นที่อื่นจริงๆสามารถลากคุณลง (นั่นเป็นเรื่องสำหรับโพสต์อื่น!)