คอมเมนท์ในโค๊ด – มลภาวะสำหรับโปรแกรมเมอร์

ถ้าเปรียบโค๊ดโปรแกรมหนึ่งเป็นเหมือนเมืองเมืองหนึ่ง สิ่งที่จะเปรียบเทียบได้กับมลภาวะนั้นก็คือ “comment”

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

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

แต่คราวนี้มาดูกันครับว่าทำไมเราถึงไม่ควรเขียน comment เยอะ ๆ ต่อไปนี้จะเป็นประเภทของ comment ที่เห็นได้ทั่วไปครับ

Comment ประเภทคำอธิบายว่าโค๊ดทำอะไร หรือทำงานอย่างไร
หลาย ๆ คนคงเขียน comment กำกับที่โค๊ดเอาไว้ว่าโค๊ดมันทำงานอะไร ทำงานยังไง input คืออะไรและ output คำนวนอย่างไร

ความคิดข้างต้นของผมเปลี่ยนเมื่อผมเริ่มถูก comment หลอกบ่อยครั้งขึ้นเรื่อย ๆ ความหมายของการถูกหลอกตรงนี้คือการที่ comment นั้นไม่ได้สื่อถึงสิ่งที่ code ตรงจุดนั้นทำงาน หลาย ๆ คนคงคิดว่าเป็นความผิดของคนที่เขียน comment หรือคนที่เขียน code ว่าไม่ได้อัพเดตให้มันสื่อถึงกัน แต่ความจริงก็คือเมื่อมีคนแก้โค๊ดแล้ว 90% จะไม่ไปแก้ comment ให้มันสื่อว่า code ทำงานอะไร

แต่พอมีคนอ่าน คนจะอ่าน comment เพราะว่ามันอ่านง่ายกว่า …

ลองคิดดูเล่น ๆ นะครับ ว่าทำไมเราถึงเขียน comment ในจุดนี้ตั้งแต่แรก ? … คำตอบของหลาย ๆ คนคือ “ก็เพราะโค๊ดมันซับซ้อน อ่านไม่รู้เรื่อง ก็เลยเขียน comment เอาไว้ให้คนอ่านรู้ว่าเขียนอะไรไว้”

คำถามต่อมาของผมคือ “แล้วเขียนให้มันอ่านรู้เรื่องตั้งแต่แรกไม่ได้เหรอ ???”

… หลายคนคงพูดอะไรไม่ออก แต่นี่คือความจริงครับ โค๊ดที่ต้องมี comment กำกับเอาไว้ว่ามันทำงานยังไงคือโค๊ดที่อ่านไม่รู้เรื่อง อ่านไม่ออก ถ้าให้ตอกย้ำอีกนิด โค๊ดประเภทนี้คือโค๊ดคุณภาพต่ำและไม่สมควรจะถูกใช้งานจริงครับ

ทางเลือกที่ดีกว่าคือการเขียน code ให้เข้าใจง่ายขึ้น และควรเขียน unit test กำกับเอาไว้ว่าถ้า input เป็นอะไร output ต้องเป็นอะไร เมื่อทำทั้งสองส่วนนี้แล้วความจำเป็นของการเขียน comment กำกับเอาไว้ก็จะหมดไป

Comment ประเภท ประวัติการแก้ไขไฟล์
ประวัติการแก้ไขไฟล์ หรือที่เรียกกันว่า version history นั้นเป็นวิถีปฎิบัติกันของโปรแกรมเมอร์ตั้งแต่สมัยโบราณกาล … คือเราต้องมีการ track ว่าไฟล์นั้นเคยแก้ไขอะไรมาบ้างก็เลยต้องหาที่ใส่เอาไว้ ก็เลยใส่มันไปตรงหัวไฟล์นั่นแหละ

แต่ … คุณมั่นใจหรือเปล่าว่า version history นั้นถูกต้อง ? คุณเอาความมั่นใจนี้มาจากไหน ??

มันเป็นเรื่องที่เป็นไปได้และเกิดขึ้นประจำครับ คือ … มันจะมีโปรแกรมเมอร์ประเภทที่ว่าเวลาเขาเขียน fix code อะไรเขาจะทำสำเนาแยกเป็นอีกไฟล์ แล้วก็พอทำเสร็จก็ก๊อปไฟล์มาทับดื้อ ๆ แล้วถ้าไอ้ตอนที่ทำสำเนาเขาไม่ได้สำเนา version history ติดมาด้วย (ซึ่งมันอยู่ใน comment จะมีหรือไม่มีก็ไม่ผลต่อโปรแกรม) ก็จะกลายเป็นว่าประวัติศาสตร์บางอย่างก็หายไป …

ทีนี้ไอ้คนที่มาอ่านก็งงสิครับ เอ้ ตกลงว่ามันแก้ไปแล้วหรือยังไม่ได้แก้ บางทีเห็นไม่มีใน history ก็คิดไปเองว่ายังไม่ได้แก้ ก็มานั่งงมหาต่อว่าต้องแก้ยังไงก่อนจะพบว่ามีคนแก้ไปแล้ว ….

เสียเวลา เสียเงินเสียทอง เสียอารมณ์ และเสียความรู้สึกครับ เจอแบบนี้

แล้วนึกสภาพว่ามีโปรแกรมเมอร์คนนึง พี่ท่านรีบมากเพราะต้องรีบปิดงาน ก็เลยรีบแก้ไฟล์ให้เสร็จ แล้วก็ดันลืมเขียน version history ในไฟล์ไปซะ … ก็เจ๊งสิครับ

ทีนี้ผมบอกว่า version history ในไฟล์นั้นเป็นวิถีปฎิบัติของโปรแกรมเมอร์มาตั้งแต่สมัยโบราณ … ที่จริงผมพูดผิดไปหน่อย

version history นั้นเป็นวิถีปฎิบัติของโปรแกรมเมอร์ “โบราณ” ต่างหาก

ทำไมถึงเป็นเช่นนั้น คือ หลังจากที่โปรแกรมเริ่มมีขนาดใหญ่ขึ้นเรื่อย ๆ เริ่มมีความซับซ้อนมากขึ้น ไอ้การมาเขียนแค่ว่าแก้อะไรไปบ้างแล้วมันก็ไม่พอใช่ไหมครับ มันต้องมีการเก็บไฟล์หลาย ๆ เวอร์ชั่นเพื่อที่จะเป็นหลักฐานได้ว่าในอดีตเคยเป็นอย่างไรอะไรทำนองนี้ ก็เลยมีการพัฒนาระบบที่เรียกว่า VCS หรือ Version Control System (บางคนจะเรียกว่า SCM หรือ Software Configuration Management ผมมองว่ามันต่างกันนิดหน่อยนะ) เพื่อที่เก็บว่าแต่ละเวอร์ชั่นของไฟล์นั้นมีหน้าต่างเป็นอย่างไร และเราสามารถระบุได้ด้วยว่าแต่ละเวอร์ชั่นนั้นทำอะไร

ดังนั้นเราจึงสามารถระบุ version history ได้ใน VCS ได้เลย! … ไม่ต้องเอาไปใส่ไฟล์ให้ “ซ้ำซ้อน” อีก

อันที่จริงการระบุว่าการเปลี่ยนแปลงของแต่ละเวอร์ชั่นนั้นทำอะไรทั้งบน version history ในไฟล์กับบน VCS นั้นเป็นการซ้ำซ้อนและสามารถนำไปสู่ความสับสน นึกสภาพว่าถ้าไอ้คนเขียนโค๊ดมันดันเมาโคล่า เขียน comment ในไฟล์กับใน VCS ไม่เหมือนกัน คนอ่านก็คงมานั่งงงว่าตกลงจะเอาอะไรกันแน่ และถ้าในโค๊ดมันดันผิด … ก็บรรลัยกันไปใหญ่

ดังนั้น กรุณาใส่ประวัติการแก้ไขไฟล์ลงไปเฉพาะบน VCS นะครับ อย่าใส่ในไฟล์เพิ่มอีกให้สับสนเล่น

VCS นั้นมีข้อดีอีกอย่างตรงที่สามารถบังคับให้ผู้ที่เอาโค๊ดเข้าไปในระบบต้องเขียน version history ในตัว VCS เองทุกครั้ง ดังนั้นเราจึงแก้ไขปัญหาประเภทลืมเขียนได้อีกด้วย

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

ปัญหาก็คือ คำว่า “ชั่วคราว” ของคนหนึ่งมันคือ “ตลอดกาล” ใช่ครับ มันมีบางคนที่ดันส่งงานไปทั้ง ๆ ที่ยังมี comment ประเภทนี้ติดไปด้วย

ทีนี้มันก็จะเป็นปัญหาของคนอ่านโค๊ด (อีกแล้ว) ว่าจะเอาอย่างไรกับไอ้ comment นี่ดี ตกลงจะควรจะเก็บไว้หรือควรจะลบทิ้ง และส่วนใหญ่แล้วเขาก็จะทิ้งเอาไว้ครับ เพราะว่าการไปแก้ไฟล์ในจุดที่ไม่ได้เกี่ยวกับงานตัวเองมันเป็นการหาภาระใส่ตัวซะงั้น

ทุกครั้งที่มีคนจะแก้ไฟล์นี้ก็จะมานั่งคิด ตกลงตูควรจะทำไงกับ comment นี้ดีฟะ ? แล้วก็จะผ่านไป กลายเป็นภาระของลูกหลาน

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

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

ที่ว่ามานั้นเป็นตัวอย่างของ comment ที่ไม่ควรมีในไฟล์ครับ เราก็น่าจะพอเห็นแล้วว่า comment นั้นคือมลภาวะในโค๊ด ก็เหมือนกับ CO2 กับฝุ่นทั้งหลายที่อยู่ในอากาศ ที่นอกจากจะไม่มีประโยชน์ต่อร่างกายแล้วยังสามารถทำให้เราเจ็บป่วยได้อีกด้วย ดังนั้นถ้าลดได้ก็ลดเถอะครับ

สุดท้ายนี้จริง ๆ แล้วมันก็มี comment บางประเภทที่ควรต้องมี เพราะไม่มีอะไรแทนทีได้หรือแทนได้ก็ทำได้ไม่ดี ยกตัวอย่างเช่น

  1. คำประกาศการอนุญาตใช้งาน (License) ก็คือ ระบุว่า ใครเป็นเจ้าของ จะเอาไฟล์ไปใช้อย่างไรได้บ้าง และอย่างไรไม่ได้บ้าง
  2. ข้อมูลคร่าว ๆ เกี่ยวกับไฟล์ เช่น ใครเป็นผู้สร้าง สร้างขึ้นเมื่อไหร่ เพื่ออะไร

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

ปล. เกือบลืม เดี๋ยวจะเข้าใจผิดว่าเป็นความคิดของผมเองทั้งหมด post นี้ผมอ้างอิงจากหนังสือ Clean Code: A Handbook of Agile Software Craftsmanship โดย Robert C. Martin ครับ เล่มนี้น่าสนใจถึงแม้ว่าคุณจะไม่ได้ใช้ Agile เลยก็ตาม (อันที่จริงผมว่าเนื้อหาส่วนใหญ่ก็ไม่ได้เกี่ยวกับ Agile ตรง ๆ นะ)

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *

This site uses Akismet to reduce spam. Learn how your comment data is processed.