6 บทเรียนที่ฉันได้เรียนรู้จากการพัฒนา Open-Source Projects

มุมมองของนักวิทยาศาสตร์ข้อมูล

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

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

ในช่วงไม่กี่ปีที่ผ่านมา ฉันโชคดีที่ได้มีส่วนร่วมในโอเพ่นซอร์สและมีโอกาสพัฒนาและดูแลแพ็คเกจต่างๆ มากมาย!

การพัฒนาโอเพ่นซอร์สเป็นมากกว่าแค่การเขียนโค้ด

ในช่วงเวลานี้มีอุปสรรคมากมายที่ต้องเอาชนะและมีบทเรียนให้เรียนรู้ ตั้งแต่การพึ่งพาที่ยุ่งยากและตัวเลือกการออกแบบ API ไปจนถึงการสื่อสารกับฐานผู้ใช้

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

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

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

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

เชื่อฉันเถอะว่าการเขียนเอกสารที่ดีนั้นเป็นทักษะในตัวเอง

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

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

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

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

ชุมชนโอเพ่นซอร์สเป็นมากกว่าส่วนรวมอย่างแท้จริง

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

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

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

ยิ่งไปกว่านั้น การพัฒนาโครงการโอเพ่นซอร์สทำให้ฉันมีโอกาสทำงานร่วมกับนักพัฒนาคนอื่นๆ

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

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

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

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

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

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

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

ตัวอย่างเช่น จะดีมากหากแพ็คเกจของคุณได้รับการแนะนำ ข่าวแฮกเกอร์ แต่ไม่ได้บอกว่าใช้สม่ำเสมอหรือไม่

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

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

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

การใช้เวลาทำความเข้าใจผู้ใช้โดยเฉลี่ยจะผลักดันให้เกิดการยอมรับ

ทั้งหมดที่กล่าวมามักนำไปสู่กฎพื้นฐานแต่สำคัญ
ทำให้มันง่ายมาก

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

หากคุณหลงใหลเกี่ยวกับ AI, วิทยาศาสตร์ข้อมูล หรือจิตวิทยา เช่นเดียวกับฉัน โปรดเพิ่มฉันเข้ามาได้เลย LinkedIn หรือติดตามผมได้ที่ Twitter- คุณยังสามารถค้นหาเนื้อหาบางส่วนของฉันได้ใน my เว็บไซต์ส่วนตัว.

ภาพทั้งหมดที่ไม่มีเครดิตแหล่งที่มาถูกสร้างขึ้นโดยผู้เขียน

6 บทเรียนที่ฉันเรียนรู้จากการพัฒนาโครงการ Open-Source ที่เผยแพร่ซ้ำจาก Source https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 ผ่าน https://towardsdatascience.com/feed

<!–

->