สัปดาห์ก่อนได้รับแรงบันดาลใจจากอีเมลสอบถามจากผู้ใช้ CppJieba คนหนึ่ง (ผมก็สงสัยเหมือนกันว่าทำไมหลายคนยังชอบสอบถามทางอีเมล แทนที่จะถามผ่าน issue) ผมจึงปรับโครงสร้างโค้ดของ CppJieba ใหม่ รวบรวม API ต่างๆ ให้ผู้ใช้ใช้งานได้ง่ายขึ้นและเริ่มต้นได้ง่ายขึ้น แล้วก็ถือโอกาสปล่อย CppJieba v3.0.0 และ NodeJieba 1.0.0
ทั้งสองโปรเจกต์นี้มีจำนวน star มากที่สุดบน GitHub ของผม ดูแลมาเกือบสองปีแล้ว นอกจากจะทำให้ GitHub ของผมดูดีขึ้นแล้ว ยังได้รับประโยชน์มากมาย GitHub เป็นสมบัติทางปัญญาของโลก IT หลายปีที่ผ่านมาสิ่งที่สอนผมมากที่สุด เกือบทั้งหมดมาจากโปรเจกต์โอเพนซอร์สบน GitHub
มักมีเพื่อนนักศึกษาถามผมว่าจะเรียนรู้โปรเจกต์โอเพนซอร์สอย่างไร ดังนั้นผมจึงเขียนบทความนี้เพื่อพูดถึงวิธีการเรียนรู้โปรเจกต์โอเพนซอร์สบางอย่าง
ในตอนแรกทุกอย่างเรียบง่ายมาก
วันนั้นผมโพสต์เวย์โบเกี่ยวกับการขุดค้นโค้ด Node.js:
การขุดค้นซอฟต์แวร์น่าสนใจมากจริงๆ checkout ไปยังเวอร์ชันเก่ามาก ดู Makefile ตอนแรกเริ่มของ node ทำให้รู้สึกเหมือนเปิดโหมดง่ายของเกม
ตอนนั้นมีความตื่นเต้นแบบเจ้าเล่ห์ เพราะผมค้นพบว่า Node.js ในตอนแรกก็เรียบง่ายมาก แต่ความเรียบง่ายมักหมายถึงความง่าย เช่น Node.js ในตอนแรกใช้ Makefile ในการจัดการ ไฟล์ที่คอมไพล์ได้ทั้งหมดชัดเจน ไม่ใช่ node-gyp แบบปัจจุบันที่มีโค้ดกองใหญ่ แค่จะเข้าใจความสัมพันธ์ระหว่างไฟล์เหล่านี้ก็ต้องดูนานมาก
สิ่งเหล่านี้เหมือนกับตอนที่ผมเริ่มเขียน CppJieba เพราะข้อบกพร่องของไลบรารีมาตรฐานของภาษา C++ และ C++11 ไม่ได้แพร่หลายนัก แล้วไลบรารีฟังก์ชันทั่วไปหลายอย่าง ทุกคนใช้ไลบรารีอย่าง boost ไม่รู้ว่ามีใครเป็นเหมือนผมไหม คือทุกครั้งที่ใช้โค้ด C++ สิ่งที่น่ารำคาญที่สุดคือต้องติดตั้งโค้ดที่เป็น dependency ต่างๆ และมักจะล้มเหลวเพราะปัญหาเวอร์ชันของโค้ด dependency สถานการณ์นี้รุนแรงมากบน Linux จน vczh ยังเคยเสียดสีเรื่องการติดตั้งซอฟต์แวร์บน linux ว่า: “อ่านไม่ใช่คู่มือการใช้งาน แต่เป็นคู่มือเทคนิคการใช้งาน”
ดังนั้นตั้งแต่แรกผมตัดสินใจไม่พึ่งพาไลบรารีบุคคลที่สามใดๆ เขียนฟังก์ชันที่ต้องใช้เองทั้งหมด จึงเกิดไลบรารี C++ ของผมเองชื่อ limonp แม้ตอนแรกโค้ดจะเรียบง่ายมาก แต่อย่างน้อยโปรแกรมของผมสามารถรันได้โดยไม่ต้องติดตั้ง dependency ใดๆ ปลอดภัยและเบามาก แน่นอนว่า unit test ใช้ gtest แต่เป็นการรวมซอร์สโค้ด gtest เข้ากับโปรเจกต์ของตัวเอง
พิสูจน์แล้วว่าสิ่งนี้สำคัญมาก ยังคงเป็นคำเดิม: ไม่มี dependency ก็ไม่มีปัญหา และต่อมาผมเห็น SSDB ของ ideawu ก็เป็นเช่นนั้น โปรเจกต์โอเพนซอร์สแบบนี้คือโปรเจกต์ที่ให้ความสำคัญกับประสบการณ์ผู้ใช้
สะสมโค้ดสั้นๆ ของตัวเองให้เก่ง
ผมมีโปรเจกต์หนึ่งชื่อ practice ใช้สะสมโค้ดสั้นๆ ของตัวเอง เมื่อผมสัมผัสเทคโนโลยีใหม่ๆ ผมต้องเขียนโค้ดฝึกหัดเล็กๆ ผมจะใส่โค้ดฝึกหัดเหล่านั้นใน repository นี้ บางครั้งโค้ดสั้นๆ เหล่านี้คือเมล็ดพันธุ์ของโปรเจกต์ใหญ่ เหมือนกับที่เห็นในการขุดค้นโค้ด Node.js Node.js ในตอนแรกก็เป็นโค้ดทดลองของผู้เขียน เป็นโค้ดทดลองที่ใช้ JavaScript เขียนบริการ IO แบบอะซิงโครนัส (ตอนแรกโค้ดทำแค่เมื่อเซิร์ฟเวอร์รับคำขอ ก็อ่านไฟล์ซอร์สโค้ด js แล้วส่งผลลัพธ์การทำงานกลับไป เท่านั้นเอง)
เช่น HTTP เซิร์ฟเวอร์ง่ายๆ ที่ผมเขียนเอง ก็ประกอบจากโค้ดทดลองเล็กๆ เช่น การรับส่ง socket, การแยกวิเคราะห์ HTTP header, การสร้าง thread pool ด้วย BlockingQueue ฯลฯ สิ่งเหล่านี้เป็นโค้ดทั่วไป แต่เมื่อประกอบเข้าด้วยกันก็กลายเป็นโปรเจกต์ และการเขียนโค้ดสั้นๆ เหล่านี้ช่วยให้เรียนรู้เทคโนโลยีใหม่ๆ ได้ดีมาก ภายหลังยังสามารถย้อนกลับไปดูได้ ตอนนี้มี GitHub เป็นชุมชนที่ดี สะดวกกว่าตอนเรียนเขียนโปรแกรมสมัยก่อนมาก
ยืนบนบ่าของผู้ก่อนให้เก่ง
เรื่องนี้เข้าใจง่าย คือใช้ประโยชน์จากเอกสารวิเคราะห์ของคนอื่น เช่น ถ้าจะอ่านซอร์สโค้ด Redis ให้ลึกซึ้ง ไม่แนะนำให้อ่านหนังสือ “Redis Design and Implementation” ก่อนแล้วค่อยไปดูซอร์สโค้ด เหมือนกับการเดินเขาวงกต คนอื่นให้แผนที่คุณมา ก็สบายขึ้นมาก แถมยังชมวิวไปด้วยได้
แต่ที่ไม่เข้าใจคือทำไมหลายคนชอบอ่านแบบยากๆ ผมจะอ่านแบบยากๆ ก็ต่อเมื่อเจอโปรเจกต์โอเพนซอร์สใหม่มากๆ ค้นหาเอกสารของผู้ก่อนไม่เจอ ถึงจะจำใจอ่านแบบยากๆ แต่ตอนนี้ผู้เขียนโปรเจกต์โอเพนซอร์สให้ความสำคัญกับเอกสารมาก มักจะเขียนเอกสารซอร์สโค้ดเองอย่างตั้งใจ
จากมุมมองการเรียนรู้ โปรเจกต์โอเพนซอร์สไม่ใช่ยิ่งมี star มากยิ่งดี
โปรเจกต์โอเพนซอร์สไม่ใช่ยิ่งมี star มากยิ่งดี แต่ยิ่งอ่านเข้าใจง่ายสำหรับคุณยิ่งดี โดยทั่วไปยิ่งใกล้เคียงกับงานที่คุณทำอยู่ยิ่งอ่านเข้าใจง่าย เมื่อใกล้เคียงกับงานที่คุณทำ การอ่านซอร์สโค้ดจะนำมาซึ่งแรงบันดาลใจในการพัฒนาหรือปรับโครงสร้าง แม้แค่ดูชื่อไฟล์ ชื่อคลาส คอมเมนต์ซอร์สโค้ด ก็รู้ได้ว่าใช้เทคโนโลยีอะไร แล้วไปค้นหาบทความและบทความวิจัยเกี่ยวกับเทคโนโลยีนั้นๆ มาศึกษาอย่างละเอียด สิ่งเหล่านี้ช่วยได้มาก
ถ้าซอร์สโค้ดที่อ่านไม่เกี่ยวข้องกับงานของตัวเองเลย ก็เข้าใจไม่ลึกซึ้ง แล้วก็ลืมในไม่กี่วัน เหลือแค่ไว้คุยโวให้คนอื่นฟังเวลาอวดดี
การไล่ตามอ่านโค้ดประสิทธิภาพสูงอย่างเดียวไม่ดีนัก “โค้ดเขียนเพื่อให้คนอ่าน และบังเอิญรันบนเครื่องได้” แต่โปรเจกต์โอเพนซอร์สดังๆ หลายโปรเจกต์เพราะประสิทธิภาพสำคัญมาก บางครั้งต้องเสียสละความอ่านง่ายเล็กน้อยเพื่อให้ได้ประสิทธิภาพสูง และโปรเจกต์ดังๆ ที่มี star เยอะ ต้องพิจารณาหลายอย่าง ความเข้ากันได้ ความง่ายในการดูแลรักษา ฯลฯ ล้วนเป็นโค้ดจำนวนไม่น้อย ซึ่งไม่ใช่แก่นของโปรเจกต์ การอ่านซอร์สโค้ด ควรยิ่งอ่านแก่นหลักเข้าใจง่ายยิ่งดี
ความคิดเล็กน้อย
รู้สึกว่าผู้เขียนโปรเจกต์โอเพนซอร์สถูกยกย่องมากขึ้นเรื่อยๆ ทำให้โปรเจกต์โอเพนซอร์สมีความเป็นประโยชน์มากขึ้น
หวังว่าอย่าลืมจุดประสงค์เดิมของโปรเจกต์โอเพนซอร์ส คือเพื่อการแบ่งปันและเผยแพร่ความรู้ที่ดีขึ้น
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
