--- title: "Nguyên tắc 100% code" url: "https://bahub.vn/khoa-hoc/erp-cho-ba/nguyen-tac-100-phan-tram-code" author: "Võ Văn Trí" published: "2026-09-10" updated: "2026-11-02" source: "bahub.vn" license: "Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc." --- # Nguyên tắc 100% code > Nếu dự án Odoo có bất kỳ yêu cầu nào bắt buộc phải code thì bỏ Studio cho toàn bộ dự án. Cơ chế xung đột đứng sau, và ba trường hợp nguyên tắc này quá chặt. - Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/nguyen-tac-100-phan-tram-code - Tác giả: Võ Văn Trí - Khoá học: ERP cho Business Analyst (mục lục: https://bahub.vn/khoa-hoc/erp-cho-ba.md) - Chương: Tùy biến và phân quyền Dự án chạy tốt suốt sáu tháng. Hệ thống lên, người dùng quen việc, và mọi thứ ổn định tới mức không ai nhắc tới nó nữa. Rồi doanh nghiệp quyết định nâng cấp lên phiên bản mới. Sau khi nâng cấp thì một trường dữ liệu trên màn hình đơn hàng biến mất, một trường khác vẫn còn nhưng dữ liệu bên trong không khớp với báo cáo, và không ai nhớ trường đó do ai tạo ra, tạo bằng cách nào, vào lúc nào. Chuyện này xảy ra vì trong dự án đó **có phần được làm bằng Studio và có phần được viết bằng code**. ## Nguyên tắc Nguyên tắc chỉ có một câu. > Nếu dự án có bất kỳ một yêu cầu nào bắt buộc phải customize bằng code, thì bỏ Studio cho toàn bộ dự án và làm tất cả bằng code. Không phải bỏ Studio cho riêng yêu cầu đó, mà là **bỏ cho cả dự án**, kể cả những yêu cầu nhỏ mà Studio thừa sức làm trong năm phút. Đây là nguyên tắc của tôi, rút ra từ những dự án tôi tham gia, chứ **không phải khuyến nghị chính thức của Odoo**, nên phần tiếp theo sẽ giải thích cơ chế đứng sau để bạn tự đánh giá xem nó có hợp với bối cảnh của mình không. ## Cơ chế đứng sau Mọi thứ bắt đầu từ cách hệ thống đặt tên. Trên Odoo 19, trường tạo bằng Studio mặc định có **tên kỹ thuật bắt đầu bằng tiền tố `x_studio_`**, và đây là dấu hiệu để phân biệt trường do người dùng thêm với trường thuộc về mã nguồn. Đồng thời mọi tùy biến bằng Studio được gom vào một module tên là `studio_customization` nằm ngay trong database, tức **một module không nằm trong kho mã nguồn của đội phát triển**. Toàn bộ phần cơ chế trong bài này tôi mô tả trên Odoo 19, và đây là loại nội dung bạn phải dựng lại trên đúng bản mình đang chạy chứ không nên tin theo trí nhớ. Vấn đề nảy sinh khi developer viết code có tham chiếu tới những trường đó, và chuyện này xảy ra rất tự nhiên: BA đã dựng sẵn vài trường bằng Studio trong lúc làm mockup hoặc lúc xử lý một yêu cầu nhỏ, developer thấy có rồi nên dùng luôn thay vì khai báo lại. Từ lúc đó trở đi, **một phần logic của hệ thống phụ thuộc vào thứ được tạo ra bên ngoài mã nguồn**, và sự phụ thuộc ấy không được ghi ở đâu cả. ![Developer dùng luôn trường Studio có sẵn, logic bắt đầu dựa vào thứ nằm ngoài mã nguồn](https://bahub.vn/uploads/2026/11/1793630763075-z5isc6-nguyen-tac-100-phan-tram-code-1.webp "Developer dùng luôn trường Studio có sẵn, logic bắt đầu dựa vào thứ nằm ngoài mã nguồn") Tới lần nâng cấp thì hai phần này đi theo hai đường khác nhau. Theo tài liệu chính thức của Odoo, dịch vụ nâng cấp của nhà sản xuất bao gồm các tùy chỉnh tạo bằng Studio, với điều kiện Studio còn được cài và thuê bao còn hiệu lực; còn module do nội bộ hoặc bên thứ ba viết thì không nằm trong phạm vi đó, trừ khi có hợp đồng bảo trì tùy chỉnh riêng. Nghĩa là một nửa được nhà sản xuất nâng cấp, nửa kia do đội của bạn tự nâng cấp, và theo tôi thì **chỗ hai nửa tham chiếu lẫn nhau là chỗ không bên nào đứng ra chịu trách nhiệm**. Kết quả tôi từng gặp là dữ liệu bị sai, bị dư, hoặc không cập nhật qua lại giữa hai bên, và khi nâng cấp phiên bản lớn thì bạn không chỉ mất dữ liệu mà còn mất luôn manh mối để biết mình đã mất cái gì. Có thêm một lớp rủi ro ít người tính tới. Theo ghi nhận của tôi, **Studio không có lịch sử phiên bản**; bạn hoàn tác được trong lúc còn mở phiên làm việc, nhưng đóng lại là mất, và không có cách nào xem lại ai đã đổi gì vào lúc nào. Khi một dự án có cả hai loại thay đổi thì một nửa lịch sử nằm trong hệ thống quản lý mã nguồn, còn nửa kia không nằm ở đâu cả. ## Nguyên tắc này chặt hơn mức cần thiết Cần nói thẳng chuyện này, vì nếu không thì bài viết thành một lời phán. Về mặt kỹ thuật thuần túy, xung đột chỉ xảy ra ở những chỗ có giao nhau. Một trường Studio nằm trên phân hệ nhân sự thì chẳng liên quan gì tới đoạn code viết cho phân hệ kho, và về lý thuyết thì hai thứ đó sống chung hòa bình được. Tuy nhiên, lý do tôi vẫn chọn nguyên tắc chặt là vì **trong thực tế bạn không kiểm soát được chỗ giao nhau**: dự án kéo dài, người vào người ra, yêu cầu phát sinh, và tới tháng thứ tư thì sẽ có người dùng một trường Studio trong một đoạn code mà không ai để ý. Do đó một nguyên tắc chặt nhưng đơn giản thì cả đội tuân thủ được, còn một nguyên tắc chính xác hơn nhưng phải đánh giá theo từng trường hợp thì tới tuần thứ ba là không ai đánh giá nữa. Nói cách khác, **đây là nguyên tắc đánh đổi sự tối ưu để lấy sự chắc chắn**, và bạn nên biết mình đang đánh đổi cái gì. ![Một nguyên tắc chặt nhưng đơn giản thì cả đội theo được lâu hơn](https://bahub.vn/uploads/2026/11/1793630763602-3rfea4-nguyen-tac-100-phan-tram-code-2.webp "Một nguyên tắc chặt nhưng đơn giản thì cả đội theo được lâu hơn") ## Ba trường hợp tôi vẫn phá nguyên tắc Cả ba có chung một điều kiện. **Trường hợp thứ nhất là mockup trong giai đoạn phân tích.** Đây là ngoại lệ quan trọng nhất, và thật ra nó không phải ngoại lệ mà là hiểu đúng phạm vi của nguyên tắc, bởi **nguyên tắc áp cho sản phẩm bàn giao chứ không áp cho công cụ làm việc**. Dùng Studio kéo thả ra một màn hình rồi chụp lại thì nhanh hơn vẽ bằng công cụ thiết kế rất nhiều, và chính xác hơn vì bạn biết ngay trường đó kiểu dữ liệu gì, có widget gì, liên kết tới model nào. Ranh giới ở đây là môi trường: **mockup dựng trên bản thử, không dựng trên bản chạy thật**. Còn dựng tới đâu là đủ, và [cách chạy một buổi lấy xác nhận từ khách trên chính bản mockup đó](https://bahub.vn/khoa-hoc/erp-cho-ba/dung-mockup-tren-he-thong-thay-vi-ve-ngoai), là chủ đề của một bài riêng. **Trường hợp thứ hai là những thứ thuần túy hiển thị và không có đoạn code nào chạm tới**, chẳng hạn đổi nhãn, đổi vị trí trường trên màn hình, thêm một bộ lọc tìm kiếm. Điều kiện đi kèm là phải ghi lại vào tài liệu đã đổi gì bằng Studio, vì thứ không được ghi lại thì lần nâng cấp sau không ai biết mà kiểm tra. **Trường hợp thứ ba là giai đoạn sau go-live**, khi khách tự vận hành và có nhu cầu nhỏ phát sinh mà chờ một chu kỳ phát triển thì quá lâu. Ở đây tôi chấp nhận Studio, nhưng phải giao kèm quy ước: * chỉ một người được quyền dùng Studio * mọi thay đổi phải ghi vào một danh sách * và trước mỗi lần nâng cấp thì rà lại danh sách đó Điểm chung của ba trường hợp là **chúng đều có ranh giới rõ ràng và đều có cách ghi lại dấu vết**. > Cái nguyên tắc muốn chặn không phải là Studio, mà là những thay đổi không ai biết. ## Vế bị bỏ quên Nguyên tắc này có hai vế, và vế thứ hai quan trọng không kém: **phải nói cho doanh nghiệp biết dự án dùng Studio hay dùng code, và vì sao**. Lý do rất thực tế. Hệ thống đó là của họ, và ba năm nữa họ sẽ nâng cấp, có thể với một đội khác. Người tiếp quản cần biết phần tùy chỉnh nằm ở đâu để lên kế hoạch, và nếu không ai nói thì họ phải tự đi tìm, mà chi phí đi tìm thì cuối cùng vẫn là doanh nghiệp trả. Cách nói không cần dài. Một đoạn trong tài liệu giải pháp, ghi rõ: * dự án này tùy chỉnh bằng phương thức nào * những phân hệ nào có phần tùy chỉnh * và điều đó có nghĩa gì khi nâng cấp phiên bản Nếu dự án có dùng Studio thì cũng nên ghi ra rằng tên kỹ thuật của các trường mang tiền tố `x_studio_`, vì đó chính là dấu hiệu để người sau nhận diện. > Đây là phần thuộc về cách hành nghề chứ không phải kỹ thuật, và nó là thứ phân biệt một đối tác với một nhà thầu. ![Nói cho doanh nghiệp biết dự án tùy chỉnh bằng gì để người tiếp quản sau còn lần được](https://bahub.vn/uploads/2026/11/1793630764097-jxyd53-nguyen-tac-100-phan-tram-code-3.webp "Nói cho doanh nghiệp biết dự án tùy chỉnh bằng gì để người tiếp quản sau còn lần được") ## Audit một hệ thống đã có sẵn Tình huống hay gặp là bạn tiếp nhận một hệ thống do đội khác triển khai, và không có tài liệu nào nói nó được tùy chỉnh bằng gì. **Cách kiểm nhanh nhất là tìm tiền tố `x_studio_` trong tên kỹ thuật của các trường.** Bật chế độ nhà phát triển rồi rê chuột qua các trường trên những màn hình chính, hoặc vào Settings, Technical, Fields và lọc theo tên kỹ thuật. Thấy tiền tố đó nghĩa là hệ thống có phần làm bằng Studio. Tuy nhiên không thấy chưa chắc là không có, bởi tên kỹ thuật đổi lại được và người đổi có thể chỉ giữ chữ `x_` bắt buộc, nên hãy tìm thêm module `studio_customization` trong danh sách module đã cài. Nếu tìm thấy cả trường Studio lẫn module tùy chỉnh do developer viết, bạn đang ở đúng tình huống mà nguyên tắc này muốn tránh, và **việc cần làm không phải là dọn sạch ngay**. Việc cần làm là lập danh sách: những trường Studio nào đang được code tham chiếu tới, những trường nào chỉ để hiển thị. **Nhóm thứ nhất là nhóm phải xử lý trước khi nâng cấp**; nhóm thứ hai thì để nguyên cũng được, chỉ cần ghi lại. Và trước khi làm bất cứ điều gì, **hãy dùng chức năng Export trong Studio để xuất phần tùy biến ra một file nén**, giữ lại một bản. Đây cũng là cách chuyển tùy biến giữa các môi trường mà không phải dựng lại thủ công. ## Chi phí thật nằm ở đâu Toàn bộ nguyên tắc này thực ra chỉ phục vụ một con số: **chi phí của lần nâng cấp tiếp theo**. Nếu bạn không quan tâm tới con số đó, vì dự án nhỏ, khách không có kế hoạch nâng cấp, hoặc hệ thống sẽ được thay trong hai năm nữa, thì trộn Studio với code cũng chẳng sao, và nguyên tắc này là thừa. Còn nếu doanh nghiệp định dùng hệ thống này lâu dài thì **mỗi quyết định tùy chỉnh hôm nay đều là một dòng chi phí định kỳ trong tương lai**; cách quy dòng chi phí đó ra con số để đưa lên bàn thì tôi đã nói riêng ở bài về [nợ kỹ thuật của customization](https://bahub.vn/khoa-hoc/erp-cho-ba/no-ky-thuat-cua-customization). --- Nguồn: https://bahub.vn/khoa-hoc/erp-cho-ba/nguyen-tac-100-phan-tram-code — Được dùng lại, trích dẫn và đưa cho AI đọc, với điều kiện ghi rõ nguồn bahub.vn kèm link bài gốc.