Bỏ qua để đến nội dung

Chuẩn hóa cho team

Một người dùng Hackolade giỏi tạo ra model đẹp. Một team dùng Hackolade mà không có chuẩn chung tạo ra… nhiều kiểu model đẹp khác nhau — và đó là vấn đề. Vai trò của administrator là thiết lập chuẩn trước khi team bắt đầu, vì Hackolade có sẵn cơ chế để chuẩn hóa: naming convention, custom property và plugin đều lưu dưới dạng file cấu hình chia sẻ được qua Git.

Naming convention: một nơi cấu hình, cả team dùng chung

Phần tiêu đề “Naming convention: một nơi cấu hình, cả team dùng chung”

Hackolade quản lý song song hai lớp tên cho mọi object: business name (tên nghiệp vụ, dễ đọc) và technical name (tên vật lý xuống database). Tính năng Naming Conventions — cấu hình tại Tools > Options > Naming Conventions — tự động chuyển đổi giữa hai lớp:

  • Hướng chuyển đổi: business-to-technical (hãng khuyến nghị), technical-to-business, hoặc tắt để quản lý thủ công.
  • Quy tắc tự động: đổi case (camelCase, PascalCase, snake_case, kebab-case, UPPERCASE, lowercase…), loại bỏ/thay thế ký tự không hợp lệ, tùy chọn bỏ nguyên âm.
  • File CSV (Comma-Separated Values) ánh xạ từ viết tắt: số lượng → qty, khách hàng → cust… — đây là chỗ đưa từ điển viết tắt của công ty vào tool.
  • Khi reverse engineering, tên nguồn được lưu làm technical name rồi sinh business name theo quy tắc đã khai — tên gốc trong database không bị mất.

Điểm then chốt cho administrator: tham số naming lưu trong file JSON (JavaScript Object Notation) theo từng target — đưa các file này vào Git repository chung là cả team dùng cùng một bộ quy tắc, thay vì mỗi người tự cấu hình theo trí nhớ.

Custom property: bắt buộc nhập metadata quản trị

Phần tiêu đề “Custom property: bắt buộc nhập metadata quản trị”

Ngoài thuộc tính có sẵn, administrator có thể định nghĩa custom property — ví dụ cờ phân loại PII (Personally Identifiable Information), thuộc tính tuân thủ GDPR (General Data Protection Regulation), data owner, mức độ nhạy cảm — để mọi model trong công ty ghi nhận cùng một bộ metadata:

  • Định nghĩa trong file JSON tại ~/.hackolade/options/<target>/customProperties (Windows: C:\Users\%username%\.hackolade\options\...), tách theo cấp object: model, container, entity, field (<level>LevelConfig.json).
  • Khởi tạo thư mục qua Help > Plugin Manager > Installed, sửa file bằng text editor (file mẫu có sẵn comment hướng dẫn), khởi động lại ứng dụng để nạp.
  • Tám kiểu control: text, textarea, dropdown chọn một/nhiều, số, checkbox, group, danh sách field… Từ khóa requiredProperty để bắt buộc nhập, dependency để hiện thuộc tính theo điều kiện.
  • Hãng khuyến nghị rõ dùng Git để đồng bộ và phân phối custom property cho toàn team.

Plugin: một người quản lý version, cả team đồng bộ

Phần tiêu đề “Plugin: một người quản lý version, cả team đồng bộ”

Target plugin (MongoDB, Snowflake, Avro…) tải qua Help > Plugin Manager; máy không ra internet thì tải ZIP từ GitHub của Hackolade rồi Install from Zip. Vấn đề của team: hai máy chạy hai version plugin khác nhau có thể sinh ra kết quả forward engineering khác nhau. Cách hãng gợi ý:

  1. Chỉ định một người phụ trách tải bản cập nhật plugin.
  2. Thư mục ~/.hackolade (chứa plugin và cấu hình) đặt dưới Git.
  3. Người phụ trách push thay đổi; các thành viên pull về định kỳ.

Kết quả: toàn team luôn chạy cùng version plugin mà không phải phát tay từng máy.

Hackolade lưu mỗi model là một file — rất hợp với Git. Vài quy ước nên chốt sớm (đây là khuyến nghị thực hành của BSD, không phải quy định của hãng):

  • Model đặt trong repo Git riêng hoặc cạnh code của hệ thống tương ứng — chọn một, áp dụng nhất quán.
  • Quy tắc đặt tên file model theo hệ thống/domain, ví dụ core-banking-khach-hang.json.
  • Thay đổi schema đi qua pull request như code, không sửa trực tiếp nhánh chính.
  • Tên tuân thủ naming convention (không tắt convention để “lách” một trường hợp)
  • Custom property bắt buộc (data owner, phân loại PII…) đã điền đủ
  • Đã chạy so sánh model (compare) với bản đang chạy để thấy đúng phạm vi thay đổi
  • Description của entity/attribute mới không bỏ trống
  • Thay đổi phá vỡ tương thích (đổi tên cột, đổi kiểu) có kế hoạch migration đi kèm
  • Mỗi người một quy ước đặt tên: không đưa file cấu hình naming vào Git chung, mỗi máy tự cấu hình — đến khi ghép model mới phát hiện customer_id và CustomerID cùng tồn tại.
  • Plugin lệch version giữa các máy: cùng một model nhưng hai máy sinh DDL (Data Definition Language) khác nhau, mất thời gian truy tìm “bug” không tồn tại.
  • Định nghĩa custom property sau khi đã có hàng chục model: bổ sung thuộc tính bắt buộc muộn đồng nghĩa quay lại điền tay cho toàn bộ model cũ.
  • Chuẩn chỉ nằm trong tài liệu Word: quy ước không đưa vào cấu hình tool thì mỗi lần review là một lần tranh luận lại từ đầu.

Chuẩn đã có, giờ tự động hóa để chuẩn được thực thi: CLI và CI/CD.

BSD Insight là đối tác triển khai Hackolade tại Việt Nam — liên hệ tư vấn.

Chia sẻ: