Nếu cần hiểu nhanh triết lý của Midicoder trong 10 phút, hãy nhớ một ý trung tâm: contract là nguồn chân lý, còn code là đầu ra được tạo và kiểm soát từ contract. Nói ngắn gọn, Midicoder không khuyến khích sửa thẳng mã nguồn như cách làm thủ công truyền thống, mà ưu tiên mô tả đúng ý định nghiệp vụ và quy tắc hệ thống trong contract, sau đó dùng cơ chế compiler-first để tạo ra code, cấu hình và các artefact liên quan một cách nhất quán.
Bản đồ tư duy đơn giản của Midi Coder
- Trung tâm: Contract-first
- Nguồn chân lý: Contract thay vì code rời rạc hoặc prompt khó kiểm soát
- Cơ chế vận hành: Compiler-first, code từ contract
- Nguyên tắc làm việc: Không sửa thẳng code sinh ra
- Mục tiêu: Traceability, ổn định, lặp lại được, kiểm soát thay đổi
- Kết quả: Software factory có quy trình tạo phần mềm rõ ràng và đồng nhất
Khác nhau giữa contract-first và sửa thẳng mã nguồn
Ở cách làm quen thuộc, đội kỹ thuật thường bắt đầu từ code. Khi có yêu cầu mới, lập trình viên sửa từng file, cập nhật từng đoạn logic, rồi hy vọng tài liệu, test, API spec và hành vi hệ thống vẫn còn đồng bộ. Cách này linh hoạt trong ngắn hạn, nhưng về dài hạn dễ sinh lệch pha giữa ý định ban đầu và hiện trạng thực tế.
Với Midi Coder, điểm xuất phát là contract. Contract mô tả cấu trúc, ràng buộc, hành vi mong muốn và mối liên hệ giữa các thành phần. Từ đó, hệ thống biên dịch hoặc sinh ra code tương ứng. Khi cần thay đổi, đội ngũ sửa contract trước, rồi tái tạo đầu ra. Điều này làm cho thay đổi trở nên có hệ thống hơn thay vì vá trực tiếp vào nhiều nơi trong codebase.
Nói cách khác:
- Cách cũ: code dẫn dắt tài liệu và quy ước
- Contract-first: contract dẫn dắt code và các đầu ra khác
Khi nào contract là nguồn chân lý tốt hơn code hoặc prompt?
Contract trở thành nguồn chân lý tốt hơn khi đội ngũ cần một biểu diễn vừa đủ chặt chẽ để máy có thể xử lý, vừa đủ rõ ràng để con người có thể kiểm tra. So với code, contract ở mức trừu tượng cao hơn, tập trung vào ý định và quy tắc thay vì chi tiết triển khai. So với prompt, contract có cấu trúc rõ, ít mơ hồ hơn và dễ kiểm soát phiên bản hơn.
Contract đặc biệt hữu ích khi:
- Hệ thống có nhiều module cần đồng bộ đầu ra
- Đội ngũ muốn truy vết một thay đổi từ yêu cầu đến code
- Cần lặp lại kết quả ổn định qua nhiều lần sinh mã
- Muốn giảm phụ thuộc vào trí nhớ cá nhân của từng lập trình viên
- Cần kiểm soát thay đổi ở mức quy tắc thay vì sửa lỗi rải rác
Ví dụ luồng làm việc từ ý định nghiệp vụ đến code đầu ra
Hãy lấy một ví dụ đơn giản: doanh nghiệp muốn thêm quy tắc duyệt hợp đồng với hai cấp phê duyệt.
- Ý định nghiệp vụ: Hợp đồng trên một ngưỡng giá trị phải qua hai cấp duyệt.
- Biểu diễn bằng contract: Định nghĩa thực thể hợp đồng, trạng thái, điều kiện chuyển trạng thái, vai trò có quyền phê duyệt và ngưỡng giá trị áp dụng.
- Compiler-first xử lý: Từ contract, hệ thống sinh ra model, API, validator, state transition hoặc các thành phần cần thiết theo quy ước.
- Đầu ra kỹ thuật: Code được tạo ra nhất quán với contract, giảm nguy cơ quên cập nhật một lớp nào đó.
- Thay đổi về sau: Nếu ngưỡng phê duyệt đổi, sửa ở contract rồi biên dịch lại, thay vì đi tìm nhiều file để chỉnh tay.
Điểm quan trọng là toàn bộ chuỗi này tạo ra traceability: có thể lần ngược từ code đầu ra về contract, và từ contract về ý định nghiệp vụ ban đầu.
Vì sao Midi Coder nhấn mạnh “không sửa thẳng code”?
Khi code được sinh từ contract, việc sửa trực tiếp vào code sinh ra thường tạo ra hai nguồn sự thật cạnh tranh nhau: một ở contract, một ở code. Lần sinh lại sau đó có thể ghi đè thay đổi thủ công hoặc làm hệ thống trở nên khó hiểu. Vì vậy nguyên tắc “không sửa thẳng code” không phải để làm khó lập trình viên, mà để giữ tính nhất quán và bảo toàn dấu vết thay đổi.
Nếu cần thay đổi hành vi, nơi đúng để sửa là contract hoặc lớp extension được thiết kế sẵn cho chỉnh sửa thủ công. Triết lý này gần với tư duy dùng compiler: ta không sửa đầu ra của compiler như nguồn chính, mà sửa đầu vào chuẩn của nó.
Lợi ích cốt lõi: ổn định, lặp lại và kiểm soát thay đổi
- Ổn định hơn: Cùng một contract sẽ cho ra đầu ra nhất quán hơn so với thao tác thủ công nhiều điểm.
- Lặp lại được: Có thể tái tạo code và artefact trong những lần chạy khác nhau.
- Kiểm soát thay đổi tốt hơn: Mọi thay đổi đi qua contract nên dễ review và audit.
- Traceability rõ hơn: Biết thay đổi nào đến từ yêu cầu nào và tác động đến đâu.
- Giảm drift: Hạn chế việc tài liệu, API, logic và triển khai lệch nhau theo thời gian.
Những điểm dễ hiểu sai khi mới nghe về Contract Coding
Một hiểu sai phổ biến là nghĩ Contract Coding chỉ là đổi tên của code generation. Thực ra điểm khác biệt nằm ở triết lý vận hành: contract không chỉ để sinh vài file mẫu, mà là hạt nhân điều phối toàn bộ cách định nghĩa, tạo và kiểm soát hệ thống.
Một hiểu sai khác là cho rằng contract sẽ làm giảm sự linh hoạt. Đúng hơn phải nói contract đổi kiểu linh hoạt: bớt linh hoạt kiểu sửa nhanh từng chỗ, nhưng tăng linh hoạt kiểu thay đổi có chủ đích, có thể lặp lại và có thể truy vết.
Cũng có người nghĩ prompt có thể thay contract. Prompt hữu ích cho khám phá hoặc hỗ trợ tạo nội dung, nhưng thường không phải là nguồn chân lý bền vững cho vận hành kỹ thuật dài hạn. Contract có cấu trúc, có versioning và phù hợp hơn để trở thành nền tảng của software factory.
Khi nào nên thử Midi Coder đầu tiên?
Midi Coder phù hợp nhất khi tổ chức đang gặp một trong các vấn đề sau: thay đổi nhiều nhưng khó kiểm soát, nhiều lớp kỹ thuật dễ lệch nhau, team muốn chuẩn hóa đầu ra, hoặc cần tăng tốc mà vẫn giữ tính nhất quán. Điểm bắt đầu tốt thường là một luồng nghiệp vụ có quy tắc rõ ràng, lặp lại nhiều và đang gây tốn công khi cập nhật thủ công.
Ví dụ phù hợp để thử đầu tiên gồm: định nghĩa API và validation, quy trình phê duyệt có state rõ, mô hình dữ liệu cần đồng bộ giữa nhiều lớp, hoặc các module nội bộ nơi traceability là yêu cầu quan trọng.
Kết luận
Nếu phải gói gọn triết lý Midi Coder trong một câu, đó là: hãy sửa ý định ở contract, không vá đầu ra ở code. Từ góc nhìn đó, Midicoder là một cách làm contract-first, compiler-first và định hướng software factory, nơi contract trở thành source of truth giúp đội kỹ thuật tạo code từ contract một cách có kiểm soát, dễ lặp lại và dễ truy vết hơn.
