Vì sao mọi người vẫn sử dụng VBA

 (sancarn.github.io)
3 điểm bởi GN⁺ 2023-11-16 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi Excel trở thành nền tảng của quy trình công việc trong nhiều tổ chức, mỗi khi cần một tự động hóa nhỏ thì VBA gần như là lựa chọn mặc định trên thực tế
  • Tổ chức trong ví dụ có 13 nền tảng dữ liệu và nhiều công cụ tự động hóa, nhưng các công cụ có thể truy cập rộng rãi vào những nguồn dữ liệu cần thiết thực tế chỉ còn lại VBA và PowerShell
  • Bộ phận CyberSecurity đã từ chối cài đặt các ngôn ngữ bậc cao như Python, Ruby, Node, Rust, còn lựa chọn thay thế là Power Platform thì bộc lộ hạn chế về khả năng truy cập dữ liệu và bảo trì các thuật toán phức tạp
  • Các trường hợp trước đây với Lotus Notes và IBM BPM cho thấy những hệ thống do IT dẫn dắt có thể dễ tổn thương trước việc kết thúc hỗ trợ, migration dở dang và khoảng trống bảo trì
  • VBA tuy cũ và có điểm yếu, nhưng vì được tích hợp trong Office nên ai cũng có thể tiếp cận, đồng thời mang lại quyền kiểm soát để SME tự xác minh logic nghiệp vụ và việc di chuyển dữ liệu

Những lý do trực tiếp khiến VBA tiếp tục được chọn

  • Trong khảo sát năm 2021 của /r/vba, phần lớn người dùng VBA trả lời rằng họ dùng VBA vì không có lựa chọn nào khác
  • Nhiều tổ chức vận hành toàn bộ quy trình công việc bằng Excel, nên khi cần một chút tự động hóa thì VBA thường là lựa chọn đầu tiên
  • Đằng sau lời chỉ trích kiểu “điều khiển một phần hạ tầng bằng bảng tính” là các ràng buộc về công cụ tổ chức cung cấp, khả năng truy cập dữ liệu và cấu trúc bảo trì

Hạn chế của khả năng truy cập dữ liệu và công cụ tự động hóa

  • Bộ phận kỹ thuật của tổ chức ví dụ có thể sử dụng nhiều nền tảng tự động hóa khác nhau
    • OnPrem: PowerShell, VBA của Excel / OfficeJS bị giới hạn / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
    • OnCloud: PowerApps, Power BI, PowerAutomate không premium
    • Môi trường sandbox: ArcGIS của ArcPy, MapInfo của MapBasic, Ruby của InfoWorks ICM, ArcGIS Online
  • Các nền tảng dữ liệu do IT quản lý trải từ D1 đến D13, bao gồm DB không gian địa lý, SAP DB, nền tảng telemetry, SharePoint, Lotus Notes, IBM BPM, hệ thống tệp, Hydraulic Model Information, v.v.
  • Các nền tảng tự động hóa có thể kết nối tới những nguồn dữ liệu cần thiết thực tế chỉ gói gọn ở VBA và PowerShell
    • Power BI Desktop đã được triển khai trong tổ chức, nhưng không bao phủ được mọi nền tảng mà VBA có thể truy cập
    • Ngay cả khi phạm vi truy cập tương đương, Power BI cũng khó dùng cho tự động hóa quy trình, và để xử lý các dataset khác thì người ta dùng cách tạo CSV rồi lưu vào SharePoint
    • Việc tạo CSV đó đôi khi cũng do VBA đảm nhiệm
  • Một số kết nối từ VBA tới dịch vụ OnCloud dựa trên thử nghiệm trực tiếp, và tác giả cho rằng VBA cũng có thể giao tiếp với SAP BW4HANA cùng các dịch vụ cloud khác, nhưng các yêu cầu xác thực và giao thức vẫn chưa được giải quyết

Giới hạn của ngôn ngữ bậc cao và Power Platform

  • Tổ chức muốn dùng các ngôn ngữ bậc cao như Python, Ruby, Node, Rust cho tự động hóa công việc, nhưng mọi yêu cầu cài đặt ở cấp nhóm hay toàn doanh nghiệp đều bị CyberSecurity từ chối
  • Lý do bị từ chối là việc cho phép người dùng cuối truy cập các ngôn ngữ lập trình bậc cao đi ngược với tầm nhìn chiến lược công nghệ của công ty
  • Các lựa chọn thay thế thường được nhắc tới như PowerAutomate, PowerApps gần như không thể truy cập dữ liệu cần thiết
  • Ngay cả khi có thể truy cập dữ liệu, Power Platform vẫn không đủ để thực hiện phần lớn quy trình
    • Các thuật toán cần thiết quá phức tạp nên giải pháp PowerAutomate khó bảo trì và ngay cả nhân sự IT cũng có thể khó hiểu
    • Ví dụ được nêu là projection algorithms
  • Cuối cùng, những công cụ còn lại thực tế chỉ là PowerShell v3 và VBA
    • PowerShell v3 không hỗ trợ cú pháp class và cũng không thể cài module
    • VBA là đối tượng mà tác giả đã phải bỏ ra hàng trăm giờ để tạo các open source VBA libraries nhằm bổ sung cho nó thành một ngôn ngữ hợp lý hơn theo tiêu chuẩn hiện đại

VBA như một bảo đảm về khả năng bảo trì

  • Trong thập niên 2000, nhiều hệ thống được xây dựng trên cơ sở dữ liệu IBM Lotus Notes
  • Sau khi Lotus Notes được HCL mua lại vào năm 2019, tính liên tục của hỗ trợ trở nên bấp bênh, và thời điểm kết thúc hỗ trợ chính thức được dự kiến vào tháng 6 năm 2024
  • Từ năm 2019, đội ngũ kỹ thuật đã cố gắng chuyển nhiều hệ thống sang công nghệ mới, và tổ chức đã chi khoản lớn để phát triển một hệ thống dựa trên IBM Business Process Manager nhằm thay thế một cơ sở dữ liệu Lotus Notes
  • Kế hoạch là điền đầy toàn bộ dữ liệu D10 vào D11 rồi lưu trữ D10, nhưng trạng thái vào năm 2023 lại khác
    • Chỉ còn 8 tháng trước khi hỗ trợ chính thức kết thúc
    • Đội ngũ kỹ thuật đã bỏ hợp đồng hỗ trợ IBM BPM
    • Không thấy hệ thống thay thế nào cho cả IBM BPM lẫn cơ sở dữ liệu Lotus Notes
    • Giải pháp IBM BPM thiếu bảo trì và không hoạt động như mong muốn
    • Một giải pháp không phù hợp với mục đích đã bị ép nhét vào IBM BPM
    • Có REST API, nhưng gần như vô dụng với đội kỹ thuật và SME
      • Một số lệnh gọi REST dùng JavaScript được mã hóa dưới dạng chuỗi
      • Những lệnh gọi khác yêu cầu nhét HTML vào JSON nằm trong XML
      • Các bảng DB được query bằng GUID chứ không phải tên
      • Không có tài liệu về GUID nào tương ứng với bảng hay quy trình nào
    • Dữ liệu D10 trên thực tế chưa được chuyển sang D11, nên doanh nghiệp đang dùng 2 hệ thống chứ không phải 1
    • Mô hình dữ liệu D11 cũng không hỗ trợ đúng dữ liệu D10
  • SME là những người dùng công cụ hằng ngày và là bên quyết định nhu cầu thay đổi hệ thống
  • Khi SME dùng VBA, họ có thể trực tiếp kiểm soát và duy trì hệ thống ở mức cần thiết; điều này hoạt động như một bảo đảm về khả năng bảo trì mà các hệ thống IT không đảm bảo được

Quyền kiểm soát và vấn đề cộng tác với SME

  • Một dự án gần đây là tạo ra hệ thống IT tích hợp mới để thay thế bảng tính cốt lõi của doanh nghiệp, và nếu thành công thì mức độ quan trọng của D6 sẽ được hạ xuống cấp C
  • Đặc tả ban đầu khá đơn giản
    • Máy chủ NodeJS và cơ sở dữ liệu MySQL
    • UI React
    • Cấp quyền truy cập codebase và git cho quản trị viên và SME
    • IT và SME cùng cộng tác xây dựng hệ thống
  • Đội kỹ thuật lại đưa ra yêu cầu khác
    • Quản trị viên và SME không được truy cập mã nguồn
    • Frontend được xây bằng Microsoft PowerApps để phù hợp với “Strategic Vision”
    • Backend được xây bằng Microsoft Azure Pipelines để phù hợp với “Strategic Vision”
  • Từ góc nhìn SME, những yêu cầu này tạo ra nhiều vấn đề
    • Đội kỹ thuật không hiểu công việc thực tế nên khó nắm bắt logic nghiệp vụ và phép tính
    • Khi lập trình viên viết logic nghiệp vụ, lỗi rất dễ xảy ra
    • Đội kỹ thuật thường bỏ mặc các dự án công nghệ tùy biến, khiến nguồn lực bảo trì và cải tiến biến mất
    • Nếu cộng tác với SME, ít nhất sẽ có một nhóm duy trì nguồn lực bảo trì hệ thống
    • SME cần có thể tin vào sản phẩm bàn giao, nhưng nếu không nhìn thấy mã nguồn thì khó xác minh liệu nó có hoạt động ở mọi edge case hay không
    • Dù có unit test, nếu không thấy mã nguồn thì cũng khó kiểm chứng rằng test thực sự tồn tại và được chạy thường xuyên
    • SME có nhiều kiến thức về việc cải tiến và duy trì hệ thống legacy hiện có cũng như cách các hệ thống tương tác với nhau
    • Để xác minh mọi dữ liệu được chuyển và biểu diễn chính xác trong hệ thống mới, họ cần quyền truy cập backend
  • Nếu mã nguồn vẫn nằm trong VBA, SME và bộ phận nghiệp vụ sẽ giữ được quyền kiểm soát
  • Đội kỹ thuật hầu như không chuyển giao quyền kiểm soát cho đội nghiệp vụ, trong khi SME có thể bảo đảm phần mềm được phát triển mô-đun đúng cách thay vì trở thành một khối công nghệ chắp vá, liên kết lỏng lẻo

Trải nghiệm người dùng trong môi trường quen thuộc

  • Phần lớn kỹ sư dùng bảng tính trong công việc hằng ngày
  • VBA được nhúng ngay trong bảng tính, nên có thể cung cấp một công cụ xa lạ bên trong môi trường quen thuộc
  • So với việc đưa ra một công cụ xa lạ trong một môi trường xa lạ, việc thêm chức năng mới vào môi trường quen thuộc có thể mạnh mẽ hơn đối với người dùng

Kết luận: Điểm yếu của VBA và lựa chọn thực tế

  • Có nhiều lý do khiến các tổ chức chọn bảng tính và VBA
    • Các lựa chọn thay thế do IT cung cấp quá nghèo nàn vì lo ngại bảo mật
    • Công cụ thay thế không kết nối đúng cách tới các hệ thống nguồn và thường vẫn còn đang dang dở
    • Có vấn đề trong chiến lược IT vì chưa phản ánh được một số trường hợp sử dụng
    • Vì lo ngại về bảo mật và bảo trì nên họ không muốn cộng tác với SME
    • Người dùng, quản trị viên và SME không được đào tạo đầy đủ về các hệ thống thay thế
    • Người dùng và SME muốn có một mức độ kiểm soát nhất định đối với logic nghiệp vụ của hệ thống
    • Đây là công nghệ khả thi duy nhất được tích hợp trong Office nên ai cũng có thể dùng
  • Không phải VBA không có điểm yếu
  • Bài viết của mataroa có một số điểm đúng
  • Đôi khi việc quản lý rất tệ, nhưng nhiều người trong tổ chức vẫn đang cố gắng làm điều đúng đắn với những công cụ họ được trao

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-11-16
Ý kiến trên Hacker News

  • Trong doanh nghiệp, ngay bên trong Excel đã có sẵn một môi trường phát triển không cần phải đi qua quản lý, quản lý cấp cao, đăng ký dự án, ngân sách, phân công quản lý dự án, v.v. để được phê duyệt phần mềm ngoài danh mục
    Nếu muốn có cả kho dữ liệu trên mạng và giao diện web thì chỉ cần gắn thêm SharePoint. Từ góc độ người dùng cuối như vậy, giải pháp xuất hiện, và giải pháp đó được tạo bằng VBA

    • Trong môi trường mang tính phản địa đàng như doanh nghiệp, đừng kỳ vọng rằng bạn có thể yêu cầu hoặc cài phần mềm lên thiết bị của mình. Bạn chỉ có thể dùng những thứ đã có sẵn, còn muốn thay đổi thì phải đấu với bộ máy quan liêu, nên không đáng
      Trước đây từng có một engine báo cáo kinh khủng làm bằng Word VBA: nó đọc định nghĩa báo cáo từ file share, cắt dán các mảnh template rồi xuất ra. Vì IT không thu hồi chiếc PC của một người đã nghỉ việc nên họ dùng nó chạy .doc suốt ngày để tạo báo cáo kỹ thuật; việc này nhanh và rẻ hơn nhiều so với mua tùy chọn báo cáo của phần mềm CAD/CAM. Tùy chọn đó hẳn sẽ cần tối thiểu 18 tháng, consultant, và tiêu tốn ngân sách dự án
      Khi người ta chửi chuyện làm những thứ kinh khủng bằng Excel VBA, nguyên nhân rất có thể nằm ở tầng cao hơn của stack. Một nguyên nhân khác là “cái búa của khỉ”: nếu đưa cho khỉ một cái búa thì nó sẽ gõ mọi thứ; nếu công cụ duy nhất bạn có là VBA thì mọi thứ trông giống như một giải pháp VBA. Giờ thì ta đã thành loài linh trưởng tiến hóa hơn một chút
    • Tôi đã thấy ít nhất hai lần cảnh một quản lý bộ phận cần thứ gì đó nhưng không thể, hoặc không muốn, làm phiền đội phát triển, rồi bắt đầu bằng câu “cái này khó đến mức nào chứ”. Rồi chẳng mấy chốc đã có vài trăm dòng VBA để giải quyết nhu cầu của họ
      Sang bước tiếp theo, Jim cũng muốn chạy nó nên script được sao chép; Jane thì dùng một phiên bản VBA khác nên nó được sửa; rồi bắt đầu có kiểu “cái này nữa!” và nó phình ra. Cuối cùng thành một mớ vá víu 1.500 dòng, rồi họ muốn chuyển việc bảo trì cho đội phát triển
    • Một người bạn đã tự động hóa toàn bộ công việc của mình bằng Excel. Anh ấy nói hoàn thành việc của cả ngày trong 15 phút, thời gian còn lại thì nghỉ
      Máy tính công ty bị khóa rất chặt nên không cài được gì, cũng không vào được các trang không nằm trong whitelist, nhưng có Excel
    • Bản thân Visual Basic cũng là một ngôn ngữ rất mạnh. Trong các môi trường như macro Excel, sức mạnh đó có thể được khai thác khá nhiều, và nhiều power user trong doanh nghiệp thực sự dùng nó như vậy
      Nó khá giống việc áp dụng mô hình “hệ điều hành Emacs” ngày xưa vào một bối cảnh khác
    • VBA có ở đó, và chạy được. Đây là một ngôn ngữ rất dễ tiếp cận và trực quan để code và lặp lại, không phải lãng phí thời gian vào việc cài dependency bên ngoài, địa ngục thư viện, hay bước biên dịch
      Vì vậy không có gì ngạc nhiên khi VBA vẫn rất có giá trị trong doanh nghiệp. Ngay cả trong các môi trường có công cụ và ngôn ngữ khác, quy trình build trưởng thành, tôi cũng từng thấy các product manager làm phân tích kinh doanh phức tạp đến há hốc mồm bằng VBA, và với vấn đề trong tay họ thì đó là công cụ phù hợp

  • Tôi đã ngạc nhiên khi thấy các lập trình viên chuyên nghiệp cũng dùng Excel/VBA rất nhiều như công cụ phụ trợ
    Vài năm trước, khi làm việc với một quỹ phòng hộ lớn, một nhà phân tích dữ liệu gửi cho tôi một mô hình Excel tự tạo; nhìn phần mở rộng .xlsm là tôi nghĩ chắc có mã VBA bên trong. Tôi tự nhủ “để xem mấy cao bồi ghi macro đã làm gì nào”, nhưng bên trong có rất nhiều VBA, và tác giả là một nhà phân tích dữ liệu tốt nghiệp khoa học máy tính ở Caltech, rất giỏi Python
    VBA được dùng để lấy dữ liệu từ cơ sở dữ liệu đưa vào sheet, tạo công thức, định dạng cho đẹp, và cũng có vài UserForm. Tôi trêu “VBA à? Ở đó còn dùng gì nữa? Máy tỉa bông với xẻng hơi nước à?”, nhưng trái với dự đoán, anh ấy khen Excel và VBA rất nhiều, khiến tôi ngạc nhiên
    Tôi nhớ mãi điều anh ấy nói: “Excel giúp người ta dễ hiểu cấu trúc phụ thuộc mà các phép tính hàm ý. Nếu làm chuyện này bằng Python thì tôi sẽ phải trả lời câu hỏi cả ngày”

    • Càng có kinh nghiệm làm lập trình viên, việc dùng công cụ phù hợp với công việc càng trở nên quan trọng. Có những lúc một giải pháp lười biếng tốt hơn nhiều so với một đống ý tưởng không thể hiểu nổi
    • VBA đúng là có vấn đề (https://sancarn.github.io/vba-articles/issues-with-vba.html), nhưng còn xa mới là công cụ tệ nhất. Ví dụ, nó tốt hơn những thứ như PowerAutomate
      VB6 có một cộng đồng khá lớn, và https://twinbasic.com/ gần đây đã giúp ích nhiều trong việc hợp nhất cộng đồng VBA và VB6. Vì vậy có thể sẽ có một chút hồi sinh trong cộng đồng lập trình viên
    • Doanh nghiệp tôi vận hành phụ thuộc rất nhiều vào Google Sheets. Bằng cách bơm giá trị vào và đọc các giá trị đã tính ra, có thể định nghĩa logic nghiệp vụ khá phức tạp dưới dạng bảng tính, và những người phụ trách kinh doanh, tài chính có thể dễ dàng điều chỉnh. Mọi người đều rất hài lòng với giải pháp này
    • Excel là một giao diện tuyệt vời cho rất nhiều việc, và ở một mức độ nào đó giúp mọi người hiểu dữ liệu. Ngược lại, vì mọi người đã quen với mô hình dữ liệu đó, nên khi nó hơi phức tạp lên, họ cũng có xu hướng tự trách mình thay vì đặt câu hỏi
      Ở Thụy Điển còn có một mô hình dự báo lương hưu Excel/VBA dung lượng 3GB đi kèm hướng dẫn sử dụng dài 38 trang. Nhưng khó có thể xem đây là một ví dụ tận dụng Excel thật tốt: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
    • Một phòng khám nhập viện trước phẫu thuật của một bệnh viện đại học lớn từng được vận hành bằng Excel
      VBA mạnh mẽ và cho phép tạo prototype, lặp lại nhanh. Thậm chí có thể nói VB6 từng là đỉnh cao của ứng dụng CRUD

  • “Vì nó đáng kinh ngạc”
    Trước đây tôi từng nghe nói trên mạng của JP Morgan có hơn 20.000 cơ sở dữ liệu Access. Các nhà phân tích dữ liệu ở nhiều công ty đến một ngày nào đó chán ghét công việc lặp lại hằng ngày của mình, rồi bắt đầu để ý đến nút “ghi macro”. Có người thấy nó khá tiện và tiếp tục dùng. Cũng có người khôn hơn một chút, nhìn vào đoạn mã mà macro sinh ra, học chút ít rồi thử sửa nó
    Một số ít còn học cả cấu trúc dữ liệu và thuật toán để tạo hệ thống xác thực/phân quyền bắt chước Django, làm lại UI UserForm từ đầu, rồi triển khai cả Markdown, phân tích SAX, thanh cuộn tùy chỉnh, logging, thậm chí cả game
    Câu trả lời có lẽ là vì các nhà phân tích dữ liệu đã chán công việc hằng ngày của họ

    • Cũng có thể bộ phận IT đã áp quá nhiều quy trình từ tháp ngà xuống, đẩy mọi người sang shadow IT. Tôi từng thấy ở các tập đoàn lớn, các nhà phân tích dù có năng lực nâng những thứ Frankenstein họ tự tạo lên mức đàng hoàng, vẫn bị chặn bởi kiểu “phải khởi động dự án, tạo ticket, lịch trình, yêu cầu”
      Tất nhiên, việc phải hỗ trợ một thứ mà ai vào cũng cần học là một mối lo hợp lý. Nhưng miễn là phía kinh doanh có thể tiếp cận công cụ để giải quyết vấn đề, những người “chán” sẽ tìm ra cách. Ma sát quá lớn
    • “Ghi macro” là điểm cốt lõi. Dù Microsoft chuyển sang C#, JavaScript, Python hay gì khác, chỉ cần gắn nút đó vào là được
    • Đây cũng là trải nghiệm của nhiều người bắt đầu trong ngành tài chính rồi chuyển sang kỹ thuật dữ liệu hoặc triển khai hệ thống
      Việc tạo một thứ tương đối phức tạp trong Excel rồi đưa lên thư mục chia sẻ mạng dễ hơn so với đi qua IT để cài IDE, làm ra thứ gì đó, qua quy trình bảo mật rồi triển khai, nên có lẽ chuyện này sẽ chưa sớm kết thúc. Không phải vấn đề nào cũng cần một dự án Jira và một giải pháp phức tạp quá mức
      Tuy nhiên, tôi hoàn toàn phản đối việc xây những thứ lớn bằng VBA. Một script nhỏ kiểu dựa trên thay đổi giá trị vài ô để truy vấn cube của một hệ thống rồi kết hợp với dữ liệu bảng từ hệ thống khác thì ổn, nhưng đến một ngưỡng nào đó thì phải chuyển sang chỗ khác
      Với đa số dự án, với giả định có license server để tự động hóa, tôi rất thích stack Alteryx+Tableau/PowerBI
    • Nói thật là tôi cũng từng làm thứ tương tự rồi chuyển sang C#, và giờ thì đơn giản là đã trở thành lập trình viên phần mềm

  • Tôi từng phải tạo một giao diện CRUD đơn giản cho các nhà phân tích
    Vấn đề đầu tiên là các nhà phân tích muốn xử lý toàn bộ các bước CRUD ngay trong Excel. Vì Excel là giao diện thực tế, nên cần một thứ có thể chạy bên trong Excel
    Bộ phận IT không cho truy cập dòng lệnh, và cũng từ chối cài các công cụ phát triển chưa được phê duyệt. Để được phê duyệt có thể mất vài tháng. Các quản trị viên cơ sở dữ liệu không mặn mà với việc thêm DB mới vào Oracle DB hiện có, còn bộ phận IT cũng không thích tự vận hành DB
    Thậm chí chỉ cần thêm add-in mới vào Excel cũng phải đi năn nỉ người phụ trách IT. Nếu may mắn, một ngày nào đó add-in bỗng xuất hiện, nhưng không biết sẽ mất một ngày, một tuần hay một tháng
    Vì vậy lựa chọn thực tế duy nhất là VBA, và cuối cùng chúng tôi đã dựng được một giải pháp tạm thời nhưng cố định, để các nhà phân tích dùng hai tuần một lần

  • Khi làm ở một cơ quan tình báo, tôi phải tạo một ứng dụng cho những người được triển khai ở Afghanistan. Máy tính họ có thể dùng chỉ là Windows XP bị khóa, không có cách nào cài mới
    Vì bị ràng buộc vào Office vốn đã được kiểm định và cài sẵn, nên dù là người dùng Linux, tôi cũng bị ràng buộc vào Office. Chỉ bằng VBA thuần, tôi đã tạo ra khá nhiều thứ Frankenstein và được đánh giá tốt

    • Từ góc nhìn của một người từng được triển khai ở Trung Đông, tôi cũng có trải nghiệm tương tự. Tôi đã tự động hóa được rất nhiều thứ có thể làm bằng VBA trên một máy XP hoàn toàn tách mạng
    • Trong một tình huống tương tự nhưng không hẳn giống, tôi đã xoay xở bằng một file HTML có mã JavaScript trong thẻ script. Tôi tự hỏi không biết dù máy đã tách mạng thì IE vẫn bị chặn chạy, hay chỉ là VBA tiện hơn JavaScript

  • Phải thừa nhận rằng IT là bộ phận quan liêu của thời hiện đại, 95% bận rộn với những vấn đề do chính mình tạo ra, còn tính hướng dịch vụ thì khoảng 5%. Với người ngoài, quy trình rất mù mờ và thường chẳng giúp ích gì
    Tôi đã bật cười thật sự khi đọc đoạn này trong phần mô tả IBM BPM, vì nó tóm tắt khá tốt một phần lớn vấn đề
    “IBM BPM đúng là có REST API, nhưng REST API này gần như vô dụng với đội kỹ thuật và các doanh nghiệp vừa và nhỏ. Một số lệnh gọi REST dùng JavaScript được mã hóa dưới dạng chuỗi, các lệnh gọi khác lại yêu cầu HTML bên trong JSON bên trong XML. Các bảng cơ sở dữ liệu được tra cứu bằng GUID chứ không phải bằng tên. Không có tài liệu nào cho biết GUID nào gắn với bảng/quy trình nào”
    Nhiều thứ đã trở nên phức tạp đến phi lý đến mức không ai ngoài IT muốn đụng vào, và đôi khi ngay cả trong IT cũng không ai muốn đụng. Từ AJAX trở đi, một nửa nỗ lực phát triển bắt đầu đổ vào việc thiết kế mã front-end và các dịch vụ back-end, trong khi chuyện đó thật ra gần như chẳng liên quan gì đến bài toán tự động hóa cho người dùng cuối. Sau đó mọi thứ còn tệ hơn, và UI ngày nay trông hiện đại nhưng lại thù địch với người dùng chẳng kém gì tech stack dùng để tạo ra nó
    Trong Excel, UI đơn giản là đã “ở đó”, còn có cả trình ghi macro như một công cụ sinh mã, và bộ phận IT cũng không xét xem tôi có quyền gì hay nói rằng họ không có thời gian và ngân sách để giúp vấn đề nghiệp vụ của tôi. Vì vậy VBA là một lối đi vòng để người dùng vượt qua bộ phận IT. Nó không hoàn hảo, nhưng vẫn tốt hơn các lựa chọn khác

    • VBA là ngôn ngữ lập trình Agile tối thượng. IT của công ty, tức bộ phận quan liêu, thì bị trói vào những thứ như Scrum, Squad, còn người ở các bộ phận khác thì hoàn thành việc bằng Excel/VBA
      Chẳng có gì thay đổi cả. Thế kỷ trước chuyện này cũng đã xảy ra và được gọi là các hòn đảo tự động hóa. Khi đó, ở quanh tôi, nó được xem là một chiến lược tốt: để các bộ phận thử nghiệm trước, rồi nếu thấy có tiềm năng thì tích hợp
    • Nếu tìm đủ lâu, ở bộ phận nào cũng có thể tìm ra ví dụ tệ. Trong những thứ IT quản lý có thứ nào gần như mất trí không? Tất nhiên là có. Nhưng đó không phải là cái cớ hay để tạo ra shadow IT
      Việc vài nhà phân tích tụ lại hack một công cụ VBA nhỏ của riêng họ thì tôi hoàn toàn không khó chịu. Tinh thần đó đáng được khen, và kết quả thậm chí có thể giúp tôi hiểu công việc hằng ngày của mình rõ hơn
      Điều khiến tôi khó chịu là đến một lúc nào đó các nhà phân tích ấy lại kỳ vọng kiến trúc hệ thống của tôi bằng cách nào đó phải accomodate dự án cá nhân của họ. Hỏi xin tài liệu thì không có, sơ đồ kiến trúc cũng không, xin quyền truy cập repository của con quái vật đó thì họ hỏi “repository là gì?”
      Họ hỏi tại sao bảng tính của họ lại không được bơm dữ liệu vào pipeline xử lý của tôi, và cho rằng tôi phải viết controller cho khớp với mẩu REST họ học được sau khi xem nửa video YouTube. Trong cuộc họp xuất hiện câu hỏi “Ý anh là cần xác thực là sao? Sao IT lúc nào cũng làm mọi chuyện phức tạp lên vậy?”
      Dù là VBA, low-code hay bất cứ thứ gì, việc mọi người tạo công cụ là tốt. Tôi cũng làm điều tương tự, chỉ là tôi gọi nó là shell script và để trong Git repository. Nhưng cũng như tôi không thả công cụ CLI của mình lên server production, tôi cũng sẽ không để bất cứ thứ gì chưa từng qua code review làm vậy
    • Một trong những công việc kỹ sư phần mềm chính thức đầu tiên của tôi là ngồi làm việc cạnh một trader tiền tệ trên sàn giao dịch của một ngân hàng
      Người tuyển tôi là trưởng bộ phận quản lý rủi ro thị trường, và vai trò của ông ấy là đảm bảo ngân hàng không mất quá nhiều tiền trong một ngày. Ông ấy tuyển tôi vì không tin bộ phận IT được phê duyệt chính thức của ngân hàng sẽ viết đúng phần mã triển khai thuật toán của mình. Chẳng hạn, đã có lần họ sai vì không hiểu thứ tự ưu tiên toán tử, rằng phép nhân được ưu tiên hơn phép cộng
      Mọi giao dịch đều phải được đưa làm đầu vào cho phép tính rủi ro thị trường, và vào đầu những năm 2000, tôi đã cài Apache và Perl CGI trên chiếc PC dưới bàn để làm một ứng dụng nhỏ cho các trader nhập giao dịch và theo dõi vị thế. Các trader bắt đầu thích nó hơn giải pháp IT chính thức vì dễ dùng hơn và xem vị thế thuận tiện hơn
      Trong nhiều môi trường doanh nghiệp, tìm cách đi vòng qua IT là một chức năng quan trọng. Quay lại Excel, các trader dùng Excel để tính toán và mô phỏng, còn chúng tôi cung cấp công cụ cắm vào Excel để tận dụng những gì họ vốn đã làm
    • Trong bài có một câu nói rằng đây là quyết định chính sách rõ ràng của công ty
      “Việc cho phép người dùng cuối truy cập một ngôn ngữ lập trình cấp cao đi ngược lại tầm nhìn chiến lược công nghệ của công ty”
    • Câu trả lời là thế này: vì VBA là ngôn ngữ lập trình duy nhất mà doanh nghiệp không thể chọn không cài đặt
      Đúng là điều kỳ diệu của “enterprise”. Mỗi lần có người lôi nó ra như một ưu điểm hay cái cớ, tôi lại thấy kinh ngạc

  • Vì cho đến gần đây chưa có lựa chọn thay thế tốt. Tương lai nằm ở mô hình phần bổ trợ Office mới: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
    Dù bạn nói gì về TypeScript thì ít nhất nó vẫn tốt hơn VBA. Tuy nhiên, khác với VBA, việc không thể lập trình ngay bên trong Excel là một vấn đề lớn. Đôi khi người ta không muốn bắt đầu một dự án phần bổ trợ hoàn chỉnh với giả định sẽ tái sử dụng, mà chỉ muốn một script chạy qua loa một lần để sửa gì đó ngay lúc này. Trong lúc dùng cái này tôi biết đến Script Lab(https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...), có thể nó sẽ hữu ích

    • “Khác với VBA, không thể lập trình ngay bên trong Excel” gần như là lý do đủ để dừng cuộc chơi
      Hơn nữa còn có một câu hỏi hiển nhiên. Người dùng không có quyền có thể cài phần bổ trợ mà không cần bộ phận IT can thiệp không? Có thể nhúng vào bảng tính không? Nếu câu trả lời cho vế đầu là “không” thì thật sự chí mạng, và ngay cả nếu vế sau là “không” thì cũng ảnh hưởng xấu đến việc được chấp nhận. Ưu điểm của macro và VBA là, trừ các thiết lập bảo mật, mọi phiên bản Excel đều có thể chạy ngay mà không cần cài thêm gì
    • Tôi đã không thấy phần nhắc đến Script Lab ở cuối bình luận. Nếu là Microsoft Script Lab thì có thể làm đúng việc đó: https://www.microsoft.com/en-us/garage/profiles/script-lab/
      Vấn đề khác là việc chia sẻ phần bổ trợ cho người dùng cuối không hề đơn giản. Bạn phải đăng lên marketplace hoặc SharePoint, còn sideload thì cần máy chủ SMB và GPO. Tuy nhiên có một lựa chọn hầu như không được nhắc đến ở đâu: nếu đưa nó vào tài liệu, khi mở lần đầu người dùng có thể xác nhận rồi cài đặt
    • Nếu chỉ để hiển thị một UI đẹp cho nhập liệu hoặc trực quan hóa thì ổn, nhưng OfficeJS đáng tiếc là không làm được đến một nửa những gì VBA có thể làm. Nếu hệ thống phần bổ trợ có FFI thì tôi đã chuyển hẳn mãi mãi rồi
      Một vấn đề lớn khác là để dùng OfficeJS, bạn phải có khả năng host một web server. Thông thường phần lớn người dùng cuối không có quyền truy cập như vậy

  • VB(A) giống Python. Không đẹp, nhưng làm được việc. Nếu bạn thấy nó đẹp thì là vì thiếu kinh nghiệm nên không biết nhiều lựa chọn tốt hơn
    Một công cụ có hệ sinh thái tốt — tức công cụ, thư viện và tích hợp — giúp hoàn thành công việc thực tế là hữu ích. Với tư cách là một hệ thống phát triển ứng dụng desktop, Visual Basic, cùng với MS Access cộng thêm lợi thế về DB, đã rất hữu dụng trong nhiều tình huống. Khi vượt quá mức đó, có lẽ cũng đã có tiền để mở rộng sang một giải pháp “thực thụ”
    Không nghi ngờ gì là các hệ thống dựa trên VBA đã kiếm được những khoản tiền khổng lồ. Theo kinh nghiệm làm phát triển tài chính chủ yếu từ góc nhìn người ngoài, lần viết lại Excel/VBA lớn nhất mà tôi thấy là của một công ty đã kiếm rất nhiều tiền từ hợp đồng hoán đổi rủi ro tín dụng quanh năm 2008. Trước khi viết lại, workbook mất 5 phút để mở, nhưng VBA đang xử lý rất nhiều công việc nặng. Những người có kiến thức đã kiếm được khoản thưởng lớn cho công ty và cho chính họ
    Bài học ở đây là điều quan trọng hơn việc công cụ có lý tưởng hay không là liệu nó có dễ tiếp cận với những người không được đào tạo chuyên biệt để dùng công cụ đó hay không. Đó cũng là lý do Python trở thành số một bên ngoài trình duyệt web phía client. Không có nghĩa là nó tốt nhất, mà là nó làm được việc và dễ tiếp cận

    • Có thể lập luận rằng Python là một ngôn ngữ đẹp; nó là một ngôn ngữ hoàn chỉnh có hỗ trợ class và hàm hạng nhất, nhưng vẫn tương đối đơn giản và dễ tiếp cận
      Nhưng đó không phải là lý do duy nhất khiến nó phổ biến. Nó có các công cụ khoa học dữ liệu vững chắc nhất nên tạo ra hiệu ứng áp đảo, và cũng có các web framework khá tốt như Django và Flask. Việc nhiều trường đại học dùng nó làm “ngôn ngữ đầu tiên” thay cho Java cũng là một lý do khiến mức độ phổ biến tăng lên. VBA thì không như vậy
    • Python đẹp, và tôi cho rằng cách dùng khoảng trắng của nó tốt hơn các chiến lược đánh dấu block như dấu ngoặc nhọn, begin/end, if/else
      Kinh nghiệm cũng là biết rằng chuyện đẹp hay không có yếu tố chủ quan. VBA tiến hóa trong các điều kiện “khắc nghiệt”, nên điều đó phần nào giải thích những điểm kỳ lạ của nó
    • Python không phải Scheme, nhưng trong số các ngôn ngữ lập trình thì chắc chắn là thuộc loại đẹp, và trong nhiều trường hợp không có lựa chọn thay thế tốt hơn. Đó là đánh giá dựa trên khoảng 25 năm lập trình bằng hàng chục ngôn ngữ

  • VBA là một ngôn ngữ khá ổn, có hỗ trợ lập trình hướng đối tượng. Không có kế thừa nhưng có thể dùng composition. Nó cho phép truy cập và điều khiển Excel rất sâu, đã trưởng thành và ổn định. Lý do là Microsoft không còn thay đổi nó nhiều nữa
    Việc các “lập trình viên thực thụ” ghét VBA phần lớn là vì có rất nhiều mã VBA spaghetti nghiệp dư do phía nghiệp vụ viết, và đôi khi các lập trình viên bị nhờ debug chúng

    • Phản biện lại thì VBA là một ngôn ngữ tệ hại, nếu bỏ qua việc nó có thể truy cập và điều khiển Excel, Word, v.v.
      Nó đầy những đặc tính kỳ quặc, chẳng hạn các ký tự điều khiển trong mã cũng bị bản địa hóa.[1][2] Nếu muốn mã chạy được cả trên các bản cài đặt không dùng tiếng Anh, bạn phải dùng các placeholder như Application.International(xlDecimalSeparator) để tạo động chuỗi truyền vào hàm đó, khiến khả năng đọc mã giảm mạnh. Khi mã hỏng vì lý do này, thông báo lỗi gần như vô dụng đến khó tin, và nếu lập trình viên không biết đây là một vấn đề tiềm ẩn của VBA thì việc tái hiện lỗi gần như bất khả thi. Muốn tái hiện, họ phải đổi ngôn ngữ giao diện sang một ngôn ngữ có thể họ không biết
      Ít nhất trong Word, khoảng một nửa các hàm hữu ích nhất, chẳng hạn chèn một đoạn văn sau đoạn hiện tại, sẽ hỏng nếu dùng ở đoạn văn cuối cùng của một ô trong bảng, nên cần rất nhiều cách vòng spaghetti
      Nếu muốn truyền qua lại chuỗi văn bản có nhiều định dạng, như tham chiếu thuộc tính innerHtml của một phần tử DOM, thì không dễ làm trừ khi dùng kiểu chọn và copy/paste dựa trên script khá hacky
      Có người ở một thread khác so sánh nó với Bash, và tôi thực sự đồng ý. Không nên viết thứ phức tạp bằng bất kỳ ngôn ngữ nào trong số đó
      [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
      [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
    • Tôi đã đầu tư rất nhiều thời gian để tạo thư viện VBA (https://github.com/sancarn/stdVBA) và cũng thích VBA, nhưng ngôn ngữ này có những vấn đề thực sự gây hạn chế lớn (https://sancarn.github.io/vba-articles/issues-with-vba.html)
      Tuy vậy, đúng là một phần đáng kể sự ghét bỏ dành cho VBA cũng đến từ tình trạng của các dự án VBA (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
    • Tôi nghĩ việc nhìn không thiện cảm với một môi trường có những tính năng sai lầm như On Error Resume Next là công bằng

  • Nếu xét Excel và toàn bộ spreadsheet, nhiều người bên ngoài không hiểu ngôn ngữ spreadsheet đã triển khai lập trình hàm phản ứng tốt đến mức nào. Đó chính là thứ React/Angular đã cố làm cho đúng qua hơn 10 bản phát hành
    Ngoài ra, nhiều người không hiểu vì sao spreadsheet lại tiện với người dùng cuối đến vậy, và kết quả là họ cung cấp những UI kém hơn, thực ra khiến mọi thứ khó dùng hơn
    Đôi khi cần lùi lại một bước và hiểu rằng ngay cả thời chưa có UI đồ họa, những người đi trước đã làm đúng. Ngay từ đầu, kinh doanh vẫn vận hành được, và trong phần lớn thời gian, thứ doanh nghiệp cần là chế độ xem dạng bảng cùng lựa chọn tính toán hàm phản ứng trên đó. Hãy hỏi một người bạn làm ở doanh nghiệp vừa và nhỏ, họ sẽ xác nhận điều đó

    • Một phần đáng kể công sức trong phát triển web được dùng cho phần trình bày. Tôi đồng ý rằng nếu chỉ cần dữ liệu, khó có gì vượt qua được spreadsheet
    • Excel có thể được xem là IDE dành cho người dùng cuối tốt nhất từng được phát minh