ซอฟต์แวร์ใดๆ วันหนึ่งก็ต้องมีจุดที่มีการหยุดการให้บริการ ไม่ว่าจะเป็นเพราะหมดอายุการใช้งานจริงๆ หรือมีระบบใหม่ที่ทดแทนกันขึ้นมา EP นี้ สรุปเนื้อหาจาก Chapter 15 ของหนังสือ Software Engineering at Google ว่าเราจะทำกระบวนการ Deprecation (การหยุดให้บริการหรือหยุดการดูแลรักษา) ของซอฟต์แวร์อย่างไร ให้เหมาะสม และมีปัญหาน้อยที่สุด 

ไปฟังรายละเอียดใน EP นี้กันครับ

AI Engineer เป็นงานที่กำลังเป็นที่ต้องการมากขึ้นเรื่อยๆ ในอนาคต ในขณะที่ Software Engineer เองก็เป็นตำแหน่งงานที่ยังได้รับความนิยมสูงสุดในปัจจุบัน บทความจาก IEEE Software ของคุณ Ipek Ozkaya ชี้ให้เห็นว่าสองงานนี้มีความใกล้เคียงกันมากกว่าที่คิด โดยงาน AI Engineering ซึ่งเกิดใหม่ ยังต้องการความรู้พื้นฐานจาก Software Engineering อีกหลายส่วน เพราะการสร้าง ML models ก็เป็นการสร้างซอฟต์แวร์แบบหนึ่ง

ไปฟังเนื้อหากันใน EP นี้ครับ

ผมได้ไปฟัง Talks at Google อันหนึ่งแล้วพบว่าน่าสนใจมาก เลยหยิบมาเล่าให้ฟังกันใน EP นี้ครับ หัวข้อคือ "A Philosophy of Software Design" โดย Prof. John Ousterhout จาก Stanford University ศาสตราจารย์ Ousterhout นี่เป็นผู้คร่ำหวอดในวงการการศึกษาและพัฒนาซอฟต์แวร์ เพราะแกทำงานเป็นอาจารย์ก่อน แล้วก็ไปทำบริษัท 14 ปี แล้วก็กลับมาเป็นอาจารย์อีก เพราะฉะนั้นแกรู้ทั้งบุ๋นและบู๊แน่นอน

คำแนะนำใน Talks at Google จากหนังสือของแก (ที่ชื่อเดียวกับ talk) มีดังนี้ครับ

รายละเอียดจะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ

EP นี้กลับมาอ่าน Chapter 14 Larger Tests ในหนังสือ Software Engineering at Google กันต่อ โดยจะเล่าให้ฟังถึง larger tests ทั้งหมด 10 ชนิด ที่ใช้อยู่ใน Google 

แต่ละชนิดจะเป็นอย่างไร และมีวิธีการทดสอบอย่างไร ไปฟังกันใน EP นี้ครับ

EP นี้ขอคั่นรายการจาก EP ที่แล้วนิดนึง เนื่องจากเพิ่งกลับมาจากงาน DevMountain Tech Festival 2 ที่เชียงใหม่ เลยมาแชร์ประสบการณ์ในการไปร่วมงาน Developer Conference ครั้งแรกครับ ไปฟังกันใน EP นี้ครับ

EP นี้ขยับมา Chapter 14 ในหนังสือ SE at Google ครับ มาคุยกันเรื่อง "Larger Test" ซึ่งก็หมายถึง System Test หรือ End-to-End Test นั่นเอง โดยในตอนที่ 1 นี้ ผมจะเล่าให้ฟังว่า Google ตีความหมายของเทสต์ขนาดใหญ่เหล่านี้อย่างไร และเหตุผลใดจึงต้องทำเทสต์เหล่านี้

รายละเอียดเป็นอย่างไร ไปฟังกันใน EP นี้ครับ

ในปัจจุบันการเรียนการสอนด้าน SE เป็นอย่างไร? ใช้วิธีการใดในการสอนบ้างเพื่อให้นักศึกษาที่จบออกไปมีความรู้ความสามารถที่ตรงกับความต้องการของตลาดจริงๆ EP นี้พาไปดูกันครับ 

ผมนำงานวิจัยจาก University of Zagreb ที่ไปศึกษางานวิจัยด้านการศึกษาที่เกี่ยวกับ software development จำนวน 120 งานวิจัย และสรุปผลออกมาในสองด้าน คือ (1) วิธีการสอน (teaching methods and approaches) และ (2) ลักษณะของการสอนและวิธีการสอน (characteristics of teaching methods and approaches) 

โดยผลพบว่าการเรียนการสอนที่ได้รับความนิยมมากที่สุดจะเป็นแบบ project-based learning และลักษณะการสอนที่ได้รับความนิยมสูงสุดจะเป็นการทำงานเป็นทีม (teamwork) 

รายละเอียดจะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ

EP นี้นำงานศึกษาวิจัยจาก IEEE Software ชื่อ The Current and Evolving Landscape of Requirements Engineering in Practice มาเล่าให้ฟังกันครับ Mohamad Kassab และ Phillip Laplante จากมหาวิทยาลัย Pennsylvania State University ศึกษาเรื่อง requirement engineering มาอย่างยาวนาน และได้ทำการเปรียบเทียบผลการ survey นักพัฒนาตั้งแต่ปี 2003, 2008, 2013 จนถึงรอบล่าสุด 2020/2021 (ทำสองรอบ) และเปรียบเทียบผลลัพธ์ใน 5 ด้าน ได้แก่ requirement elicitation, requirement representation, requirement inspection, requirement estimation และ tools ว่ามีการเปลี่ยนแปลงไปอย่างไรในรอบเกือบๆ 10 ปี (เทียบปี 2020/2021 กับ 2013)

รายละเอียดจะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ

EP นี้มาคุยกันต่อเรื่อง Test Doubles จากบทที่ 13 ในหนังสือ Software Engineering at Google ครับ โดยจะลงรายละเอียดไปที่การใช้ test doubles สองแบบคือ

1. Fake - ตัวแทน implementation จริง ที่ทำงานเหมือนตัวจริง แต่ใช้วิธีการต่างกันบางอย่าง เพื่อให้เหมาะกับการเทสต์ เช่น การเขียน/อ่านข้อมูลจาก memory แทนที่จะเป็น disk 

2. Stub - การใช้ mock object พร้อมกับการกำหนด return value หรือคำตอบจากการเรียก mock method ซึ่งทำให้ทดสอบ method ที่เราต้องการได้ โดยไม่ต้องมี object อื่นๆ ที่เกี่ยวข้องอยู่จริง

และวิธีการทดสอบสองแบบคือ state testing vs. interaction testing ซึ่ง Google แนะนำว่าควรทำ state testing (เช็คไปที่ state ของ object ที่ถูกเทสต์ หรือ ผลลัพธ์ที่ได้ออกมา) มากกว่า interaction testing (เช็ควิธีการทำงาน เช่น method ที่ทดสอบถูกเรียกหรือไม่ กี่ครั้ง)

รายละเอียดจะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ

EP นี้เล่าเรื่องจาก Chapter 13 ในหนังสือ Software Engineering at Google เรื่อง Test Doubles หรือ การใช้ตัวแทนของ implementation หรือ API บางส่วนที่จำเป็นในการเทสต์ เพื่อทำให้การทดสอบนั้นเป็นไปได้อย่างรวดเร็วและสะดวกมากขึ้น

ส่ิงที่น่าสนใจคือ Google เชื่อว่า เราไม่ควรใช้ test doubles เยอะๆ เพราะมักจะนำไปสู่ปัญหาในการดูแลรักษาภายหลัง รวมถึงเทสต์ที่ใช้ test doubles ก็ไม่ค่อยมีประโยชน์ในการหาบั๊กสักเท่าไหร่ด้วย คำแนะนำจาก Google คือ เราควรเลือกใช้ implementation จริงเป็นหลักก่อน แล้วค่อยพิจารณาปัจจัยดังต่อไปนี้เมื่อจำเป็นจะต้องตัดสินใจว่าจะใช้ test doubles หรือไม่

รายละเอียดจะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ