คำนำอย่างละเอียดถึงการพัฒนา Bitcoin Core ( Jimmy Song )
แปลโดย : Claude 3.7 Sonnet / source : https://medium.com/bitcoin-tech-talk/a-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8
คำนำอย่างละเอียดถึงการพัฒนา Bitcoin Core
Jimmy Song, 1 สิงหาคม 2560
หากคุณเป็นนักพัฒนาและถือครองบิทคอยน์ไม่ว่าจำนวนเท่าใด การมีส่วนร่วมในการพัฒนา Bitcoin Core อาจเป็นหนึ่งในสิ่งที่ดีที่สุดที่คุณสามารถทำเพื่อช่วยเหลือการลงทุนของคุณ ในบทความนี้ ผมจะให้ภาพรวมทีละขั้นตอนอย่างละเอียดเกี่ยวกับวิธีการมีส่วนร่วมในการพัฒนา Core
คุณอยากเป็นนักพัฒนา Core...
ก่อนที่เราจะเข้าสู่รายละเอียดของการมีส่วนร่วมกับ Core มีข้อควรระวังบางประการที่ต้องกล่าวถึง
ประการแรกและสำคัญที่สุด Bitcoin Core เป็นระบบคุณธรรม (meritocracy) ในฐานะผู้เริ่มต้นใหม่ คุณมีโอกาสน้อยที่จะได้รับการผสาน pull request ที่มีการเปลี่ยนแปลง proof-of-work ที่ซับซ้อนเข้าสู่ Core เหมือนกับระบบคุณธรรมทั่วไป คุณเริ่มต้นด้วยชื่อเสียงเป็นศูนย์และค่อยๆ สร้างขึ้นมา
ข่าวดีคือไม่มีใครสนใจภูมิหลังของคุณ ไม่ว่าคุณจะเป็นเด็กอายุ 14 ปีในอินเดียหรือ CTO วัย 45 ปีของบริษัทใน Fortune-500 สิ่งเดียวที่สำคัญจริงๆ คือคุณภาพของงานที่คุณทำ
ข่าวร้ายคือคุณต้องเต็มใจที่จะทิ้งอีโก้ไว้ที่ประตู ไม่มีใครสนใจว่าคุณมีประสบการณ์มากี่ปีหรือคุณมีความคิดดีๆ อะไรสำหรับการแก้ไข Bitcoin คุณภาพของโค้ด การตรวจสอบ เอกสาร และการทดสอบของคุณต่างหากที่สำคัญ
ประการที่สอง คุณควรตั้งความคาดหวังให้เหมาะสม นักพัฒนา Core ที่มีชื่อเสียงเช่น Pieter Wuille, Cory Fields และ Gregory Maxwell ได้รับความเคารพจากการทำงานหนักมาหลายปี การเพิ่ม PR ที่แก้ไขข้อผิดพลาดในการสะกดคำไม่ได้ทำให้คุณได้รับความเคารพระดับ Pieter Wuille งานที่ดีจะทำให้คุณได้รับการยอมรับและความเคารพ แต่เฉพาะหลังจากที่คุณได้สร้างผลงานมาสักระยะหนึ่งแล้ว
ประการที่สาม นี่ไม่ใช่เส้นทางที่ง่าย การเป็นนักพัฒนาระดับสูงของบริษัท X ไม่จำเป็นต้องทำให้คุณเป็นนักพัฒนา Core ที่ดี มีเหตุผลหลากหลายสำหรับเรื่องนี้ แต่โดยทั่วไป งานของคุณต้องมีมาตรฐานสูงในด้านการทดสอบ เอกสาร และการตรวจสอบโค้ด ซึ่งไม่ค่อยพบในบริษัทเทคโนโลยีที่มีความสามารถสูง
กล่าวทั้งหมดนี้ หากคุณมีความถ่อมตัว แรงผลักดัน และความปรารถนาในความเป็นเลิศ การมีส่วนร่วมกับ Core จะทำให้คุณเป็นนักพัฒนา ผู้ตรวจสอบโค้ด ผู้จัดทำเอกสาร และผู้ทดสอบที่ดีขึ้น
ข้อกำหนดเบื้องต้น
คุณจะต้องมีความรู้และทักษะบางอย่างเพื่อเริ่มต้น
Bitcoin Core ใช้ภาษาหลักสองภาษาคือ C++ และ Python คุณน่าจะต้องเรียนรู้อย่างน้อยบางส่วนของทั้งสองภาษาหากคุณหวังที่จะมีส่วนร่วม
การควบคุมซอร์สโค้ดจัดการผ่าน Git เป็นอย่างน้อย คุณควรรู้วิธีดึงข้อมูลจาก origin วิธีสร้าง topic branches และวิธีทำ rebase หากคุณกำลังทดสอบโค้ดของคนอื่น คุณควรรู้วิธีเพิ่มพื้นที่เก็บข้อมูลหลายแห่งในสภาพแวดล้อมการพัฒนาในเครื่องของคุณเพื่อให้คุณสามารถดึงและทดสอบโค้ดได้
การเปลี่ยนแปลงทั้งหมดต่อ Core จะถูกผสานบน GitHub ในรูปแบบ PR ต่อ PR ดังนั้นคุณจะต้องมีบัญชี GitHub
สุดท้าย คุณจะต้องรู้วิธีติดตั้งและลบแพ็คเกจบนแพลตฟอร์มของคุณ คำแนะนำค่อนข้างละเอียด แต่มันช่วยได้ เช่น คุณสามารถเพิ่มและลบ ZMQ ได้ตามต้องการ
การเริ่มต้น
สิ่งแรกที่คุณควรทำเมื่อเริ่มต้นคือการอ่านเอกสารบางอย่าง README และแนวทางการมีส่วนร่วมเป็นจุดเริ่มต้นที่ดี
หลังจากนั้น ให้ไปที่ไดเรกทอรี doc และอ่าน README ที่นั่น เอกสารทั้งหมดในไดเรกทอรี doc จะถูกอธิบายไว้ใน README คุณสามารถกลับมาอ้างอิงได้หากคุณหลงทางหรือสับสนในจุดใดจุดหนึ่ง
โปรดทราบว่าคุณไม่จำเป็นต้องเข้าใจทุกอย่างในทุกเอกสารที่ผมแนะนำ มีคนดีๆ มากมายที่สามารถช่วยคุณได้บน IRC, StackExchange และ Slack หากคุณพบสิ่งที่คุณไม่เข้าใจ
การสร้างจากซอร์สโค้ด
หลังจากที่คุณได้อ่านพื้นฐานเกี่ยวกับวิธีการทำงานของการพัฒนา เริ่มต้นด้วยการสร้าง Bitcoin จากซอร์สโค้ด อันดับแรก โคลนพื้นที่เก็บ Git ของ Bitcoin:
ขั้นตอนต่อไปคือการตั้งค่าสภาพแวดล้อมการพัฒนาของคุณ ซึ่งจะขึ้นอยู่กับแพลตฟอร์มที่คุณใช้อย่างมาก แต่การคอมไพล์เป็นสิ่งที่คุณจะต้องทำบ่อย ดังนั้นจึงคุ้มค่าที่จะทำความเข้าใจส่วนนี้ให้ดี
นอกจากนี้ คุณจะต้องรันการทดสอบแบบบูรณาการทั้งหมด ดังนั้นให้แน่ใจว่าได้เปิดใช้งาน GUI และ ZMQ เมื่อทำตามคำแนะนำด้านล่าง
คำแนะนำสำหรับ *nix อยู่ที่นี่
คำแนะนำสำหรับ osx อยู่ที่นี่
คำแนะนำสำหรับ windows อยู่ที่นี่
คำแนะนำสำหรับ openBSD อยู่ที่นี่
เมื่อคุณตั้งค่าสภาพแวดล้อมของคุณ หากมีบางอย่างไม่ทำงาน ให้ค้นหาข้อผิดพลาดใน Google ก่อนที่จะส่ง PR เอกสาร ตามที่ได้กล่าวไว้ก่อนหน้านี้ IRC, StackExchange และ Slack เป็นทรัพยากรที่ดี แต่โปรดอย่าเป็นคนที่ถามคำถามง่ายๆ และสูญเสียเวลาของทุกคน
การทดสอบ
หลังจากที่คุณได้คอมไพล์ทุกอย่างแล้ว ขั้นตอนต่อไปคือการทดสอบซอฟต์แวร์ โชคดีที่ Bitcoin Core มีการทดสอบหน่วยและการทดสอบแบบบูรณาการหลากหลายเพื่อตรวจสอบว่าซอฟต์แวร์ที่คุณเพิ่งคอมไพล์ทำงานได้อย่างถูกต้อง
อันดับแรก ให้รันการทดสอบหน่วยที่อยู่ที่นี่ การทดสอบหน่วยจะถูกคอมไพล์พร้อมกับทุกอย่าง ดังนั้นสิ่งที่คุณต้องทำคือรันไบนารีที่เป็นผลลัพธ์ ตรวจสอบว่าการทดสอบทั้งหมดผ่าน หากไม่ผ่าน อาจมีคำแนะนำบางอย่างที่พลาดไป
หากการทดสอบหน่วยทั้งหมดของคุณผ่าน ให้รันการทดสอบแบบบูรณาการที่อยู่ที่นี่ คุณจะต้องรันการทดสอบแบบขยาย การทดสอบ pruning โดยเฉพาะใช้เวลานานในการรัน ดังนั้นคุณอาจต้องยกเว้นการทดสอบนั้นเมื่อรันการทดสอบแบบบูรณาการในอนาคต
อีกครั้ง ตรวจสอบว่าการทดสอบทั้งหมดผ่าน คุณจะเห็นจุดมากมายจนกว่าจะมีสรุปปรากฏขึ้นที่ตอนท้าย หากมีบางอย่างไม่ผ่าน คุณอาจพลาดคำแนะนำบางอย่าง แม้ว่าบางครั้ง การทดสอบแบบบูรณาการบางอย่างอาจขึ้นอยู่กับ RAM และ CPU
หมวดหมู่การมีส่วนร่วม
ตอนนี้คุณได้ตั้งค่าระบบของคุณแล้ว คุณสามารถเริ่มมีส่วนร่วมได้!
คุณอาจคิดว่าการมีส่วนร่วมหมายถึงการเพิ่มโค้ดจำนวนมาก ส่ง PR และรับเกียรติยศ แต่ในความเป็นจริง งานส่วนใหญ่เกี่ยวข้องกับการตรวจสอบและทดสอบโค้ดที่ผู้อื่นส่ง ช่วยให้เข้าใจขั้นตอนที่เกี่ยวข้องในการผสาน PR:
มีคนสร้างการเปลี่ยนแปลงและส่งโค้ดผ่าน Pull Request (PR)
คนหนึ่งคนหรือมากกว่าตรวจสอบโค้ด
คนหนึ่งคนหรือมากกว่าทดสอบโค้ด
เมื่อมีคนตรวจสอบและทดสอบโค้ดเพียงพอแล้ว ผู้ดูแลจะผสานโค้ด — มีเพียงไม่กี่คนที่สามารถทำสิ่งนี้ได้
คนส่วนใหญ่คิดว่าการมีส่วนร่วมในโครงการโอเพนซอร์สคือการมีส่วนร่วมเฉพาะโค้ด แต่ในความเป็นจริง การทดสอบและการตรวจสอบมีความสำคัญมากกว่าต่อความสำเร็จของโครงการ การขาดการตรวจสอบและทดสอบมักเป็นสาเหตุของช่องโหว่ด้านความปลอดภัยในหลายโครงการ ดังที่เราเห็นในข้อบกพร่องของ Ethereum Parity ล่าสุด
การตรวจสอบและการทดสอบยังมีความสำคัญเนื่องจากมักเป็นการยากที่จะมีมุมมองแบบปฏิปักษ์ที่ครอบคลุมทุกกรณี การมีหลายสายตามองและทดสอบโค้ดช่วยให้ค้นพบวิธีที่เป็นไปได้ซึ่งโค้ดอาจถูกโจมตี
สุดท้าย ไม่เพียงแต่การตรวจสอบและการทดสอบเป็นสิ่งดีสำหรับโครงการ แต่ยังดีสำหรับคุณด้วย! การตรวจสอบและการทดสอบจะบังคับให้คุณเรียนรู้เพิ่มเติมเกี่ยวกับฐานโค้ดและจะให้ความเข้าใจที่ลึกซึ้งมากกว่าแม้แต่การเขียนโค้ด
การเริ่มต้น
เพื่อให้คุ้นเคยกับกระบวนการมีส่วนร่วม คุณไม่ควรเริ่มต้นด้วยการเพิ่ม PR จำนวนมาก แทนที่จะเป็นนักพัฒนาใหม่ที่ไม่มีชื่อเสียง ทางเลือกที่ดีที่สุดของคุณคือการเริ่มต้นด้วยการตรวจสอบและทดสอบงานของผู้อื่น การตรวจสอบและการทดสอบมักเป็นคอขวด ดังนั้นคุณสามารถมีส่วนร่วมและสร้างชื่อเสียงในชุมชนไปพร้อมกัน
มีประเด็นที่ควรกล่าวถึงที่นี่คือส่วนหนึ่งของเหตุผลที่ Greg Maxwell มีชื่อเสียงดีในหมู่นักพัฒนาคือเขาเป็นผู้ตรวจสอบและทดสอบที่ดีมาก เขามีความสามารถระดับโลกในการค้นหาวิธีที่เป็นไปได้ที่บางสิ่งอาจล้มเหลว และเขาตรวจสอบและทดสอบโค้ดมากกว่าที่เขียน ผมสัญญาว่าคุณจะชื่นชมเขามากขึ้นหลังจากที่คุณได้ตรวจสอบและทดสอบโค้ดด้วยตัวเอง
นอกจากนี้ โค้ดโดยทั่วไปจะถูกเขียนครั้งเดียว แต่ถูกอ่านหลายครั้ง การตรวจสอบจึงเป็นขั้นตอนที่สำคัญกว่าเนื่องจากเผยให้เห็นว่าโค้ดนั้น "อ่านง่าย" เพียงใด กฎทั่วไปคือสำหรับทุก pull request ที่คุณทำ คุณควรตรวจสอบประมาณ 3 pull requests ในตอนเริ่มต้น คุณอาจต้องการให้อัตราส่วนของการตรวจสอบต่อ pull requests สูงกว่านี้
วิธีการตรวจสอบ
โดยทั่วไป คุณจะไม่สามารถให้การตรวจสอบ Pull Request ที่ดีได้จนกว่าคุณจะเข้าใจสิ่งที่โค้ดกำลังทำ ตามที่พูดกันในการเขียนโค้ด การเขียนง่ายกว่าการอ่านมาก ดังนั้นจึงใช้เวลาทำความเข้าใจโค้ดอย่างแท้จริง
บ่อยครั้ง เพื่อให้เข้าใจสิ่งที่เกิดขึ้นใน PR คุณจะต้องค้นหาฟังก์ชันและวิธีการที่กำลังถูกใช้และตรวจสอบบริบทของโค้ดอย่างระมัดระวัง หากคุณสับสนและคนที่คุณกำลังตรวจสอบโค้ดอยู่บน IRC คุณอาจต้องถามคำถามโดยตรง ส่วนใหญ่ ผู้เขียน PR มักจะชื่นชมผู้ตรวจสอบและยินดีที่จะช่วยเหลือคุณ
เช่นเดียวกับการตรวจสอบบทความหรือหนังสือ มีหลายสิ่งที่คุณควรมองหา ได้แก่:
โค้ดกำลังทำสิ่งที่ควรทำหรือไม่?
โค้ดได้รับการทดสอบอย่างเพียงพอหรือไม่?
ความคิดเห็นทั้งหมดรอบๆ โค้ดมีประโยชน์และถูกต้องหรือไม่?
โค้ดชัดเจนและง่ายต่อการแก้ไขในภายหลังหรือไม่?
เป็นกฎทั่วไป หากคุณไม่เห็นด้วยกับวิธีการทำบางสิ่ง ควรสันนิษฐานว่าคุณไม่เข้าใจสิ่งที่เกิดขึ้นแทนที่จะเริ่มบรรยาย ความเห็นอกเห็นใจและความละเอียดอ่อนจะช่วยคุณได้มาก จำไว้ว่า คุณกำลังแสดงความคิดเห็นต่อ "ลูก" ของใครบางคนในหลายๆ ด้าน ถามคำถามและอ่อนโยน อย่างน้อยในตอนแรก บ่อยครั้ง นักเขียนโค้ดเหล่านี้ไม่รู้จักคุณหรือความตั้งใจของคุณ ให้ชัดเจนเมื่อบางสิ่งเป็นปัญหาเล็กน้อยเกี่ยวกับสไตล์เทียบกับปัญหาใหญ่ที่อาจทำให้บางสิ่งเสียหาย เป็นการดีกว่าที่จะฟังดูเหมือนนักเรียนที่พยายามทำความเข้าใจการปรับปรุงมากกว่าผู้เฝ้าประตู
เมื่อคุณแน่ใจว่าโค้ดกำลังพยายามทำอะไร จากนั้นคุณสามารถแสดงความคิดเห็นว่านี่เป็นฟีเจอร์ที่คุ้มค่าหรือไม่ จนกว่าคุณจะสร้างชื่อเสียงได้บ้าง ให้หลีกเลี่ยงความคิดเห็นใดๆ ที่อาจถูกมองในแง่ลบ
เมื่อคุณตรวจสอบโค้ดเสร็จแล้ว ให้แสดงความคิดเห็นใน PR ด้วยความคิดเห็นการตรวจสอบที่เหมาะสม หากคุณต้องการให้ NACK เริ่มต้นใหม่และสันนิษฐานว่าคุณไม่เข้าใจสิ่งที่เกิดขึ้น สนทนากับผู้เขียนและถามคำถามจนกว่าคุณจะแน่ใจว่านี่เป็น PR ที่ไม่ดี แม้แต่ตอนนั้น ให้สนทนากับผู้มีประสบการณ์มากกว่าเพื่อให้แน่ใจ
วิธีการทดสอบ
เพื่อทดสอบอย่างเหมาะสม คุณจะต้องดาวน์โหลดโค้ดจาก pull request คอมไพล์อีกครั้งและรันการทดสอบ หากคุณสามารถคิดวิธีทดสอบฟีเจอร์ด้วยตนเองในบางวิธี ยิ่งดีกว่า แต่ไม่จำเป็น
ส่วนใหญ่ pull request จะรวมการทดสอบหนึ่งรายการหรือมากกว่า หากนักเขียนโค้ดไม่ได้ให้การครอบคลุมการทดสอบ พยายามทำความเข้าใจว่าทำไม — การปรับโครงสร้างมักไม่มีด้วยเหตุผลที่ชัดเจน หากคุณคิดว่าควรมีการทดสอบ คุณสามารถเขียน "นี่ต้องการการทดสอบ" ใน PR ดีกว่านั้น เขียนการทดสอบด้วยตัวเองและแจ้งให้ผู้เขียนทราบว่าสามารถ cherry-pick ได้ที่ไหนใน PR! นี่เป็นวิธีที่ยอดเยี่ยมในการสร้างไมตรีจิตจากคนที่คุณกำลังตรวจสอบโค้ด
งานของคุณในฐานะผู้ทดสอบคือการตรวจสอบว่าการทดสอบผ่านและครอบคลุมฟังก์ชันการทำงานที่แนะนำอย่างเพียงพอ ความคิดเห็นที่ดีในการตรวจสอบอาจเป็น "จะดีถ้าสถานการณ์เช่นนั้นสามารถครอบคลุมโดยการทดสอบที่ทำอย่างนี้"
หลังจากทดสอบ อย่าลืมระบุใน PR ว่าคุณได้ทดสอบแล้ว
Pull Requests ที่ดีขึ้น
ในที่สุด คุณจะถึงจุดที่คุณรู้สึกสบายใจในการสร้าง pull requests ของคุณเอง pull request สามารถเป็นอะไรก็ได้ตั้งแต่การเพิ่มเอกสารไปจนถึงฟังก์ชันการทำงานที่สำคัญต่อฉันทามติ ไม่ว่าจะเป็นการเปลี่ยนแปลงอะไร กุญแจสำคัญในการสร้าง pull requests ที่ดีคือการทำให้เข้าใจง่ายและไม่เป็นภาระในการตรวจสอบ
เพื่อจุดประสงค์นั้น โปรดอย่าทรมานผู้ตรวจสอบของคุณโดยทำให้ PR ของคุณเป็นการคอมมิตเดียวที่มีการเปลี่ยนแปลง 3000 บรรทัด แยกการเปลี่ยนแปลงเหล่านั้นเป็นการคอมมิตที่ตรวจสอบง่ายน้อยกว่า 300 บรรทัด (หรืออาจน้อยกว่า 100!) และจัดกลุ่มอย่างเหมาะสม ตัวอย่างเช่น คุณควรใส่การเปลี่ยนแปลงการจัดรูปแบบในการคอมมิตหนึ่ง การเปลี่ยนแปลงการเขียนโค้ดจริงในอีกหนึ่ง และการย้ายบล็อกโค้ดขนาดใหญ่ในอีกหนึ่ง
พยายามอธิบายอย่างชัดเจนว่าคุณกำลังทำอะไรและเหตุผลเบื้องหลังสิ่งที่คุณได้ทำในแต่ละการคอมมิต ผมไม่สามารถเน้นย้ำส่วนนี้ได้มากพอ ทำให้ทุกอย่างใน PR ของคุณเข้าใจง่าย! หากคุณไม่ทำ คุณจะไม่มีใครมาตรวจสอบโค้ดของคุณ
เมื่อผู้ตรวจสอบแสดงความคิดเห็นหรือแนะนำการเปลี่ยนแปลง พยายามทำความเข้าใจว่าเหตุผลคืออะไร หากคุณไม่เข้าใจ ถามจนกว่าจะชัดเจนว่าพวกเขาต้องการให้คุณทำอะไร หากคุณเห็นด้วย ทำการเปลี่ยนแปลงที่เหมาะสมและแจ้งให้ผู้ตรวจสอบทราบ แต่หากไม่ ตรวจสอบให้แน่ใจว่าคุณมีการสนทนาที่เป็นผู้ใหญ่และมีความละเอียดอ่อนกับพวกเขาเพื่อดูว่าคุณจะได้รับ ACKs ของพวกเขาได้อย่างไร
แนวคิด PR เมื่อเริ่มต้น
นี่คือแนวคิด PR บางอย่างที่คุณสามารถมีส่วนร่วมได้ทันที (จำไว้ว่า ตรวจสอบ 3 เท่าของ PR ที่คุณส่ง!)
ทำเอกสาร โดยเฉพาะเกี่ยวกับการตั้งค่า ให้ชัดเจน
เขียนการทดสอบหน่วยหรือการทดสอบแบบบูรณาการสำหรับสิ่งที่ยังไม่ได้รับการทดสอบ
เขียนความคิดเห็นในโค้ดที่ไม่มีเอกสารเพื่อช่วยให้คนอื่นหาทางของพวกเขา
บทสรุป
แนวทางการพัฒนาซอฟต์แวร์ที่ใช้โดย Bitcoin Core มักไม่ได้ถูกใช้ในสภาพแวดล้อมอื่น คนส่วนใหญ่ที่เข้ามาในการพัฒนา Core พบว่ากระบวนการมีข้อจำกัดและข้อบังคับมากเกินไป ผมขอรับรองว่ามีเหตุผลสำหรับทุกขั้นตอน
จำไว้ว่าให้มีมารยาท อ่อนโยน และมีความละเอียดอ่อน เข้ามาด้วยทัศนคติที่ถ่อมตัวและความปรารถนาที่จะเรียนรู้และนั่นจะนำคุณไปสู่เส้นทางไม่เพียงแต่การเป็นนักพัฒนาที่ดีขึ้น แต่ยังเป็นพลังเพื่อความดีในชุมชน Bitcoin อีกด้วย
Last updated