Tôi hoài nghi về low-code

• Tôi có quan điểm hoài nghi về low-code
• Khi làm tư vấn phần mềm, tôi thường gặp các khách hàng bị thu hút bởi quảng cáo hứa hẹn thời gian phát triển nhanh và chi phí bảo trì thấp của low-code
• Có một số lý do khiến khách hàng không hài lòng

Giới hạn của tính năng tùy biến

• Các giải pháp low-code đáp ứng khoảng 80% yêu cầu của doanh nghiệp, nhưng 20% còn lại không thể giải quyết bằng tính năng mặc định
• Những người tiếp thị công cụ low-code khẳng định 20% còn lại có thể được xử lý dễ dàng, nhưng trên thực tế lại cần mức độ tùy biến đáng kể và đôi khi là không thể
• Doanh nghiệp phải chọn giữa việc liệu các tính năng mặc định của công cụ có đủ gần với nhu cầu hay không, hoặc cố gắng hack công cụ để khớp chính xác với trường hợp sử dụng của mình

Hạn chế của nguồn nhân lực lập trình viên

• Doanh nghiệp đôi khi cố hack công cụ low-code để đáp ứng 100% yêu cầu
• Kết quả là phải viết rất nhiều mã tùy biến bằng một công cụ cụ thể hoặc ngôn ngữ độc quyền, đến mức số lập trình viên có thể hiểu được là cực kỳ ít
• Khi đó, thay vì tuyển từ nguồn lập trình viên dùng các ngôn ngữ mã nguồn mở phổ biến, công ty phải tìm người bảo trì có chuyên môn rất sâu với chính công cụ này

Vấn đề khi nâng cấp nền tảng

• Việc nâng cấp phần mềm mà vẫn không làm hỏng các tích hợp liên quan là rất khó
• Công cụ low-code phải xử lý mã tùy ý cho những trường hợp sử dụng mà bản thân công cụ không được thiết kế để phục vụ
• Lý thuyết thì điều này phải thực hiện được thông qua các hợp đồng API chặt chẽ, nhưng thực tế tôi đã thấy rất nhiều mã tùy biến làm đủ mọi trò ở bên trong

Sự hỗn loạn trong cấu trúc cơ sở dữ liệu

• Tôi từng thấy các doanh nghiệp dùng công cụ low-code cho những quy trình mà phân tích chính xác là điều bắt buộc
• Nhưng khi nhìn vào mô hình dữ liệu nền tảng thì mọi thứ trở nên khó hiểu: user_attribute_47 nghĩa là gì? Chỉ cần chuyển một trường từ trang 1 sang trang 2 của ứng dụng là dữ liệu lại nằm ở một trường riêng khác?

Ý kiến của GN⁺

• Low-code là một công cụ đầy hứa hẹn có thể giúp tăng tốc phát triển và giảm chi phí bảo trì, nhưng khi sử dụng thực tế có thể phát sinh những vấn đề ngoài dự kiến.
• Đặc biệt, khi cần tính năng tùy biến hoặc phải phụ thuộc vào ngôn ngữ phát triển gắn với một công cụ low-code cụ thể, nguồn lập trình viên sẽ bị thu hẹp và việc bảo trì trở nên khó khăn hơn.
• Việc nâng cấp công cụ low-code và sự phức tạp trong cấu trúc cơ sở dữ liệu là những điểm cần cân nhắc quan trọng trong quản lý dự án dài hạn.
• Bài viết này chỉ ra những điều cần lưu ý khi sử dụng công cụ low-code và mang lại góc nhìn đáng chú ý bằng cách khuyến nghị đánh giá thận trọng các trường hợp sử dụng phù hợp.

[ats62]

Cho đến nay, tôi cho rằng khái niệm no-code chỉ được áp dụng một cách giới hạn trong những lĩnh vực nhất định.

Tôi nghĩ trước hết là khi xuất hiện những dịch vụ well-made sử dụng LLM, thì trend của no-code? dòng chảy? xu thế? dù sao thì khái niệm này cũng sẽ thay đổi.

[quack337]

Tôi biết một trường hợp đã tận dụng MS Access khá hữu ích vào khoảng 10 năm trước.

Trong hệ thống thông tin của tổ chức có một cơ sở dữ liệu được thiết kế tương đối tốt và triển khai trên MS Sql Server,
và các tác vụ OLTP hằng ngày cũng được triển khai tương đối ổn.

Tuy nhiên, sự bất mãn đã tích tụ trước cách phản hồi chậm chạp và thiếu tích cực của bộ phận IT đối với các yêu cầu truy vấn dữ liệu không thường xuyên và in báo cáo.

Một nhân viên của bộ phận nghiệp vụ rất thành thạo MS Excel và Access đã cho thấy rằng bằng cách import dữ liệu Excel được tải xuống từ hệ thống thông tin vào Access, họ có thể triển khai các chức năng truy vấn dữ liệu và in báo cáo cần thiết bằng Access chỉ trong vài giờ, hoàn toàn không cần viết mã.

[quack337]

Bộ phận nghiệp vụ yêu cầu có thể kết nối trực tiếp từ Access vào DB, còn bộ phận IT thì phản đối việc để lộ DB của hệ thống thông tin ra mạng bên ngoài. Tuy vậy, vì yêu cầu từ bộ phận nghiệp vụ quá mạnh nên cuối cùng đã tạo riêng một DB được mirror chỉ với một phần dữ liệu rồi cho phép truy cập.

Những nhân viên thành thạo các tính năng dữ liệu của Excel chỉ sau vài ngày đào tạo đã bắt đầu sử dụng Access cho công việc.

[tequila]

Tôi khá đồng cảm với bài viết này. Đây là suy nghĩ cá nhân của tôi thôi,
Nếu dùng cú pháp đặc thù -> sẽ cần thời gian học và việc bảo trì trở nên khó khăn hơn
Nếu chỉ đơn thuần thay thế code bằng UI -> nhiều khi cứ lập trình trực tiếp còn tiện hơn
Nếu trở thành công cụ no-code hoàn chỉnh -> sẽ có nhiều ràng buộc và dễ khiến người dùng phải "hack" lách luật. Tần suất người dùng tạo ra hành vi ngoài dự định cũng tăng mạnh
Kết quả: nó trở thành một công cụ không thể làm hài lòng bất kỳ ai.
Khoảng cách giữa khâu lên kế hoạch, phát triển và người dùng quá lớn, nên đây có vẻ là một lĩnh vực khó làm tốt hơn tưởng tượng.

[GN⁺]

Ý kiến trên Hacker News

• Các góc nhìn đa dạng về low-code

  • Góc nhìn của một nhà phát triển nền tảng low-code

    Low-code rất dễ bán. Chiến lược là biến bộ phận IT thành vấn đề và khai thác những bất mãn sẵn có. Trong demo, nó cho thấy các tác vụ đơn giản được làm rất nhanh. Nhưng tốt hơn là không nên đưa logic nghiệp vụ cốt lõi vào low-code. Giả định rằng các tác vụ phức tạp sẽ được offload sang những hệ thống chuyên biệt. Nó hữu ích cho các nhóm trong doanh nghiệp lớn có kiến thức kỹ thuật nhưng ít quyền hạn về IT. Low-code giải quyết được nhiều vấn đề bằng các công cụ đơn giản, nhưng khả năng mở rộng kém và cần phối hợp với một hệ thống trung tâm mạnh.

  • Góc nhìn của một SRE (kỹ sư độ tin cậy hệ thống)

    Tôi hoài nghi về low-code. Quản lý mã nguồn yếu, tài liệu không tốt. Cần nhiều mã tùy chỉnh nhưng khả năng tái sử dụng thấp. Yêu cầu runtime độc quyền, khó giám sát. Trên thực tế, tôi chưa thấy trường hợp kỹ sư làm phần việc còn người không phải kỹ sư sử dụng. Các công cụ như Looker có thể tích hợp với mã nguồn, nhưng cuối cùng vẫn là kỹ sư dùng. Nó nén bớt độ phức tạp, nhưng tôi vẫn thích những nền tảng có thể tùy biến và mở rộng khi cần.

  • Góc nhìn về nền tảng low-code của Microsoft

    Tôi từng quan tâm đến nền tảng low-code của MS, nhưng nó có vẻ được xây dựng một cách phức tạp trên O365 và Azure. Giao diện người dùng kém, và về lâu dài, tổn thất do vấn đề về khả năng sử dụng có thể còn lớn hơn khoản tiết kiệm chi phí.

  • Kinh nghiệm kinh doanh chuyển đổi các giải pháp cơ sở dữ liệu/biểu mẫu MS-Access

    Tôi đã xây dựng một doanh nghiệp chuyên chuyển các giải pháp MS-Access do người không phải lập trình viên/người dùng cuối tạo ra mà không qua bộ phận IT thành các ứng dụng client/server .net thực thụ. Các giải pháp low-code hữu ích để giải quyết một số vấn đề hoặc làm cho POC chạy được, nhưng có thể phát sinh vấn đề khi cần mở rộng quy mô hoặc thích nghi.

  • Góc nhìn của nhà phát triển website builder SQLPage

    Các giải pháp low-code cần có lối thoát để tương tác với các API "high-code" bên ngoài. Trong SQLPage, điều này được cung cấp qua sqlpage.exec. Có vấn đề là việc nâng cấp nền tảng low-code có thể phá vỡ các triển khai tùy chỉnh. Hầu hết công cụ low-code giữ dữ liệu làm con tin, nhưng SQLPage chỉ thêm một lớp lên trên cơ sở dữ liệu mà người dùng vẫn hoàn toàn kiểm soát.

  • Ý kiến phản đối các công cụ low-code cấp doanh nghiệp

    Tôi phản đối các công cụ low-code mà các tập đoàn lớn sử dụng. Các tập đoàn lớn lẽ ra phải đủ khả năng chi trả cho đội ngũ phát triển phù hợp, kế hoạch phù hợp và tổ chức phù hợp. Không phải code tạo ra chi phí, mà là các lập trình viên kém đưa ra quyết định tồi bằng những công cụ tồi mới tạo ra chi phí.

  • Góc nhìn về low-code và các tầng trừu tượng

    "Low-code" có ít bề mặt code mà bạn có thể giao tiếp trực tiếp hơn, nhưng trên thực tế có rất nhiều code bị ẩn đi. Các tầng trừu tượng rất mạnh khi phù hợp với mục đích, nhưng có thể gây vấn đề khi bị rò rỉ hoặc không phù hợp. Nhìn chung, low-code là sự trừu tượng hóa của code được điều chỉnh cho những mục đích cụ thể, nhưng trên thực tế vẫn cần kinh nghiệm trong miền cụ thể.

  • Kinh nghiệm xây dựng MVP bằng Bubble/Airtable

    Tôi từng nhận báo giá xây dựng MVP từ một đội ở Ukraine, nhưng đã thuê một thực tập sinh dùng Bubble/Airtable để làm ra sản phẩm trong hai tháng và có khách hàng trả phí trong vòng 6 tháng. Suốt gần hai năm, tôi vẫn chưa tìm được lý do để chuyển sang stack truyền thống.

  • Câu chuyện kinh hoàng khi phát triển khóa học học low-code

    Một công ty quan trọng đã dùng gói phần mềm tạo khóa học học tập bằng low-code để phát triển các khóa đào tạo nội bộ cho nhân viên marketing và bán hàng. Vài năm sau, họ cần cập nhật các khóa học, nhưng lại phát sinh vấn đề vì không còn phần mềm đã dùng để phát triển hoặc công cụ có thể thực hiện công việc đó.

  • Câu hỏi về khả năng quản lý phiên bản của triển khai low-code

    Có người đặt câu hỏi liệu triển khai low-code có thể được đưa vào quản lý phiên bản hay không, liệu có thể truy ra nguyên nhân khi có sự cố hay không, và có thể dùng công cụ miễn phí để rollback về một commit cụ thể hay không. Trong đa số trường hợp, các khả năng này không tồn tại, nên không phù hợp cho việc sử dụng nghiêm túc.