เหตุผลที่ผู้คนยังคงใช้ VBA

 (sancarn.github.io)
3 คะแนน โดย GN⁺ 2023-11-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อ Excel กลายเป็นรากฐานของกระบวนการทำงานในหลายองค์กร เมื่อต้องการระบบอัตโนมัติเล็ก ๆ น้อย ๆ VBA จึงกลายเป็นตัวเลือกเริ่มต้นโดยพฤตินัย
  • องค์กรในกรณีศึกษามีแพลตฟอร์มข้อมูล 13 แพลตฟอร์มและเครื่องมืออัตโนมัติหลายตัว แต่เครื่องมือที่เข้าถึงแหล่งข้อมูลที่ต้องการได้อย่างกว้างขวางนั้นเหลือเพียงประมาณ VBA และ PowerShell
  • CyberSecurity ปฏิเสธการติดตั้งภาษาระดับสูงอย่าง Python, Ruby, Node, Rust และทางเลือกอย่าง Power Platform ก็มีข้อจำกัดด้านการเข้าถึงข้อมูลและการดูแลรักษาอัลกอริทึมที่ซับซ้อน
  • กรณีก่อนหน้าของ Lotus Notes และ IBM BPM แสดงให้เห็นว่าระบบที่ขับเคลื่อนโดย IT อาจเปราะบางต่อการสิ้นสุดการสนับสนุน การไมเกรตที่ไม่เสร็จสมบูรณ์ และช่องว่างด้านการบำรุงรักษา
  • แม้ VBA จะเก่าและมีจุดอ่อน แต่รวมอยู่ใน Office ทำให้ทุกคนเข้าถึงได้ และให้ สิทธิ์ควบคุม ที่ SME สามารถตรวจสอบตรรกะทางธุรกิจและการย้ายข้อมูลได้โดยตรง

เหตุผลโดยตรงที่ VBA ยังคงถูกเลือก

  • ในแบบสำรวจของ /r/vba ปี 2021 ผู้ใช้ VBA ส่วนใหญ่ตอบว่าใช้ VBA เพราะ ไม่มีทางเลือกอื่น
  • หลายองค์กรดำเนินกระบวนการทำงานทั้งหมดด้วย Excel และเมื่อจำเป็นต้องทำ automation เล็กน้อย VBA มักเป็นตัวเลือกแรก
  • เบื้องหลังคำวิจารณ์ว่า “ควบคุมโครงสร้างพื้นฐานบางส่วนด้วยสเปรดชีต” คือข้อจำกัดด้านเครื่องมือที่องค์กรจัดให้ การเข้าถึงข้อมูล และโครงสร้างการบำรุงรักษา

ข้อจำกัดด้านการเข้าถึงข้อมูลและเครื่องมือ automation

  • ฝ่ายวิศวกรรมขององค์กรในกรณีศึกษาสามารถใช้แพลตฟอร์ม automation ได้หลายแบบ
    • OnPrem: PowerShell, VBA ของ Excel / OfficeJS ที่จำกัด / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
    • OnCloud: PowerApps, Power BI, PowerAutomate แบบไม่ใช่พรีเมียม
    • สภาพแวดล้อม sandbox: ArcPy ของ ArcGIS, MapBasic ของ MapInfo, Ruby ของ InfoWorks ICM, ArcGIS Online
  • แพลตฟอร์มข้อมูลที่ IT ดูแลมีตั้งแต่ D1 ถึง D13 รวมถึงฐานข้อมูลเชิงภูมิสารสนเทศ, SAP DB, แพลตฟอร์ม telemetry, SharePoint, Lotus Notes, IBM BPM, ระบบไฟล์, Hydraulic Model Information และอื่น ๆ
  • แพลตฟอร์ม automation ที่เชื่อมต่อกับแหล่งข้อมูลที่ต้องการได้ สรุปแล้วเหลือเพียงประมาณ VBA และ PowerShell
    • แม้ Power BI Desktop จะถูกนำมาใช้ในองค์กรแล้ว แต่ก็ไม่ครอบคลุมทุกแพลตฟอร์มที่ VBA เข้าถึงได้
    • แม้ช่วงการเข้าถึงจะเท่ากัน Power BI ก็ใช้กับ process automation ได้ยาก และเมื่อต้องจัดการ dataset อื่น ๆ มักใช้วิธีสร้าง CSV แล้วบันทึกไว้ใน SharePoint
    • การสร้าง CSV นั้นบางครั้งก็เป็นหน้าที่ของ VBA
  • การเชื่อมต่อบริการ OnCloud บางส่วนของ VBA อาศัยการทดลองโดยตรง และมองว่าสามารถ interface กับ SAP BW4HANA และบริการคลาวด์อื่น ๆ ผ่าน VBA ได้เช่นกัน แต่ข้อกำหนดด้านการยืนยันตัวตนและโปรโตคอลยังไม่ได้รับการแก้ไข

ข้อจำกัดของภาษาระดับสูงและ Power Platform

  • องค์กรต้องการใช้ภาษาระดับสูงอย่าง Python, Ruby, Node, Rust สำหรับงาน automation ทางธุรกิจ แต่คำขอติดตั้งให้ทีมหรือทั่วทั้งธุรกิจถูก CyberSecurity ปฏิเสธทั้งหมด
  • เหตุผลในการปฏิเสธคือ การอนุญาตให้ผู้ใช้ปลายทางเข้าถึงภาษาการเขียนโปรแกรมระดับสูงขัดกับวิสัยทัศน์ด้านกลยุทธ์เทคโนโลยีของบริษัท
  • PowerAutomate และ PowerApps ที่ถูกกล่าวถึงเป็นทางเลือกแทบเข้าถึงข้อมูลที่ต้องการไม่ได้
  • แม้จะเข้าถึงข้อมูลได้ Power Platform ก็ยังไม่เพียงพอสำหรับการทำกระบวนการส่วนใหญ่
    • อัลกอริทึมที่ต้องใช้นั้นซับซ้อน ทำให้โซลูชัน PowerAutomate ดูแลรักษายาก และแม้แต่บุคลากร IT ก็อาจเข้าใจได้ยาก
    • ตัวอย่างที่กล่าวถึงคือ projection algorithms
  • สุดท้าย เครื่องมือที่เหลือในทางปฏิบัติคือ PowerShell v3 และ VBA
    • PowerShell v3 ไม่รองรับไวยากรณ์ class และไม่สามารถติดตั้งโมดูลได้
    • VBA คือสิ่งที่ต้องใช้เวลาหลายร้อยชั่วโมงสร้าง open source VBA libraries เพื่อเสริมให้เป็นภาษาที่สมเหตุสมผลตามมาตรฐานสมัยใหม่

VBA ในฐานะหลักประกันการบำรุงรักษา

  • ในยุค 2000 ระบบจำนวนมากถูกสร้างขึ้นบนฐานข้อมูล IBM Lotus Notes
  • หลังจาก Lotus Notes ถูก HCL เข้าซื้อในปี 2019 ความต่อเนื่องของการสนับสนุนก็สั่นคลอน และมีการกำหนดสิ้นสุดการสนับสนุนอย่างเป็นทางการในเดือนมิถุนายน 2024
  • ตั้งแต่ปี 2019 ทีมเทคนิคพยายามย้ายหลายระบบไปยังเทคโนโลยีใหม่ และองค์กรลงทุนอย่างมากในการพัฒนาระบบบน IBM Business Process Manager เพื่อทดแทน Lotus Notes DB หนึ่งตัว
  • แผนคือเติมข้อมูล D10 ทั้งหมดเข้า D11 แล้ว archive D10 แต่สถานะ ณ ปี 2023 กลับแตกต่างออกไป
    • เหลืออีก 8 เดือนก่อนสิ้นสุดการสนับสนุนอย่างเป็นทางการ
    • ทีมเทคนิคยกเลิกสัญญาสนับสนุน IBM BPM
    • ไม่เห็นระบบทดแทนสำหรับทั้ง IBM BPM และ Lotus Notes DB
    • โซลูชัน IBM BPM ขาดการบำรุงรักษาและไม่ทำงานตามที่ต้องการ
    • อยู่ในสภาพที่ยัดโซลูชันซึ่งไม่เหมาะกับวัตถุประสงค์ลงใน IBM BPM
    • มี REST API แต่แทบไม่มีประโยชน์ต่อทีมเทคนิคและ SME
      • REST call บางส่วนใช้ JavaScript ที่เข้ารหัสเป็นสตริง
      • call อื่น ๆ ต้องใส่ HTML ไว้ใน JSON ภายใน XML
      • ตาราง DB ถูก query ด้วย GUID ไม่ใช่ชื่อ
      • ไม่มีเอกสารว่า GUID ใดสอดคล้องกับตารางหรือกระบวนการใด
    • ข้อมูล D10 ไม่ได้ถูกย้ายไป D11 จริง ทำให้ธุรกิจต้องใช้ระบบ 2 ระบบ ไม่ใช่ 1 ระบบ
    • โมเดลข้อมูลของ D11 ก็ไม่รองรับข้อมูล D10 อย่างเหมาะสม
  • SME คือผู้ที่ใช้เครื่องมือทุกวันและเป็นผู้ตัดสินใจว่าระบบต้องเปลี่ยนแปลงอะไร
  • เมื่อ SME ใช้ VBA พวกเขาสามารถควบคุมและดูแลระบบได้โดยตรงเท่าที่จำเป็น และสิ่งนี้ทำหน้าที่เป็น หลักประกันการบำรุงรักษา ที่ระบบ IT ไม่ได้ให้ไว้

สิทธิ์ควบคุมและปัญหาการร่วมงานกับ SME

  • โปรเจกต์ล่าสุดคือการสร้างระบบ IT แบบบูรณาการใหม่เพื่อแทนที่สเปรดชีตหลักของธุรกิจ และหากสำเร็จ ความสำคัญของ D6 จะลดลงเป็นระดับ C
  • ข้อกำหนดเริ่มต้นเรียบง่าย
    • เซิร์ฟเวอร์ NodeJS และฐานข้อมูล MySQL
    • UI แบบ React
    • ให้ผู้ดูแลระบบและ SME เข้าถึง codebase และ git
    • IT และ SME ร่วมกันสร้างระบบ
  • ทีมเทคนิคเสนอข้อกำหนดอื่น
    • ผู้ดูแลระบบและ SME ไม่สามารถเข้าถึงโค้ดได้
    • frontend สร้างด้วย Microsoft PowerApps ให้สอดคล้องกับ “Strategic Vision”
    • backend สร้างด้วย Microsoft Azure Pipelines ให้สอดคล้องกับ “Strategic Vision”
  • จากมุมมองของ SME ข้อกำหนดนี้สร้างปัญหาหลายอย่าง
    • ทีมเทคนิคไม่เข้าใจงานภาคธุรกิจ จึงเข้าใจตรรกะทางธุรกิจและการคำนวณได้ยาก
    • หากนักพัฒนาเขียนตรรกะทางธุรกิจ ก็เกิดข้อผิดพลาดได้ง่าย
    • ทีมเทคนิคมักปล่อยโปรเจกต์เทคโนโลยีแบบ custom ทิ้งไว้ ทำให้ทรัพยากรสำหรับการบำรุงรักษาและปรับปรุงหายไป
    • หากร่วมงานกับ SME อย่างน้อยหนึ่งทีมก็สามารถรักษาทรัพยากรในการดูแลระบบไว้ได้
    • SME ต้องเชื่อถือผลลัพธ์ได้ แต่ถ้ามองไม่เห็นโค้ดก็ยากที่จะตรวจสอบว่าทำงานได้ในทุก edge case หรือไม่
    • แม้จะมี unit test แต่ถ้ามองไม่เห็นโค้ด ก็ตรวจสอบได้ยากว่า test มีอยู่จริงและถูกรันบ่อยหรือไม่
    • SME ปรับปรุงและดูแลระบบ legacy เดิม และมีความรู้มากเกี่ยวกับปฏิสัมพันธ์ระหว่างระบบ
    • การจะตรวจสอบว่าข้อมูลทั้งหมดถูกย้ายและแสดงผลในระบบใหม่อย่างถูกต้อง จำเป็นต้องเข้าถึง backend
  • หากโค้ดยังคงอยู่ใน VBA SME และธุรกิจจะรักษา สิทธิ์ควบคุม ไว้ได้
  • ทีมเทคนิคแทบไม่ส่งมอบสิทธิ์ควบคุมให้ทีมธุรกิจ และ SME สามารถตรวจสอบได้ว่าซอฟต์แวร์ถูกพัฒนาอย่างเป็นโมดูลอย่างเหมาะสม ไม่กลายเป็นกองเทคโนโลยีที่เชื่อมต่อกันแบบหลวม ๆ

ประสบการณ์ผู้ใช้ภายในสภาพแวดล้อมที่คุ้นเคย

  • วิศวกรส่วนใหญ่ใช้สเปรดชีตในงานประจำวัน
  • VBA ฝังอยู่ในสเปรดชีต จึงสามารถมอบเครื่องมือที่ไม่คุ้นเคยภายใน สภาพแวดล้อมที่คุ้นเคย ได้
  • การใส่ฟังก์ชันใหม่เข้าไปในสภาพแวดล้อมที่คุ้นเคยอาจทรงพลังสำหรับผู้ใช้มากกว่าการให้เครื่องมือที่ไม่คุ้นเคยในสภาพแวดล้อมที่ไม่คุ้นเคย

สรุป: จุดอ่อนของ VBA และทางเลือกในโลกจริง

  • มีหลายเหตุผลที่องค์กรเลือกสเปรดชีตและ VBA
    • ทางเลือกที่ IT จัดให้มีน้อยเพราะความกังวลด้านความปลอดภัย
    • เครื่องมือทางเลือกเชื่อมต่อกับระบบต้นทางได้ไม่ดี และมักยังอยู่ระหว่างดำเนินการ
    • มีปัญหากลยุทธ์ IT ที่ไม่ครอบคลุม use case บางส่วน
    • ไม่ต้องการร่วมงานกับ SME เพราะความกังวลด้านความปลอดภัยและการบำรุงรักษา
    • ผู้ใช้ ผู้ดูแลระบบ และ SME ไม่ได้รับการฝึกอบรมเกี่ยวกับระบบทดแทนอย่างเพียงพอ
    • ผู้ใช้และ SME ต้องการสิทธิ์ควบคุมระดับหนึ่งเหนือตรรกะทางธุรกิจของระบบ
    • เป็นเทคโนโลยีเดียวที่ใช้การได้จริง ซึ่งรวมอยู่ใน Office และทุกคนสามารถใช้ได้
  • ไม่ใช่ว่า VBA ไม่มีจุดอ่อน
  • บทความของ mataroa มีบางส่วนที่ถูกต้อง
  • บางครั้งการบริหารจัดการก็แย่ แต่หลายคนในองค์กรพยายามทำสิ่งที่ถูกต้องภายใต้เครื่องมือที่มีอยู่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-16
ความเห็นจาก Hacker News

  • ในองค์กรมีสภาพแวดล้อมสำหรับพัฒนาที่อยู่ใน Excel อยู่แล้ว โดยไม่ต้องผ่านขั้นตอนอย่างการขออนุมัติซอฟต์แวร์ที่ไม่ใช่มาตรฐานจากผู้บริหาร ผู้บริหารระดับสูง การลงทะเบียนโปรเจกต์ งบประมาณ หรือการมอบหมายผู้จัดการโครงการ
    ถ้าอยากได้ทั้งที่เก็บข้อมูลบนเครือข่ายและเว็บอินเทอร์เฟซ ก็แค่ต่อ SharePoint เข้าไป โซลูชันแบบมุ่งไปที่ผู้ใช้ปลายทางลักษณะนี้จึงเกิดขึ้น และโซลูชันนั้นก็ถูกสร้างด้วย VBA

    • ในสภาพแวดล้อมแบบดิสโทเปียขององค์กร อย่าคาดหวังว่าจะขอหรือติดตั้งซอฟต์แวร์ลงเครื่องตัวเองได้ ใช้ได้แค่สิ่งที่มีอยู่แล้ว และถ้าจะเปลี่ยนก็ต้องไปสู้กับ ระบบราชการ ซึ่งไม่คุ้ม
      เมื่อก่อนเคยมีเอนจินทำรายงานสุดสยองที่สร้างด้วย Word VBA มันอ่านนิยามรายงานจาก file share แล้วตัดแปะชิ้นส่วนเทมเพลตเพื่อพิมพ์ออกมา IT ไม่ได้ยึด PC ของพนักงานที่ลาออกไป จึงใช้เครื่องนั้นรัน .doc ทั้งวันเพื่อสร้างรายงานวิศวกรรม ซึ่งเร็วและถูกกว่าการซื้อ option ทำรายงานของซอฟต์แวร์ CAD/CAM มาก เพราะตัวเลือกนั้นน่าจะต้องใช้เวลาอย่างน้อย 18 เดือน ต้องมีที่ปรึกษา และเผางบโปรเจกต์ไปอีก
      เวลาใครด่าว่าคนทำเรื่องสยองด้วย Excel VBA สาเหตุน่าจะอยู่ที่สแต็กชั้นบนมากกว่า อีกเหตุผลหนึ่งคือ “ค้อนของลิง” คือถ้าให้ลิงถือค้อน มันก็จะทุบทุกอย่าง ถ้ามีเครื่องมืออยู่แค่ VBA ทุกอย่างก็ดูเหมือนปัญหาที่แก้ด้วย VBA ได้ ตอนนี้เราอาจจะเป็นไพรเมตที่วิวัฒน์ขึ้นมาหน่อยแล้ว
    • เคยเห็นอย่างน้อยสองครั้งที่ผู้จัดการฝ่ายต้องการอะไรบางอย่าง แต่ไม่สามารถหรือไม่อยากไปรบกวนทีมพัฒนา เลยเริ่มจาก “มันจะยากสักแค่ไหนกัน” แล้วสุดท้ายก็กลายเป็น VBA หลายร้อยบรรทัดที่แก้ปัญหาของตัวเองได้
      ขั้นต่อไปคืออยากให้ Jim ใช้ได้ด้วย ก็เลยคัดลอกสคริปต์ไปให้ ส่วน Jane ใช้ VBA อีกเวอร์ชันหนึ่งเลยต้องแก้เพิ่ม แล้วก็เริ่มมี “เอาอันนี้ด้วย!” จนขยายต่อ สุดท้ายกลายเป็นผ้าขี้ริ้ว 1500 บรรทัด แล้วพยายามโยนงานบำรุงรักษาให้ทีมพัฒนา
    • เพื่อนคนหนึ่งทำงานของตัวเองทั้งหมดให้เป็นอัตโนมัติด้วย Excel เขาบอกว่างานหนึ่งวันเสร็จใน 15 นาที แล้วเวลาที่เหลือก็นั่งพัก
      คอมบริษัทถูกล็อกแน่นมาก ติดตั้งอะไรไม่ได้เลย เข้าเว็บที่ไม่อยู่ใน whitelist ก็ไม่ได้ แต่มี Excel ให้ใช้
    • ตัว Visual Basic เองก็เป็นภาษาที่ทรงพลังมาก ในสภาพแวดล้อมอย่าง Excel macro ก็สามารถดึงพลังนั้นออกมาใช้ได้มากทีเดียว และ power user ในหลายองค์กรก็ใช้งานแบบนั้นจริง
      มันค่อนข้างคล้ายกับการนำพาราไดม์ “Emacs operating system” ไปใช้ในอีกบริบทหนึ่ง
    • VBA มันอยู่ตรงนั้นและมันก็ใช้ได้ผล เป็นภาษาที่เข้าถึงง่ายและเป็นธรรมชาติมากสำหรับการเขียนโค้ดและทำซ้ำ โดยไม่ต้องเสียเวลาไปกับการติดตั้ง dependency ภายนอก นรกของไลบรารี หรือขั้นตอน compile
      เพราะแบบนี้จึงไม่แปลกที่ VBA ยังมีคุณค่ามากในองค์กร แม้ในสภาพแวดล้อมที่มีเครื่องมือและภาษาอื่น รวมถึงกระบวนการ build ที่เป็นผู้ใหญ่แล้ว ก็ยังเคยเห็น product manager ทำ การวิเคราะห์ธุรกิจ ที่ซับซ้อนจนอ้าปากค้างด้วย VBA และสำหรับปัญหาในมือ มันก็เป็นเครื่องมือที่เหมาะสม

  • แปลกใจที่เห็นแม้แต่นักพัฒนามืออาชีพก็ยังใช้ Excel/VBA เป็นเครื่องมือเสริมกันมาก
    เมื่อหลายปีก่อนตอนทำงานกับ hedge fund รายใหญ่แห่งหนึ่ง นักวิเคราะห์ข้อมูลส่งโมเดล Excel ที่เขาทำเองมาให้ พอเห็นนามสกุล .xlsm ก็คิดว่ามีโค้ด VBA อยู่แน่ ๆ แล้วก็คิดว่า “มาดูกันว่าพวกคาวบอยสายอัด macro ทำอะไรไว้” แต่ข้างในมี VBA เยอะมาก และคนเขียนเป็นนักวิเคราะห์ข้อมูลจบวิทยาการคอมพิวเตอร์จาก Caltech ที่เก่ง Python มาก
    VBA ถูกใช้เพื่อดึงข้อมูลจากฐานข้อมูลมาใส่ในชีต สร้างสูตร และจัดรูปแบบให้ดูดี รวมถึงมี UserForm อยู่หลายอัน ตอนนั้นก็แซวว่า “VBA เหรอ? ที่นั่นใช้อะไรอีก เครื่องรีดผ้าหรือรถขุดไอน้ำ?” แต่ผิดคาด เขากลับชม Excel และ VBA อย่างมากจนน่าประหลาดใจ
    ยังจำคำพูดของเขาได้ว่า “Excel ช่วยให้เข้าใจ โครงสร้างการพึ่งพา ที่การคำนวณสื่อออกมาได้ง่าย ถ้าทำสิ่งนี้ด้วย Python ผมคงต้องตอบคำถามทั้งวัน”

    • ยิ่งมีประสบการณ์เป็นนักพัฒนามากขึ้น ก็ยิ่งเห็นความสำคัญของการใช้ เครื่องมือที่เหมาะกับงาน บางครั้งทางแก้ที่ดูขี้เกียจก็ยังดีกว่ากองไอเดียที่ไม่มีใครเข้าใจ
    • VBA มีปัญหาอยู่บ้าง(https://sancarn.github.io/vba-articles/issues-with-vba.html) แต่ก็ห่างไกลจากการเป็นเครื่องมือที่แย่ที่สุด เช่น ยังดีกว่า PowerAutomate
      VB6 มีชุมชนขนาดค่อนข้างใหญ่ และ https://twinbasic.com/ ก็ช่วยรวมชุมชน VBA กับ VB6 ได้มากในช่วงหลัง ดังนั้นอาจมีการ ฟื้นคืนชีพ เล็ก ๆ ในชุมชนนักพัฒนาก็ได้
    • ธุรกิจที่ดูแลอยู่พึ่งพา Google Sheets อย่างมาก โดยใช้วิธีใส่ค่าเข้าไปแล้วอ่านค่าที่คำนวณออกมา ทำให้สามารถนิยาม ตรรกะทางธุรกิจ ที่ค่อนข้างซับซ้อนในรูปแบบสเปรดชีตได้ และคนฝั่งธุรกิจหรือการเงินก็ปรับแต่งได้ง่าย ทุกคนพอใจกับวิธีแก้นี้มาก
    • Excel เป็นอินเทอร์เฟซที่ยอดเยี่ยมสำหรับหลายงาน และในระดับหนึ่งก็ช่วยให้ผู้คนเข้าใจข้อมูลได้ แต่ในทางกลับกัน ผู้คนก็คุ้นกับโมเดลข้อมูลแบบนั้นมาก จนเมื่อมันเริ่มซับซ้อนขึ้น ก็มักจะไม่ตั้งคำถามและโทษตัวเองแทน
      ในสวีเดนยังมี โมเดลพยากรณ์เงินบำนาญ Excel/VBA ขนาด 3GB พร้อมคู่มือผู้ใช้ยาว 38 หน้าอยู่ด้วย แต่คงไม่ใช่ตัวอย่างของการใช้ Excel ได้ดีนัก: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
    • เคยบริหารคลินิกรับผู้ป่วยก่อนผ่าตัดของโรงพยาบาลมหาวิทยาลัยขนาดใหญ่ด้วย Excel
      VBA ทรงพลัง และเหมาะมากกับการทำต้นแบบรวมถึงการทำซ้ำอย่างรวดเร็ว ถึงขั้นพูดได้ว่า VB6 เคยเป็นจุดสูงสุดของแอป CRUD

  • คงเป็นเพราะว่า “มันน่าทึ่ง”
    เคยได้ยินมาว่าสมัยก่อนในเครือข่ายของ JP Morgan มีฐานข้อมูล Access มากกว่า 20,000 ตัว นักวิเคราะห์ข้อมูลในหลายบริษัทวันหนึ่งเริ่มเบื่อกับงานที่ต้องทำทุกวัน แล้วก็หันไปกดปุ่ม “บันทึกแมโคร” บางคนรู้สึกว่ามันสะดวกดีเลยใช้ต่อไป
    บางคนฉลาดกว่านั้นอีก โดยไปเปิดดูโค้ดที่แมโครสร้างออกมา เรียนรู้เพิ่มอีกนิดแล้วลองแก้ไขมัน
    มีคนส่วนน้อยที่ถึงขั้นเรียนโครงสร้างข้อมูลและอัลกอริทึม แล้วสร้างระบบยืนยันตัวตนและกำหนดสิทธิ์แบบเลียน Django สร้าง UI ของ UserForm ใหม่ทั้งหมด และยังทำทั้ง Markdown, SAX parsing, custom scrollbar, logging ไปจนถึงเกมได้เลย
    คำตอบน่าจะเป็นเพราะนักวิเคราะห์ข้อมูล เบื่องานที่ต้องทำทุกวัน

    • อาจเป็นไปได้ด้วยว่าแผนก IT ส่งขั้นตอนจากหอคอยงาช้างลงมามากเกินไป จนคนถูกผลักให้ไปทำ shadow IT เคยเห็นนักวิเคราะห์ในองค์กรใหญ่มีความสามารถพอจะยกระดับแฟรงเกนสไตน์ที่ตัวเองทำขึ้นมาให้ดูดีได้จริง แต่กลับโดนขวางด้วยแนวคิดแบบ “ต้องเริ่มโปรเจกต์ เปิดทิกเก็ต ทำตารางเวลา และเขียน requirement ก่อน”
      แน่นอนว่าการต้องซัพพอร์ตบางอย่างที่ใครก็เข้ามาเรียนรู้ได้ถือเป็นความกังวลที่สมเหตุสมผล แต่ตราบใดที่ฝั่งธุรกิจยังเข้าถึงเครื่องมือสำหรับแก้ปัญหาได้ คนที่ “เบื่อ” ก็จะหาทางเองอยู่ดี เพราะแรงเสียดทานมันสูงเกินไป
    • ประเด็นสำคัญคือ “บันทึกแมโคร” ต่อให้ Microsoft เปลี่ยนไปใช้ C#, JavaScript, Python หรือภาษาอื่น ถ้ายังมีปุ่มนั้นอยู่ก็ทำได้
    • เป็นประสบการณ์แบบเดียวกับคนจำนวนมากที่เริ่มจากสายการเงินแล้วค่อยย้ายไปทำ data engineering หรือ system implementation
      เพราะการทำอะไรที่ซับซ้อนพอประมาณใน Excel แล้วเอาขึ้น network share ยังง่ายกว่าต้องผ่าน IT เพื่อติดตั้ง IDE สร้างอะไรสักอย่าง แล้วผ่านขั้นตอนความปลอดภัยก่อน deploy ดังนั้นคงไม่หายไปในเร็ว ๆ นี้ ไม่ใช่ทุกปัญหาที่ต้องมี Jira project และวิธีแก้ที่ซับซ้อนเกินเหตุ
      แต่ก็ไม่เห็นด้วยอย่างยิ่งกับการทำของชิ้นใหญ่ด้วย VBA สคริปต์เล็ก ๆ ที่ดูค่าเปลี่ยนในไม่กี่เซลล์ แล้วไป query cube ของระบบหนึ่งมารวมกับข้อมูลตารางจากอีกระบบหนึ่งยังพอรับได้ แต่พอถึงจุดหนึ่งก็ควรย้ายไปอย่างอื่น
      สำหรับโปรเจกต์ส่วนใหญ่ ถ้าสมมติว่ามี server license และสามารถทำ automation ได้ จะชอบสแตก Alteryx+Tableau/PowerBI มาก
    • พูดตามตรง ฉันก็เคยทำอะไรคล้าย ๆ กัน ก่อนจะย้ายไป C# แล้วตอนนี้ก็กลายเป็น software developer ไปแล้ว

  • เคยต้องสร้างอินเทอร์เฟซ CRUD แบบง่ายให้พวกนักวิเคราะห์
    ปัญหาแรกคือนักวิเคราะห์อยากทำทุกขั้นตอนของ CRUD ภายใน Excel ทั้งหมด เพราะ Excel คืออินเทอร์เฟซจริง จึงต้องมีบางอย่างที่รันได้ใน Excel
    แผนก IT ไม่อนุญาตให้เข้าถึง command line และก็ไม่ยอมให้ติดตั้งเครื่องมือพัฒนาที่ไม่ได้รับอนุมัติ การจะขออนุมัติอาจกินเวลาหลายเดือน ผู้ดูแลฐานข้อมูลก็ไม่ค่อยอยากเพิ่ม DB ใหม่เข้าไปใน Oracle DB เดิม และแผนก IT ก็ไม่ชอบให้ดูแล DB เองด้วย
    แค่จะเพิ่ม add-in ใหม่ให้ Excel ก็ยังต้องไปอ้อนเจ้าหน้าที่ IT ถ้าโชคดีวันหนึ่ง add-in อาจโผล่มาเอง แต่ไม่มีทางรู้ว่าจะใช้เวลาหนึ่งวัน หนึ่งสัปดาห์ หรือหนึ่งเดือน
    เพราะงั้นทางเลือกที่เป็นจริงได้เพียงอย่างเดียวคือ VBA และสุดท้ายก็ทำวิธีแก้แบบชั่วคราวที่นักวิเคราะห์ใช้ทุกสองสัปดาห์ให้ใช้งานได้สำเร็จ

  • ตอนทำงานอยู่ในหน่วยข่าวกรองแห่งหนึ่ง เคยต้องสร้างแอปสำหรับคนที่ถูกส่งไปประจำการในอัฟกานิสถาน คอมพิวเตอร์ที่พวกเขาใช้ได้มีแค่ Windows XP ที่ถูกล็อกไว้ และไม่มีทางติดตั้งอะไรเพิ่มได้
    เพราะมันผูกอยู่กับ Office ที่ผ่านการตรวจรับและติดตั้งไว้แล้ว แม้ฉันจะเป็นคนใช้ Linux ก็ยังต้องผูกกับ Office ไปด้วย สุดท้ายก็สร้างแฟรงเกนสไตน์ได้หลายอย่างจาก VBA ล้วน ๆ และได้รับเสียงตอบรับที่ดี

    • ในฐานะคนที่เคยถูกส่งไปประจำการในตะวันออกกลาง ก็มีประสบการณ์แบบเดียวกัน ทำ automation ให้ได้มากที่สุดเท่าที่ VBA จะทำได้บน เครื่อง XP ที่แยกเครือข่ายอย่างสมบูรณ์
    • สถานการณ์คล้ายกันแต่ไม่เหมือนกันนัก ฉันเอาตัวรอดด้วยไฟล์ HTML ที่ใส่โค้ด JavaScript ไว้ในแท็ก script แปลกใจว่าเครื่องนั้นแม้จะแยกเครือข่ายแล้ว แต่ IE ก็ยังถูกบล็อกไม่ให้รัน หรือไม่ก็ VBA ใช้ง่ายกว่า JavaScript

  • พูดกันตามตรง IT คือ แผนกระบบราชการ แห่งยุคสมัยใหม่ ยุ่งอยู่กับปัญหาที่ตัวเองสร้างขึ้น 95% และมีความเป็นงานบริการอยู่ราว 5% สำหรับคนนอก กระบวนการต่าง ๆ ไม่โปร่งใสและมักไม่ค่อยช่วยอะไร
    ตอนอ่านคำอธิบาย IBM BPM ส่วนนี้แล้วขำมาก เพราะมันสรุปปัญหาไปได้เยอะทีเดียว
    “IBM BPM มี REST API ก็จริง แต่ REST API นี้แทบไม่มีประโยชน์สำหรับทีมเทคนิคและธุรกิจขนาดเล็กเลย บาง REST call ใช้ JavaScript ที่เข้ารหัสเป็นสตริง บาง call อื่นต้องการ HTML ที่อยู่ใน JSON ที่อยู่ใน XML ตารางฐานข้อมูลถูกอ้างอิงด้วย GUID แทนชื่อ และไม่มีเอกสารว่า GUID ไหนเชื่อมกับตาราง/กระบวนการใด”
    หลายอย่างซับซ้อนอย่างไร้เหตุผลจนไม่มีใครนอกฝ่าย IT อยากแตะต้อง และบางครั้งแม้แต่คนใน IT ก็ไม่แตะ เริ่มตั้งแต่ AJAX ครึ่งหนึ่งของความพยายามในการพัฒนาก็เริ่มถูกใช้ไปกับการออกแบบโค้ดฝั่งฟรอนต์เอนด์และบริการฝั่งแบ็กเอนด์ ซึ่งจริง ๆ แล้วแทบไม่เกี่ยวกับปัญหาการทำงานอัตโนมัติของผู้ใช้ปลายทางเลย หลังจากนั้นมันก็ยิ่งแย่ลง และทุกวันนี้ UI ดูทันสมัยก็จริง แต่ก็เป็นปฏิปักษ์ต่อผู้ใช้พอ ๆ กับเทคโนโลยีสแต็กที่ใช้สร้างมัน
    ใน Excel นั้น UI มันก็แค่อยู่ตรงนั้นเลย มีทั้ง macro recorder ซึ่งเป็นตัวสร้างโค้ดด้วย และฝ่าย IT ก็ไม่มานั่งตรวจสิทธิ์ของฉันหรือบอกว่าไม่มีเวลาและงบประมาณจะช่วยปัญหาทางธุรกิจของฉัน ดังนั้น VBA จึงเป็น ทางลัดอ้อม ที่ผู้ใช้ใช้เพื่อเลี่ยงฝ่าย IT มันไม่สมบูรณ์แบบ แต่ก็ยังดีกว่าทางเลือกอื่น

  • VBA คือภาษาโปรแกรมแบบแอไจล์ขั้นสุดยอด ฝ่าย IT ของบริษัท ซึ่งก็คือฝ่ายราชการ ถูกผูกมัดด้วย Scrum, Squad และอะไรทำนองนั้น แต่คนในแผนกอื่นก็ทำงานให้เสร็จด้วย Excel/VBA
    ไม่มีอะไรเปลี่ยนไป เรื่องแบบนี้มีมาตั้งแต่ศตวรรษก่อนแล้ว และมันถูกเรียกว่า เกาะแห่งระบบอัตโนมัติ ตอนนั้นคนรอบตัวฉันมองว่านี่เป็นกลยุทธ์ที่ดี คือปล่อยให้แต่ละแผนกลองเล่นกันก่อน แล้วถ้าเห็นแววค่อยรวมเข้าระบบ

  • ถ้าหานานพอ ก็ย่อมหาตัวอย่างแย่ ๆ ได้จากทุกแผนก แน่นอนว่าของที่ฝ่าย IT ดูแลอยู่ก็มีที่ใกล้เคียงคำว่าเพี้ยนเหมือนกัน แต่ก็ไม่ได้แปลว่านั่นเป็นข้ออ้างที่ดีในการสร้าง Shadow IT
    ถ้านักวิเคราะห์ไม่กี่คนรวมตัวกันแฮ็กเครื่องมือ VBA เล็ก ๆ ใช้กันเอง ฉันไม่ได้รังเกียจเลย จิตวิญญาณแบบนั้นน่าชื่นชม และผลลัพธ์อาจทำให้ฉันเข้าใจงานประจำวันของพวกเขามากขึ้นด้วย
    สิ่งที่น่ารำคาญคือเมื่อถึงจุดหนึ่งนักวิเคราะห์เหล่านั้นเริ่มคาดหวังให้สถาปัตยกรรมระบบของฉันต้องปรับตัวมารองรับโปรเจกต์ส่วนตัวของพวกเขา พอขอเอกสารก็ไม่มี ไม่มีแม้แต่ภาพรวมสถาปัตยกรรม พอขอสิทธิ์เข้าถึง repository ของเจ้าสัตว์ประหลาดนั่นก็ได้คำตอบว่า “repository คืออะไร?”
    พวกเขาถามว่าทำไมสเปรดชีตของพวกเขาถึงส่งข้อมูลเข้า pipeline ประมวลผลของฉันไม่ได้ และคิดว่าฉันควรเขียน controller ให้เข้ากับเศษเสี้ยว REST ที่พวกเขาไปเรียนจากการดู YouTube มาแค่ครึ่ง ๆ กลาง ๆ แล้วในที่ประชุมก็มีคำถามอย่าง “คำว่าต้องมี authentication นี่หมายความว่าอะไร? ทำไม IT ต้องทำทุกอย่างให้ซับซ้อนตลอด?”
    ไม่ว่าจะเป็น VBA, low-code หรืออะไรก็ตาม การที่คนสร้างเครื่องมือขึ้นมาใช้เองนั้นเป็นเรื่องดี ฉันเองก็ทำเหมือนกัน แค่ของฉันเรียกว่าเชลล์สคริปต์และเก็บไว้ใน Git repository แต่เหมือนที่ฉันจะไม่ปล่อยเครื่องมือ CLI ของตัวเองขึ้น production server ฉันก็จะไม่ทำแบบนั้นกับของที่ไม่เคยผ่าน code review เลยเช่นกัน

  • งานซอฟต์แวร์เอนจิเนียริงประจำช่วงแรก ๆ ของฉันงานหนึ่งคือการนั่งทำงานข้าง ๆ เทรดเดอร์ค่าเงินบน trading floor ของธนาคาร
    คนที่จ้างฉันคือหัวหน้าฝ่ายบริหารความเสี่ยงตลาด ซึ่งมีหน้าที่ทำให้ธนาคารไม่เสียเงินมากเกินไปในหนึ่งวัน เขาจ้างฉันเพราะไม่เชื่อว่าฝ่าย IT ที่ได้รับการรับรองอย่างเป็นทางการจะเขียนโค้ดตามอัลกอริทึมของเขาได้ถูกต้อง ตัวอย่างเช่น พวกเขาเคยพลาดเพราะไม่เข้าใจ ลำดับความสำคัญของตัวดำเนินการ ว่าการคูณมาก่อนการบวก
    การคำนวณความเสี่ยงตลาดต้องใช้ทุกธุรกรรมเป็นข้อมูลนำเข้า และในยุคต้นทศวรรษ 2000 ตอนนั้นฉันติดตั้ง Apache กับ Perl CGI ลงบนพีซีใต้โต๊ะเพื่อทำแอปเล็ก ๆ ให้เทรดเดอร์ป้อนรายการซื้อขายและติดตามสถานะโพสิชันได้ พวกเทรดเดอร์เริ่มชอบสิ่งนี้มากกว่าโซลูชัน IT ทางการ เพราะใช้ง่ายกว่าและดูโพสิชันได้สะดวกกว่า
    ในสภาพแวดล้อมองค์กรหลายแห่ง ความสามารถสำคัญอย่างหนึ่งคือการหาทางเลี่ยงฝ่าย IT กลับมาที่ Excel เทรดเดอร์ใช้ Excel สำหรับการคำนวณและการจำลองสถานการณ์ และเราก็พยายามให้เครื่องมือที่เสียบเข้ากับ Excel ได้ เพื่อใช้ประโยชน์จากสิ่งที่พวกเขาทำอยู่แล้ว

  • ในบทความมีประโยคหนึ่งที่บอกว่านี่เป็นการตัดสินใจเชิงนโยบายอย่างชัดเจนของบริษัท
    “การอนุญาตให้ผู้ใช้ปลายทางเข้าถึงภาษาการเขียนโปรแกรมระดับสูง ขัดกับวิสัยทัศน์ด้านกลยุทธ์เทคโนโลยีของบริษัท”

  • คำตอบก็คือนี่เอง เพราะ VBA เป็นภาษาการเขียนโปรแกรมเพียงภาษาเดียวที่องค์กรเลือกไม่ติดตั้งไม่ได้
    นี่แหละความมหัศจรรย์ของ “องค์กร” ทุกครั้งที่มีคนหยิบเรื่องนี้ขึ้นมาเหมือนเป็นข้อดีหรือข้อแก้ตัว ฉันก็ยังทึ่งอยู่เสมอ

  • จนกระทั่งเมื่อไม่นานมานี้ก็ยังไม่มีทางเลือกที่ดีนัก อนาคตอยู่ที่โมเดล Office Add-ins แบบใหม่: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
    จะว่าอย่างไรกับ TypeScript อย่างน้อยมันก็ดีกว่า VBA เพียงแต่ต่างจาก VBA ตรงที่ไม่สามารถเขียนโปรแกรมได้ทันทีจากภายใน Excel ซึ่งเป็นปัญหาใหญ่ บางครั้งเราก็ไม่ได้อยากเริ่มโปรเจ็กต์ add-in แบบจริงจังที่ตั้งใจให้ใช้ซ้ำ แค่อยากได้สคริปต์ที่เขียนแบบคร่าว ๆ เพื่อรันครั้งเดียวแล้วแก้อะไรบางอย่างได้ทันที ระหว่างใช้ไปก็ได้รู้จัก Script Lab(https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...) ซึ่งอาจจะช่วยได้

    • “ต่างจาก VBA ตรงที่ไม่สามารถเขียนโปรแกรมได้ทันทีจากภายใน Excel” นี่แทบจะเป็น เหตุให้ยุติการพิจารณา เลย
      แถมยังมีคำถามสำคัญที่ชัดเจนอีกว่า ผู้ใช้ที่ไม่มีสิทธิ์สามารถติดตั้ง add-in ได้เองโดยไม่ต้องให้ฝ่าย IT เข้ามาเกี่ยวข้องหรือไม่? สามารถฝังไปกับสเปรดชีตได้หรือไม่? ถ้าข้อแรกตอบว่า “ไม่ได้” นี่ถือว่าร้ายแรงจริง ๆ และถึงข้อหลังจะตอบว่า “ไม่ได้” ก็ยังส่งผลเสียต่อการนำไปใช้ ข้อดีของแมโครและ VBA คือยกเว้นเรื่องการตั้งค่าความปลอดภัยแล้ว Excel ทุกอินสแตนซ์สามารถรันได้ทันทีโดยไม่ต้องติดตั้งอะไรเพิ่ม
    • ตอนแรกผมไม่เห็นว่าท้ายคอมเมนต์มีการพูดถึง Script Lab ถ้าเป็น Microsoft Script Lab มันทำแบบนั้นได้พอดี: https://www.microsoft.com/en-us/garage/profiles/script-lab/
      ปัญหาอีกอย่างคือการแชร์ add-in ให้ผู้ใช้ปลายทางไม่ใช่เรื่องเล็ก ต้องเผยแพร่ผ่าน marketplace หรือ SharePoint และการ sideload ต้องใช้เซิร์ฟเวอร์ SMB กับ GPO แต่ก็มีอีกทางเลือกหนึ่งที่แทบไม่มีใครพูดถึง คือสามารถใส่ไว้ในเอกสารเพื่อให้ติดตั้งได้ตอนเปิดครั้งแรกหลังจากผู้ใช้ยืนยัน
    • ถ้าใช้เพื่อแสดงแค่ UI สวย ๆ สำหรับการป้อนข้อมูลหรือการทำภาพข้อมูลก็ดีอยู่หรอก แต่ OfficeJS น่าเสียดายที่ยังทำได้ไม่ถึงครึ่งของสิ่งที่ VBA ทำได้ ถ้าระบบ add-in มีแค่ FFI ก็คงย้ายไปใช้ตลอดกาลแล้ว
      ปัญหาใหญ่อีกอย่างคือถ้าจะใช้ OfficeJS คุณต้องมีความสามารถในการโฮสต์เว็บเซิร์ฟเวอร์ ซึ่งโดยปกติแล้วผู้ใช้ปลายทางส่วนใหญ่ไม่มีสิทธิ์เข้าถึงแบบนั้น

  • VB(A) คล้าย Python ไม่ได้สวยงามแต่ทำงานสำเร็จ ถ้าคุณคิดว่ามันสวย นั่นอาจเป็นเพราะประสบการณ์ยังไม่มากพอที่จะรู้จักทางเลือกที่ดีกว่านี้อีกเยอะ
    เครื่องมือที่มี ecosystem ดี ซึ่งหมายถึงมีเครื่องมือ ไลบรารี และการผสานรวมที่ช่วยให้ทำงานจริงให้เสร็จได้ นั้นมีประโยชน์มาก ในฐานะระบบพัฒนาแอปเดสก์ท็อป Visual Basic รวมถึง MS Access ที่เพิ่มข้อได้เปรียบด้าน DB เข้ามา เคยมีประโยชน์มากในหลายสถานการณ์ หากไปไกลเกินระดับนั้น ก็น่าจะมีงบพอจะขยายไปสู่โซลูชัน “ของจริง” ได้แล้ว
    แทบไม่ต้องสงสัยเลยว่ามีการทำเงินมหาศาลจากระบบที่อิง VBA จากประสบการณ์ที่ผมทำงานด้านการพัฒนาการเงินเป็นหลักในฐานะคนนอก งานเขียนใหม่ Excel/VBA ที่ใหญ่ที่สุดที่เคยเจอเป็นของบริษัทที่ทำเงินก้อนโตจาก credit default swaps แถว ๆ ปี 2008 ก่อนเขียนใหม่ เวิร์กบุ๊กใช้เวลา 5 นาทีถึงจะเปิดขึ้นมาได้ แต่ VBA เป็นตัวจัดการงานหนักจำนวนมาก คนที่มีความรู้เรื่องนี้ทำเงินโบนัสก้อนโตให้ทั้งบริษัทและตัวเอง
    บทเรียนที่ควรได้จากเรื่องนี้คือ สิ่งสำคัญกว่าการที่เครื่องมือจะสมบูรณ์แบบหรือไม่ คือมัน เข้าถึงได้ สำหรับคนที่ไม่ได้รับการฝึกมาโดยเฉพาะให้ใช้เครื่องมือนั้นหรือเปล่า นั่นก็เป็นเหตุผลเดียวกับที่ Python ขึ้นเป็นอันดับ 1 นอกเว็บเบราว์เซอร์ฝั่งไคลเอนต์ ไม่ได้แปลว่าดีที่สุด แต่แปลว่ามันทำงานได้และเข้าถึงได้

    • จะบอกว่า Python เป็นภาษาที่สวยก็พอได้ และมันเป็นภาษาที่สมบูรณ์รองรับทั้งคลาสและฟังก์ชันชั้นหนึ่ง ขณะเดียวกันก็ยังค่อนข้างเรียบง่ายและเข้าถึงได้
      แต่นั่นไม่ใช่เหตุผลเดียวที่มันได้รับความนิยม มันมี เครื่องมือด้านวิทยาศาสตร์ข้อมูล ที่แข็งแรงที่สุดจนเกิดแรงดึงดูดแบบท่วมท้น และยังมีเว็บเฟรมเวิร์กใช้ได้อย่าง Django และ Flask อีกด้วย การที่มหาวิทยาลัยจำนวนมากใช้มันแทน Java เป็น “ภาษาแรกสำหรับการเรียนรู้” ก็เป็นอีกเหตุผลที่ทำให้ความนิยมเพิ่มขึ้น VBA ไม่ได้เป็นแบบนั้น
    • Python สวย และผมมองว่าวิธีใช้ช่องว่างของมันดีกว่ายุทธศาสตร์การแสดงบล็อกแบบวงเล็บปีกกา, begin/end หรือ if/else
      ประสบการณ์ยังหมายถึงการรู้ด้วยว่าความสวยหรือไม่สวยมีองค์ประกอบเชิงอัตวิสัยอยู่บ้าง VBA วิวัฒน์ขึ้นมาภายใต้เงื่อนไขที่ “โหด” จึงพออธิบายความแปลกหลายอย่างของมันได้ในระดับหนึ่ง
    • Python อาจไม่ใช่ Scheme แต่ในบรรดาภาษาโปรแกรมมันก็ถือว่าสวยแน่นอน และในหลายกรณีก็ไม่มีทางเลือกที่ดีกว่า นี่คือความเห็นจากการเขียนโปรแกรมมาราว 25 ปีด้วยภาษาหลายสิบภาษา

  • VBA เป็นภาษาที่ใช้ได้และรองรับการเขียนโปรแกรมเชิงวัตถุ ไม่มี inheritance แต่ทำ composition ได้ เข้าถึงและควบคุม Excel ได้ลึกมาก อีกทั้งยังสุกงอมและเสถียร เพราะ Microsoft แทบไม่เปลี่ยนแปลงมันมากแล้ว
    ที่ “โปรแกรมเมอร์ตัวจริง” มักเกลียด VBA ก็ส่วนใหญ่เพราะมี โค้ด VBA แบบสปาเกตตี ที่คนฝั่งธุรกิจเขียนแบบสมัครเล่นอยู่เยอะ และบางครั้งโปรแกรมเมอร์ก็ถูกขอให้ช่วยดีบักมัน

    • ถ้าจะโต้แย้ง ก็ต้องบอกว่า VBA เป็นภาษาที่แย่มาก ถ้าไม่นับความสามารถในการเข้าถึงและควบคุม Excel, Word ฯลฯ
      มันเต็มไปด้วยพฤติกรรมประหลาด เช่น อักขระควบคุมในโค้ดถูกแปลตาม locale [1][2] ถ้าอยากให้โค้ดรันได้บนเครื่องติดตั้งที่ไม่ใช่ภาษาอังกฤษ ก็ต้องใช้ตัวแทนอย่าง Application.International(xlDecimalSeparator) แล้วประกอบสตริงที่จะส่งเข้าไปในฟังก์ชันนั้นแบบไดนามิก ซึ่งทำให้อ่านโค้ดยากลงมาก ด้วยเหตุนี้ เวลาที่โค้ดพัง ข้อความผิดพลาดก็แทบไม่ช่วยอะไรเลย และถ้านักพัฒนาไม่รู้ว่านี่เป็นปัญหาแฝงของ VBA ก็แทบจะจำลองปัญหาซ้ำไม่ได้เลย การจะทำซ้ำได้อาจต้องเปลี่ยนภาษาอินเทอร์เฟซไปเป็นภาษาที่เราอาจไม่รู้ด้วยซ้ำ
      อย่างน้อยใน Word ฟังก์ชันที่มีประโยชน์ที่สุดประมาณครึ่งหนึ่ง เช่น การแทรกย่อหน้าหลังย่อหน้าปัจจุบัน จะพังถ้าใช้กับย่อหน้าสุดท้ายในเซลล์ตาราง จนต้องมีทางอ้อมแบบสปาเกตตีเต็มไปหมด
      ถ้าอยากรับส่งสตริงข้อความที่มีการจัดรูปแบบหลายแบบรวมอยู่ด้วย คล้ายกับการอ้างถึงพร็อพเพอร์ตี innerHtml ของ DOM element ก็ทำได้ไม่ง่าย เว้นแต่จะใช้วิธีแฮ็ก ๆ ด้วยสคริปต์เพื่อเลือกแล้วคัดลอก/วาง
      มีคนหนึ่งเทียบมันกับ Bash ในอีกเธรดหนึ่ง ซึ่งผมก็เห็นด้วยจริง ๆ ไม่ควรเขียนอะไรที่ซับซ้อนด้วยภาษาไหนก็ตามแบบนี้
      [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
      [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
    • ผมทุ่มเวลาอย่างมากไปกับการสร้างไลบรารี VBA (https://github.com/sancarn/stdVBA) และผมก็ชอบ VBA แต่ก็มีปัญหาจริงที่เป็นข้อจำกัดใหญ่ของภาษา (https://sancarn.github.io/vba-articles/issues-with-vba.html)
      แต่ก็จริงเหมือนกันว่าความเกลียดชังจำนวนมากที่ VBA ได้รับนั้นมาจากสภาพของโปรเจกต์ VBA เอง (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
    • ผมคิดว่าการมองสภาพแวดล้อมที่มีฟีเจอร์แย่ ๆ อย่าง On Error Resume Next ในแง่ลบนั้นก็ยุติธรรมดี

  • เมื่อคิดถึง Excel และสเปรดชีตโดยรวม หลายคนจากโลกภายนอกไม่ค่อยเข้าใจว่าสเปรดชีตทำ การเขียนโปรแกรมเชิงฟังก์ชันแบบ reactive ได้ดีแค่ไหน นี่แหละคือสิ่งที่ React/Angular พยายามทำให้ถูกต้องมาตลอดมากกว่า 10 รุ่นรีลีส
    อีกทั้งหลายคนก็ไม่เข้าใจว่าทำไมสเปรดชีตถึงใช้งานสบายมากสำหรับผู้ใช้ปลายทาง ผลลัพธ์คือพวกเขากลับทำ UI ที่ด้อยกว่าและใช้งานจริงยากกว่า
    บางครั้งเราต้องถอยมาหนึ่งก้าวเพื่อเข้าใจว่า คนยุคก่อนก็ทำสิ่งต่าง ๆ ได้ถูกต้องดีแม้ในสมัยที่ยังไม่มีกราฟิก UI ช่วงแรก ๆ ธุรกิจก็ยังเดินต่อได้ และตลอดเวลาส่วนใหญ่ สิ่งที่องค์กรต้องการก็คือมุมมองแบบตารางกับความสามารถในการคำนวณแบบ reactive บนมัน ลองไปถามเพื่อนที่ทำงานใน SME ดูก็ได้ เขาจะยืนยันให้เอง

    • งานส่วนใหญ่ของการพัฒนาเว็บใช้ไปกับการนำเสนอ ถ้าต้องการแค่ข้อมูลอย่างเดียว ก็เห็นด้วยว่ายากที่จะทำได้ดีกว่า สเปรดชีต
    • Excel อาจถือได้ว่าเป็น IDE สำหรับผู้ใช้ปลายทางที่ดีที่สุดเท่าที่เคยถูกประดิษฐ์ขึ้นมา