การตรวจสอบโค้ด

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

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

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

การเรียนรู้เป็น "ผู้ร่วมให้ข้อมูล XLA เต็มรูปแบบ" ไม่ใช่แค่การเขียนโค้ด โดยไม่มีข้อบกพร่อง ยังมีอีกหลายสิ่งให้เรียนรู้เกี่ยวกับการร่วมให้ข้อมูลกับ XLA รวมถึงกรณีต่อไปนี้

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

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

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

  • ตรวจสอบ PR อย่างละเอียดและ/หรือให้เพื่อนร่วมงานตรวจสอบ PR ของคุณก่อนส่ง: ลองนำข้อผิดพลาดเล็กๆ น้อยๆ ออก (สไตล์โค้ด ข้อผิดพลาดด้านไวยากรณ์ และไวยากรณ์ ฯลฯ) ก่อนส่งไปเข้ารับการตรวจสอบ ตรวจสอบว่าการทดสอบทั้งหมดผ่าน
  • อ่านความคิดเห็นของผู้ตรวจสอบอย่างละเอียด: พยายามทำความเข้าใจสิ่งที่ผู้รีวิวขอและพยายามจัดการกับความคิดเห็นทั้งหมดก่อนที่จะลองใช้เวอร์ชันใหม่
  • หลีกเลี่ยงการสนทนาที่จับต้องได้ (การปั่นจักรยาน): การพูดคุยทางเทคนิคและการไม่เห็นด้วยร่วมกันเป็นสิ่งที่มีค่ามากและไม่มีใครสมบูรณ์แบบ อย่างไรก็ตาม โปรดหลีกเลี่ยงการพูดคุยที่ไม่ก่อให้เกิดความแตกต่างหรือเป็นเพียงสไตล์การเขียน หากคุณไม่เห็นด้วยกับความคิดเห็นของผู้ตรวจสอบ ให้พยายามอธิบายเหตุผลของคุณโดยละเอียดและครบถ้วนที่สุด เพื่อหลีกเลี่ยงการพูดคุยกันไปมาเป็นเวลานาน
  • หลีกเลี่ยงการถาม "คําถามที่พบบ่อยเกี่ยวกับรีวิว" ตามรายการด้านล่าง: เราได้ระบุคําตอบสําหรับคําถามที่พบบ่อยและเหตุผลของเราไว้ด้านล่าง

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

ขอขอบคุณที่มีส่วนร่วมกับ XLA และขอให้สนุกกับการแฮ็ก

คำถามที่พบบ่อยเกี่ยวกับรีวิว

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

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

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

"ฉันจะจัดการกับความคิดเห็นของคุณในการประชาสัมพันธ์ในอนาคตได้ไหม"

คำถามที่พบบ่อยเกี่ยวกับคำขอโครงสร้างพื้นฐาน (หรือคำขอขนาดใหญ่อื่นๆ) ในการประชาสัมพันธ์คือ การเปลี่ยนแปลงต้องทำในการประชาสัมพันธ์เดิมหรือไม่ หรือสามารถดำเนินการเป็นการติดตามผลในการประชาสัมพันธ์ในอนาคตได้หรือไม่

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

มีเหตุผล 2-3 ข้อที่ XLA ใช้แนวทางนี้

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

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

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