Vườn thú công nghệ trong dự án: định nghĩa, nguyên nhân và giải pháp

Vườn thú công nghệ trong dự án là gì

Vườn thú công nghệ là tình huống khi một dự án hoặc công ty sử dụng số lượng quá mức các công cụ không đồng nhất để giải quyết cùng một nhiệm vụ. Ví dụ, ba HTTP client khác nhau (Alamofire, OkHttp, Ktor), hai trình quản lý trạng thái (Redux, MobX) và ba cơ sở dữ liệu (Realm, CoreData, SQLite).

Sự khác biệt giữa vườn thú và việc lựa chọn có chủ ý các công cụ khác nhau cho các nhiệm vụ khác nhau là sự thiếu vắng chiến lược. Nếu nhóm A chọn React Native, nhóm B chọn Flutter, và nhóm C chọn Kotlin Multiplatform mà không có quyết định chung — đó là vườn thú. Sự đa dạng tự nó không có hại; bản chất không kiểm soát được của nó mới có hại.

Mỗi stack mới trong dự án làm tăng tải nhận thức cho các nhà phát triển. Để làm việc hiệu quả, cần phải nhớ các sắc thái của tất cả công nghệ được sử dụng. Theo Google (2024), việc chuyển đổi ngữ cảnh giữa các stack khác nhau làm giảm năng suất của nhà phát triển 23% so với làm việc trong môi trường công nghệ thống nhất.

Nguyên nhân của vườn thú công nghệ

Quyết định phi tập trung là nguyên nhân chính. Mỗi nhóm chọn công nghệ cho dự án của mình mà không quan tâm đến chiến lược tổng thể. Nhóm backend sử dụng Kotlin, nhóm ML sử dụng Python, nhóm di động sử dụng Flutter. Riêng lẻ, các quyết định đều đúng, nhưng cùng nhau chúng tạo ra một vườn thú.

Sáp nhập và Mua lại (M&A) — khi một công ty mua lại công ty khác, các stack công nghệ hợp nhất. Hai hệ thống giải quyết cùng một vấn đề theo những cách khác nhau. Ví dụ: sau khi mua lại một startup, một công ty lớn có được stack Ruby on Rails của nó, mặc dù tiêu chuẩn nội bộ là Java Spring. Câu hỏi đặt ra: viết lại hay duy trì hai stack song song.

Thay đổi công nghệ thời thượng — mỗi chu kỳ hype thêm một stack mới. Năm 2015, mọi người viết bằng AngularJS, năm 2017 — bằng React, năm 2020 — bằng Svelte. Nếu không có kỷ luật, một dự án tích tụ các lớp từ nhiều thời đại khác nhau. Các module legacy hoạt động nhưng không được hỗ trợ làm tăng tính không đồng nhất mà không có khả năng loại bỏ nhanh chóng.

Tại sao vườn thú nguy hiểm cho nhóm và doanh nghiệp

Onboarding nhà phát triển mới trở thành việc học 5+ công nghệ khác nhau thay vì một. Thay vì một tuần để hòa nhập vào dự án, người mới mất một tháng để làm chủ tất cả công cụ được sử dụng. Thời gian đến năng suất tăng tỷ lệ thuận với số lượng stack trong dự án.

Chuyển đổi ngữ cảnh — một nhà phát triển làm việc với 3+ stack trong ngày dành tới 30% thời gian để khôi phục ngữ cảnh sau mỗi lần chuyển đổi. Theo Đại học California (2023), sau mỗi lần chuyển đổi, cần 23 phút để trở lại mức năng suất ban đầu. Với 5 lần chuyển đổi mỗi ngày — gần 2 giờ bị mất.

Rủi ro bảo mật — mỗi stack yêu cầu cập nhật, giám sát lỗ hổng và kiến thức về các phương pháp hay nhất. Một nhóm không thể là chuyên gia trong tất cả công nghệ cùng lúc. Mệt mỏi phụ thuộc — khi số lượng thư viện được sử dụng vượt quá khả năng theo dõi và cập nhật của nhóm — là mối đe dọa trực tiếp đến bảo mật sản phẩm.

Phức tạp hạ tầng — CI/CD cần được cấu hình cho mỗi stack. Các hệ thống build khác nhau (Gradle, CocoaPods, npm, pip), yêu cầu môi trường khác nhau. Nhóm hạ tầng dành tài nguyên để duy trì các pipeline không đồng nhất thay vì cải thiện chúng.

Cách chẩn đoán vấn đề trong dự án

Kiểm kê stack — tổng hợp danh sách đầy đủ các công nghệ được sử dụng: ngôn ngữ, framework, cơ sở dữ liệu, CI/CD, hệ thống giám sát. Với mỗi công nghệ, ghi lại số lượng dự án/module, mức độ hỗ trợ và số lượng nhà phát triển thành thạo ở cấp độ chuyên nghiệp.

Technology Radar — phương pháp của ThoughtWorks chia công nghệ thành 4 góc phần tư: Adopt, Trial, Assess, Hold. Adopt — stack được khuyên dùng, Trial — thử nghiệm, Assess — đang đánh giá, Hold — không khuyên dùng. Ví dụ: Flutter ở Adopt, React Native ở Hold — các nhóm hiểu nên chọn gì.

Chỉ số chi phí bảo trì — ước tính bao nhiêu giờ kỹ thuật được dành cho việc bảo trì mỗi stack mỗi tháng. Nếu một stack tiêu thụ 10% tài nguyên nhưng được sử dụng trong 2% module — nó là ứng viên để thay thế. Bản đồ nhiệt stack với trục "số lượng dự án" vs "độ phức tạp bảo trì" hiển thị rõ các khu vực có vấn đề.

Phương pháp tiêu chuẩn hóa stack công nghệ

Architecture Decision Records (ADR) — tài liệu hóa các quyết định kiến trúc với lý do chọn công nghệ. Mỗi ADR chứa bối cảnh, các phương án đã xem xét và lập luận cho lựa chọn. Michael Nygard (2022) đã phổ biến cách tiếp cận này, và ngày nay ADR là tiêu chuẩn cho các nhóm kiểm soát sự đa dạng công nghệ.

Technology Review Board — ủy ban gồm các nhà phát triển chủ chốt phê duyệt công nghệ mới trong dự án. Quyết định được đưa ra dựa trên các tiêu chí: tương thích với stack hiện tại, hỗ trợ cộng đồng, chi phí di chuyển, sẵn có nhân tài. Spotify đã sử dụng ủy ban tương tự từ năm 2018.

Cổng cho dự án mới — quy tắc: bất kỳ dịch vụ hoặc module mới nào chỉ sử dụng stack đã được phê duyệt. Ngoại lệ có thể thông qua ADR có lý do. Ví dụ: một microservice mới chỉ có thể được viết bằng Kotlin nếu nhóm chứng minh rằng Java không phù hợp cho nhiệm vụ này. Việc sử dụng bất kỳ công nghệ nào mà không có rào cản đều bị cấm.

Giảm dần sự đa dạng của stack

Giai đoạn 1: Đóng băng — các dự án mới trên stack không được hỗ trợ bị dừng lại. Ngày kết thúc vòng đời được đặt cho mỗi stack trong góc phần tư Hold. Chức năng mới chỉ được viết trên các stack đã được phê duyệt. Các module legacy tiếp tục hoạt động nhưng không được mở rộng.

Giai đoạn 2: Hợp nhất — một công cụ được chọn cho mỗi nhiệm vụ. Một HTTP client, một trình quản lý trạng thái, một cơ sở dữ liệu. Các module trên stack thay thế được lên lịch di chuyển theo ưu tiên. Mô hình Strangler Fig là phương pháp chính để thay thế mà không có thời gian chết hệ thống.

Giai đoạn 3: Di chuyển — mỗi sprint, nhóm dành 20% thời gian để viết lại các module quan trọng từ stack cũ sang stack đã được phê duyệt. Kiến trúc mục tiêu được tài liệu hóa và không thay đổi nếu không có quyết định của ủy ban. Quá trình này mất từ 6 đến 24 tháng tùy thuộc vào quy mô của vườn thú.

Ví dụ: Di chuyển 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()
        }
    }
}