นักพัฒนาปกป้อง Excel และเครื่องมือ Visual Workflow ต่อข้อกล่าวหาว่าพวกเขา "ยอมแพ้" การเขียนโค้ด

บทความล่าสุดที่วิพากษ์วิจารณ์เครื่องมือ visual workflow อย่าง Zapier และ Microsoft Power Automate ว่าเป็น Excel สำหรับนักพัฒนาที่ยอมแพ้ ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนเทคโนโลยี บทความต้นฉบับโต้แย้งว่านักพัฒนามืออาชีพกำลังขี้เกียจโดยเลือกใช้อินเตอร์เฟซแบบลากและวางแทนการเขียนโค้ดแบบดั้งเดิม แต่การตอบสนองจากชุมชนกลับเล่าเรื่องราวที่แตกต่างออกไป

เครื่องมือ Visual Workflow ยอดนิยมที่ได้รับการกล่าวถึง:

• Zapier - แพลตฟอร์มระบบอัตโนมัติบนเว็บ
• Microsoft Power Automate - บริการระบบอัตโนมัติเวิร์กโฟลว์ของ Microsoft
• make.com - แพลตฟอร์มระบบอัตโนมัติแบบภาพ
• n8n - เครื่องมือระบบอัตโนมัติเวิร์กโฟลว์แบบโอเพนซอร์ส

Excel กลายเป็นฮีโร่ที่ไม่คาดคิดในการถกเถียง

แทนที่จะเห็นด้วยกับการวิจารณ์ นักพัฒนาจำนวนมากรีบเข้าปกป้อง Excel ในฐานะซอฟต์แวร์ที่ประสบความสำเร็จมากที่สุดชิ้นหนึ่งที่เคยถูกสร้างขึ้น ชุมชนผลักดันกลับแนวคิดที่ว่า Excel แสดงถึงความล้มเหลว แต่กลับเน้นย้ำถึงพลังของมันในการช่วยให้ผู้ใช้ที่ไม่ใช่ด้านเทคนิคสามารถแก้ปัญหาที่ซับซ้อนได้ ผู้แสดงความเห็นคนหนึ่งสังเกตว่า Excel ให้พลัง turing-complete มากมายแก่ผู้ใช้ที่ไม่ใช่ด้านเทคนิค และช่วยให้คนอย่าง Karen จากแผนกบัญชีสามารถเขียนโปรแกรมได้อย่างแท้จริงด้วยการฝึกอบรมเพียงเล็กน้อย

การอภิปรายเผยให้เห็นว่าตัวอย่างของ Karen ที่สร้างสเปรดชีตติดตามค่าใช้จ่ายที่ซับซ้อนในบทความต้นฉบับไม่ใช่เรื่องเตือนใจ แต่เป็นเรื่องราวแห่งความสำเร็จจริง ๆ สมาชิกชุมชนโต้แย้งว่า Karen รวมทักษะทางเทคนิคเข้ากับความรู้ในโดเมนเพื่อสร้างสิ่งที่มีค่ามากจนบริษัทต้องพึ่งพาในปัจจุบัน นี่แสดงถึงการเสริมพลังประเภทที่ทำให้ Excel ปฏิวัติวงการ

คำถามเรื่องผู้ชมที่แท้จริงจุดประกายความชัดเจน

สมาชิกชุมชนหลายคนตั้งคำถามว่านักพัฒนาที่มีประสบการณ์จริง ๆ ใช้เครื่องมือ visual workflow เป็นโซลูชันหลักสำหรับโปรเจ็กต์ใหญ่ ๆ หรือไม่ ความท้าทายนี้นำไปสู่การชี้แจงที่สำคัญจากผู้เขียนต้นฉบับ ซึ่งยอมรับว่าบุคลิกภาพนี้อาจไม่แพร่หลายเท่าที่แนะนำในตอนแรก ผู้เขียนเปิดเผยว่าพวกเขาเองก็เป็นส่วนหนึ่งของผู้ชมกลุ่มนี้ โดยตกอยู่ในรูปแบบของการหยิบเครื่องมือภาพแม้ว่าโค้ดจะเหมาะสมกว่า

การยอมรับนี้เปลี่ยนการสนทนาไปสู่ความเข้าใจที่มีความแตกต่างมากขึ้น ชุมชนตระหนักว่าเครื่องมือ visual workflow ให้บริการผู้ชมที่ตั้งใจไว้ - ผู้ใช้ธุรกิจและผู้ที่ไม่ใช่โปรแกรมเมอร์ - ได้เป็นอย่างดี ปัญหาจะเกิดขึ้นเมื่อนักพัฒนามืออาชีพใช้เครื่องมือเหล่านี้สำหรับเวิร์กโฟลว์ที่ซับซ้อนซึ่งการเขียนโค้ดแบบดั้งเดิมจะดีกว่า

ความเป็นจริงทางธุรกิจขับเคลื่อนการนำเครื่องมือมาใช้

การอภิปรายเปิดเผยเหตุผลเชิงปฏิบัติว่าทำไมองค์กรถึงเลือกเครื่องมือ visual workflow ที่เกินกว่าความชอบของนักพัฒนา สมาชิกชุมชนเน้นว่าเครื่องมือเหล่านี้ประสบความสำเร็จเพราะช่วยให้ทีมสามารถสร้างโซลูชันได้โดยไม่ต้องเกี่ยวข้องกับแผนก IT ส่วนกลาง ให้ความสามารถในการจัดการปฏิบัติการที่ดีกว่า และมักจะสามารถซื้อได้ด้วยง예산ค่าใช้จ่ายแทนที่จะต้องจัดสรรกำลังคน

คุณค่าของแพลตฟอร์ม 'Low-Code No-Code' เหล่านี้ไม่เกี่ยวข้องกับประสบการณ์ 'ผู้ใช้/นักพัฒนา' ที่ดีกว่า/ง่ายกว่า/ทรงพลังกว่าเลย แต่เกี่ยวข้องกับความสามารถในการจัดการ การสืบทอด การมองเห็น การจัดการ และความปลอดภัยที่แพลตฟอร์มเหล่านี้ให้

นักพัฒนาหลายคนแบ่งปันประสบการณ์ที่ผู้มีส่วนได้ส่วนเสียทางธุรกิจเลือกโซลูชัน low-code เนื่องจากความใจร้อนกับไทม์ไลน์การพัฒนาแบบดั้งเดิมหรือความหงุดหงิดกับข้อจำกัดของทรัพยากร สิ่งนี้สร้างสถานการณ์ที่ธุรกิจข้ามทีมวิศวกรรมไปเลย บางครั้งนำไปสู่สถานการณ์ vendor lock-in ที่มีราคาแพง

ข้อได้เปรียบหลักของเครื่องมือ Visual Workflow:

• ช่วยให้ผู้ใช้ที่ไม่มีความรู้ด้านเทคนิคสามารถสร้างระบบอัตโนมัติได้
• มีความสามารถในการจัดการและติดตามการดำเนินงาน
• สามารถจัดซื้อด้วยงบประมาณค่าใช้จ่ายแทนที่จะต้องจ้างพนักงานเพิ่ม
• มีการพัฒนาต้นแบบและการพิสูจน์แนวคิดอย่างรวดเร็ว
• รวมการเชื่อมต่อกับบริการยอดนิยมต่างๆ ไว้ในตัว

เส้นทางข้างหน้า: การผสานรวมที่ดีกว่า ไม่ใช่การขจัด

แทนที่จะปฏิเสธเครื่องมือภาพทั้งหมด การอภิปรายของชุมชนชี้ไปที่โซลูชันที่สร้างสรรค์มากกว่า บางคนแนะนำให้สร้างเส้นทางที่ดีกว่าสำหรับสเปรดชีต Excel และ visual workflow ให้พัฒนาไปเป็นแอปพลิเคชันที่เหมาะสมเมื่อมันเติบโตเกินขอบเขตเดิม คนอื่น ๆ เน้นความต้องการความสามารถในการดีบักที่ดีขึ้นและการควบคุมเวอร์ชันสำหรับเครื่องมือภาพ

การสนทนายังเน้นตัวอย่างที่ประสบความสำเร็จที่เครื่องมือภาพทำหน้าที่เป็นก้าวย่างแทนที่จะเป็นโซลูชันถาวร นักพัฒนาสังเกตว่าเครื่องมือเหล่านี้เก่งในการสร้างต้นแบบอย่างรวดเร็วและงาน proof-of-concept ช่วยให้ทีมสามารถตรวจสอบไอเดียได้อย่างรวดเร็วก่อนลงทุนในการดำเนินการที่แข็งแกร่งกว่า

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

อ้างอิง: Every Visual Workflow Tool is Just Excel for Developers Who Gave Up