ผมยังสงสัยใน low-code

 (nick.scialli.me)
13 คะแนน โดย GN⁺ 2023-12-31 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ผู้เขียนมีจุดยืนค่อนข้างกังขาต่อ low-code
  • ระหว่างทำงานที่ปรึกษาด้านซอฟต์แวร์ มักพบลูกค้าที่ถูกดึงดูดด้วยโฆษณาซึ่งสัญญาว่า low-code จะช่วยให้พัฒนาได้รวดเร็วและมีค่าบำรุงรักษาต่ำ
  • มีเหตุผลหลายประการที่ทำให้ลูกค้าเหล่านั้นไม่ค่อยพอใจ

ข้อจำกัดด้านฟีเจอร์แบบปรับแต่งเฉพาะ

  • โซลูชัน low-code ตอบโจทย์ความต้องการขององค์กรได้ราว 80% แต่ที่เหลืออีก 20% ไม่สามารถแก้ได้ด้วยความสามารถพื้นฐาน
  • นักการตลาดของเครื่องมือ low-code มักอ้างว่าสามารถจัดการ 20% ที่เหลือได้อย่างง่ายดาย แต่ในความเป็นจริงกลับต้องปรับแต่งอย่างมาก และบางครั้งก็ทำไม่ได้เลย
  • องค์กรจึงต้องเลือกว่า ความสามารถพื้นฐานของเครื่องมือนั้นใกล้เคียงพอหรือไม่ หรือจะพยายามแฮ็กเครื่องมือให้ตรงกับ use case ของตัวเองแบบเป๊ะๆ

ข้อจำกัดของกลุ่มนักพัฒนา

  • บางครั้งองค์กรพยายามแฮ็กเครื่องมือ low-code เพื่อให้รองรับความต้องการได้ครบ 100%
  • ผลลัพธ์คือมีการเขียนโค้ดปรับแต่งจำนวนมากด้วยเครื่องมือเฉพาะหรือภาษาที่เป็นกรรมสิทธิ์ จนแทบไม่มีนักพัฒนาที่เข้าใจมัน
  • จากนั้นบริษัทก็ต้องตามหาผู้ดูแลระบบที่เชี่ยวชาญเครื่องมือนี้อย่างมาก แทนที่จะรับคนจากกลุ่มนักพัฒนาภาษาโอเพนซอร์สที่ใช้กันอย่างแพร่หลาย

ปัญหาของการอัปเกรดแพลตฟอร์ม

  • การอัปเกรดซอฟต์แวร์โดยไม่ให้สิ่งที่เชื่อมต่ออยู่พังนั้นเป็นเรื่องยาก
  • เครื่องมือ low-code ต้องรองรับโค้ดตามอำเภอใจสำหรับ use case ที่ตัวเครื่องมือเองไม่ได้ถูกออกแบบมาเพื่อรองรับ
  • ตามทฤษฎีแล้วควรทำได้ผ่านสัญญา API ที่เข้มงวด แต่ในทางปฏิบัติกลับเห็นโค้ดปรับแต่งทำเรื่องสารพัดอยู่ภายในบ่อยมาก

ความสับสนของโครงสร้างฐานข้อมูล

  • ผู้เขียนพบองค์กรที่ใช้เครื่องมือ low-code กับกระบวนการที่ต้องอาศัยการวิเคราะห์อย่างละเอียดเป็นอย่างยิ่ง
  • แต่เมื่อดู data model เบื้องหลังกลับอยู่ในสภาพที่ยากจะเข้าใจ: user_attribute_47 หมายถึงอะไร? ถ้าย้ายฟิลด์จากหน้า 1 ไปหน้า 2 ของแอป ข้อมูลกลับไปอยู่ในอีกฟิลด์หนึ่ง?

ความเห็นของ GN⁺

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

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

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

 
ats62 2024-01-02

จนถึงตอนนี้ผมคิดว่าแนวคิดของ no-code ถูกนำไปใช้แบบจำกัดอยู่ในบางสาขาเฉพาะเท่านั้น。

ถ้ามีบริการที่สร้างมาอย่างดีโดยใช้ LLM ปรากฏขึ้นมา ผมก็รู้สึกว่าก่อนอื่นเลยเทรนด์? กระแส? แนวโน้ม? เอาเป็นว่า ตัวแนวคิดของ no-code น่าจะต้องเปลี่ยนแปลงไป
 
quack337 2024-01-02

ผมค่อนข้างสงสัยในเรื่องโลว์โค้ด

เมื่อราว 10 ปีก่อน ผมรู้จักกรณีหนึ่งที่ใช้ MS Access ได้อย่างมีประโยชน์

ในระบบสารสนเทศขององค์กร มีฐานข้อมูลที่ออกแบบมาค่อนข้างดีและนำไปใช้บน MS Sql Server
และงาน OLTP ในชีวิตประจำวันก็ถูกทำไว้ค่อนข้างดีเช่นกัน

แต่ความไม่พอใจสะสมขึ้นจากการที่ฝ่ายไอทีตอบสนองต่อความต้องการในการค้นดูข้อมูลและพิมพ์รายงานที่ไม่ใช่งานประจำได้ช้าและไม่ค่อยกระตือรือร้น

พนักงานฝ่ายงานคนหนึ่งที่ใช้งาน MS Excel และ Access ได้คล่อง แสดงให้เห็นว่าเขาสามารถนำข้อมูล Excel ที่ดาวน์โหลดจากระบบสารสนเทศมา import เข้า Access แล้วสร้างฟังก์ชันค้นดูข้อมูลและพิมพ์รายงานตามต้องการได้ด้วย Access ภายในเวลาเพียงไม่กี่ชั่วโมงโดยไม่ต้องเขียนโค้ดเลย
 
quack337 2024-01-02

ฝ่ายงานขอให้สามารถเชื่อมต่อจาก Access เข้ากับ DB ได้โดยตรง และฝ่าย IT คัดค้านการเปิดเผย DB ของระบบสารสนเทศต่อเครือข่ายภายนอก แต่เนื่องจากความต้องการจากฝ่ายงานมีสูง จึงได้สร้าง DB แยกต่างหากที่มิเรอร์เฉพาะข้อมูลบางส่วนแล้วเปิดให้ใช้งาน

พนักงานที่ใช้ฟีเจอร์ข้อมูลของ Excel ได้คล่อง เริ่มนำ Access มาใช้กับงานได้หลังจากอบรมเพียงไม่กี่วัน
 
tequila 2024-01-02

ผมค่อนข้างเห็นด้วยกับบทความนี้นะ นี่เป็นความเห็นส่วนตัวของผม
กรณีที่ใช้ไวยากรณ์เฉพาะทาง -> ต้องมีช่วงเรียนรู้เพิ่มขึ้น และทำให้บำรุงรักษายาก
กรณีที่แค่เอา UI มาแทนโค้ดแบบตรง ๆ -> หลายครั้งเขียนโค้ดไปเลยกลับสะดวกกว่า
กรณีที่เป็นเครื่องมือ no-code แบบสมบูรณ์ -> มีข้อจำกัดเยอะ และชวนให้ผู้ใช้หาทางดัดแปลงเอง ทำให้ความถี่ของผู้ใช้ที่ทำงานนอกเจตนาที่ออกแบบไว้เพิ่มขึ้นมาก
ผลลัพธ์: กลายเป็นเครื่องมือที่ไม่มีใครพอใจได้
ช่องว่างระหว่างฝ่ายวางแผน-พัฒนา-ผู้ใช้นั้นกว้างกันเกินไป เลยเป็นเหมือนสาขาที่ทำออกมาให้ดีได้ยากกว่าที่คิดครับ
 
GN⁺ 2023-12-31
ความคิดเห็นบน Hacker News
  • มุมมองที่หลากหลายเกี่ยวกับ low-code

    • มุมมองของผู้พัฒนาแพลตฟอร์ม low-code

      low-code ขายได้ง่าย ใช้กลยุทธ์โยนปัญหาให้แผนก IT และอาศัยความไม่พอใจที่มีอยู่ เดโมจะแสดงงานง่าย ๆ ได้อย่างรวดเร็ว แต่ไม่ควรใส่ business logic หลักลงไปใน low-code โดยตั้งสมมติฐานว่างานที่ซับซ้อนจะถูก offload ไปยังระบบเฉพาะทาง เหมาะสำหรับทีมในองค์กรขนาดใหญ่ที่มีความรู้ด้านเทคนิคแต่มีอำนาจด้าน IT น้อย low-code แก้ปัญหาได้มากด้วยเครื่องมือที่เรียบง่าย แต่ขยายระบบได้ไม่ดีและต้องทำงานร่วมกับระบบศูนย์กลางที่แข็งแกร่ง

    • มุมมองของ SRE (Site Reliability Engineer)

      มีความสงสัยต่อ low-code เพราะการจัดการ source code ไม่ดี เอกสารไม่เพียงพอ ต้องใช้โค้ดปรับแต่งจำนวนมากแต่การนำกลับมาใช้ซ้ำต่ำ ต้องพึ่ง runtime แบบ proprietary และทำ monitoring ได้ยาก ในทางปฏิบัติไม่ค่อยเห็นกรณีที่วิศวกรเป็นคนทำและคนที่ไม่ใช่วิศวกรเป็นคนใช้ เครื่องมืออย่าง Looker ผสานกับ source code ได้ แต่สุดท้ายวิศวกรก็ยังเป็นผู้ใช้งานอยู่ แม้มันจะบีบอัดความซับซ้อน แต่ก็ยังชอบแพลตฟอร์มที่ปรับแต่งและขยายต่อได้ตามต้องการมากกว่า

    • มุมมองต่อแพลตฟอร์ม low-code ของ Microsoft

      สนใจแพลตฟอร์ม low-code ของ MS แต่ดูเหมือนถูกสร้างซ้อนอย่างซับซ้อนบน O365 และ Azure ส่วนติดต่อผู้ใช้ก็ไม่ดี และในระยะยาวความสูญเสียจากปัญหาด้านการใช้งานอาจมากกว่าการประหยัดต้นทุน

    • ประสบการณ์ทางธุรกิจในการย้ายโซลูชันฐานข้อมูล/ฟอร์ม MS-Access

      สร้างธุรกิจจากการแปลงโซลูชัน MS-Access ที่ผู้ใช้ปลายทางหรือคนที่ไม่ใช่นักพัฒนาสร้างขึ้นเองโดยไม่ผ่านแผนก IT ให้เป็นแอปพลิเคชัน client/server .net ที่แท้จริง โซลูชัน low-code มีประโยชน์ในการแก้บางปัญหาหรือทำให้ POC ใช้งานได้ แต่เมื่อจำเป็นต้องขยายขนาดหรือปรับตัว ก็อาจเกิดปัญหาได้

    • มุมมองของผู้พัฒนาเครื่องมือสร้างเว็บไซต์ SQLPage

      โซลูชัน low-code ควรมีทางออกให้โต้ตอบกับ API แบบ "high-code" ภายนอกได้ ใน SQLPage มีสิ่งนี้ผ่าน sqlpage.exec มีปัญหาที่การอัปเกรดแพลตฟอร์ม low-code อาจทำให้การปรับแต่งที่สร้างไว้พังได้ เครื่องมือ low-code ส่วนใหญ่มักจับข้อมูลไว้เป็นตัวประกัน แต่ SQLPage เป็นเพียงการเพิ่มเลเยอร์บนฐานข้อมูลที่ผู้ใช้ยังคงควบคุมได้อย่างเต็มที่

    • ความเห็นคัดค้านต่อเครื่องมือ low-code ระดับองค์กร

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

    • มุมมองต่อ low-code และชั้น abstraction

      "low-code" มีพื้นผิวของโค้ดที่ให้แตะต้องได้โดยตรงน้อย แต่ความจริงแล้วมีโค้ดจำนวนมากถูกซ่อนไว้ ชั้น abstraction ทรงพลังมากเมื่อเหมาะกับวัตถุประสงค์ แต่ถ้ามีการรั่วไหลหรือไม่เหมาะสมก็อาจก่อปัญหาได้ โดยทั่วไป low-code คือการ abstract โค้ดที่ออกแบบมาเพื่อการใช้งานเฉพาะด้าน แต่ในความเป็นจริงก็ยังต้องอาศัยประสบการณ์เฉพาะโดเมนอยู่ดี

    • ประสบการณ์สร้าง MVP ด้วย Bubble/Airtable

      เคยได้รับใบเสนอราคาจากทีมในยูเครนเพื่อสร้าง MVP แต่สุดท้ายจ้างเด็กฝึกงานให้ใช้ Bubble/Airtable ทำผลิตภัณฑ์ขึ้นมาในสองเดือน และได้ลูกค้าที่จ่ายเงินจริงภายใน 6 เดือน ตลอดเกือบสองปีก็ยังหาเหตุผลไม่เจอที่จะย้ายไปใช้สแตกแบบดั้งเดิม

    • เรื่องสยองจากการพัฒนาคอร์สเรียนด้วย low-code

      บริษัทสำคัญแห่งหนึ่งใช้แพ็กเกจซอฟต์แวร์สร้างคอร์สเรียนแบบ low-code เพื่อพัฒนาหลักสูตรภายในสำหรับทีมการตลาดและฝ่ายขาย หลายปีต่อมาต้องอัปเดตคอร์ส แต่กลับเกิดปัญหาเพราะไม่มีทั้งซอฟต์แวร์ที่ใช้พัฒนาเดิมหรือเครื่องมือที่จะทำงานนั้นได้

    • คำถามเรื่องความสามารถในการทำ version control กับ implementation แบบ low-code

      ตั้งคำถามว่าสามารถนำ implementation แบบ low-code เข้า version control ได้หรือไม่ เมื่อเกิดปัญหาจะตามหาสาเหตุได้หรือไม่ และจะ rollback ไปยัง commit ที่กำหนดด้วยเครื่องมือฟรีได้หรือไม่ ซึ่งส่วนใหญ่แล้วไม่มีความสามารถเหล่านี้ จึงไม่เหมาะกับการใช้งานจริงจัง