รหัสสปาเก็ตตี้คืออะไรและจะหลีกเลี่ยงได้อย่างไร

แม้ว่าการทำอาหารเย็นแบบอิตาลีจะอร่อย แต่สิ่งสุดท้ายที่คุณอยากทราบเกี่ยวกับ codebase ของคุณก็คือ สปาเก็ตตี้ แนวคิดที่ว่าโค้ดของคุณพันกันราวกับปาเก็ตตี้จานหนึ่งเป็นสิ่งที่น่ากลัว แต่สำหรับนักพัฒนาหลายๆ คน แนวคิดนี้เป็นนามธรรมมากจนไม่สามารถรับมือได้ (หรือเข้าใจวิธีหลีกเลี่ยงหรือแก้ไข) นั่นเป็นสาเหตุว่าทำไมในโพสต์นี้ เราจึงอยากเจาะลึกว่าจริงๆ แล้วรหัสสปาเก็ตตี้คืออะไร แสดงแนวทางปฏิบัติที่ดีที่สุดเพื่อหลีกเลี่ยง และ (เมื่อมันเกิดขึ้น) วิธีจัดการกับมัน

สมัครสมาชิกช่อง Youtube ของเรา

รหัสสปาเก็ตตี้คืออะไร?

รหัสสปาเก็ตตี้เป็นฝันร้าย นั่นคือสิ่งที่ อย่างที่เรากล่าวไว้ข้างต้น ศัพท์สแลงได้ชื่อมาเพราะ เหมือนกับเส้นสปาเก็ตตี้พันกันเส้นใหญ่ หากคุณดึงเส้นหนึ่ง (โค้ด) ก็จะเข้าไปพันกันอีกเส้นหนึ่งและอีกเส้นหนึ่ง จนกระทั่งมันหรือทั้งหมด ชิ้นส่วนที่พันกันแตก

ตัวอย่างเช่น ลองนึกถึงคุณสมบัติ !important ใน CSS มีประสิทธิภาพอย่างเหลือเชื่อ ทำให้นักออกแบบสามารถแทนที่สไตล์ที่สืบทอดมา และสามารถควบคุมองค์ประกอบเฉพาะใดๆ โดยไม่ต้องเขียนโค้ดใหม่ทั้งสไตล์ชีต อย่างไรก็ตาม เมื่อพวกเขา (หรือนักพัฒนาและนักออกแบบในอนาคต) จำเป็นต้องปรับเปลี่ยนอย่างอื่น พวกเขาอาจเพิ่มแท็ก !important อื่นเพื่อแทนที่แท็กก่อนหน้า และอื่นๆ. แต่ถ้าคุณต้องย้อนกลับและลบหรือแก้ไขสิ่งใด ๆ ในสแต็กนั้น สไตล์ใด ๆ บนหน้าอาจแตกสลาย

ซึ่งเป็นสิ่งที่เราพยายามหลีกเลี่ยง

แนวทางปฏิบัติที่ดีที่สุดเพื่อหลีกเลี่ยงรหัสสปาเก็ตตี้

1. พัฒนามาตรฐานการเข้ารหัส

วิธีหนึ่งในการป้องกันรหัสสปาเก็ตตี้อันดับหนึ่งคือการสร้างและเข้ารหัสมาตรฐานภายในองค์กรหรือโครงการของคุณ มาตรฐานการเข้ารหัสคือสิ่งที่ทำให้โครงการอย่าง WordPress เป็นไปได้ นักพัฒนาหลายพันคนทำงานบน WP Core แต่ WordPress Coding Standards ได้ทำให้มันทำงานภายใต้แนวทางเดียวกันและทำงานภายใต้พารามิเตอร์เดียวกันในลักษณะเดียวกัน

มาตรฐานการเข้ารหัสเป็นเพียงกฎที่คุณบังคับใช้ พวกเขาทำให้โค้ดของทุกคนทำงานในรูปแบบเดียวกันเพื่อให้หาข้อผิดพลาดและแก้ไขได้ง่าย และนักพัฒนาในอนาคต (หรือแม้แต่คุณหรือทีมปัจจุบันของคุณ) สามารถรู้ได้อย่างชัดเจนว่าโค้ดแต่ละบรรทัดทำอะไรได้อย่างมีประสิทธิภาพมากที่สุด หากรหัสของ Susan ไม่ผ่านการทดสอบ ก็จะเข้าไปไม่ได้ หากรหัสของ Janine ไม่มีการทดสอบให้เรียกใช้ คำขอดึงจะถูกปฏิเสธ บางที Daniel ไม่ได้ใช้ divs กับคำขอดึงล่าสุดของเขา ไม่มีการรวมกันจนกว่าสิ่งต่าง ๆ จะถูกแบ่งออก

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

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

2. ปฏิบัติตามคำแนะนำสไตล์

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

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

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

3. แสดงความคิดเห็นรหัสของคุณ

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

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

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

ห่อ

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

จะทำอย่างไรเพื่อป้องกันรหัสสปาเก็ตตี้?

ภาพเด่นของบทความโดย Donnay Style / shutterstock.com