การสร้างโค้ดด้วย AI ก่อให้เกิดหนี้ทางเทคนิคมากขึ้น ขณะที่นักพัฒนาถกเถียงทฤษฎีความซับซ้อนของซอฟต์แวร์

ทีมชุมชน BigGo
การสร้างโค้ดด้วย AI ก่อให้เกิดหนี้ทางเทคนิคมากขึ้น ขณะที่นักพัฒนาถกเถียงทฤษฎีความซับซ้อนของซอฟต์แวร์

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

เครื่องมือ AI ขยายผลการปฏิบัติการเขียนโค้ดที่ไม่ดี

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

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

ปัจจัยหลักที่ส่งผลต่อความซับซ้อนของซอฟต์แวร์

ปัญหาที่เกี่ยวข้องกับการพึ่งพา:

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

ปัญหาที่เกี่ยวข้องกับความไม่ชัดเจน:

  • การตั้งชื่อที่คลุมเครือ
  • รูปแบบโค้ดที่ไม่สอดคล้องกัน
  • เอกสารประกอบที่ไม่เพียงพอ
  • การใช้ listeners หรือ polymorphism แบบอ้อมเกินไป

การถกเถียงเรื่องคำจำกัดความของความซับซ้อนทวีความรุนแรงขึ้น

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

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

อาการของความซับซ้อนของซอฟต์แวร์

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

ความท้าทายขององค์กรเอาชนะโซลูชันทางเทคนิค

แม้ว่านักพัฒนาจะเข้าใจหลักการออกแบบที่ดี แต่การนำไปปฏิบัติจริงยังคงเป็นเรื่องยาก ความท้าทายที่แท้จริงอยู่ที่การทำให้การคิดเชิงกลยุทธ์อยู่รอดจากแรงกดดันประจำวันของคำขอฟีเจอร์ การแก้ไขบั๊ก และกำหนดเวลาที่เข้มงวด

คำถามที่ยากจริงๆ น่าจะเป็นการทำให้แม้แต่ 10% ของภูมิปัญญาและความตั้งใจดีดังกล่าวอยู่รอดได้เมื่อโปรแกรมถูกโจมตีด้วยแพตช์จากผู้มีส่วนร่วม หรือคนที่รับตั๋ว Jira

นักพัฒนาที่มีประสบการณ์หลายคนรายงานว่าผู้จัดการโครงการมักจะไม่สนใจความพยายามในการปรับปรุงคุณภาพโค้ด โดยมองว่าเป็นภาระที่ไม่จำเป็น สิ่งนี้สร้างวงจรที่การแก้ไขเชิงยุทธวิธีระยะสั้นสะสมเป็นฝันร้ายในการบำรุงรักษาระยะยาว

เส้นทางข้างหน้า

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

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

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

อ้างอิง: Designing Software in the Large