SE CORNER

ท่านผู้ฟังอาจจะเคยเห็นมีมอันนี้ "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 นี้ครับ

EP นี้จะพาไปดูสาขางานวิจัยใหม่ที่บอกว่า "โค้ดที่เราเขียนขึ้นไม่ใช่แค่ให้คอมพิวเตอร์เข้าใจนะ แต่เรายังต้องการให้คนก็เข้าใจง่ายด้วย" ซึ่งทีมวิจัยจาก University of California Davis กำลังศึกษาอยู่ว่า เราสามารถที่จะใช้ machine learning เพื่อปรับปรุงโค้ดที่เราเขียนขึ้นมาแล้ว ให้อ่านง่ายขึ้น review ง่ายขึ้น และดูแลรักษาง่ายขึ้น ได้หรือไม่ นอกจากนี้เรายังสามารถใช้วิธีการคล้ายๆ กัน เพื่อช่วยแก้ปัญหาในการเขียนโปรแกรมที่คนเริ่มโค้ดใหม่ๆ มักจะมีปัญหาได้เช่นกัน

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

EP นี้ชวนคุยเรื่องการเติบโตอย่างก้าวกระโดดของจำนวนนักพัฒนาซอฟต์แวร์และการสนับสนุนที่นักพัฒนาซอฟต์แวร์เหล่านั้นต้องการ ผมหยิบบทความจาก IEEE Software ชื่อ "The Developer Nation" มาเล่าให้ฟัง 

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

EP นี้เอางานวิจัยล่าสุดของ DeepMind ชื่อ "Competitive programming with AlphaCode" มาเล่าสู่กันฟังครับ งานนี้เป็นการพัฒนาระบบปัญญาประดิษฐ์ชื่อ AlphaCode ที่สามารถอ่านโจทย์ปัญหาภาษามนุษย์ (ภาษาอังกฤษ) แล้วสร้างโปรแกรมที่สามารถแก้ปัญหาดังกล่าวออกมาได้ โดยผลการทดสอบจากโจทย์จริงบนระบบของ Codeforces พบว่าเจ้า AlphaCode สามารถทำคะแนนได้ในระบบ Top 54% เทียบกับคนที่เข้าร่วมการแข่งขันทั้งหมด

ทำให้น่าคิดว่า เหมือนว่างาน programming ก็จะสามารถให้คอมพิวเตอร์และซอฟต์แวร์ทำแทนเราได้แล้วในอนาคตอันใกล้ แล้วถ้าอย่างนั้นในอนาคต คนเราไปทำอะไรดี?

ลองไปค้นหากันดูใน EP นี้ครับ

Episode นี้ต่อตอนที่สองของ How to Lead a Team จาก Chapter 5 ของหนังสือ Software Engineering at Google มีคำแนะนำดีๆ ในการทำงานเป็น engineering manager ที่จะช่วยให้สร้างทีมที่แข็งแกร่งได้

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

EP นี้กลับมาอ่านหนังสือ Software Engineering at Google ต่อครับ Chapter 5 เรื่อง How to Lead a Team เป็นเรื่องเกี่ยวกับการบริหารจัดการ software team ของ engineering manager และ teach lead โดยหนังสือได้ยกตัวอย่างทั้งวิธีการที่ควรหลีกเลี่ยงและวิธีการที่ควรปฏิบัติ ใน EP จะสรุปส่วนของ 6 antipatterns หรือ 6 วิธีการที่ควรหลีกเลี่ยงก่อน ดังนี้ครับ

1. Hire Pushovers - เลือกจ้างเฉพาะลูกน้องที่สั่งได้ง่ายๆ

2. Ignore Low Performers - ไม่สนใจคนที่ทำงานไม่ดี

3. Ignore Human Issues - ไม่สนใจปัญหาความสัมพันธ์ ให้ความสำคัญแค่กับปัญหาเทคนิคเท่านั้น

4. Be Everyone's Friend - อยากรักษาความสัมพันธ์กับเพื่อนร่วมงานไว้ ทำตัวเหมือนเป็นเพื่อนกับลูกน้อง

5. Compromise the Hiring Bar - ไม่มีมาตรฐานที่ชัดเจนในการรับคนเข้าทีม

6. Treat Your Team Like Children - ดูแลลูกน้องเหมือนเด็กๆ ไม่ให้ความเชื่อใจ

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

EP นี้นำผลการศึกษาจาก DevOps Research and Assessment (DORA) ที่ Google Cloud มาแชร์ให้ฟังกันครับ เราสามารถแบ่งองค์กร IT ออกเป็นกลุ่มๆ ในด้าน software delivery and operational performance ได้โดยใช้ตัวชี้วัด 4 อย่างคือ Deployment frequency (deploy บ่อยแค่ไหน), Lead time for change (โค้ดที่ commit ขึ้นไป production เร็วแค่ไหน), Time to restore service (เมื่อระบบมีปัญหาแล้ว กู้กลับได้เร็วแค่ไหน), และ Change failure rate (โค้ดที่แก้ทำให้เกิด software failure บ่อยแค่ไหน)

และถ้าพบว่าเรายังสามารถหรือควรต้องปรับปรุงในด้านใดด้านหนึ่ง สามารถลองทำตามคำแนะนำต่อไปนี้ครับ