EP นี้ไม่ได้มาเล่าเรื่อง software engineering ครับ แต่จะขอทำรีวิวตัวเองในการทำ SE Corner Podcast นี้มาครบ 1 ปีเต็มๆ เนื่องจากเป็นพอดแคสต์เกี่ยวกับวิศวกรรมซอฟต์แวร์ ก็เลยขอใช้วิธีการ retrospective สักหน่อย จะได้เข้าธีม :-) 

ใน EP นี้ผมเลยมาเล่าให้ฟังว่ามีเรื่องไหนบ้างที่ผมคิดว่า (1) ผมทำได้ดี (what we did well), (2) ผมยังสามารถปรับปรุงได้ (what we can do better), และ (3) อะไรที่จะเริ่มทำหลังจากนี้ไป (actions)

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

Machine learning-enabled systems หรือระบบซอฟต์แวร์ที่มี machine learning เป็นส่วนประกอบ เป็นซอฟต์แวร์ที่พบได้มากขึ้นเรื่อยๆ ในปัจจุบัน งานวิจัยจาก Software Engineering Institute (SEI) ที่ Carnegie Mellon University โดย Grace Lewis และ Ipek Ozkaya พบว่า ทีมพัฒนาของระบบดังกล่าวมักจะประกอบด้วยทีม 3 ทีมที่มีความรู้และความเข้าใจในด้านที่แตกต่างกัน คือ data scientist, software engineering, และ operations 

ทีม data scientist มีหน้าที่สร้าง ML model แล้วส่งต่อให้ทีม software engineering นำไปรวมกับส่วนอื่นๆ ของซอฟต์แวร์ให้ออกมาเป็นระบบที่คนใช้งานได้ง่าย และสุดท้ายส่งต่อให้ operations ทีม เพื่อนำไปติดตั้งและ monitor การทำงาน 

งานวิจัยของ Grace และ Ipek พบว่า ยังมีความเข้าใจผิดและปัญหาในการสื่อสารระหว่างสามทีมนี้อยู่มาก ทำให้ซอฟต์แวร์ที่ใช้ Machine Learning หลายๆ ตัว ไม่ประสบความสำเร็จเท่าที่ควร ทั้งก่อนและหลังการขึ้น production

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

EP นี้เอารายงานผลของ Stack Overflow Developer Survey 2022 มาเล่าให้ฟังกันครับ เนื้อหามีเยอะมากๆ เลยสรุปสั้นๆ ในแต่ละด้านมาให้ฟังกัน น่าสนใจทั้งนั้นเลย

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

ที่มา Stack Overflow Developer Survey 2022: https://survey.stackoverflow.co/2022/

EP นี้มาคุยกันต่อจาก EP ที่แล้วเรื่องการเขียน document ครับ Google แบ่งชนิดของ document ออกเป็น 5 ชนิด คือ 

1. Reference documentation, including code comments

2. Design documents

3. Tutorials

4. Conceptual documentation

5. Landing pages

แล้วแต่ละอันมีความแตกต่างกันอย่างไร ใครคือคนอ่าน? มีวิธีเขียนอย่างไรให้เหมาะสม?

นอกจากนี้เรายังไปดูว่ามีวิธีการ review ตัว document อย่างไร และมี tips & tricks อะไรในการเขียน document ที่ดีบ้าง

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

EP นี้พากลับไปอ่าน Chapter 10 ในหนังสือ Software Engineering at Google เรื่อง Documentation กันครับ เราจะพาไปดูว่า Google แปลความหมายของ document อย่างไร และประโยชน์ของการเขียน document (ซึ่ง write once, read many times) นั้นมีอะไรบ้าง

นอกจากนี้ผมจะเล่าให้ฟังว่าแนวทางการแก้ปัญหาว่า dev ไม่อยากเขียน document นั้นจะต้องทำอย่างไร จากประสบการณ์ของ Google เอง

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

EP ชวนคุยเรื่อง software license โดยเฉพาะ license ของโค้ดบน Stack Overflow 

โค้ดและเนื้อหาใดๆ บน Stack Overflow นั้น ไม่ได้เป็น public domain แต่อยู่ภายใต้ license ชื่อ Creative Commons Attribution-ShareAlike 4.0 International (หรือ CC BY-SA 4.0) ซึ่งมีแนวทางกำหนดไว้ว่าสามารถนำไปใช้ได้ แต่จะต้อง (1) ให้ attribution หรือให้เครดิตกลับมาที่เจ้าของเนื้อหา และ (2) หากนำไปใช้ต่อ ผลงานนั้นๆ ก็จะต้องมี license CC BY-SA 4.0 หรือ license ที่รองรับด้วย เช่น Free Art license 1.3 หรือ GPLv3

EP นี้เลยอยากจะให้นักพัฒนาทุกท่านตระหนักไว้ทุกครั้งเรื่อง software license ก่อนที่จะก๊อปปี้โค้ดจาก Stack Overflow มาใช้ เพื่อจะได้ไม่ทำผิดข้อกำหนดของ license กัน

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

อ่านๆ Software Engineering at Google บทที่ 10 แล้วไปเจอเรื่องแทรก เลยเปลี่ยนเรื่องเล่าใน EP นี้เลย :-) เป็น case study ของการเปลี่ยนจาก Google Wiki มาใช้ระบบ g3doc ที่ผสานเข้ากับ workflow การทำงานของ developer ที่ Google ได้อย่างดี ทำให้การทำ documentation กลายเป็นเรื่องง่าย และได้รับการยอมรับเป็นอย่างดีจาก developer เลยไปนั่งอ่านและดู talk ของคุณ

SE at Google บทที่ 10 เรื่อง documentation เลยขอเลื่อนไปพูด EP ถัดไปแทนนะครับ ;-)

EP นี้พูดคุยเนื้อหาจากหนังสือ Software Engineering at Google ในบทที่ 9 เรื่อง Code Review มีเรื่องที่น่าสนใจหลายเรื่องเช่น

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

เราน่าจะรู้จักหนี้ทางเทคโนโลยี technical debt (tech debt) กันอยู่บ้างแล้ว มีตัวอย่างมากมายที่แสดงให้เห็นว่า tech debt ก่อให้เกิดปัญหาในภายหลังได้ร้ายแรงขนาดไหน ซอฟต์แวร์ทีมส่วนใหญ่กลัวว่าจะเผลอสร้าง tech debt กัน แต่สุดท้ายก็หนีมันไม่พ้น EP นี้พาไปดูบทความเรื่อง "Reframing tech debt" ของคุณ Leemay Nassery ที่เป็น engineering manager ของ Dropbox ที่บอกว่า เราควรจะปรับความคิดเสียใหม่ ให้เน้นไปที่การสร้างความมั่งคั่งทางเทคโนโลยีหรือ "Tech Wealth" แทนที่จะคอยมาลดหนี้ทางเทคโนโลยี (Tech Debt) โดยคอยใส่แพลนในการเพิ่ม tech wealth เข้าไปในทุกๆ sprint หรือทุกๆ quarter และ เมื่อระบบเราร่ำรวยไปด้วยความพร้อมของ infrastructure, scalability, stability, ทีมพัฒนามีความสุข จำนวน unit test ที่เพิ่มขึ้น ส่ิงเหล่านี้จะส่งผลให้ tech debt ลดลงไปเอง

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