จักรยานในการเขียนโปรแกรม: มันคืออะไร สาเหตุและวิธีหลีกเลี่ยง

จักรยานในการเขียนโปรแกรมคืออะไร

จักรยาน — คำศัพท์ในชุมชนนักพัฒนา ซึ่งหมายถึงการสร้างการทำงานของตัวเองที่อยู่ในรูปแบบของไลบรารี เฟรมเวิร์ก หรือบริการที่มีอยู่แล้ว ในภาษาอังกฤษใช้สำนวน reinventing the wheel — การประดิษฐ์ล้อ ในภาษาไทยก็มีคำว่า «จักรยาน» «การทำงานที่เขียนเอง» «จักรยานของตัวเอง»

ที่มาของการเปรียบเทียบเกี่ยวข้องกับความจริงที่ว่า ล้อ — เป็นหนึ่งในสิ่งประดิษฐ์ที่เก่าแก่ที่สุดของมนุษยชาติ การพยายามสร้างมันขึ้นมาใหม่ในศตวรรษที่ 21 ไม่มีความหมาย ในการเขียนโปรแกรม การเปรียบเทียบยังถูกต้องยิ่งขึ้น: ไลบรารีที่พร้อมใช้เป็น «ล้อ» ที่ได้รับการปรับให้เหมาะสมที่สุดโดยวิศวกรผู้ชำนาญการหลายพันคนเป็นเวลาหลายปี การสร้างล้อของตัวเองที่มีคุณภาพต่ำกว่าเป็นการสิ้นเปลืองทรัพยากร

RedMonk ในรายงานวิเคราะห์ (2023) คำนวณได้ว่า โดยเฉลี่ยแอปพลิเคชันเชิงพาณิชย์ใช้ประมาณ 500 การพึ่งพาภายนอก หากนักพัฒนาเขียนแต่ละอย่างด้วยตัวเอง ต้นทุนของโปรเจกต์จะเพิ่มขึ้นหลายเท่า และเวลาออกสู่ตลาดจะนานออกไปหลายปี ระบบนิเวศตัวจัดการแพคเกจ (npm, Maven, PyPI, NuGet) มีอยู่เพื่อหลีกเลี่ยงการประดิษฐ์จักรยาน

ลักษณะของจักรยาน

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

ความแตกต่างระหว่างจักรยานและโซลูชันที่กำหนดเอง

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

ทำไมนักพัฒนาถึงประดิษฐ์จักรยาน

สาเหตุแรก และพบบ่อยที่สุด — การไม่รู้จักโซลูชันที่มีอยู่ นักพัฒนา Junior อาจไม่รู้ว่ามีฟังก์ชันในตัวสำหรับการแยกวิเคราะห์ JSON อยู่ในไลบรารีมาตรฐาน แทนนั้นเขาจะเขียน parser เอง ปัญหานี้เกี่ยวข้องโดยเฉพาะกับผู้เริ่มต้นที่เพิ่งเข้าระบบนิเวศของภาษา

สาเหตุที่สอง — ภาพลวงตาเรื่องการควบคุม นักพัฒนาที่มีประสบการณ์บางครั้งเชื่อว่า «เขาเขียนได้ดีกว่า» ผู้เขียนไลบรารียอดนิยม สถิติพูดตรงกันข้าม: ความน่าจะเป็นของข้อผิดพลาดในไลบรารีที่ใช้ในล้านโปรเจกต์นั้นต่ำกว่าในโค้ดที่เขียนใหม่มาก ตามข้อมูลของ Synopsys (2024) โค้ด Open Source มีข้อผิดพลาดเฉลี่ย 0.1 จุดต่อพันบรรทัด ในขณะที่โค้ดขององค์กรมี 1–2

สาเหตุที่สาม — การขาดวัฒนธรรมการใช้ซ้ำ ในบริษัทที่ไม่มีการศึกษาโซลูชันที่มีอยู่ก่อนเริ่มงาน นักพัฒนาแต่ละคนจะสร้าง «จักรยานของตัวเอง» ซึ่งนำไปสู่การกระจายตัวของโค้ด: ในโปรเจกต์เดียวอาจมี HTTP-ไคลเอนต์สามแบบที่แตกต่างกันซึ่งเขียนโดยพนักงานคนละคน

แง่มุมทางจิตวิทยา

ปรากฏการณ์ IKEA — ปรากฏการณ์ทางจิตวิทยาที่ผู้คนให้คุณค่ากับสิ่งที่ตัวเองสร้างสูงกว่าสิ่งที่ดีที่สุดในเชิงวัตถุวิสัย ในการเขียนโปรแกรม สิ่งนี้แสดงออกเป็นความภูมิใจใน «จักรยานของตัวเอง» และไม่ต้องการแทนที่ด้วยไลบรารีที่พร้อมใช้แม้ว่าหลังจะมีข้อดีที่ชัดเจน

ผลกระทบของการสร้างจักรยานในโปรเจกต์

ผลกระทบทางเศรษฐกิจ ชัดเจนที่สุด จากการประเมินของ Stripe (2022) นักพัฒนาใช้เวลามากถึง 35% ของเวลาทำงานในการสร้างโค้ดที่มีอยู่แล้วในรูปแบบของโซลูชันที่พร้อมใช้ เมื่อคำนวณเป็นเงินเดือนของทีมที่มี 10 คน นี่เป็นเงินประมาณ 200,000 ดอลลาร์ต่อปีที่สูญเสียไปกับการประดิษฐ์จักรยาน

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

Google ในงานวิจัยเรื่อง «Why Google Stores Billions of Lines of Code» (2023) กล่าวว่าแม้แต่ในบริษัทเทคโนโลยีที่ใหญ่ที่สุดก็ยังมีกระบวนการตัดสินใจที่เข้มงวดในการเพิ่มการพึ่งพาใหม่หรือเขียนของตัวเอง ทีมส่วนใหญ่จะค้นหาโซลูชันที่พร้อมใช้ในคลังโค้ดรวมก่อน

ผลกระทบต่อทีม

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

ตัวอย่างจักรยานที่พบบ่อยในโค้ด

ที่ พบบ่อยที่สุด — การแยกวิเคราะห์ JSON หรือ XML ด้วยตนเอง ทั้งที่ภาษาเกือบทั้งหมดในปัจจุบันมีเครื่องมือในตัว นักพัฒนาเขียนฟังก์ชันการเดินโครงสร้างต้นไม้ของออบเจกต์แบบเรียกซ้ำ โดยไม่รู้ว่า JSON.parse() แก้ปัญหาในหนึ่งบรรทัด

ตัวอย่างที่สอง — การสร้าง HTTP-ไคลเอนต์ของตัวเอง ไลบรารีมาตรฐาน (fetch, axios, OkHttp, URLSession) รองรับการเก็บแคช การเชื่อมต่อใหม่ การหมดเวลา และความปลอดภัย ไคลเอนต์ที่เขียนเองโดยทั่วไปไม่คำนึงถึงอย่างน้อยหนึ่งข้อกำหนดเหล่านี้ ซึ่งนำไปสู่บักในโปรดักชัน

ตัวอย่างที่สาม — ระบบการบันทึกที่เขียนเองแทนที่จะใช้ SLF4J, Winston หรือ Log4j นักพัฒนาใช้เวลาหลายสัปดาห์เขียนสิ่งที่ไลบรารีที่พร้อมใช้ทำได้ทันที โดยรองรับการหมุนเวียน ระดับการบันทึก การเขียนแบบอะซิงโครนัส และการผนวกรวมกับระบบติดตาม

# จักรยาน — การแยกวิเคราะห์ CSV ด้วยตนเอง
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# ใช้ไลบรารีมาตรฐานแทน
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

แอนติแพทเทิร์น ORM ที่เขียนเอง

การเขียน ORM (Object-Relational Mapping) ของตัวเอง — อาจเป็นจักรยานที่แพงที่สุด ไลบรารี ORM ที่พร้อมใช้อย่าง Hibernate, Entity Framework หรือ SQLAlchemy ได้รับการพัฒนามาหลายปี รองรับการเก็บแคช การโหลดแบบขี้เกียจ การย้ายข้อมูล และ DBMS หลายสิบชนิด ORM ที่เขียนเองโดยทั่วไปจำกัดเฉพาะฐานข้อมูลเดียวและมีข้อผิดพลาดร้ายแรงในการจัดการการเชื่อมต่อ

เมื่อไรที่จักรยานถูกต้อง

การเรียนรู้ — สถานการณ์เดียวที่จักรยานไม่เพียงแต่สมเหตุสมผลแต่ยังมีประโยชน์ การเขียน parser, HTTP-server หรือ ORM ของตัวเองเพื่อการศึกษา ช่วยให้เข้าใจว่าเครื่องมือเหล่านี้ทำงานภายใต้ฝาอย่างไร สำคัญคือต้องแยกความแตกต่างระหว่างโปรเจกต์การศึกษาและโค้ดโปรดักชัน: สิ่งที่ดีสำหรับ pet-project อาจไม่สามารถยอมรับได้ในการพัฒนาเชิงพาณิชย์

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

ข้อจำกัดด้านลิขสิทธิ์ — อีกเหตุผลที่ชอบด้วยกฎหมาย ใบอนุญาต Open Source บางฉบับ (GPL, AGPL) อาจไม่สอดคล้องกับโมเดลธุรกิจของบริษัท ในกรณีเช่นนี้ การพัฒนาการดำเนินงานของตัวเองภายใต้ใบอนุญาตที่มีขอบเขตกว้างกว่าก็สมเหตุสมผล

กฎของสามความพยายาม

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

วิธีหลีกเลี่ยงการสร้างจักรยาน

ขั้นตอนแรก — การสร้างนิสัยในการค้นหาโซลูชันที่มีอยู่ก่อนเริ่มงานกับงานที่เป็นระบบ ใช้การค้นหาผ่านตัวจัดการแพคเกจ GitHub, Stack Overflow เวลาที่ใช้ในการวิจัยจะคุ้มค่าหลายเท่าโดยการไม่ต้องเขียนโค้ดของตัวเอง

ขั้นตอนที่สอง — การนำ code review ที่มีจุดเน้นในการระบุจักรยาน ในการตรวจสอบให้ถามว่า: «ทำไมเราไม่ใช้ไลบรารีที่พร้อมใช้สำหรับงานนี้?» หากคำตอบไม่มีเหตุผลที่ชัดเจน — นี่คือจักรยาน ในบริษัทใหญ่ (Google, Meta) code review รวมถึงขั้นตอนบังคับในการตรวจสอบการประดิษฐ์จักรยาน

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

• ค้นคว้า ตัวจัดการแพคเกจก่อนเริ่มงานใหม่
• ตรวจสอบ ไลบรารีมาตรฐานของภาษา — มันครอบคลุม 80% ของงานทั่วไป
• ใช้ code review เพื่อระบุจักรยาน
• เอกสาร การตัดสินใจเกี่ยวกับการเลือกไลบรารี
• อัปเดต ความรู้เกี่ยวกับระบบนิเวศในการประชุมและบล็อก

กลุ่มอาการ Not Invented Here

NIH-กลุ่มอาการ (Not Invented Here — «ไม่ได้ประดิษฐ์ที่เรา») — อคติขององค์กรต่อการใช้โซลูชันภายนอก บริษัทที่มี NIH-กลุ่มอาการชอบพัฒนาทุกอย่างด้วยตัวเอง ปฏิเสธไลบรารี Open Source แม้ว่าจะเหนือกว่าสิ่งที่พัฒนาของตัวเอง กลุ่มอาการนี้เป็นจักรยานระดับองค์กร

ตัวอย่างคลาสสิก — Netscape ในปลายทศวรรษ 1990 เมื่อบริษัทใช้เวลาหลายปีเขียนเบราว์เซอร์ใหม่จากศูนย์แทนที่จะพัฒนาโค้ดเบสที่มีอยู่ ผลลัพธ์ — การสูญเสียส่วนแบ่งตลาดและการถูก AOL เข้าซื้อ ในทางกลับกัน Android สร้างบนเคอร์เนล Linux และใช้ส่วนประกอบ Open Source นับพัน — สิ่งนี้ช่วยนำผลิตภัณฑ์ออกสู่ตลาดในเวลาที่เป็นประวัติการณ์

Harvard Business Review (2023) พบว่าบริษัทที่มีระดับ NIH-กลุ่มอาการต่ำนำผลิตภัณฑ์ออกสู่ตลาดเร็วขึ้น 40% และใช้จ่ายในการพัฒนาน้อยลง 30% วัฒนธรรมการใช้โค้ดซ้ำเป็นข้อได้เปรียบทางการแข่งขันในการพัฒนาสมัยใหม่

// จักรยาน — การimplement การเรียงลำดับแบบกำหนดเอง
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// การเรียงลำดับในตัว — โซลูชันมาตรฐาน
arr.sort((a, b) => a - b);