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

สวนสัตว์เทคโนโลยีในโปรเจกต์คืออะไร

สวนสัตว์เทคโนโลยี คือสถานการณ์ที่โปรเจกต์หรือบริษัทใช้เครื่องมือที่ต่างกันจำนวนมากเกินไปเพื่อแก้ไขงานเดียวกัน ตัวอย่างเช่น HTTP client ที่แตกต่างกันสามตัว (Alamofire, OkHttp, Ktor), ตัวจัดการสถานะสองตัว (Redux, MobX) และฐานข้อมูลสามแห่ง (Realm, CoreData, SQLite)

ความแตกต่างระหว่างสวนสัตว์และการเลือกใช้เครื่องมือที่แตกต่างกันสำหรับงานที่แตกต่างกันอย่างมีจุดประสงค์คือการขาดกลยุทธ์ หากทีม A เลือก React Native ทีม B เลือก Flutter และทีม C เลือก Kotlin Multiplatform โดยไม่มีการตัดสินใจร่วมกัน — นั่นคือสวนสัตว์ ความหลากหลายในตัวมันเองไม่เป็นอันตราย ธรรมชาติที่ไร้การควบคุมของมันต่างหากที่เป็นอันตราย

สแต็กใหม่แต่ละอันในโปรเจกต์เพิ่ม ภาระทางปัญญา ให้กับนักพัฒนา เพื่อทำงานอย่างมีประสิทธิภาพ ต้องจดจำรายละเอียดปลีกย่อยของเทคโนโลยีทั้งหมดที่ใช้ ตามข้อมูลของ Google (2024) การสลับบริบทระหว่างสแต็กที่แตกต่างกันลดประสิทธิภาพการทำงานของนักพัฒนา 23% เมื่อเทียบกับการทำงานในสภาพแวดล้อมทางเทคโนโลยีที่เป็นหนึ่งเดียว

สาเหตุของสวนสัตว์เทคโนโลยี

การตัดสินใจแบบกระจายศูนย์ เป็นสาเหตุหลัก แต่ละทีมเลือกเทคโนโลยีสำหรับโปรเจกต์ของตนโดยไม่คำนึงถึงกลยุทธ์โดยรวม ทีม backend ใช้ Kotlin ทีม ML ใช้ Python ทีมโมบายล์ใช้ Flutter เมื่อแยกกัน การตัดสินใจถูกต้อง แต่เมื่อรวมกันแล้วสร้างสวนสัตว์

การควบรวมและซื้อกิจการ (M&A) — เมื่อบริษัทหนึ่งซื้ออีกบริษัทหนึ่ง สแต็กเทคโนโลยีจะรวมกัน สองระบบแก้ไขปัญหาเดียวกันด้วยวิธีที่แตกต่างกัน ตัวอย่าง: หลังจากซื้อสตาร์ทอัพ บริษัทใหญ่ได้รับสแต็ก Ruby on Rails แม้ว่ามาตรฐานภายในจะเป็น Java Spring คำถามเกิดขึ้น: เขียนใหม่หรือบำรุงรักษาสองสแต็กแบบขนาน

การเปลี่ยนแปลงเทคโนโลยียอดนิยม — แต่ละวงจรกระแสเพิ่มสแต็กใหม่ ในปี 2015 ทุกคนเขียนด้วย AngularJS ในปี 2017 — ด้วย React ในปี 2020 — ด้วย Svelte หากไม่มีวินัย โปรเจกต์จะสะสมชั้นจากยุคต่างๆ โมดูลมรดกตกทอดที่ทำงานแต่ไม่ได้รับการสนับสนุนเพิ่มความแตกต่างโดยไม่มีความสามารถในการกำจัดมันอย่างรวดเร็ว

ทำไมสวนสัตว์ถึงเป็นอันตรายต่อทีมและธุรกิจ

การเริ่มต้นทำงานของนักพัฒนาใหม่ กลายเป็นการเรียนรู้เทคโนโลยีที่แตกต่างกัน 5+ รายการแทนที่จะเป็นหนึ่งรายการ แทนที่จะใช้เวลาหนึ่งสัปดาห์ในการทำความเข้าใจโปรเจกต์ ผู้มาใหม่ใช้เวลาหนึ่งเดือนในการฝึกฝนเครื่องมือทั้งหมดที่ใช้ เวลาสู่ประสิทธิภาพการทำงาน เพิ่มขึ้นตามสัดส่วนของจำนวนสแต็กในโปรเจกต์

การสลับบริบท — นักพัฒนาที่ทำงานกับ 3+ สแต็กในระหว่างวันใช้เวลาถึง 30% ในการฟื้นฟูบริบทหลังการสลับแต่ละครั้ง ตามข้อมูลของ มหาวิทยาลัยแคลิฟอร์เนีย (2023) หลังการสลับแต่ละครั้งต้องใช้เวลา 23 นาทีเพื่อกลับสู่ระดับประสิทธิภาพการทำงานเดิม ด้วยการสลับ 5 ครั้งต่อวัน — เสียเวลาเกือบ 2 ชั่วโมง

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

ความซับซ้อนของโครงสร้างพื้นฐาน — CI/CD ต้องกำหนดค่าสำหรับแต่ละสแต็ก ระบบบิลด์ที่แตกต่างกัน (Gradle, CocoaPods, npm, pip) ความต้องการสภาพแวดล้อมที่แตกต่างกัน ทีมโครงสร้างพื้นฐานใช้ทรัพยากรในการบำรุงรักษาไปป์ไลน์ที่แตกต่างกันแทนที่จะปรับปรุงพวกมัน

วิธีวินิจฉัยปัญหาในโปรเจกต์

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

Technology Radar — วิธีการของ ThoughtWorks ที่แบ่งเทคโนโลยีออกเป็น 4 จตุภาค: Adopt, Trial, Assess, Hold Adopt — สแต็กที่แนะนำ Trial — ทดลอง Assess — อยู่ระหว่างการประเมิน Hold — ไม่แนะนำให้ใช้ ตัวอย่าง: Flutter อยู่ใน Adopt, React Native อยู่ใน Hold — ทีมเข้าใจว่าจะเลือกอะไร

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

วิธีการมาตรฐานสแต็กเทคโนโลยี

Architecture Decision Records (ADR) — การบันทึกการตัดสินใจทางสถาปัตยกรรมพร้อมเหตุผลในการเลือกเทคโนโลยี แต่ละ ADR ประกอบด้วยบริบท ทางเลือกที่พิจารณา และข้อโต้แย้งสำหรับการเลือก Michael Nygard (2022) ทำให้แนวทางนี้เป็นที่นิยม และวันนี้ ADR เป็นมาตรฐานสำหรับทีมที่ควบคุมความหลากหลายทางเทคโนโลยี

Technology Review Board — คณะกรรมการของนักพัฒนาระดับนำที่อนุมัติเทคโนโลยีใหม่ในโปรเจกต์ การตัดสินใจขึ้นอยู่กับเกณฑ์: ความเข้ากันได้กับสแต็กที่มีอยู่ การสนับสนุนจากชุมชน ค่าใช้จ่ายในการย้าย ความพร้อมของบุคลากร Spotify ใช้คณะกรรมการที่คล้ายกันตั้งแต่ปี 2018

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

การลดความหลากหลายของสแต็กอย่างค่อยเป็นค่อยไป

ระยะที่ 1: หยุด — โปรเจกต์ใหม่บนสแต็กที่ไม่ได้รับการสนับสนุนถูกหยุด กำหนดวันสิ้นสุดการใช้งานสำหรับแต่ละสแต็กในจตุภาค Hold ฟังก์ชันการทำงานใหม่เขียนบนสแต็กที่ได้รับการอนุมัติเท่านั้น โมดูลมรดกตกทอด ยังคงทำงานต่อไปแต่ไม่ถูกขยาย

ระยะที่ 2: การรวม — เลือกเครื่องมือหนึ่งรายการสำหรับแต่ละงาน HTTP client หนึ่งตัว ตัวจัดการสถานะหนึ่งตัว ฐานข้อมูลหนึ่งแห่ง โมดูลบนสแต็กทางเลือกถูกกำหนดเวลาสำหรับการย้ายตามลำดับความสำคัญ รูปแบบ Strangler Fig เป็นวิธีการหลักสำหรับการแทนที่โดยไม่ต้องหยุดระบบ

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

ตัวอย่าง: การย้าย HTTP client

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}