Blog Archives

Code Smell & Refactoring ตอนที่ 3
จากครั้งที่แล้ว เรารู้จัก ประเภทของ Code Smell ไป 2 ประเภทแล้วนะครับ ในครั้งนี้เราจะมาเล่าเกี่ยวกับประเภทของ Code Smell ที่เหลือกัน

3. Code Smell แบบเด็ดดอกไม้สะเทือนถึงดวงดาว (Change Preventers)

หลายท่านคงเคยได้ยินคำว่า Butterfly Effect ซึ่งคำนี้มันคือส่วนหนึ่งของทฤษฎีความยุ่งเหยิง (chaos theory) ถูกเสนอโดย ศาสตราจารย์เอ็ดเวิร์ด ลอเรนซ์ ได้เคยตั้งคำถามว่า   การกระพือปีกของผีเสื้อในประเทศบราซิลก่อให้เกิดพายุทอร์นาโดในรัฐเท็กซัสได้หรือไม่? อันเป็นที่มาของแนวคิดที่โด่งดังไปทั่วโลกในนาม “ปรากฏการณ์ผีเสื้อขยับปีก”(Butterfly Effect) แต่คนไทยจะคุ้นเคยกับสำนวนของ พอล ดิแรก นักฟิสิกส์รางวัลโนเบลว่า เด็ดดอกไม้สะเทือนถึงดวงดาว นั่นแหละครับ ซึ่งมีความหมายเดียวกัน แต่แนวคิดเช่นนี้ไม่ใช่เพิ่งถูกคิดแค่ในปัจจุบัน ในอดีตสำนักปรัชญาในอินเดียโบราณเสนอ ตาข่ายของพระอินทร์(Indra’s net) กล่าวถึงตาข่ายของพระอินทร์  ซึ่งถักไว้ด้วยแก้วมณีต่างๆ แต่ละเมล็ดสะท้อนให้เห็นแสงของกันและกันโยงใยเป็นปัจจัยต่อกัน  โดยตาข่ายของพระอินทร์นี้ใช้ ใยแมงมุงที่ถูกน้ำค้างในตอนเช้าเป็นสัญลักษณ์

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

4. Code Smell แบบเอาไว้ก่อน (Dispensables)

สมมุติ มีบริษัทแห่งหนึ่ง มีพนักงาน 3 คน พนักงานคนแรกไม่มาทำงานตลอด อีกคนหนึ่งตายไปแล้ว เหลือพนักงานทำงานอยู่คนเดียว แต่คุณก็ยังจ่ายเงินเดือนให้พนักงานทั้งสามคนเหมือนเดิม ถ้าคุณเป็นนายจ้าง คุณควรจัดการอย่างไรดีครับ ย้อนกลับมาที่ พนักงานคนที่ทำงานเพียงคนเดียวของคุณ ลักษณะการทำงานของพนักงานคนนี้ คือทุกวันๆเค้าต้องมาฟังวิธีการทำงานกับนายจ้างทุกวัน วันละหลายชั่วโมงก่อนทำงานจริง เวลาทำงานเค้าต้องใช้เอกสารต่างๆที่เก็บไว้รวมกับกองหนังสือการ์ตูน เอกสารงานนั้นก็มักพิมพ์มามากกว่าหนึ่งฉบับ ถ้าคุณเป็นนายจ้าง คุณควรจัดการกับวิธีการทำงานของพนักงานคนนี้อย่างไรดีครับ
เรื่องดังกล่าวก็เพียงจะอุปมาให้เข้าใจ Code Smell แบบเอาไว้ก่อนไม่เป็นไร (Dispensables) มันก็คือลักษณะ Code ที่มีสิ่งที่ไม่จำเป็นหรือ เขียนมาโดยไม่มีจุดหมาย หรือเพื่อทดลองอะไรบางอย่าง หรือไม่ได้ใช้แล้ว เมื่อใช้งานจริงไม่ได้ถูกเรียกใช้งาน และไม่ได้มีการลบทิ้งหรือ Code มีลักษณะซ้ำช้อนกันมาก หรือมี Comment จำนวนมากเกินความจำเป็น Code ในลักษณะนี้อาจจะไม่ได้สร้างปัญหาให้ในกระบวนการอื่น แต่ในการทำงาน เราอาจจะต้องเสียเวลากับมันมากโดยไม่ได้ประโยชน์อะไร ดังนั้น เราควรหมั่นทำความสะอาดโปรแกรม มีประสิทธิภาพมากขึ้นและง่ายต่อการเข้าใจ

จบเนื้อหาครั้งนี้ไว้เท่านี้ก่อนครับ    ในครั้งต่อไปเราจะมาพูดถึงประเภทของ Code Smell ประเภทสุดท้าย สรุป Code Smell แต่ละประเภท เพื่อเกริ่นนำก่อนจะลงรายละเอียดต่อไปครับ ว่ามีอะไรบ้างครับ

Stream Magento ทีม Code คุณภาพ

Sources

• Refactoring: Improving the Design of Existing Code – Martin Fowler
• Mäntylä, M. V. and Lassenius, C. “Subjective Evaluation of Software Evolvability Using Code Smells: An Empirical Study”. Journal of Empirical Software Engineering, vol. 11, no. 3, 2006, pp. 395-431.

Code Smell & Refactoring ตอนที่ 2
จากครั้งที่แล้ว เรารู้จักความหมายของ Code Smell และ Refactoring กันแล้วนะครับ
วันนี้ Stream Magento ทีม Code คุณภาพ  มาพูดถึง Code Smell ในแต่ละชนิดกันครับ หากเรารู้ว่า Code Smell มีลักษณะอย่างไร เราก็จะป้องกันการเกิด Code Smell ได้ตั้งแต่ต้น และสามารถรู้จุดที่จะ Refactoring ให้ Code มีคุณภาพได้ครับ และอย่างไรก็ตามการใช้ Unit Testing Framework ตั้งแต่ต้นก็จะสามารถ Refactoring ได้ง่ายและปลอดภัย

ในครั้งนี้เราจะมาเล่าเกี่ยวกับประเภทของ Code Smell กันก่อนนะครับ เพื่อให้เข้าใจในภาพกว้างก่อนที่จะรายละเอียด Code Smell มีการแบ่งประเภทไว้ใหญ่ๆ  5 ประเภท

1. Code Smell แบบบวมๆ(Bloaters)

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

Bloaters  คือลักษณะของ Code, Method และ  Class ที่มีขนาดใหญ่ ทำงานหลายๆอย่างเสร็จสรรพในตัวมันเอง ลักษณะเหล่านี้ในระยะการเขียนโปรแกรมแรกๆอาจยังไม่ปรากฏขึ้น  แต่จะเกิดจากการเขียนส่วนเพิ่มเติมเข้าไป หรือขาดการวางโครงสร้างที่ดี และลักษณะ Bloaters  มีแนวโน้มสะสมโตขึ้นเรื่อยๆ ซึ่งจะเกิดผลเสียขึ้นในกรณีที่มีการเปลี่ยนแปลง การแก้ไขทำได้ยากเนื่องจาก อาจมีส่วนเกี่ยวข้องกับส่วนอื่นๆอีก มีความซับซ้อนมาก หรือถ้าพยายามเปลี่ยนแปลงโครงสร้างภายหลังทำให้ระบบพังเลยก็มี ดังนั้นในส่วนนี้จึงไม่มีใครอยากจะยุ่งเท่าไรนัก เป็นไปได้ว่า Code, Method และ  Class ที่มีขนาดใหญ่ ทำงานหลายๆอย่างเสร็จสรรพในตัวมันเอง แต่การเปลี่ยนแปลงเพียงเล็กน้อยนั้นก็เพียงพอที่จะทำให้ล้มเหลวหลายๆอย่างด้วยตัวมันเองได้เช่นกันครับ

2. Code Smell แบบใช้ OO  แบบผิดๆ(Object-Orientation Abusers)

วิธีการหรือแนวทางการเขียนโปรแกรม แม้จะมีหลากหลายแบบตามการใช้งาน แต่ก็ปฏิเสธไม่ได้ว่า การเขียนโปรแกรมเชิงวัตถุ ( Object-oriented programming, OOP) ได้รับความนิยมนำมาพัฒนาในงานธุรกิจเป็นอย่างมาก OOP คือรูปแบบการเขียนโปรแกรมคอมพิวเตอร์ ที่ให้ความสำคัญกับ วัตถุ ซึ่งสามารถนำมาประกอบกันและนำมาทำงานรวมกันได้ โดยการแลกเปลี่ยนข่าวสารเพื่อนำมาประมวลผลและส่งข่าวสารที่ได้ไปให้ วัตถุ อื่นๆที่เกี่ยวข้องเพื่อให้ทำงานต่อไป โดยหลักการ OO มีหลักการขั้นตอนที่เป็นที่ยอมรับกันในระดับสากล แต่ก็ไม่แปลกที่มีการละเมิดหลักการเหล่านั้น หรือการใช้งานแบบผิด เนื่องจากผู้เขียนเองไม่ทราบหลักการนั้นๆ หรือขี้เกียจ หรือสุดแท้แล้วแต่เหตุผล ดังนั้น Object-Orientation Abusers ก็คือ โปรแกรมที่ไม่สมบูรณ์ตามหลักการ หรือผิดหลักการการเขียนโปรแกรมเชิงวัตถุนั้นเองครับ

เนื้อหาชักจะมากเกินไป ครั้งนี้เอาไว้เพียงแค่นี้ก่อน ในครั้งต่อ ๆ ไปเราจะมาพูดถึง Code Smell 3 ประเภท  ที่เหลือนะครับ

Stream Magento ทีม Code คุณภาพ

Sources

• Refactoring: Improving the Design of Existing Code – Martin Fowler
• Mäntylä, M. V. and Lassenius, C. “Subjective Evaluation of Software Evolvability Using Code Smells: An Empirical Study”. Journal of Empirical Software Engineering, vol. 11, no. 3, 2006, pp. 395-431.

Code Smell & Refactoring ตอนที่ 1 

วันนี้ Stream Magento ทีม Code คุณภาพ  จะมาแบ่งปันประสบการณ์พัฒนาระบบในเรื่อง Code Smell และ Refactoring  เบื้องต้นเรามารู้จักความหมายของคำทั้งสองก่อน

ในการพัฒนาหรือการบำรุงรักษาซอฟแวร์นั้น สิ่งที่นักพัฒนาส่วนมากต้องการ :ความทนทานซอฟต์แวร์( robustness คือ เมื่อเกิดข้อผิดพลาดขึ้น เราจะยอมให้โปรแกรมทำงานต่อไป ), ใช้ง่าย-เรียบง่าย,นำกลับมาใช้ได้อีกครั้ง, ปรับเปลี่ยนได้ แต่ในการพัฒนาหรือการบำรุงรักษาซอฟแวร์นั้น นักพัฒนาส่วนมากจะมักพบคือ : ความเปราะบาง, ซับซ้อน, ไม่ยืดหยุ่น, และโค้ดอ่านไม่รู้เรื่อง ซึ่งทำให้ยากต่อการแก้ไข ยากต่อการนำมาใช้ใหม่ Code อ่านไม่ออกยุ่งเหยิง Code ซ้ำๆ Code ซับซ้อน ซึ่งมักเรียกว่า Legacy Code หรือ Spaghetti Code ใน Code เหล่านี้มี Code Smells มากมาย และผู้พัฒนาส่วนมากไม่รู้ว่า Code Smell คืออะไร

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

Refactoring คือ การจัดองค์ประกอบและโครงสร้างภายในของซอฟแวร์ใหม่ โดยทำการปรับปรุงส่วนที่เป็น Code Smell หรือโครงสร้างของซอฟแวร์ให้มีความเป็นมาตรฐาน โดยที่การเปลี่ยนแปลงนั้น ไม่มีผลกระทบต่อผลลัพธ์เดิมของซอฟแวร์และการทำ refactoring ที่ดีและปลอดภัยนั้นมักทำร่วมกับการทำ Unit Testing Framework อย่างครอบคลุม ซึ่งจะการันตีได้ว่าผลลัพท์จะไม่ถูกเปลี่ยนแปลงไป
ซึ่งซอฟต์แวร์มีการพัฒนาไปนานๆ ก็มักจะมีการเพิ่มความซับซ้อน ซึ่งการทำ refactoring จะช่วยให้การออกแบบดีขึ้นและสามารถเข้าถึงปัญหาได้ง่ายกรณีที่ซอฟแวร์เกิดปัญหาขึ้น

แต่การทำ Refactoring ก็มีข้อจำกัดบางประการ ตัวอย่างปัญหาของการทำ Refactoring
– Refactoring ไม่สามารถแก้ไขได้ทุกปัญหา ต้องดูตามความเหมาะสมในการใช้
– Refactoring ถ้าเกี่ยวข้องกับ Database ควรระวัง
– Refactoring มีข้อจำกัดกับ Interface , Service หรือส่วนที่ Code ยุ่งจนเกินไป และเต็มไปด้วย bug ซึ่งจะไปกระทบกับหลายๆ ส่วน
– อย่าทำ Refactoring เมื่อใกล้เวลาส่งมอบงาน เพราะการทำค่อนข้างใช้เวลาพอสมควร

อย่างไรก็ตามหากเรารู้ว่า Code Smell มีลักษณะอย่างไร เราก็จะป้องกันการเกิด Code Smell ได้ตั้งแต่ต้น และการใช้ Unit Testing Framework ตั้งแต่ต้นก็จะสามารถ Refactoring ได้ง่ายและปลอดภัย

ในครั้งต่อ ๆ ไปเราจะมาพูดถึง Code Smell และ Refactoring ในแต่ละชนิด เครืองมือในการวิเคราะห์ และการทำงานของทีม Stream Magento

Stream Magento ทีม Code คุณภาพ