EP นี้หยิบงานวิจัยใหม่เอี่ยมจาก Mining Software Repositories (MSR '22) ชื่อ "An Empirical Evaluation of GitHub Copilot’s Code Suggestions" โดย Nhan Nguyen and Sarah Nadi จาก University of Alberta มาเล่าให้ฟังกันครับ ทีมวิจัยนี้ศึกษาความถูกต้องและความเข้าใจง่าย (understandability) ของโค้ดที่แนะนำมาจาก GitHub Copilot โดยได้ใช้ตัวอย่างคำถาม 33 คำถามจาก LeetCode ซึ่งเป็น website สำหรับฝึกฝนการเขียนโปรแกรม และให้ Copilot สร้างคำตอบใน 4 ภาษา ได้แก่ภาษา Python, ภาษา Java, ภาษา Javascript และภาษา C

ทีมวิจัยพบว่าในแง่ของความถูกต้อง คำตอบของ Copilot ในภาษา Java นั้นถูกต้องมากที่สุด (ผ่าน test cases ทั้งหมดใน LeetCode 100%) จำนวน 57% ของคำตอบทั้งหมด ตามมาด้วย Python (42%), C (39%) แต่ Javascript ทำได้ไม่ดีนักที่ 27%

ในแง่ของความเข้าใจง่าย ทีมวิจัยใช้ค่า cognitive complexity กับ cyclomatic complexity ของโค้ดที่ Copilot แนะนำให้เป็นคำตอบ ผลพบว่าโค้ดจาก Copilot ส่วนใหญ่มีค่า complexity ต่ำ หรือเข้าใจได้ง่ายนั่นเอง

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

EP นี้ชวนคุยเรื่อง developer experience หรือ DX ครับ คุณ Jean Yang เจ้าของบริษัท Akita ให้ความเห็นว่าต่อไปในอนาคต DX จะมีส่วนสำคัญอย่างมาก เพราะจำนวน developers ในโลกนี้เพิ่มขึ้นเรื่อยๆ (ตอนนี้มีจำนวนมากกว่าคนออสเตรเลียทั้งประเทศ!) เราจะสร้าง developer tools ที่ดีอย่างไร? เพื่อให้นักพัฒนามี DX ที่ดี และมีความสุขระหว่างการทำงาน

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

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

EP นี้ไปอ่านบทที่ 8 ของหนังสือ Software Engineering at Google กันต่อ มาดูกันว่า Google สร้าง Style Guide ขึ้นมาจากหลักการทั้ง 5 ที่กล่าวไปก่อนหน้าได้อย่างไร? กฎทั้งหลายใน Style Guide สามารถเปลี่ยนได้หรือไม่และมีวิธีการอย่างไร? การนำกฎไปใช้ นำไปใช้ตอนไหนและใช้อย่างไร?

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

EP นี้กลับมาอ่านหนังสือ Software Engineering at Google ต่อ ในบทที่ 8 "Style Guides and Rules" ที่พูดถึงเรื่องการกำหนดแนวทางการเขียนโค้ดในบริษัทกูเกิ้ล EP จะเป็นตอนที่ 1 ที่พูดถึงหลักการสำคัญ 5 ประการในการกำหนด coding styles and guides ซึ่งได้แก่

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

EP นี้หยิบบทความเรื่อง "To Microservices and Back Again - Why Segment Went Back to a Monolith" ซึ่งเล่าตัวอย่าง case study ของบริษัท Segment ที่เคยพยายามจะแก้ปัญหา Environment Isolation ของซอฟต์แวร์ตนเองด้วยไมโครเซอร์วิส แต่สุดท้ายกลับพบว่าเจอปัญหาที่บริหารจัดการได้ยากกว่าเก่า และสุดท้ายเลือกที่จะกลับมาใช้สถาปัตยกรรมแบบ Monolith อีกครั้งหนึ่ง

ปัญหาเริ่มต้นคืออะไร ทำไมย้ายไปไมโครเซอร์วิสแล้วไม่เวิร์ค ไปฟังกันใน EP นี้ครับ

EP นี้หยิบงานวิจัยที่เก่าหน่อยแต่ยังมีประโยชน์อยู่มาเล่าให้ฟังกันครับ เป็นงานวิจัยของ Alberto Bacchelli และ Christian Bird ที่ Microsoft ชื่อว่า "Expectations, Outcomes, and Challenges Of Modern Code Review" ซึ่งเป็นงานวิจัยที่ศึกษาจากนักพัฒนาของไมโครซอฟต์และพยายามเข้าใจ 3 อย่าง คือ (1) ความคาดหวังจากการทำ code review, (2) ผลที่ได้จากการทำ code review และ (3) ปัญหาหรือความท้าทายในกระบวนการ code review

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

ทำไมสิ่งที่หวังกับสิ่งที่ได้จึงไม่ตรงกัน? ไปหาคำตอบใน EP นี้ครับ

อ่านงานวิจัยฉบับเต็ม: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ICSE202013-codereview.pdf

ท่านผู้ฟังอาจจะเคยเห็นมีมอันนี้ "I don’t always test my code, but when I do, I test in production." - the Most Interesting Man in the World ซึ่งก็เป็นมีมขำๆ ที่ให้ชวนหัวเราะว่า การปล่อยให้ซอฟต์แวร์ไปถูกทดสอบบน production นี่มันช่างกล้า เหมือนฆ่าตัวตายชัดๆ

Charity Majors (CTO ของบริษัท honeycomb.io) เธอบอกว่าการทดสอบไม่ได้จำกัดหรือไม่ควรถูกจำกัดอยู่แค่ระหว่างการพัฒนาหรือ staging enviroment เท่านั้น แต่ควรจะต้องรวมถึง production ด้วย เนื่องจากการ deploy หรือการใช้งานจริงจากผู้ใช้ เราจะเจอกับตัวแปรที่ควบคุมไม่ได้ (หรือไม่ได้อยู่ในการควบคุม) ระหว่างที่เราทดสอบซอฟต์แวร์อีกเยอะมากๆ คำแนะนำคือเราต้องยอมรับและเตรียมพร้อมรับมือกับมันต่างหาก

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

Episode นี้พาท่านผู้ฟังกลับไปอ่านหนังสือ Software Engineering at Google กันต่อ ใน Chapter 7 จะเป็นเรื่อง Measuring Engineering Productivity ที่อธิบายว่า Google นำการวัดมาใช้ประโยชน์ในกระบวนการพัฒนาซอฟต์แวร์ อย่างไร

ที่ Google จะมีทีมวิจัยเฉพาะที่ตั้งขึ้นมาเพื่อทำการวัดผลในหลากหลายกระบวนการ โดยทีมวิจัยนี้จะประกอบไปด้วยนักวิจัยด้านวิศวกรรมซอฟต์แวร์และด้านอื่นๆ ที่เกี่ยวข้อง เช่น จิตวิทยา (เพื่อเข้าใจความรู้สึกของนักพัฒนา) หรือนักเศรษฐศาสตร์ เป็นต้น และทีมนี้จะช่วยเหลือองค์กรเมื่อต้องการผลไปใช้ทำการตัดสินใจ เช่น องค์กรควรทำกระบวนการนี้ต่อไปหรือไม่? สิ่งเหล่านี้มีประโยชน์ต่อนักพัฒนาหรือไม่? 

วิธีการ measurement ใน Google เป็นอย่างไร และมีประโยชน์อย่างไร ไปฟังกันใน EP นี้ครับ

EP นี้ขอหยิบงานวิจัยล่าสุดมาเล่าให้ฟังกันครับ ผมและทีมอาจารย์จากคณะ ICT มหิดล ร่วมกับนักวิจัยจาก University College London ร่วมกันกับบริษัทซอฟต์แวร์ในประเทศไทย 4 บริษัท เพื่อศึกษาถึงปัญหาและความท้าทายในการพัฒนาซอฟต์แวร์ของบริษัทซอฟต์แวร์ขนาดเล็กไปถึงกลาง หรือที่เรียกว่า SME ในประเทศไทย ว่ามีอะไรบ้าง เพื่อที่เราจะให้หาวิธีการแก้ไขปัญหาและความท้าทายเหล่านั้นด้วยกัน ผ่านการใช้งานวิศวกรรมซอฟต์แวร์อัตโนมัติ หรือ Automated Software Engineering ซึ่งได้แก่ การนำเครื่องมือแบบอัตโนมัติเข้ามาใช้งานเพื่อให้นักพัฒนาไปโฟกัสกับงานส่วนอื่นที่จำเป็นต้องใช้ความสามารถและความคิดสร้างสรรค์ของคน ตัวอย่างความท้าทายที่เราพบ ได้แก่ software testing, software measurements, requirements และ effort estimation

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