Blog Archives

สตรีมฯ ได้เข้าร่วมงาน CIT Mini Workshop จัดโดย สำนักงานคณะกรรมการกำกับและส่งเสริมการประกอบธุรกิจประกันภัย (คปภ.) ในช่วงบ่ายวันที่ 21 สิงหาคม 2566 และได้รับเลือกให้นำเสนอโซลูชั่น InsurTech บนเวที ในหัวข้อ Cloud Native Development – Road to “Super App” การนำ Cloud Native มาใช้ประโยชน์ในการทำ Super App แอปเดียวครบ สะดวก เร็ว คุ้มค่า ลูกค้าประทับใจ ซึ่งเป็นเทรนด์ที่กำลังมาแรง

สตรีมฯ ให้บริการลูกค้าองค์กรในการทำแอปพลิเคชั่นสำหรับบริษัทประกันที่อยากสร้าง New Application หรือการ Re-design แอปพลิชั่นของตัวเอง ให้ตอบรับกับการใช้งานของลูกค้า End-user ได้ดียิ่งขึ้น โดยเฉพาะบริษัทประกันซึ่งเรามีประสบการณ์ในการพัฒนา ทั้ง Web App, Mobile App

หากลูกค้าอยากพัฒนาแอปพลิเคชั่นที่สามารถปรับแต่งเพื่อสร้างความได้เปรียบในการแข่งขัน และมีทีมงานที่มี Skill Programing ทางสตรีมฯ มีทีม Modernized Application Development แนะนำให้ทำแอปซึ่งใช้การออกแบบ Microservices Architecture นำเทคโนโลยีใหม่ๆ และเป็นรูปแบบ Cloud-Native มาช่วย run application จุดเด่นคือ ใช้ได้กับทุก Environment และทำให้สามารถเพิ่ม/ลดแอปได้อย่างคล่องตัว

ไม่เพียงเท่านั้น หากลูกค้าเน้นเรื่อง Speed to market ต้องการให้ได้แอปเร็ว ก็สามารถเลือกใช้ Low-code Platform ซึ่งสตรีมฯ มีให้บริการด้วยเช่นกัน

ด้วยประสบการณ์ในการพัฒนาแอปในหลากหลายธุรกิจ ทำให้ สตรีมฯ มีความรู้ความเข้าใจรูปแบบการพัฒนา Web App, Mobile App ได้อย่างลึกซึ้ง ดังนั้นหากต้องการสร้าง Super App เพื่อส่งมอบประสบการณ์ที่ดีที่สุดให้กับผู้ใช้งานครอบคลุมทุกบริการ สามารถเสนอผลิตภัณฑ์ใหม่ๆ ให้ง่าย รวดเร็ว เชื่อมต่อการทำงานกับ 3rd party ครบจบในแอปเดียว ทางสตรีมฯ ยินดีให้คำปรึกษาและร่วมเป็นส่วนหนึ่งในการพัฒนา Application ให้มีความเร็ว ยืดหยุ่น แข็งแรง และยั่งยืนไปกับลูกค้า

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

5. Code Smell แบบน้ําพึ่งเรือเสือพึ่งป่า (Couplers)

หลักการพื่้นฐานในการออกแบบส่วนประกอบของซอฟแวร์ ศัพท์ที่จำเป็นต้องทราบมีสองตัวคือ  Coupling และ Cohesion
Cohesion คือ เป็นการบอกถึงความสอดคล้องกัน นั้นหมายความว่า ใน Class หนึ่่งคลา่ส Method ในคลาสนั้นๆควรจะต้องทำงานให้มีความสอดคล้องกัน การทำงานต่างๆที่ควรจะเป็นไปในทางเดียวกัน
Coupling คือ ระดับความเกี่ยวข้อง หรือ พึ่งพากันของ Object ต่างๆในระบบ  หากระบบใดมีความเกี่ยวข้องกันของ Object ที่สูงก็จะทำให้ระบบนั้นมีความอิสระนั้นต่ำ
สรุปอย่างตรงมาตรงไป การออกแบบส่วนประกอบของซอฟแวร์ที่ดี ต้อง Strong cohesion , loosely coupling นั้นก็คือ  พยายามเขียนโปแกรมให้สัมพันธ์สอดคล้องกันภายในคลาสให้มากที่สุด และพยายามลดความสัมพันธ์ระหว่าง class ให้น้อยที่สุด
Code Smell แบบน้ําพึ่งเรือเสือพึ่งป่า (Couplers) ก็เช่นเดียวกัน  คือ ความเกี่ยวข้องกันของ Class ต่างๆในระบบมีความเกี่ยวข้องกันมากเกินไป อาจจะทำให้เวลาทำการย้าย หรือ แก้ไข ก็ทำได้ลำบาก และเมื่อทำการแก้ไขส่วนใดส่วนหนึ่งของระบบ ก็อาจจะไปกระทบกับส่วนอื่นๆ ที่เกี่ยวข้องครับ Class ไม่เป็นอิสระต่อกัน

สรุปหัวข้อประเภทของ Code Smell 

สรุปหัวข้อประเภทของ Code Smell ที่จะพูดถึงรายละเอียดในครั้งหน้าครับ
1. Code Smell แบบบวมๆ(Bloaters)

• Long Method
• Large Class
• Primitive Obsession
• Long Parameter List
• Data Clumps

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

• Switch Statements
• Temporary Field
• Refused Bequest
• Alternative Classes with Different Interfaces

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

• Divergent Change
• Shotgun Surgery
• Parallel Inheritance Hierarchies

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

• Comments
• Duplicate Code
• Lazy Class
• Data Class
• Dead Code
• Speculative Generality

5. Code Smell แบบน้ําพึ่งเรือเสือพึ่งป่า (Couplers)

• Feature Envy
• Inappropriate Intimacy
• Message Chains
• Middle Man
• Incomplete Library Class

จบ เนื้อหา ประเภทของ 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 ตอนที่ 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.