Clean Code
เคยทำความสะอาดโค้ดกันบ้างหรือเปล่า ?
Last updated
Was this helpful?
เคยทำความสะอาดโค้ดกันบ้างหรือเปล่า ?
Last updated
Was this helpful?
เคยอ่านโค้ดแล้วกร่นด่าในใจกันไหม "นี่มันโค้ดบ้าอะไร?", "ทำไมเขียนแบบนี้ฟร๊า?", "จะเริ่มจากตรงไหนดี?" บลาๆ ซึ่งถ้าเกิดเหตุการณ์แบบนี้ขึ้นนั่นแสดงว่า เราจะทำงานได้ช้าลง เพราะต้องเสียเวลานั่งทำความเข้าใจเจ้าโค้ดพวกนั้น และเลวร้ายที่สุดคือการที่พบว่า ลบโค้ดพวกนั้นทิ้งแล้วเขียนใหม่ดีกว่า นั่นแสดงว่าทีมต้องเสียเวลาไปทำงานเดิมซ้ำสอง
โค้ด !@#$%^&* พวกนั้นเราเรียกมันว่า Bad Code ซึ่งเราควรจะเปลี่ยนมาเขียน Good Code กัน
ถ้าในโปรเจคมี Bad Code อยู่เยอะๆ คนอื่นๆในทีมก็จะเห็น Bad Code เหล่านั้น เมื่อเห็นเรื่อยๆเห็นบ่อยๆ มันก็มีโอกาสสูงที่ทีมจะคิดว่านั่นคือเรื่องธรรมดา เลยทำให้ทีมบ่มนิสัยผลิตแต่โค้ดที่กากๆออกมา ทำให้โปรเจคนี้และโปรเจคต่อๆไปเราก็จะเจอแต่โค้ดที่ทำให้ทีมทำงานได้ช้าลงตลอดไป
สมมุติว่าเราต้องเพิ่มความสามารถใหม่ให้โค้ดหรือต้องไปแก้ bug กับงานที่มี Bad Code เยอะๆ จะได้อารมณ์ประมาณภาพด้านล่างนี้
เส้นสีเขียว - คือเราต้องเดินไปไหนบ้างถึงจะไปเจอจุดที่ต้องไปเขียนโค้ดจริงๆ โซนสีส้ม - คือจุดที่ต้องเข้าไปเขียนโค้ด
จะเห็นว่า Bad Code ต้องเสียเวลาไปหาก่อนว่าจุดที่เราจะทำงานอยู่ตรงไหน และต้องเสียเวลาทำความเข้าใจก่อนว่ามันต้องแก้ตรงไหนบ้าง ซึ่งถ้ามั่วมากๆก็อาจจะทำให้ไปแก้ผิดจุดได้
คราวนี้มาดูงานที่มีแต่ Good Code ที่ทุกอย่างเป็นระเบียบเรียบร้อยกันบ้าง
จะเห็นว่า Good Code ทำให้เราเข้าถึงจุดของงานได้เร็ว และ ลดโอกาสเกิดข้อผิดพลาดลง
การดูว่าโค้ดเราดีหรือเปล่าให้ดูจาก คำด่าต่อนาที ตอนทำ Code Review
Code Review คือชั่วโมงที่เราเอาโค้ดทั้งของเราและของคนอื่นๆมากางออก แล้วไล่ดูว่ามีโค้ดจุดไหนที่ต้องปรับแก้ ตรงไหนควรสร้าง code standard บลาๆ ซึ่งวัตถุประสงค์ของมันคือช่วยให้ทีมได้เรียนรู้และไม่ทำโค้ดกากๆออกมา
ก็อย่าเขียน Bad Code แต่แรกดิ !! (ไม่บอกก็รู้เฟร้ย 🤣)
การเขียน Good Code นั้นเป็นเรื่องของความเอาใจใส่ในคุณภาพของโค้ด ซึ่งการเขียนโค้ดมันก็เหมือนกับคุณเขียนหนังสือซักเล่มนั่นแหละ ถ้าคุณเขียนแล้วคนอื่นเอาไปอ่านแล้วไม่เข้าใจ มันก็หมายถึงคุณเขียนได้ไม่ดี #โค้ดก็เช่นกัน
งั้นเดี๋ยวเราไปดูมาตรฐานสากลของ Good Code แล้วเทียบกับ Bad Code กันเรย
อย่าเขียนเงื่อนไขที่ให้คนอ่านต้องแปลความหมาย เพราะมันจะเสียเวลาทำความเข้าใจ และอาจะเข้าใจผิดได้
ลองดูโค้ดด้านล่างแล้วทำความเข้าใจดูครับว่ามันจะสื่อว่าอะไร ? แล้วลองเปรียบเทียบ Bad Code กับ Good Code ดู
Bad Code
Good Code
ใจความของตัวอย่างคือ เราเข้าใจเงื่อนไขได้เร็วขนาดไหน * Bad Code เราต้องไล่ดูทีละเงื่อนไขทีละตัวใน if เพื่อจะได้รู้ว่ามันกำลังตรวจเรื่องอะไร * Good Code เราไม่ต้องไล่ดูเงื่อนไขเลย เพราะอ่านใน if ปุ๊ปเราก็เข้าใจได้ทันที
อย่าเขียนคอมเมนต์!! ถ้าเขียนคอมเมนต์แสดงว่าโค้ดคุณไม่ได้เข้าใจง่ายพอ คุณเลยต้องเขียนคอมเมนต์ทิ้งไว้ให้ชนรุ่นหลังได้เข้าใจ วิธีแก้คือสร้าง method ที่ทำให้เข้าใจได้ง่ายแทน
อย่าคอมเมนต์โค้ดที่เผื่อจะได้ใช้ เพราะคนอื่นไม่รู้สาเหตุหรอกว่าคุณคอมมเมนต์มันไว้ทำไม และเขาจะไม่กล้าลบมันแล้วมันจะกลายเป็นขยะค้างไว้แบบนั้น ลบมันทิ้งซะ เพราะยังไงก็อยู่ใน commit อยู่แล้ว
Bad Code
Good Code
ลดการเสียเวลาในการอ่านโค้ด โดยการสร้าง method เพื่อให้คนอ่านเห็นเป็นภาษามนุษย์มากขึ้น ไม่ใช่ต้องไปไล่อ่านโค้ดเพื่อทำความเข้าใจว่าเจ้า 10 บรรทัดนี้คืออะไร
จากตัวอย่างจะสังเกตุได้ว่า ใน Good Code บรรทัด 3 มันแทนที่ 14-19 ใน Bad Code ได้หมดเลย (และอ่านเป็นภาษามนุษย์ด้วย) ใน Good Code บรรทัด 4 มันแทนที่ 25-33 ใน Bad Code ได้หมดเลย (และอ่านเป็นภาษามนุษย์ด้วย) ส่วน 8-12 และ 20-23 ใน Bad Code มันถูกย้ายไปจัดการใน updateAddress() เรียบร้อยแล้ว และ 35-39 ถ้าไม่ได้ใช้ก็ลบทิ้งซะอย่างเก็บมันไว้ คนอื่นจะไม่กล้ายุ่งกับโค้ดคุณ
เวลาจะตั้งชื่ออะไรก็แล้ว ต้องตั้งให้มันสื่อความหมาย อ่านแล้วเข้าใจว่ามันมีไว้เพื่ออะไร
ชื่อต้อง อ่านออกเสียงได้ ถ้ามันออกเสียงไม่ได้เวลาจะบอกคนอื่นว่ามันผิดที่ไหน คุณจะบอกเขาว่ายังไง?
หลีกเลี่ยงคำย่อ เพราะทุกคนย่อคำไม่เหมือนกัน เช่น Student คุณจะย่อว่าอะไร (std? โรคติดต่อทางเพศงั้นเหรอ?)
ชื่อควรตั้งชื่อตามพฤติกรรม เช่น ชื่อคลาสควรเป็นคำนาม, ชื่อ method ควรขึ้นด้วยคำกิริยา
อย่าตั้งชื่อยาว เพราะมันจะเสียเวลาทำความเข้าใจ
อย่าตั้งชื่อเป็นนิเสธ เพราะคนอ่านจะ งง (แค่คำว่านิเสธก็ งง แล้ว)
อย่างตั้งชื่อกำกวม เพราะมันจะสับสนว่าตัวไหนเป็นตัวไหนกันแน่
Bad Code
Good Code
เกร็ดความรู้ คลีนโค้ดบางสำนักไม่แนะนำให้ตั้งชื่อแบบใส่ตัวเลขแทนคำอ่านนะ เช่น Good Code บรรทัดที่ 3 อาจจะเขียนเต็มๆไปเลยก็ได้ saltForPassword
กฎในการตั้งชื่อทั่วไปทั้งหมดก็ใช้กับการตั้งชื่อ Methods & Functions ด้วยนะจ๊ะ
ขึ้นต้นด้วยคำกิริยา เพราะคนเรียกใช้อ่านแล้วรู้เลยว่าใช้ทำอะไร (คนไทยอาจะไม่มีผลเท่าไหร่แต่ฝรั่งนี่มีสูงเลย)
อย่ารับ arguments เยอะ เพราะคนเรียกใช้ method อาจ งง ใส่ผิด และเวลาเพิ่ม/ลดละก็อวกแตก
ตั้งชื่อให้สื่อว่างานของมันคืออะไร ไม่งั้นคนเรียกใช้ method จะมีคำถาม
Bad Code
Good Code
ควรจัดวาง Layout ให้ตรงกับมาตรฐานของภาษาที่ใช้ เพราะโค้ดของทั้งทีมจะได้เหมือนกัน และเวลาทำงานกับ Git ก็จะไม่เกิด conflict ด้วย
Bad Code
Good Code
เรื่อง Clean Code มันเป็นเรื่องความเอาใจใส่ในผลงานของตัวเอง ซึ่งผลลัพท์ที่ได้มันจะทำให้เราไม่เสียเวลาหลงทางในเขาวงกต และมันไม่ได้มีแค่เท่านี้หรอก อันนี้เป็นเพียงน้ำจิ้มส่วนนึงเท่านั้น และแต่ละภาษาก็มีหลักในการทำ clean code ในรูปแบบของเขาอยู่เช่นกัน เลยขอดึงเฉพาะตัวที่เป็นกลางๆมาให้ดูก่อน ไว้มีโอกาสจะเอามาเพิ่มให้อ่านนะจุ๊
ทำทันที เรื่องการ Clean Code ห้ามปล่อยทิ้งไว้ เพราะ คุณไม่กลับมาแก้หรอก!! ดังนั้นจงจำไว้ "ทำ-ทัน-ที"
เกร็ดความรู้ มาตรฐานทั้งหมดที่ว่านี้ ในแต่ละภาษามันจะมี Coding Standard ของเขาเองอยู่นะ ลองไปหาอ่านได้ เช่น มาตรฐานของฝั่ง .NET สามารถอ่านได้จากลิงค์นี้ครับ Microsoft document