จำเป็นต้องเขียนโค้ดให้คนอื่นอ่านรู้เรื่องด้วยเหรอ? A Guide to Readable Code
ในปัจจุบันทุกสิ่งรอบตัวเราล้วนเปลี่ยนแปลงไปอย่างรวดเร็ว ความต้องการของผู้ใช้งานก็เช่นกัน ในมุมมองของการพัฒนาโปรแกรมจึงจำเป็นต้องปรับปรุงและพัฒนาให้เข้ากับความต้องการของผู้ใช้อยู่เสมอ เป็นเหตุให้เหล่านักพัฒนาต้องวกกลับมาอัพเดตโค้ดให้เป็นเวอร์ชันใหม่เพื่อรองรับการเปลี่ยนแปลงที่เกิดขึ้น
ทุกครั้งที่จะต้องมีการอัพเดตโค้ด เราจะต้องทำความเข้าใจโค้ดในเวอร์ชันเดิมก่อนว่ามีการทำงานอย่างไร และเราจะสามารถปรับแก้ตรงไหนให้ดีขึ้นหรือนำส่วนไหนกลับมาใช้ประโยชน์ได้บ้าง (คงไม่มีใครอัพเดตโค้ดทีนึงเขียนทั้งโปรเจคใหม่หรอกเนอะ) ดังนั้นรูปแบบการเขียนโค้ดของเวอร์ชันก่อนหน้าย่อมส่งผลกับการที่เราจะมาพัฒนาต่อ คงไม่ดีแน่ถ้าเรากลับมาอ่านโค้ดที่ตัวเองเคยเขียนไว้แล้วไม่เข้าใจ หนักกว่านั้นคือถ้าเราต้องทำงานร่วมกับทีมแล้วเจอโค้ดที่อ่านไม่รู้เรื่องเลย หนำซ้ำดันเป็นโค้ดที่เรายังไม่เคยผ่านมาก่อน เชื่อว่าไม่มีใครอยากให้เกิดปัญหาแบบนี้ขึ้นแน่ๆ ครับ เพราะฉะนั้นเราควรต้องรีบแก้ไขปัญหาตั้งแต่ต้นเหตุ ซึ่งก็คือการเขียนโค้ดในครั้งแรกนั่นเอง
Will they understand what we have written here?
เมื่อใดก็ตามที่เราจะต้องเขียนโค้ด ให้คิดอยู่เสมอว่า “พวกเขาจะเข้าใจสิ่งที่เราเขียนไว้มั้ยนะ?” คิดซะว่าถ้าเราต้องไปทำงานที่เราไม่เคยแตะต่อจากใคร นอกจากจะต้องเรียนรู้ Business ว่าการทำงานของระบบนั้นๆ เป็นยังไง เรายังต้องเสียเวลามานั่งอ่านโค้ดที่แสนจะยุ่งยากอีกหรอ ซึ่งนั่นมีแต่จะทำให้โปรเจคของเราเดินหน้าต่อได้ช้า ทุกคนทำงานได้ช้า จนลูกค้าได้รับงานที่ช้ากว่าเดิม เพียงเพราะการเขียนโค้ดเท่านั้นเอง
Why should we produce readable code?
ถ้าเลือกได้เราทุกคนมักจะอยากทำอะไรง่ายๆ เสมอ ยกตัวอย่างเช่น การกำหนดตัวแปร (Variables) ทุกครั้งที่เริ่มเขียนโค้ด ทุกคนน่าจะมีคำถามในใจคล้ายๆ กันว่า “จะตั้งชื่อตัวแปรว่าอะไรดีน้า” สุดท้ายกลายเป็นว่า “อ่ะ เอาง่ายๆ ตัวแปร a ละกัน” แน่นอนว่าถ้าเป็นโปรแกรมเล็กๆ อย่างโปรแกรมหาผลบวกของเลขสองตัวคงไม่มีปัญหา แต่ชีวิตการการเขียนโค้ดของเราคงไม่ได้จะเขียนโปรแกรมหาผลรวมตลอดไปอยู่แล้ว เราต่างต้องมีการพัฒนาและได้รับโปรเจคที่ใหญ่ขึ้นแน่นอน สมมติวันหนึ่งเราได้ทำงานที่ NASA ต้องเขียนโปรแกรมที่เป็นส่วนหนึ่งในการปล่อยจรวดที่มีนักบินอวกาศอยู่ แล้วดันไปเจอโค้ดที่คนทำงานก่อนหน้าตั้งชื่อตัวแปรเป็น x ไว้ จะให้มานั่งไล่ตั้งแต่ต้นว่าทำงานยังไง ผ่านอะไรมาบ้างคงไม่ไหวแน่ๆ แถมการตั้งชื่อตัวแปรแบบนี้ก็เสี่ยงที่จะทำให้เราเรียกใช้งานผิดได้ทุกเมื่อ ซึ่งนั่นอาจแลกมากับชีวิตของมนุษย์คนนึงเลยทีเดียว (เรื่องนี้เป็นเพียงเรื่องสมมติ ในความจริงแล้ววิศวกรมืออาชีพที่ทำงานจริงคงไม่มีเรื่องอะไรแบบนี้หรอก) หรือไม่ต้องถึงขนาด NASA แค่เราเอาโค้ดของเพื่อนมาอ่านก็ปวดหัวจะแย่แล้ว ฮ่าๆ
เพราะฉะนั้นการเขียนโค้ดโดยคำนึงถึงผู้อ่านเป็นเรื่องที่สำคัญมาก และควรฝึกฝนให้เป็นนิสัย ยิ่งทำตั้งแต่เริ่มเขียนโปรแกรมครั้งแรกเลยยิ่งดี ทั้งนี้รูปแบบการเขียนขึ้นอยู่กับการทำงานว่าทีมของเราสะดวกแบบไหนด้วย โดยทั่วไปแล้วจะมีข้อที่ควรทำความเข้าใจเบื้องต้นอยู่บ้าง ผมจะพยายามลิสต์มาให้ทุกคนนำไปปรับใช้ได้ เพื่อเราทุกคนจะได้เขียนโค้ดที่เป็นมิตรกับผู้อ่านไปด้วยกัน
So, how do you make it more readable?
1. Planning and Having Organized Diagrams
การจะทำบางสิ่งให้ประสบความสำเร็จและเป็นไปในทิศทางเดียวกัน การมีแผนย่อมดีกว่าไม่มีอะไรเลย การเขียนโค้ดก็เช่นกันครับ เราควรคุยกับทีมและหาข้อตกลงต่างๆ ให้ดีก่อนเสมอ แน่นอนว่าแผนแรกมีโอกาสที่จะสำเร็จได้น้อย เราจึงต้องมีแผนรองรับ และคุยกันเสมอว่าจะปรับเปลี่ยนไปในทิศทางไหน ทั้งนี้ทุกแผนควรมีการสร้างเป็นแผนผัง (Diagrams) ที่ชัดเจนว่าทีมจะมีการจัดการและทำงานกันอย่างไร เพื่อให้ทุกคนเห็นภาพร่วมกันและลดเวลาในการที่จะต้องมานั่งอ่านโค้ดเพื่อดูขั้นตอนการทำงานด้วยตนเอง
2. Naming Convention
สิ่งที่จำเป็นสำหรับการสื่อสารคือสรรพนามที่ใช้เรียกแทนกัน ซึ่งหากสรรพนามนั้นๆ ไม่สื่อความหมายหรือต่างคนต่างเข้าใจกันไปคนละทิศทาง เราจะคุยกันไม่รู้เรื่องแน่นอน เพราะฉะนั้นการทำงานเราควรมีการตั้งชื่อหรือเรียกสิ่งต่างๆ ที่ตรงไปตรงมาและเข้าใจง่าย ตั้งแต่การตั้งชื่อไฟล์ จนไปถึงการกำหนดชื่อตัวแปรต่างๆ ในงานพัฒนาโปรแกรม ซึ่งการตั้งชื่อที่ดีจะช่วยลดเวลาการทำความเข้าใจของผู้อ่าน และยังทำให้ผู้อ่านเข้าใจภาพรวมของระบบได้เร็วมากขึ้นด้วย
สิ่งนึงที่หลายคนมักคิดว่าไม่ดี คือการกำหนดชื่อที่ยาวจนแทบจะเป็นประโยค แต่ในการทำงานจริงนั้น หากชื่อของคุณจะยาวขึ้นมาอีกหน่อยแต่สามารถสื่อความหมายได้ดีกว่าก็ย่อมมีประโยชน์มากกว่าการที่คุณเหลือพื้นที่ว่างในโค้ดของคุณไว้อย่างไม่มีประโยชน์ เช่น เมื่อคุณต้องกำหนดชื่อตัวแปรสำหรับเก็บราคาสินค้านำเข้าเมื่อรวมกับภาษี คุณจะเลือกอะไรระหว่าง ‘price’ กับ ‘import_price_include_tax’ หรือเป็นการตั้งชื่อแบบที่มีลำดับสื่อความหมายโดยผ่านการตกลงกับทีมแล้ว เช่น month_day_year_hour_minute_temperature
3. Nobody is Unaware of Your Numbers or Texts
ไม่มีใครรู้หรอกถ้าคุณไม่บอกพวกเขาว่าเลขที่คุณเขียนขึ้นมาหรือข้อความนั้นคืออะไร ต่อให้คนที่อ่านโค้ดเก่งแค่ไหนมาอ่านก็ไม่มีทางเข้าใจ เช่น ในกรณีที่คุณเขียนโปรแกรมหาความยาวเส้นรอบวงของวงกลม (2πr) โดยให้ผู้ใช้กรอกค่ารัศมี (r) ในหน่วยเซนติเมตร
# Program A
# Getting the value of radius from user
radius = float(input("Enter radius value (Centimeter): ")) # Calculate
circumference_length = 2 * (22/7) * radius # Displaying the result
print("The length of circumference is: ", circumference_length)# Program B
# Set constant value
PI = 22/7 # Getting the value of radius from user
radius = float(input("Enter radius value (Centimeter): ")) # Calculate
circumference_length = 2 * PI * radius # Displaying the result
print("The length of circumference is: ", circumference_length)
จะเห็นว่าโปรแกรม B นั้นสามารถสร้างความเข้าใจให้กับผู้อ่านได้มากกว่าโปรแกรม A เนื่องจากสามารถทำให้ผู้อ่านเข้าใจได้ว่าค่า ‘22/7’ คือค่าอะไร ในที่นี้ทุกคนอาจจะพอเดาได้แม้จะไม่ระบุว่า ‘22/7’ คือค่าอะไร แต่ลองนึกภาพระบบที่คุณไม่รู้ว่าค่าต่างๆ คืออะไร คุณอาจจะมีอาการไมเกรนกำเริบขึ้นมาได้ ไม่เพียงแค่ค่าตัวเลขเท่านั้น แต่กลุ่มข้อความก็ควรบ่งบอกถึงวัตถุประสงค์ว่าจะนำไปใช้ทำอะไร เพื่อให้ง่ายต่อผู้อ่านมากยิ่งขึ้น
4. Comment
อันนี้เป็นเรื่องที่ง่ายมากแต่หลายคนมักมองข้าม การใส่คอมเมนต์จะช่วยให้เราอธิบายส่วนการทำงานต่างๆ ได้ดียิ่งขึ้น เราควรเขียนเพื่อสื่อสารให้ผู้อ่านสามารถเข้าใจโปรแกรมของเราได้อย่างรวดเร็ว โดยเฉพาะอย่างยิ่งในส่วนของการทำงานที่มีความซับซ้อน ดังนั้นการใส่คอมเมนต์ไว้จะช่วยให้การทำงานของทีมง่ายขึ้นเสมอ
5. Number of Lines isn’t Equal to the Quality
เราอาจสันนิษฐานเบื้องต้นได้ว่าโค้ดที่มีจำนวนบรรทัดเยอะเกินไปอาจใช้ Algorithm ที่ไม่มีประสิทธิภาพรึเปล่า แต่ในความเป็นจริงแล้วไม่ใช่เลย จำนวนของบรรทัดนั้นไม่ได้บ่งบอกถึงประสิทธิภาพของการเขียนโค้ดแม้แต่น้อย เราไม่ควรกังวลว่า ‘โปรแกรมของเรามีจำนวนบรรทัดเยอะเกินไปหรือเปล่า?’ หรือ ‘จะลบตรงไหนออกให้สั้นลงได้บ้างนะ?’ ถ้าสามารถทำให้สั้นลงและยังสื่อความหมายให้ผู้อ่านเข้าใจง่ายได้เหมือนเดิมก็ทำเลย แต่ถ้าการจะลดจำนวนบรรทัดเพื่อความสวยงามแต่ทำให้โค้ดของเราเข้าใจได้ยากยิ่งขึ้นนั้นไม่ควรทำอย่างยิ่ง ดังนั้นเราไม่จำเป็นต้องวิตกกับจำนวนบรรทัด แต่ควรคำนึงว่าผู้อ่านจะเช้าใจสิ่งที่เราเขียนหรือไม่มากกว่า
6. Try to Reuse
การลดภาระของผู้อ่านในการทำความเข้าใจโค้ดนั้น คือการที่ผู้อ่านเข้าใจสิ่งนั้นๆ อยู่แล้ว เมื่อมาอ่านซ้ำก็แทบจะไม่ต้องใช้เวลาในการทำความเข้าใจเลย ดังนั้นการพยายามเขียน Functions หรือ Methods ที่มีความยืดหยุ่น (Flexible) สามารถนำไปเรียกใช้ซ้ำได้อยู่เสมอ ก็จะช่วยให้ผู้อ่านไม่ต้องเสียเวลากับการทำความเข้าใจใหม่อยู่เรื่อยๆ เพียงแค่ผู้อ่านเห็นว่านี่คือการเรียกใช้ส่วนการทำงานในรูปแบบเดิมก็เพียงพอต่อการอ่านโค้ดให้เข้าใจง่ายขึ้นแล้ว
7. Always Refactor
แน่นอนว่าการเขียนโค้ดในครั้งแรกของเราอาจไม่ได้ดีที่สุดเสมอไป เราอาจจะยังไม่คุ้นชินกับระบบหรืออาจจะยังไม่เข้าใจมากนัก ทำให้อาจมีบางจุดที่เราอาจเขียนไปแบบซับซ้อน ทั้งๆ ที่อาจจะมี Algorithm ที่ง่ายกว่าที่เรามาคิดได้ในภายหลัง เมื่อเราคุ้นชินกับระบบ ได้พัฒนาหลายๆ ส่วนมากขึ้นแล้ว เราควรที่จะกลับมาอ่านโค้ดเดิมของเราซ้ำ ทำความเข้าใจ และปรับปรุงโครงสร้างใหม่ให้ดีขึ้น (Refactoring) ถ้าเป็นไปได้ โค้ดของเราจะได้ไม่ซับซ้อนจนเกินไป และผู้อ่านก็จะทำความเข้าใจได้รวดเร็วตามไปด้วยนั่นเอง
ทั้งหมดนี่ก็เป็นเหตุผลว่าทำไมเราถึงต้องแคร์ว่า ‘จำเป็นต้องเขียนโค้ดให้คนอื่นอ่านรู้เรื่องด้วยหรอ?’ พร้อมกับแนวทางส่วนหนึ่งที่จะช่วยให้โค้ดของเราสามารถอ่านได้ง่ายและเป็นมิตรกับผู้อ่านมากยิ่งขึ้น
ถ้าคุณไม่อยากอ่านโค้ดที่จะทำให้คุณปวดหัว ก็อย่าลืมส่ง Medium นี้ให้เพื่อนของคุณอ่านด้วยนะครับ ฮ่าๆ ทั้งนี้ ถ้าที่เขียนมาข้างต้นมีข้อผิดพลาดแต่ประการใดต้องกราบขออภัยไว้ด้วยนะครับ หรือจะสามารถคอมเมนต์แลกเปลี่ยนความคิดกันได้เลย กดปรบมือเป็นกำลังใจ และถ้าอยากติดตามเรื่องราวอื่นๆ ก็อย่าลืมกด Follow นะครับ สำหรับวันนี้ขอบคุณทุกคนที่อ่านมาถึงตรงนี้ หวังว่าเราทุกคนจะได้เจอโค้ดที่อ่านง่ายๆ แล้วพบกันใหม่ครับ 😆
สำหรับชาวเทคคนไหนที่สนใจเรื่องราวดีๆแบบนี้ หรืออยากเรียนรู้เกี่ยวกับ Product ใหม่ๆ ของ KBTG สามารถติดตามรายละเอียดกันได้ที่เว็บไซต์ www.kbtg.tech
