การตรวจทานโค๊ด คืออะไร สำคัญอย่างไร และควรทำอย่างไร

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

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

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

ถ้ามองในมุมมองของนักประพันธ์ ผู้รีวิวโปรแกรมก็เปรียบเหมือนดั่งบรรณาธิการนั่นเอง

โดยส่วนตัวผมไม่เคยได้รับหน้าที่ให้รีวิวโค๊ดอย่างเป็นทางการ เนื่องด้วยวุฒิภาวะยังไม่ถึง (อย่างน้อยก็ถูกมองว่าอย่างนั้น) แต่ก็เคยไปทำหน้าที่นี้บ้างเป็นบางครั้ง ความเห็นของผมอาจจะไม่ถูกต้องนัก ก็ฟังหูไว้หูก็แล้วกัน

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

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

คำว่า “ตรงไปตรงมา” ในที่นี้ ไม่ใช่ความเห็นลักษณะแบบ “ห่วยว่ะ” หรือ “อ่านแค่สามบรรทัดก็หมดอารมณ์แล้ว” หรืออะไรทำนองนี้ ความเห็นลักษณะนี้เป็นความเห็นแบบบ่อนทำลายและไม่ได้ให้ประโยชน์อะไรกับคนเขียน ซ้ำร้ายเขาจะไม่อยากให้คุณตรวจทานอีกเป็นครั้งที่สอง

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

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

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

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

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

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

ถ้าจะพัฒนาซอฟท์แวร์ขึ้นมาสักตัว จะเขียนเองทั้งหมด หรือว่าจะใช้ชิ้นส่วนที่มีอยู่แล้วดี

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

ถ้าเป็นในอดีต คนส่วนใหญ่มักจะตอบว่า เขียนเองหมดเลย ด้วยเหตุผลประมาณว่าไม่เชื่อใจฝีมือคนอื่น เราเรียกความคิดนี้ว่ากลุ่มอาการ NIH (หรือ Not Invented Here Syndrome) ซึ่งในอดีตซอฟท์แวร์ไม่ได้มีขนาดใหญ่ มีความซับซ้อนไม่มาก การที่จะเขียนเองทั้งหมดในบ้าน (In-House … เอามันดื้อ ๆ นี่ล่ะ) ก็เป็นสิ่งที่ยังพอทำได้

แต่ในปัจจุบัน ใครที่ทำแบบนั้น ก็คงมีอยู่สองกลุ่ม ไม่โง่ ก็บ้า ….

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

ปัญหาของการพัฒนาซอฟท์แวร์เองทั้งหมดตั้งแต่ 0 ก็คือเราจะมี Code Base ที่ใหญ่ ซับซ้อน ทำให้เราไม่สามารถดูแลมันได้อย่างทั่วถึง เราจะเจอกับบรรดาบั๊กทั้งหลายที่ไม่มีคนไปแก้ไขมัน และเมื่อเวลาผ่านไปนานเข้า พอมีคนสลับสับเปลี่ยนกันภายในทีม คนใหม่ ๆ ที่เข้ามาจะต้องมานั่งเรียนรู้ตัวโปรแกรมใหม่ทั้งหมด ซึ่งนอกจากจะเสียเวลาแล้ว มันยังยากกว่าการศึกษาโปรแกรมที่ใช้ชิ้นส่วนที่มีอยู่แล้วในตลาด

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

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

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

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

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