Screen Shot 2557-08-25 at 9.43.36 PM
ในโลกการพัฒนานั้น เราอาจจะได้ยินคำว่า code คุณมันดีหรือมันแย่นะ
บางครั้งอาจจะอธิบายว่า code ที่มันดีเป็นอย่างไร เช่น
Code ที่ดีควรจะ

  • ทำงานได้อย่างถูกต้อง ครบถ้วน
  • ง่าย และ สะอาด
  • อ่านง่าย ดูแลรักษาได้ง่าย
  • ทดสอบได้
  • ปลอดภัย
  • ขยายได้

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

ก่อนอื่นทำความเข้าใจก่อนว่า Maintenance programming คืออะไร

คือกิจกรรมสำหรับการระบุจุดที่มีปัญหาในระบบงาน
และทำการแก้ไขปัญหานั้นๆ ซะ

ดังนั้น ถ้าคุณคือ Maintence programmer แล้ว
คุณอย่าปล่อยปละละเลยสิ่งต่างๆ ที่คุณสร้างขึ้นมาโดยเด็ดขาด

ให้จำไว้ว่า

อะไรก็ตามที่มันเขียนขึ้นมายากๆ
มันก็ย่อมทำความเข้าใจยากเช่นเดียวกัน

แต่ส่วนใหญ่มักจะสร้าง code ที่มันดูแลรักษายากกันทั้งนั้น
ทำไมนะ …. ??

ดังนั้นมาดูวิธีการสร้าง Unmaintain code กันเลย ว่าทำได้อย่างไร

โดยสามารถแบ่งเป็นกลุ่มๆ ได้ดังนี้

1. Naming หรือ ชื่อที่มันแย่ๆ

ความสามารถแรกๆ ของการเขียน code ที่ดูแลรักษายากๆ ก็คือ การตั้งชื่อ
ทั้งตัวแปร method และ class ต่างๆ
โดยชื่อเหล่านี้ไม่ได้มีผลกระทบอะไรต่อตัว compiler ของภาษาเลย
แต่มันจะส่งผลต่อการดูแลรักษา code ต่อไป

โดยชื่อที่มันแย่ๆ มักมาจาก

  • ตั้งชื่อแบบง่าย หรือ แบบเด็กๆ เขาทำกัน หรือ ชื่อที่พิมพ์ง่ายๆ ใกล้มือนั่นเอง เช่น asdf เป็นต้น
  • ชื่อตัวแปร ยาว 1 ตัวอักษร เช่น a, b, c, d, i, j, k, x, y, z เป็นต้น คำถามจากการตั้งชื่อตัวแปรแบบนี้คือ ตัวแปรเหล่านั้นมันสื่อความหมายถึงอะไร มีใครสามารถเดาได้บ้าง หรือบางคนอาจจะบอกว่า i มันคือ index ไงล่ะ แล้ว j k คืออะไร ?
  • การสะกดชื่อแบบผิดๆ  มันจะส่งผลต่อการค้นหาจาก Text Editor และ IDE อย่างมาก
  • ตั้งชื่อแบบไม่สื่อ หรือ กว้างเกินไป เช่น data, handle, run, process และ perform  รวมทั้งมีตัวเลขรวมอยู่ด้วย เป็นต้น
  • ใช้ตัวย่อ เขาบอกไว้ว่า คนจริง ไม่ใช้ตัวย่อกันหรอกนะ
  • ใช้รูปแบบของการตั้งชื่อท่ีแปลกๆ เช่น ComputeHistoGram เป็นต้น
  • ชอบใข้ตัวแปรเดิมซ้ำๆ ในหลายๆ เงื่อนไข
  • ใช้แนวคิดการตั้งชื่อจากหลายๆ ภาษา มาอยู่ในที่เดียวกัน ทำให้เกิดความหลากหลายในการตั้งชื่อ
  • ตั้งชื่อโดยใช้ภาษาอื่นๆ ที่ไม่ใช่ภาษาอังกฤษ
  • ใช้ชื่อหรือคำจากวงการอื่นๆ หรือเฉพาะทาง เช่น คณิตศาสตร์ และ วิทยาศาสตร์ เป็นต้น ตัวอย่าง slash, asterix, equals
  • ใช้ชื่อที่ไม่ได้เกี่ยวข้องกับสิ่งที่ทำ หรือ บางที่อาจจะสื่ออารมณ์ของคนทำ เช่น god, superman, starwar เป็นต้น
  • ไม่สนใจ Coding standard ของภาษาที่นำมาใช้งานเลย
  • ใช้ชื่อที่ดูเหมือนกันกับตัวเลข เช่น 1 กับ L  กับ I=> 1lI  หรือ uvw หรือ 10I เป็นต้น
  • ชื่อ กับ สิ่งที่มันทำงาน ไม่สัมพันธ์กันเลย เช่น isValid() ใน method นี้ทำการตรวจสอบอะไรบ้าง ซึ่งไม่สมัพันธ์กับชื่อเลย
  • ชอบใช้ naming convention จากภาษาอื่นๆ หรือรูปแบบเก่าๆ เช่น ชื่อ method ขึ้นต้นด้วย m_  ,  o หรือ obj นำหน้า object เป็นต้น
  • ตั้งชื่อแบบ Hungarian ตัวอย่างเช่น
    • lAccountNum มาจาก ตัวแปรชนิด long
    • arrNumberList มาจาก array ของตัวเลข
    • bBusy มาจาก ตัวแปรชนิด boolean
    • fnFunction ชื่อ function
    • MonAM มาจากช่วงเช้าในวันจันทร์
    • FriPM มาจากช่วงบ่ายในวันศุกร์

2. การปกปิดความผิด

ยิ่งมีการปกปิด bug หรือซ่อนไว้นานและลึกเท่าไร มันก็ยิ่งหายากมากขึ้นเท่านั้น
ตัวอย่างเช่น

  • การ comment code ไว้ โดยไม่ลบออก ลองคิดเล่นๆ ดูว่า ถ้าคนอื่นเข้ามาดู code แล้วจะกล้าลบ code ชุดที่ comment ไว้ออกไหม
  • ตั้งชื่อคล้ายๆ กัน เช่น parselnt() กับ parseInt() หรือ method1() กับ method2()
  • สร้าง overload method จำนวนมากๆ
  • ใช้ AOP (Aspect Oriented Programming) มากเกินไป จนทำให้เกิดความซับซ้อนของระบบขึ้นมา

3. การเขียน comment ใน code

มีคนกล่าวไว้ว่า การมีเอกสารที่ไม่ถูกต้องมันแย่กว่า การไม่มีเอกสารอีกนะ
ตัวอย่างเช่น

  • comment ที่ไม่ตรงกับการทำงานของ code หรือแก้ไข code โดยไม่ได้แก้ไข comment
  • comment อธิบายขั้นตอนการใช้งานต่างๆ มากมาย
  • comment อธิบายขั้นตอนการออกแบบ code หรือการทำงานต่างๆ อย่างละเอียด
  • อัตราส่วนของ comment มากกว่า code

4. เรื่องการออกแบบ

มักจะเจอ code ที่มีลักษณะดังนี้

  • มีการ cast type จำนวนมาก
  • ไม่มีการ validate หรือตรวจสอบข้อมูลในตัวแปรต่างๆ เลย
  • ไม่ชอบการ encapsulate data ของข้อมูล หรือ ขั้นตอนการทำงาน
  • ทำการ copy-and-paste code มาใช้งานในส่วนต่างๆ จำนวนมาก
  • ชอบใช้ Global variable และ static variable
  • ทั้งตัวแปร และ method เป็น public ทั้งหมด
  • มี final class และ และตัวแปร จำนวนมาก
  • เกิด dead code หรือ code ที่ไม่ถูกเรียกใช้งานจำนวนมาก

5. ทำ code ให้ดูยุ่งเหยิง

code ที่มีลักษณะนี้ เช่น

  • ใน code มักจะมีสิ่งเล็กๆ ที่เรียกว่า magic number เช่น if( status == 1 ) {} คำถามคือ 1 คืออะไร
  • มีการใช้ if-else, switch-case จำนวนมาก และ ซับซ้อน
  • ลดการใช้งาน {  }
  • มีการ override ที่ซับซ้อนเกินไป
  • ไม่ชอบใช้ exception แต่ชอบให้ method ทำการ return กลับมา ซึ่งมันสนุกมากเลยนะ เฮ้อ …

6. ไม่ทำการทดสอบ code ที่เขียนขึ้นมา

7. เลือกภาษาโปรแกรมผิด ไม่เหมาะสมกับงานที่ทำ

เพียงเท่านี้ คุณก็สามารถสร้าง code ที่ดูแลรักษายากได้แบบง่ายๆ แล้วครับ …

สุดท้ายแล้ว

  • ในการเขียน code ที่แย่ๆ นั้น ไม่ต้องการ programmer ที่เก่งๆ เลย ถึงจะเก่งก็สร้าง code แย่ๆ ได้เช่นกัน
  • เชื่อเถอะว่า เราใช้เวลา 70% ไปกับการ debug code และดูแลรักษา code ดังนั้นสร้างให้มันดีๆ จะเป็นวิธีการดีที่สุด
  • ถ้าคุณระวังในเรื่องต่างๆ จากทั้ง 7 ข้อแล้ว  code ของคุณจะดูแลรักษาง่ายขึ้นนะ ไม่เชื่อก็ลองทำดูสิ