การสนับสนุนโอเพนซอร์สครั้งแรกของฉันสำหรับห้องสมุดที่ฉันเคยใช้มาก่อนหน้านี้ ในระหว่างการใช้งานครั้งแรกฉันพบข้อผิดพลาดในรหัสดังนั้นฉันจึงสร้างโปรแกรมแก้ไขเข้าร่วมโครงการและส่งเพื่อตรวจสอบ
ประมาณ 8 เดือนต่อมาเมื่อฉันมีเวลาว่างฉันตัดสินใจว่าฉันจะคืน (และพัฒนาทักษะการพัฒนาของฉัน) ด้วยการมีส่วนร่วมในโครงการมากขึ้น ดังนั้นฉันจึงโคลนที่เก็บและเริ่มทำความคุ้นเคยกับ codebase หลังจากสองสามสัปดาห์ของการส่งการแก้ไขเล็กน้อยไปยัง codebase และตรวจสอบการร้องขอคุณสมบัติฉันหยิบคำขอคุณลักษณะเพื่อเพิ่มโมดูลที่น่าสนใจไปยังโครงการ
เนื่องจากการสร้างการแก้ไขแพตช์ส่วนบุคคลนั้นค่อนข้างน่าเบื่อสำหรับการพัฒนาที่สำคัญใด ๆ ฉันจึงโคลนที่เก็บไปยังสาขาบนฮับ git และเริ่มเจาะรหัส ไม่กี่สัปดาห์และโค้ดหลายพันบรรทัดต่อมาหัวหน้าโครงการและฉันทำงานผ่านการบูรณาการและทดสอบการแก้ไขของฉันในห้องสมุดในวิธีที่ทำงานอย่างสม่ำเสมอกับส่วนที่เหลือของรหัสฐาน
มันเป็นกระบวนการอันล้ำค่าที่ฉันเรียนรู้มากมายจาก:
- เมื่อฉันเริ่มฉันไม่รู้ว่าจะใช้ Git ได้อย่างไรในตอนท้ายฉันสามารถสร้างสาขาการติดตามระยะไกลได้อย่างเชี่ยวชาญและผสานหรือรีบูทพวกเขาเข้าสาขาหลักโดยไม่ต้องเหนื่อย
- ฉันเริ่มใน VS 2008 และลงเอยด้วยการโยกย้ายไปยัง Linux และ Monodevelop เพื่อทำงานเกี่ยวกับการเขียนโค้ด (เพราะ VS เป็น unicode ที่ปัญญาอ่อนและการสิ้นสุดของบรรทัดเป็นความเจ็บปวดในคอมไพล์) ปรากฎว่ามีไม่มากที่คุณไม่สามารถทำใน * ระวังที่คุณสามารถทำได้ใน * dows
- ฉันไม่เคยทำการทดสอบหน่วยใด ๆ มาก่อนเลยนูนิทเป็นชิ้นส่วนของเค้กที่ใช้และการเขียนการทดสอบหน่วยเป็นเรื่องเบื้องต้น
- ฉันต้องเรียนรู้ที่จะกลืนลิ้นของฉันและฟังและฝึกความอดทน ไม่มีจุดยืนที่ชัดเจนในตำแหน่งของคุณในโครงการโอเพ่นซอร์สเพราะทุกคนที่เกี่ยวข้องมีความรู้ (อาจมากกว่าตัวคุณเอง) และสามารถยอมรับ / ปฏิเสธความคิดของคุณตามเนื้อหาที่ไม่ได้จัดส่ง เป็นเรื่องที่ถ่อมและให้รางวัลอย่างมากในเวลาเดียวกัน
- เพียงแค่มีสายตาของนักพัฒนาฝีมือคนอื่น ๆ บนฐานขนาดใหญ่ของรหัสของฉันชี้ให้เห็นข้อบกพร่องในสไตล์ของฉันที่ฉันไม่เคยพิจารณามาก่อน (เช่นเดียวกับที่ฉันชี้ข้อบกพร่องในรหัสของเขา) สำหรับฉันฉันเรียนรู้ว่าการกำหนดค่าคงที่ง่ายกว่า / ดีกว่าการใช้ตัวเลขเวทมนต์จำนวนมากพร้อมการแสดงความคิดเห็นอย่างละเอียด
โครงการนั้นขึ้นอยู่กับการสร้างและถอดรหัสแพ็กเก็ตเครือข่ายในทุกระดับของโปรโตคอลเครือข่าย ฉันมีความสนใจส่วนบุคคลในระบบเครือข่ายระดับล่างดังนั้นจึงเป็นเรื่องที่ดีมากที่ได้พูดคุยกับนักพัฒนาคนอื่นที่มีความสนใจและความรู้ร่วมกันในโดเมน
หากคุณต้องการให้เท้าเปียก: ค้นหาโครงการที่คุณใช้อยู่แล้ว โคลนที่เก็บ; และเริ่มดูว่าคุณสามารถแก้ไขข้อบกพร่องบางอย่างและ / หรือเพิ่มการทดสอบหน่วยบางอย่าง ดูเหมือนว่าข่มขู่ที่จะมองไปที่ codebase ของคนอื่นด้วยสายตาที่สดใส แต่มันเป็นทักษะที่มีค่าอย่างยิ่งในการเรียนรู้ ส่งแพทช์ คุณสามารถคาดหวังว่าโค้ดของคุณจะได้รับการตรวจสอบอย่างใกล้ชิดในตอนแรก ไม่ต้องกังวลมันเป็นเรื่องปกติของกระบวนการที่จะได้รับความไว้วางใจจากผู้ดูแลโครงการ
หลังจากสร้างฐานของการทำบุญกับผู้ดูแลโครงการเริ่มต้นค้นหาความรับผิดชอบเพิ่มเติมเช่นเสนอคุณสมบัติใหม่หรือขอให้มอบหมายให้ดำเนินการตามคำขอคุณสมบัติ
หากคุณไม่สามารถหาโครงการที่มีอยู่แล้วในหนึ่งในเครือข่ายที่เก็บข้อมูลโอเพ่นซอร์สหลัก (github, sourceforge, google code) ให้นึกถึงแอปที่คุณต้องการใช้ที่ยังไม่มีอยู่และเริ่มต้นด้วยตัวคุณเอง
เตรียมพร้อมที่จะถ่อมตนและคาดหวังว่างานจะได้รับการปฏิเสธเนื่องจากมีการแก้ไขเพิ่มเติม ตำนานที่ทุกคนสามารถเพิ่มรหัสให้กับโครงการโอเพนซอร์สนั้นเป็นเท็จอย่างสมบูรณ์ มีผู้รักษาประตูระหว่างคุณและผลักดันการเข้าถึงเสมอ ยิ่งโค้ดของคุณดีขึ้นเท่าไหร่มันก็จะน้อยลงในระยะยาวเมื่อคุณได้รับความไว้วางใจจากผู้ดูแลโครงการ ถ้าเป็นโครงการของคุณคุณจะเป็นคนเฝ้าประตูนั้น
ปรับปรุง:
ฉันเพิ่งคิดเกี่ยวกับมันและตระหนักว่าฉันไม่ได้กังวลที่จะพูดถึงโครงการที่คำตอบของฉันคือการอ้างอิง สำหรับผู้ที่ต้องการที่จะรู้ว่ามันเป็นSharpPcap Chris Morgan ผู้พัฒนานำเป็นมืออาชีพมากและตรงประเด็น เขาทำงานที่แย่มากในการจัดการโครงการและสอนฉันมากมายเกี่ยวกับสิ่งที่จะทำให้โครงการ OSS เติบโตขึ้น
เนื่องจากข้อ จำกัด ด้านเวลาส่วนตัวฉันไม่สามารถมีส่วนร่วมในรหัสในช่วงเวลาหนึ่งปี แต่ฉันยังคงพยายามที่จะตอบแทนด้วยการซุ่มซ่อนใน Stack Overflow และตอบคำถามเกี่ยวกับ SharpPcap เป็นครั้งคราว