SE CORNER

ในปัจจุบันการเรียนการสอนด้าน 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 นี้ครับ

EP นี้เป็นตอนต่อเนื่องมาจาก EP ที่แล้วที่เราคุยกันเรื่อง Top Programming Languages 2022 ที่จัดอันดับโดย IEEE Spectrum ครับ ผลการจัดอันดับในปีนี้มีจุดน่าสนใจอันหนึ่งคือ ภาษา SQL อยู่อันดับ 1 หากทำการจัดอันดับเรื่องการหางาน ใน EP นี้เลยมาเจาะลึกกันดูว่า เพราะเหตุผลใด SQL จึงกลับมาเป็นภาษาที่ได้รับความนิยมมากอีกครั้งหนึ่ง

ผมเจอบทความที่อธิบายเรื่องนี้ใน IEEE Spectrum เขียนโดยคุณ Rian Diane Caballar ครับ เธอให้เหตุผลไว้ 3 ข้อหลักๆ ดังนี้

1. Ralational database ได้เข้าไปอยู่ในทุกๆ แพลตฟอร์ม โดยเฉพาะ mobile application ที่มีการเติบโตอย่างสูงมาก

2. การทำการวิเคราะห์ข้อมูล หรือการสร้าง machine learning application จำเป็นจะต้องใช้ข้อมูลจำนวนมาก ซึ่งมักจะเก็บอยู่ใน relational database

3. เครื่องมือที่รองรับการทำงานของ SQL มีจำนวนมาก และมีการปรับปรุงมาอย่างยาวนาน

แม้ว่า SQL อาจจะไม่ได้เป็นภาษาที่โดดเด่นมาก แต่เหมือนจะเป็นภาษาที่ขาดไม่ได้ในปัจจุบันครับ

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

EP นี้พาไปดูผลการจัดอันดับ Top Programming Languages ปี 2022 โดย IEEE Spectrum ครับ เค้าจัดอันดับโดยดูข้อมูลจากหลายแหล่งด้วยกัน ได้แก่ Google Search, Twitter, Stack Overflow (no. of questions, posts), Reddit, IEEE Explore (no. of articles), IEEE Job Site, CareerBuilder, และ GitHub (starred repos, no. of PR) ซึ่งผลที่ออกมาก็คือ 

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

EP นี้มาคุยต่อเนื่องเรื่องการเขียน unit testing แบบ Google ครับ โดยจะเน้นไปที่หลักการเขียนเทสต์ให้มีความชัดเจน (Clarity) โดยเทสต์ที่มีความชัดเจนจะมีประโยชน์ทั้งในแง่การ maintenance และในแง่การตรวจหาบั๊กที่เจอด้วยเทสต์นั้นๆ ด้วย 

หลักการที่หนังสือ Software Engineering at Google แนะนำ เพื่อให้เทสต์มีความชัดเจนที่สุด มีดังต่อไปนี้

1. Make Your Tests Complete and Concise ยึดหลักสองอย่างคือ เทสต์ต้องมีข้อมูลสมบูรณ์ในตัวเอง (complete) และไม่มีข้อมูลอื่นที่ไม่จำเป็น (concise)

2. Test Behaviors, Not Methods เปลี่ยนแนวคิดว่าเราทดสอบไปที่การทำงานของโค้ด (behaviours) ที่ต้องการ ไม่ใช่สร้างเทสต์ตามจำนวน method ที่มี

3. Don't Put Logic in Tests หลีกเลี่ยงการใส่ logic ทั้งหลาย (if-else, loop, หรือแม้แต่การต่อสตริง) เพราะทำให้เทสต์มีความซับซ้อน เข้าใจได้ยาก และเสี่ยงต่อการมีบั๊ก (ในเทสต์) 

4. Write Clear Failure Messages เขียน failure message ให้ชัดเจน มีเนื้อหาครบถ้วนเพียงพอที่จะไปดีบั๊กต่อได้ง่ายๆ

5. DAMP, Not DRY มีโค้ดซ้ำบางส่วนได้บ้างในเทสต์ หากมันช่วยให้เทสต์ตรงไปตรงมา และเข้าใจได้ง่ายขึ้น

6. Shared Values, Shared Setup การมีตัวแปรที่ใช้ร่วมกัน หรือ setup methods ควรทำให้ชื่ออ่านเข้าใจง่าย และมีวิธีที่จะ override ค่าตั้งต้นใน setup method ได้

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

EP นี้อ่าน SE at Google book กันต่อครับ Chapter 12 เป็นเรื่อง Unit Testing ที่ Google ให้ความสำคัญมากๆ โดยหนังสือมีคำแนะนำว่าควรจะออกแบบ unit test อย่างไรให้หลีกเลี่ยงปัญหา brittle test และทำให้ unit test suite ของเราดูแลรักษาได้ง่าย (test maintainability สูง) 

โดยหลักการที่ Google แนะนำ เช่น test state, not interactions ผมคิดว่าชัดเจนและมีประโยชน์มากๆ และเป็นจุดที่คนเขียน unit test จะสับสนว่าจะออกแบบเทสต์แบบไหนดี จึงคิดว่า EP นี้มีปะรโยชน์กับการทำงานจริงมากเลยครับ

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

EP นี้ ชวนคุยเรื่องน่าสนใจที่ไปอ่านเจอใน Article จาก The Atlantic ครับ เรื่อง "The Coming Software Apocalypse" (https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/) อ่านแล้วคิดว่าน่าสนใจมากๆ เลย

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

นอกจากนี้บทความยังชี้ให้เห็นว่าการเขียนโค้ดแบบที่เราทำอยู่ปัจจุบันอาจจะไม่ใช่วิธีที่ดีที่สุดในการพัฒนาซอฟต์แวร์อีกต่อไป นักพัฒนาซอฟต์แวร์น่าจะต้องผันตัวมาเป็น "นักออกแบบ"​ ซอฟต์แวร์มากกว่า

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

EP นี้ขออธิบายเพิ่มเติมเรื่องงานวิจัยสมัยปริญญาเอกเรื่อง "การตรวจวัดความเหมือนของโค้ดและการค้นหาโค้ดโคลนในข้อมูลโค้ดขนาดใหญ่" (Code Similarity and Clone Search in Large-Scale Source Code Data)" ที่ได้รับการนำไปประชาสัมพันธ์ผ่านช่องทางสื่อ (เช่น Techhub facebook page) ครับ มีคนสนใจและมีคอมเม้นต์อยู่เยอะพอสมควร (ขอบคุณมากๆ เลยครับ) แต่พอดีเห็นว่ามีบางคอมเม้นต์ที่อาจจะเข้าใจงานและเนื้อหาที่ต้องการจะสื่อสารคลาดเคลื่อนไปบ้างบางส่วน ก็เลยขอใช้ EP นี้เพื่ออธิบายงานเพิ่มเติมครับ :-)

รายละเอียด ติดตามได้ใน EP นี้เลยครับ