Programmer ทุกคนคงรู้กันอยู่แล้วว่า ยิ่ง Code มีปริมาณมากเท่าไร ก็มีแนวโน้มทำให้ Code มีปัญหามากขึ้น ยังไม่รวม Code ที่มีแนวโน้มจะล้าสมัยเมื่อเวลาผ่านไป มันจึงเป็นเรื่องสำคัญที่ควรต้องรู้ว่าเมื่อใดที่ไม่ต้องเขียน Code เนื่องจาก Code ที่น้อยลงจะช่วยให้คุณประหยัดเวลาและลดความยุ่งยากที่อาจเกิดขึ้น ดังนั้น ทำไมเราควรใช้แนวคิด “น้อยแต่มาก” ในการเขียน Code
ทำไมต้อง “น้อยแต่มาก”
การที่รู้ว่าเมื่อใดไม่ควร Code ถือเป็นทักษะที่มีค่าอย่างมากในฐานะของ Developer มันทำให้ Codebase ของคุณมีขนาดเล็กซึ่งมีข้อดีหลายประการมากกว่าการมี Codebase ขนาดใหญ่
อย่าลืมว่า Code ทั้งหมดที่คุณเขียนจะถูกอ่านและทำความเข้าใจโดย Programmer คนอื่น ๆ นั่นหมายความว่า คุณไม่จำเป็นต้องเขียน Code ที่ดูฉลาดหรือเลิศหรูที่สุด ขณะดียวกันคุณก็ไม่ควรเสียความสามารถในเรื่องการอ่าน Code เพื่อให้ Code มีปริมาณน้อยลง มันไม่แปลกอะไรที่จะเพิ่มเนื้อที่ไม่กี่ Bytes หรือเพิ่ม CPU Time ไม่กี่มิลลิวินาทีเพื่อที่คุณจะได้ไม่กลับมาเสียใจกับ Code ที่คุณเคยเขียนไว้ เพราะถ้าคุณตัด Code ออกมากเกินไป บางทีอาจทำให้ Code อ่านยากได้เช่นกัน
โดยทั่วไปแล้ว Code ควรมีความยาวเท่าที่มันจำเป็น ไม่มากไม่น้อยจนเกินไป
บางครั้ง Code ที่สั้นกว่า ก็ไม่จำเป็นต้องดีกว่า Code ที่ยาวกว่าเสมอไป แต่มันก็มีแนวโน้มที่จะทำให้เกิด Error ที่น้อยลงด้วยเช่นกัน ในอีกด้านหนึ่ง หากคุณจำเป็นต้องเขียน Code หลายร้อยบรรทัดเพื่อให้ใช้งาน Features ต่าง ๆ ได้ง่ายขึ้น คุณอาจจะกำลัง Overengineer อยู่ การ Overengineer นำไปสู่ Code ที่ซับซ้อนและ Errors กรณีที่เราได้เพิ่มสิ่งที่ซับซ้อนมากเกินจริงเพื่อรองรับ Features ที่อาจไม่เคยถูกนำมาใช้จริง สามารถแก้ไขได้โดยการเขียน Code ที่สั้นลงได้
การมี Code ที่ยาว ๆ นั้นจำเป็นต้องมีการ Test และ Debug ที่มากขึ้นตามไปด้วย รวมทั้งมีโอกาสเกิด Errors บางอย่างเช่นกัน นอกจากนี้คุณจำเป็นต้องใชความพยายามที่มากขึ้นเพื่อ Test พวกมัน
Code ทุกบรรทัดที่ถูกเพิ่มเข้ามาใน Codebase โดยไม่จำเป็นนั้น มีโอกาสที่จะทำให้เกิด Bugs ใหม่ ๆ ได้ในอนาคต และเหนือสิ่งอื่นใด Features ใหม่ ๆ ก็อาจทำให้เกิดปัญหาใน Code เดิมได้
Ken Thompson ได้เคยกล่าวไว้ ซึ่งมันสรุปได้ค่อนข้างดี:
“วันที่มี Productivity ที่สุดของผม ก็คือ การโยน Code 1,000 บรรทัดทิ้งไป”
เมื่อใด ที่ไม่จำเป็นต้องเขียน Code
อย่างที่เราทราบกันดีว่า Projects ทั้งหมดเริ่มต้นด้วย File เพียงไม่กี่ File และหลังจากที่ทำงานใน Projects ไประยะหนึ่งแล้ว Codebase ก็จะถูกเพิ่มเข้าไปเรื่อย ๆ ในที่สุด Project ก็จะมีขนาดใหญ่, Maintain ยาก นี่เรายังไม่ได้พูดถึงการเพิ่ม Features ใหม่ หรือแม้แต่การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ก็ใช้เวลาหลายชั่วโมง การแก้ไข Bugs ดูเหมือนจะเป็นเรื่องที่ต้องทำอย่างไม่รู้จบ การแก้ไข Bug หนึ่งเรื่อง มักทำให้เกิด Bug ใหม่ขึ้นมาอย่างน้อยหนึ่งเรื่อง
Project ของคุณจะกลายเป็น Project ที่ยุ่งเหยิงอย่างมากโดยที่ไม่มีใครอยากจะไปยุ่งกับมัน นั่นเป็นเพราะคุณไม่รู้ว่า เมื่อใดที่เราไม่จำเป็นต้องเขียน Code ดังนั้น คำถามที่สำคัญก็คือ เมื่อใดที่คุณควรเลือกที่จะไม่ต้องเขียน Code
บทความนี้ไม่ได้พยายามที่จะบอกคุณว่า Code สั้น ๆ นั้นดีกว่าเสมอไป Code ที่สั้น ๆ อาจไม่ใช่หนทางสู่ความสำเร็จเสมอไป เพียงแค่อยากให้คุณคิดอย่างถี่ถ้วนเกี่ยวกับ Code ที่คุณจะเขียน ว่า Code นั้นมันจำเป็นต้องมีจริง ๆ ไหม
เพื่อที่จะตอบคำถามนี้ คุณต้องเข้าใจจุดประสงค์หลักของ Software ของคุณและสาเหตุที่มันถูกสร้างขึ้นตั้งแต่แรกเสียก่อน ซึ่งมันเป็น Step แรกของการรู้ว่า เมื่อใดที่ไม่จำเป็นต้องเขียน Code
และเพื่อป้องกันปัญหาที่อาจเกิดขึ้น สิ่งสำคัญคือ คุณต้องไม่เขียน Code เกินกว่าที่คุณตั้งใจไว้ อย่าสร้างสิ่งที่คุณแค่คิดว่า อาจจะใช้มันสักวันหนึ่งในอนาคต คุณควรให้ความสำคัญกับความเรียบง่าย มากกว่าการมี Features เยอะแยะมากมาย พยายามทำในสิ่งที่คุณต้องการเท่านั้น ไม่ใช่ทำเพราะคุณคาดหวังว่าคุณอาจจะต้องการมัน สิ่งนี้เรียกว่า “You aren’t gonna need it” หรือ YAGNI Principle
การทำตามรูปแบบนี้ จะช่วยคุณประหยัดเวลา เพราะคุณจะหลีกเลี่ยงการเขียน Code ที่ไม่จำเป็น ยิ่งกว่านั้นคุณภาพของ Code ของคุณจะดีขึ้นเนื่องจากเป็นการลดโอกาสการสร้าง Bug ต่าง ๆ โดยไม่ได้ตั้งใจ
ISM Technology Recruitment Ltd. (#1 Tech Recruiter in Thailand) เราเชี่ยวชาญในธุรกิจ IT Recruitment & IT Outsourcing โดยเฉพาะ เปิดทำการกว่า 30 ปี มีพนักงานทุกสายและทุกระดับทางด้าน IT ที่ได้ร่วมงานกับลูกค้าองค์กรใหญ่ที่มีชื่อเสียงและบริษัทข้ามชาติมากมาย หากคุณเป็นคน IT ที่อยากทำงานท้าทายและร่วมงานกับองค์กรชั้นนำ สามารถฝากประวัติการทำงาน (Resume) ของคุณไว้กับ ISM ได้ที่ https://www.ismtech.net/submit-your-resume แล้วคุณจะพบว่าอนาคตและโอกาสก้าวหน้ากำลังรอคุณอยู่
Source: https://medium.com/