ComBioLaw.De

ไอเดียของบล็อกนี้มีที่มามาจาก Forum ใน Blognone (อีกแล้ว) เมื่อมีโปรแกรมเมอร์ท่านหนึ่ง คือคุณ darkleonic มาระบายความอึดอัดใจในการทำงาน ให้เพื่อนร่วมวงการฟัง ในหัวข้อเรื่อง ผิดด้วยเหรอที่เขียนโปรแกรมไม่ geek มองเผิน ๆ เหมือนกับเป็นการมาบ่นเพื่อระบายความในใจเฉย ๆ แต่ประเด็นที่ถูกนำมาบ่นน่าสนใจไม่หยอก แม้ว่าเจ้าของเรื่องจะมองเป็นการเขียนโค้ด geek หรือไม่ geek (น่าจะเป็นเทพหรือไม่เทพมากกว่า) แต่เมื่อผมอ่านข้อความที่นำมาโพสต์จบ ก็รู้สึกว่าเป็นเรื่องของ โค้ดสั้น vs โค้ดยาว ทำให้รู้สึกสนใจขึ้นมา ยิ่งมีความคิดเห็นของคุณ bossalove เข้ามาด้วยแล้ว ความสนใจยิ่งเพิ่มความบรรเจิด

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

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

โดยพื้นฐานแล้วผมเชื่อว่า โค้ดสั้นย่อมดีกว่าโค้ดยาว แต่ก็ไม่สามารถครอบคลุมได้ทุกกรณี ทั้งนี้มีสองกรณีที่เราสามารถบอกได้ทันทีว่าโค้ดสั้น หรือโค้ดยาวอย่างไหนดีกว่ากัน ...

เขียนโปรแกรม

bow_der_kleine

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

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

ในความคิดเห็นของคุณ bossalove มีประเด็นหนึ่งที่น่าสนใจทีเดียว นั่นคือ การทำให้โค้ดสั้นลงอาจเป็นการเพิ่ม coupling ผมเลยลองเปิดตำรา ค้นหาความรู้ในเรื่องที่เกี่ยวข้องมาวิเคราะห์ดู ปรากฏว่าไปเจอเรื่องของ coupling & cohesion ในส่วนของ design concept

Coupling คือ ความสัมพันธ์ระหว่างหน่วยต่าง ๆ ของโปรแกรม (โมดูล, คลาส, ออพเจ็ค, etc.) การที่หน่วยต่าง ๆ ของโปรแกรมมีความสัมพันธ์กันมากเท่าไร หรือยิ่งซับซ้อนขึ้นเท่าไร ก็ยิ่งทำให้โปรแกรมมีความซับซ้อนมากขึ้นเท่านั้น ปัญหาต่าง ๆ ก็จะตามมา ดังนั้น การออกแบบที่ดีต้องลด coupling ระหว่างหน่วยให้น้อยที่สุด

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

ปัญหาทั้งหมดอยู่ที่ว่า หากเราเพิ่ม cohesion มากเท่าไร จำนวนหน่วยของโปรแกรมก็จะเพิ่มขึ้นเท่านั้น นั่นหมายถึงการเพิ่มของ coupling ที่ตามมา ศิลปะในการออกแบบจึงอยู่ตรงนี้เอง ว่าเราจะ ลด coupling ได้อย่างไร ในขณะที่เราเพิ่ม cohesion

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

ตามคำแนะนำของตำรา เราสามารถลด coupling เพิ่ม cohesion ได้ด้วยวิธีการต่าง ๆ ดังนี้

• หากมีคลาสจำนวนน้อย ๆ (เช่น 3 คลาส) มี coupling กัน ให้รวมคลาสทั้งหมดเข้าด้วยกัน
• หากมีคลาสจพนวนมากมี coupling กัน ให้ใช้คลาสอีกตัวทำหน้าที่เป็นตัวเชื่อมความสัมพันธ์ระหว่างคลาส (เรื่องนี้รู้สึกจะขัดกับหลัก refactoring แฮะ)
• หากมีเมโธทที่ทำให้เกิด coupling ที่มีความซับซ้อนในคลาส ให้ย้ายที่เมโธทนั้นไปอยู่คลาสอื่น
• หากการเรียกเมโธทของ superclass ทำให้เกิด coupling ที่มีความซับซ้อน ควรเลี่ยงการเรียกใช้เมโธทของ superclass นั้น
• ใช้ Law of Demeter เพื่อเพิ่ม cohesion
• หากแยกอทริบูทของคลาสออกเป็นกลุ่ม ๆ แล้วสามารถแยกเมโธทออกเป็นกลุ่มตามอทริบูทได้ โดยที่กลุ่มของอทริบูทและเมโธทไม่มีสมาชิกร่วมกัน ให้แยกคลาสนั้น ๆ ออกเป็นหลายคลาสตามกลุ่มของอทริบูทและเมโธท
• หากเมโธทใดมีหน้าที่มากกว่าหนึ่งอย่าง ให้แยกเมโธทนั้นออกเป็นหลาย ๆ เมโธทตามหน้าที่

นั่นคือคำแนะนำตามตำรา แต่หากเราคิดต่อไปว่า การเพิ่ม cohesion จะมีประโยชน์อะไรกับการออกแบบ นอกจากในเรื่องของการลด duplicate code ผมหาคำตอบให้กับตัวเองได้สองคำตอบคือ

• ทำให้โค้ดแต่ละส่วนสั้นลง ทำให้การดูแล และหาข้อผิดพลาดง่ายขึ้น
• ทำให้การ reuse โค้ดง่ายขึ้น (ซึ่งเกื้อหนุนกับการลด duplicate code)

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

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

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