Software Engineering

Ngành công nghiệp phần mềm đang chứng kiến một cuộc chuyển giao quyền lực lịch sử. Quyền lực đang dần rời khỏi tay những người “chỉ biết gõ code” để chuyển sang những người “biết cách giải quyết vấn đề bằng hệ thống và AI”. Bối Cảnh: Khi “Viết Code” Không Còn Là Kỹ Năng Độc Tôn Trong hơn hai thập kỷ qua, giá trị của một lập trình viên phần lớn được đo lường bằng việc họ am hiểu cú pháp (syntax) ngôn ngữ nào, thành thạo framework nào (React, Angular, Spring Boot, v.v.), và khả năng ghi nhớ các API. ...

Bất kỳ đội ngũ kỹ thuật nào xây dựng hệ thống nghiêm túc trên Magento cuối cùng cũng sẽ đụng phải ba bức tường giống nhau: bức tường bản quyền, bức tường khả năng chịu tải (scaling), và bức tường tốc độ phát triển (developer velocity). Câu hỏi chỉ là bạn sẽ đụng phải chúng trước hay sau khi chúng bào mòn tiền bạc và khách hàng thực sự của bạn. ...

Trong nhiều năm, hình ảnh một lập trình viên tài năng thường gắn liền với tốc độ gõ phím thoăn thoắt, khả năng ghi nhớ hàng tá thư viện API, và việc viết ra những đoạn mã không một lỗi cú pháp. Chúng ta gọi họ là những “Coder” thuần túy. Nhưng khi AI bước vào sân chơi, một sự thật phũ phàng đã hiện ra: Viết code chỉ là phần dễ nhất trong việc xây dựng phần mềm. ...

Bất kỳ team Magento nào khi quyết định chuyển dịch sang microservices cũng đều phải đối mặt với cùng một câu hỏi đầu tiên: cần bao nhiêu service? Ngành công nghiệp thường bảo là 4–6. “Service danh mục (Catalog), service đơn hàng (Order), service khách hàng (Customer), service tồn kho (Inventory), service thanh toán (Payment), và có thể thêm CMS nữa.” Mọi bài blog, mọi bài diễn thuyết ở hội thảo đều tựu trung ở danh sách này. Đó là một điểm khởi đầu hợp lý — nhưng nó hoàn toàn sai lầm khi áp dụng cho e-commerce nghiêm túc ở quy mô lớn. ...

Khi nhận ra tốc độ gõ code đã bị AI đánh bại (như thảo luận ở Phần 1), một nỗi sợ vô hình bao trùm lên giới lập trình: “Vậy tôi sẽ làm gì nếu AI làm hết?” Câu trả lời nằm ở việc phân định rõ ranh giới: AI không làm “hết”. AI chỉ làm những việc cơ bắp kỹ thuật, còn con người giữ lại phần đầu não và trách nhiệm. Để tối ưu hóa quá trình phát triển phần mềm mà không đánh mất quyền kiểm soát, chúng ta cần kẻ một đường chỉ đỏ giữa “Lãnh địa của Máy” và “Lãnh địa của Người”. ...

Khi bạn sở hữu 21 Go microservices và 2 ứng dụng frontend, câu hỏi hạ tầng đầu tiên không phải là Kubernetes hay CI/CD — mà là làm thế nào để bạn quản lý chính bản thân phần source code? Hai lựa chọn sau sẽ thất bại ngay lập tức: polyrepo (hơn 21 repo Git rời rạc, bất khả thi để duy trì phiên bản đồng nhất) và một monorepo ngây ngô (vứt tất tần tật mọi thứ vào chung một thư mục, dependency ma ám ngập tràn). Bạn cần một công cụ quản lý monorepo thực thụ. ...

Mạng xã hội và các chiến dịch marketing của các hãng công nghệ liên tục tiêm nhiễm vào đầu chúng ta một khái niệm: “10x Developer nhờ AI”. Hình ảnh một lập trình viên nhâm nhi ly cà phê, gõ vài dòng prompt và hoàn thành khối lượng công việc của cả một tuần trong một buổi sáng thật sự rất hấp dẫn. Nhưng sự thật dưới chiến hào (trenches) của các dự án thực tế lại phũ phàng hơn nhiều. AI mang lại một nguồn sức mạnh khổng lồ, nhưng nó tuân theo định luật bảo toàn năng lượng: Thời gian bạn tiết kiệm được khi “gõ code” sẽ bị đòi lại một phần (thậm chí là toàn bộ) ở khâu đọc và bảo trì, nếu bạn không biết cách. ...

Đối với các kỹ sư chuyển từ Magento PHP sang, việc chuyển dịch sang Go microservices không chỉ đơn thuần là đổi ngôn ngữ lập trình — mà nó là một cách thức tổ chức code khác biệt về mặt bản chất. Magento có controller, model, block, helper, và plugin. Còn Go với Kratos v2 sở hữu chính xác 5 lớp (layer), mỗi lớp mang một trách nhiệm được định nghĩa rạch ròi. ...

Quy trình phát triển phần mềm truyền thống (SDLC) thường được mô tả như một dây chuyền lắp ráp nhà máy. Business Analyst (BA) viết requirement $\rightarrow$ Designer vẽ UI $\rightarrow$ Lập trình viên (Dev) gõ code $\rightarrow$ Quality Assurance (QA) tìm bug $\rightarrow$ DevOps đẩy lên server. Mỗi người ngồi trong một “lô cốt” (silo) riêng và giao tiếp qua những tấm vé Jira. Nhưng AI đã vung chiếc búa tạ đập nát những bức tường này. Khi một BA có thể nhờ AI sinh ra một đoạn code chạy thử (Proof of Concept), và một Lập trình viên có thể nhờ AI viết kịch bản test tự động, ranh giới giữa các vai trò trở nên vô cùng mờ nhạt. ...

Mọi API hướng ra công chúng (public-facing) trong Nền tảng Composable Commerce đều bắt đầu từ một file .proto. Phần code — bao gồm các hàm handler gRPC viết bằng Go, TypeScript SDK, các route HTTP, kiểm tra tính hợp lệ của request (request validation), các mã lỗi — tất cả đều được tự động generate ra từ bản hợp đồng (contract) đó. Bài viết này sẽ ghi chép lại những quy ước đằng sau để hệ thống đó vận hành mượt mà. ...

Cho đến giờ, chúng ta đã bàn rất nhiều về AI dưới góc nhìn của Lập trình viên và Tester. Nhưng nếu bước vào phòng họp của Ban Giám Đốc (BOD) hay các Giám đốc Công nghệ (CTO), bạn sẽ thấy một lăng kính hoàn toàn khác. Giới chủ (BOD) không quan tâm bạn dùng AI xịn thế nào, hay prompt dài bao nhiêu. Lăng kính của họ được cấu thành từ 3 biến số sinh tử: Chi phí (Cost), Tốc độ ra mắt (Time-to-Market), và Quản trị Rủi ro (Risk Management). ...

Cấu trúc EAV schema chính là lý do khiến phần lớn các dự án chuyển đổi khỏi Magento chuốc lấy thất bại. Nhìn từ bên ngoài, nó có vẻ dễ xơi: dữ liệu của sản phẩm bị băm ra rải rác ở catalog_product_entity, catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, catalog_product_entity_datetime, và catalog_product_entity_text. Sáu cái bảng, viết một cái job ETL đơn giản, làm một cuối tuần là xong. Nhưng rồi bạn phát hiện ra rằng attribute_id = 75 mang ý nghĩa “tên sản phẩm” (product name) trong cái database của bạn, nhưng nó lại mang nghĩa “màu sắc” (color) trong cái database trên môi trường staging. Mỗi một mã ID thuộc tính (attribute ID) được sinh ra tự động ngay tại thời điểm cài đặt (install time) và nó hoàn toàn khác biệt giữa các môi trường với nhau. Bất kỳ script ETL nào dám cả gan gán cứng (hardcode) các mã attribute ID này sẽ lập tức đẻ ra một đống dữ liệu rác bẹp dí (corrupted data) khi mang lên chạy ở production. ...

Giai đoạn 1 (Phase 1) là giai đoạn an toàn nhất trong toàn bộ cuộc di dời — đó là chủ ý thiết kế (by design). Sẽ không có bất kỳ thao tác ghi (write) dữ liệu nào chạm tới hệ thống microservice mới. Magento vẫn là nguồn sự thật duy nhất (source of truth) cho mọi sửa đổi dữ liệu. Việc duy nhất mà Giai đoạn 1 làm, đó là chứng minh rằng đống microservice của bạn có thể phục vụ các thao tác đọc (read) với tốc độ nhanh hơn và độ ổn định cao hơn Magento. ...

Ở Phần 5, chúng ta đã thấy Ban Giám Đốc (BOD) đang ráo riết trang bị hệ thống AI nội bộ để ép KPI năng suất. Lúc này, nếu bạn vẫn cố chấp ngồi gõ từng dòng lệnh từ đầu đến cuối, bạn sẽ bị bỏ lại. Để tồn tại, lập trình viên buộc phải vứt bỏ chiếc áo “Coder” để khoác lên mình chiếc áo “AI Orchestrator” (Người chỉ huy AI). ...

Ở Giai đoạn 1, cả hai hệ thống đều tồn tại song song nhưng chỉ có duy nhất một thằng được phép ghi dữ liệu: Magento. Sang Giai đoạn 2, cả hai hệ thống sẽ cùng thi nhau ghi dữ liệu cùng một lúc (simultaneously). Đây là giai đoạn phức tạp nhất về mặt kỹ thuật — và cũng là nơi mà phần lớn các dự án di dời tự tay làm hỏng (corrupt) dữ liệu của chính mình nếu họ không chuẩn bị sẵn một chiến lược phân xử xung đột (conflict resolution strategy) rõ ràng sòng phẳng. ...

Dù bạn có kỹ năng Prompt Engineering đỉnh cao đến đâu, sớm muộn gì bạn cũng sẽ va phải một bức tường hiện thực: Viết code tạo ra một tính năng thì dễ, nhưng thiết kế một hệ thống chịu tải hàng triệu user thì vô cùng khó. Trong kỷ nguyên mà AI đang làm thay công việc “gõ phím”, System Design (Thiết kế hệ thống) chính là chiếc phao cứu sinh, là vùng “lãnh địa bất khả xâm phạm” giúp bạn không bị đào thải. ...

Giai đoạn 3 (Phase 3) là hồi kết: 100% traffic chuyển hẳn sang hệ thống microservice, Magento chính thức lùi về làm một kho lưu trữ thụ động (passive archive), và toàn bộ nền tảng vận hành hoàn toàn trên các microservice Go thông qua quy trình GitOps. Sẽ không còn bóng dáng của PHP trong những luồng request quan trọng nữa. Và cũng chấm dứt luôn chuỗi ngày phải è cổ ra đóng tiền gia hạn giấy phép (license) cho Magento. ...

Đến lúc này, chúng ta đã vẽ ra một viễn cảnh tương đối tươi sáng: Lập trình viên thoát khỏi cảnh gõ code nhàm chán, trở thành Kiến trúc sư hệ thống và điều phối AI. Nhưng viễn cảnh này chỉ đúng với Senior Developers — những người đã có sẵn nền tảng chuyên môn vững chắc để thẩm định độ đúng/sai của mã nguồn. Còn với những lập trình viên mới vào nghề (Fresher/Junior), sự xuất hiện của AI lại vô tình tạo ra một cuộc khủng hoảng đào tạo tồi tệ nhất trong lịch sử: Nghịch lý Junior (The Junior Paradox). ...

Khi một khách hàng bấm nút đặt hàng trên nền tảng Composable Commerce, có tới 7 sự kiện bắt buộc phải diễn ra theo chuỗi vắt ngang qua 4 service hoàn toàn độc lập: Tạo Đơn hàng (Order created) → Duyệt Thanh toán (Payment authorized) → Giữ chỗ Tồn kho (Stock reserved) → Kích hoạt Giao nhận (Fulfillment triggered) → Bắn Thông báo (Notification sent) → Cộng Điểm thưởng (Loyalty points awarded) → Tạo Mã vận đơn (Shipping label generated). Bất kỳ mắc xích nào trong số này cũng có thể đứt. Mạng có thể rớt. Database có thể sập. Một cái cổng thanh toán (payment gateway) của bên thứ ba có thể bị timeout. ...

Trong 8 phần trước (từ Phần 1: Sự sụp đổ của “Thợ gõ code” đến Phần 8: Nghịch lý Junior), chúng ta đã mổ xẻ việc dùng AI như một công cụ (Tool) để hỗ trợ lập trình viên (tăng năng suất, test code, xử lý legacy). Nhưng ở phần cuối cùng này, chúng ta sẽ lật ngược lại vấn đề. Nhiệm vụ tối thượng của một Kiến trúc sư Hệ thống (AI-Driven Architect) không chỉ là code nhanh hơn, mà là đưa AI vào làm “trái tim” của chính sản phẩm mà mình đang xây dựng. Chúng ta gọi đó là kiến trúc AI-Native Application. ...

21 services. 24 quyết định. 3.5 tháng trời cân lên đặt xuống được ghi chép cẩn thận vào các bản Ghi nhận Quyết định Kiến trúc (Architecture Decision Records - ADR). ADR là một tài liệu ngắn gọn gọn gàng trả lời rạch ròi câu hỏi: “Tại sao chúng ta lại cắm đầu chọn phương án X trong khi hai thằng Y và Z cũng ngon lành không kém?” Nếu không có ADR, mọi tri thức kiến trúc (architectural knowledge) sẽ chỉ tồn tại mỏng manh trong đầu các kỹ sư. Lỡ ngày đẹp trời nào đó họ nộp đơn nghỉ việc, mớ tri thức đó cũng đội nón ra đi — và thế là team mới vào tiếp quản sẽ lại cặm cụi đập đi xây lại cái component y chang cái cách mà đội ngũ cũ đã từng hăm hở thử nghiệm rồi vứt sọt rác (tried and rejected). ...

Lời Nói Đầu: Hành Trình Lột Xác Đọc xong 9 bài viết của series này, bạn có thể đang cảm thấy “ngợp” hoặc hoang mang. Đó là cảm giác bình thường khi một tư duy cũ (viết code kiếm tiền) bị phá vỡ. Để chuyển đổi từ một “Thợ gõ code” sang một “AI-Driven Engineer” thực thụ, bạn không thể làm trong một đêm. Dưới đây là Lộ trình 30-60-90 Ngày được thiết kế dưới dạng khung huấn luyện thực chiến. Không lý thuyết suông, chỉ có Action Items (Hành động). ...