Bạn vẫn xem được toàn bộ bài học mà không cần đăng nhập.
Chế độ nhà phát triển bị coi là thứ của lập trình viên. Đây là cách để BA đọc tên trường, model, kiểu dữ liệu và biết chỗ nào đã bị thêm vào.
Bạn nhận một dự án giai đoạn hai trên một hệ thống Odoo đã chạy hai năm do đội khác dựng. Trong buổi đầu tiên, khách mở màn hình sản phẩm lên, chỉ vào một ô nằm giữa form rồi hỏi: chỗ này bên anh không dùng nữa, bỏ đi và thay bằng ô khác thì mất bao lâu em.
Bạn ghi lại yêu cầu. Về tới chỗ ngồi, bạn mở lại màn hình ấy, đếm được hơn hai chục trường trên cùng một tab, và không có cách nào phân biệt trường nào của Odoo, trường nào do đội trước thêm vào.
Hai chuyện đó khác nhau hoàn toàn về khối lượng lẫn rủi ro, bởi ẩn một trường chuẩn chỉ là chuyện cấu hình giao diện, còn gỡ một trường do người khác thêm vào thì phải biết ai đang nhập nó, báo cáo nào đang lấy dữ liệu từ nó, và nó có bị tham chiếu trong đoạn code nào không.
Bạn hẹn khách tuần sau để hỏi lại đội cũ. Trong khi đó thông tin để trả lời nằm ngay trên màn hình ấy, cách bạn đúng một lần bật công tắc.
Cái công tắc ấy là chế độ nhà phát triển, và nó bị đặt tên sai cho đối tượng sử dụng.
Toàn bộ thao tác 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ớ.
Có bốn cách bật, và bạn chỉ cần nhớ một.
?debug=1 vào cuối địa chỉ trên thanh URL rồi Enter, và dùng ?debug=0 để tắt.Dấu hiệu đã bật là một icon hình con bọ xuất hiện trên thanh trên cùng, và với tài khoản quản trị database thì có thêm menu Technical trong Settings.
Bật chế độ này không đổi dữ liệu và không đổi cấu hình, nó chỉ mở thêm phần thông tin mà giao diện thường ngày giấu đi cho gọn. Tuy nhiên, đây là thứ bạn bật trên tài khoản của mình chứ không phải thứ đi bật cho người dùng cuối, vì menu Technical mở ra rất nhiều màn hình mà một người vận hành không có lý do gì để chạm vào, và một thao tác nhầm ở đó nặng hơn hẳn một thao tác nhầm trên màn hình nghiệp vụ.
Việc bạn làm nhiều nhất sau khi bật là mở khối thông tin của một trường ra đọc, và chỗ nhiều người dò mãi không ra là điểm rê chuột.
Trên form, thứ bạn cần trỏ vào là dấu chấm hỏi nhỏ in phía trên, ngay sau tên trường, chứ không phải bản thân dòng chữ tên trường; và chính dấu chấm hỏi đó cũng chỉ hiện ra khi bạn đang bật chế độ nhà phát triển hoặc khi trường có sẵn một câu trợ giúp. Còn trên dạng xem danh sách thì khối thông tin treo thẳng ở tiêu đề cột, nên ở đó bạn rê chuột lên chính tên cột rồi giữ yên khoảng một giây là nó hiện.
Khối này có tất cả mười sáu dòng khả dĩ, lần lượt là Label tức nhãn hiển thị, Field tức tên kỹ thuật, Model tức đối tượng dữ liệu chứa trường đó, Type tức kiểu dữ liệu, rồi tới Model field, Widget, Context, Domain, Invisible, Column invisible, Required, Readonly, Default, Change default, Relation và Selection. Mỗi dòng chỉ hiện khi trường có giá trị tương ứng, nên bạn không bao giờ thấy đủ mười sáu dòng cùng lúc.
Bốn dòng đầu là thứ bạn dùng hằng ngày, dòng Relation cho biết trường quan hệ này trỏ sang đối tượng nào, còn dòng Selection liệt kê thẳng toàn bộ giá trị của một trường lựa chọn, tức là bạn có sẵn danh sách để chép vào tài liệu.
Đặc biệt, hai dòng Required và Readonly đáng chú ý hơn vẻ ngoài của chúng, bởi chúng chỉ đọc lại thuộc tính được đặt trên chính dạng xem bạn đang đứng chứ không đọc thuộc tính khai báo ở tầng dữ liệu. Do đó chuyện khối thông tin không hiện dòng Required hoàn toàn không có nghĩa là trường đó được phép để trống.
Ô Customer trên đơn bán hàng là ví dụ dễ kiểm nhất: nó bắt buộc thật ở tầng model, màn hình vẫn chặn bạn lưu khi bỏ trống, mà khối thông tin thì không hiện lấy một dòng Required nào. Một trường tính toán cũng vậy, không có dòng nào trong mười sáu dòng kia nói cho bạn biết nó là trường tính toán. Muốn biết ràng buộc thật thì phải tra ở chỗ khác, và chỗ đó nằm ở phần sau.
Việc đầu tiên trong bốn việc bạn dùng chế độ này là việc quen thuộc nhất: điền bảng mô tả trường trong tài liệu đặc tả.
Ba cột nặng nhất của bảng đó là tên kỹ thuật, kiểu dữ liệu và đối tượng chứa trường, cả ba đều nằm sẵn trong khối thông tin vừa nói nên bạn không cần hỏi ai. Cấu trúc đầy đủ của bảng này thì đã có bài riêng về bảng GUI element; ở đây chỉ cần nhớ rằng nguồn của nó là hệ thống chứ không phải trí nhớ của bạn.
Có một dòng nữa hay bị bỏ qua, đó là phần chữ mô tả hiện ở trên cùng khi trường đã được gắn sẵn câu giải thích. Đây chính là dòng gợi ý người dùng cuối nhìn thấy, nên với một trường có sẵn của Odoo thì đừng tự nghĩ ra mô tả mới, hãy đọc cái đang có trước rồi quyết định giữ nguyên hay viết lại cho hợp ngữ cảnh của khách.
Việc thứ hai là việc đáng tiền nhất, bởi nó quyết định bạn đánh một dòng GAP là fit hay là gap.
Đường đi như sau: vào Settings, mở menu Technical, chọn Database Structure rồi vào Models. Ở đây bạn gõ tên đối tượng vừa đọc được từ khối thông tin, chẳng hạn res.partner, và mở nó ra để thấy toàn bộ danh sách trường của đối tượng chứ không phải chỉ những trường đang hiện trên màn hình. Danh sách đó thường dài hơn những gì form hiển thị rất nhiều, và không hiếm trường hợp thứ khách đòi thêm vốn đã tồn tại sẵn trong dữ liệu, chỉ là chưa được đưa lên form.
Mở một dòng trường ra, bạn đọc được mấy thông tin quyết định.
Thông tin còn lại là ô Type ở mức trường, chỉ nhận đúng hai giá trị. Base Field nghĩa là trường được khai báo trong code của một module, còn Custom Field nghĩa là trường do ai đó tạo thẳng trên chính database này.
Trên Odoo 19 có một ràng buộc ở tầng cơ sở dữ liệu bắt mọi Custom Field phải có tên kỹ thuật bắt đầu bằng x_, và trường kéo bằng Studio thì mang tiền tố x_studio_. Do đó quy tắc đọc nhanh là nhìn thấy tên trường mở đầu bằng x_ thì đó chắc chắn không phải trường gốc của Odoo.
Tuy nhiên chiều ngược lại thì không đúng, bởi một trường do đội trước viết bằng code trong module riêng của họ cũng hiện là Base Field và không cần tiền tố nào. Với trường hợp đó, dòng In Apps trên cùng màn hình liệt kê những module khai báo ra trường ấy, và chỉ cần trong danh sách có một module không phải ứng dụng của Odoo là bạn biết trường đã bị thêm vào.
Ghép tiền tố với dòng In Apps thì tình huống ở đầu bài được giải quyết trong mười lăm phút.
Cần lưu ý rằng biết một trường tồn tại không đồng nghĩa với việc yêu cầu đó giải được bằng cấu hình; ranh giới giữa cấu hình và customize là chủ đề của một bài khác, việc chọn kiểu field cho một trường mới cũng vậy. Ở đây bạn mới đang thu thập bằng chứng.
Việc thứ ba xảy ra vào giai đoạn kiểm thử, khi người dùng báo một hành vi mà bạn không giải thích được theo tài liệu.
Icon con bọ mở ra một danh sách công cụ, và ba mục trong đó đủ cho phần lớn tình huống.
Trình tự thao tác khi gặp một hành vi lạ như sau.
x_ khôngTrình tự này không sửa được lỗi, nó chỉ giúp bạn phân loại lỗi. Nhưng phân loại mới là phần tốn thời gian thật, bởi một issue ghi là màn hình đơn hàng bị sai thì developer phải tự đi tìm lại từ đầu, còn một issue ghi rõ trường nào trên đối tượng nào, là trường lưu hay không lưu, do module nào thêm vào và ai sửa bản ghi lần cuối thì người nhận đọc xong là biết phải mở file nào.
Việc thứ tư nghe như chuyện giao tiếp nhưng thực chất là chuyện dữ liệu.
Theo cách tôi vẫn làm, một dòng GAP mô tả phần làm thêm phải nói được:
Bốn thông tin đó bạn lấy hết được trước khi ngồi viết, còn nếu thiếu thì phần mô tả buộc phải diễn đạt bằng ngôn ngữ giao diện, kiểu như cái ô ở góc phải bên dưới tab thứ hai, mà ngôn ngữ giao diện thì đổi theo version và theo ngôn ngữ hiển thị.
Đi cùng là một quy tắc nhỏ mà tôi cho là phân biệt rõ nhất người đã làm dự án với người mới: nói tên trường với developer và tester, nói nhãn với khách hàng. Khách hàng không hiểu partner_id và cũng không cần hiểu, còn developer thì không tìm được trường nếu bạn chỉ đưa một nhãn tiếng Việt, đặc biệt khi hệ thống đã Việt hóa và nhãn trên màn hình không còn dính dáng gì tới chuỗi gốc.
Có những lúc thì ngược lại và bạn nên tính trước. Trong buổi demo giải pháp trước ban lãnh đạo, chế độ này nên tắt, vì icon con bọ cùng đống thông tin kỹ thuật hiện ra làm người xem nghĩ hệ thống đang dở dang, và câu hỏi bạn nhận được sẽ là về mấy dòng chữ lạ đó chứ không phải về giải pháp cần chốt.
Tới đây phải vẽ đường kẻ, vì nhìn thấy nhiều thông tin dễ khiến người ta tưởng mình phải hiểu hết.
Phần thuộc về bạn là phần mô tả cấu trúc, gồm nhãn, tên trường, đối tượng, kiểu dữ liệu, đối tượng quan hệ, danh sách giá trị của trường lựa chọn, trường có lưu hay không, và trường là của Odoo hay do ai đó thêm vào. Tất cả đều nói về dữ liệu, mà dữ liệu thì gắn với nghiệp vụ nên bạn có đủ thông tin để đọc chúng.
Phần không thuộc về bạn là phần điều kiện, gồm Domain, Context, các biểu thức ở Invisible và Readonly, cùng đoạn code trong tab Compute. Đây là logic viết bằng cú pháp riêng, đọc lướt thì tưởng hiểu nhưng hiểu sai rất dễ, và hiểu sai một biểu thức rồi viết vào tài liệu thì bạn vừa tạo ra một yêu cầu không ai đọc lại được. Việc đúng ở đây là chụp lại, dán vào issue và hỏi developer.
Chuyện ai được nhìn thấy trường nào lại thuộc về phân quyền và có bài riêng; đừng nhầm một trường bị ẩn trên form với một trường người dùng không có quyền đọc.
Có ba thứ chế độ nhà phát triển không làm được.
Nói thẳng thì ở một hệ thống đã có nhiều phần làm thêm, những gì đọc được từ chế độ nhà phát triển thường chỉ đủ để đặt câu hỏi đúng chứ không đủ để tự trả lời.
Nhưng hỏi đúng ngay trong buổi đầu tiên, thay vì hẹn lại một tuần, đã là khác biệt về tiến độ và cả về uy tín trước khách hàng.
Một trường bắt đầu bằng x_ hay một module lạ trong dòng In Apps cho bạn biết ai đó đã thêm nó vào, và câu hỏi kế tiếp là người đó thêm bằng Studio hay bằng code, bởi hai cách đó dẫn tới hai loại chi phí hoàn toàn khác nhau ở lần nâng cấp tiếp theo.
Thảo luận (0)
Bạn cần đăng nhập để thảo luận