SE CORNER

EP นี้พามาอ่าน Chapter 6 General-Purpose Modules are Deeper ในหนังสือ A Philosophy of Software Design กันครับ ในบทนี้ผู้เขียนพยายามโน้วน้ามให้เห็นว่า เรามักจะชินกับการเขียนโมดูล คลาส หรือ เมธอด ที่ specific หรือ specialized มากๆ (ซึ่งบางทีอาจเกิดขึ้นโดยไม่รู้ตัว) แต่จริงๆ แล้วการพยายามทำให้โมดูล/คลาส/เมธอด เหล่านั้นทำงานได้กว้างขึ้น หลากหลายขึ้น หรือที่หนังสือเรียกว่า general-purpose นั้น จะทำให้เกิด information hiding ได้มากขึ้น ใช้งานได้หลากหลายขึ้น และลด cognitive load ของคนอ่านโค้ดลงได้มากกว่าครับ

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

EP นี้เป็นเรื่องต่อเนื่องจาก EP ที่แล้วครับ วิธีการหนึ่งที่เราสามารถลดความซับซ้อนของโค้ดตามหลักการ deep module - simple interface ก็คือการทำ information hiding หรือ การซ่อนข้อมูลไว้ในโมดูล นั่นเอง เช่น หากมีการทำงานที่ต้องทำต่อเนื่องกันหลายๆ ขั้นตอน เราก็ไม่ควรแยกขั้นตอนเหล่านั้นออกมาเป็นหลายโมดูล เพราะจะทำให้โมดูลเหล่านั้นมี dependency กัน และใช้งานยากขึ้น เป็นต้น

มาฟังรายละเอียดทั้งหมดใน EP นี้ครับ

EP นี้เป็น EP พิเศษครับ เพราะเป็น EP ที่ผมทำ Podcast นี้ครบ 2 ปีพอดี! วันนี้พามาอ่านหนังสือ A Philosophy of Software Design กันต่อใน Chapter 4 เรื่อง Modules Should be Deep ซึ่งอธิบายให้เห็นว่า เราควรออกแบบโมดูลในซอฟต์แวร์ให้มี interface ที่เข้าใจง่ายแต่ซ่อน implementation ที่ซับซ้อนไว้ด้านใน ซึ่งจะเรียกว่า "deep modules" ข้อดีของ deep modules คือการซ่อนความซับซ้อน ทำให้ผู้ใช้งานโมดูลของเรา (โปรแกรมเมอร์คนอื่น) และการดูแลรักษาซอฟต์แวร์ ทำได้ง่ายมากขึ้น

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

EP นี้หยิบเรื่อง cognitive load ของ developer มาคุยกันครับ (ขอบคุณคุณเบน (https://blog.coursesquare.co/author/ben/) ที่แนะนำบทความนะครับ) โค้ดที่ดีคือโค้ดที่มี cognitive load ต่ำๆ เพราะทำให้คนมาอ่าน เข้าใจ และดูแล​ โค้ดเราต่อได้ง่ายๆ แต่การทำให้โค้ดมี cognitive load ต่ำๆ ไม่ใช่เรื่องง่ายเท่าไหร่ครับ ใน EP นี้เรามาดูกันว่าวิธีที่ลด cognitive load ของโค้ด มีอะไรบ้าง

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

บทความ: https://github.com/zakirullin/cognitive-load

EP นี้ หยิบหนังสือ A Philosophy of Software Design กลับมาอ่านต่อครับ Chapter ที่ 3 เป็นเรื่องเกี่ยวการเขียนโค้ดที่ดี โดยยกแนวทางการเขียนโค้ดสองแบบคือ tactical programming ที่เขียนแค่ให้โค้ดทำงานได้ กับ strategic programming ทีเขียนโดยคำนึงถึงการแก้ไขและความซับซ้อนของโค้ดด้วย มาดูกันว่าแบบไหนที่ทำให้ซอฟต์แวร์ดูแลง่ายกว่าในระยะยาวครับ

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

ต้อนรับ EP เลขสามตัวด้วยเรื่อง bus factor ซึ่งเป็น software measure แบบหนึ่งที่ใช้วัดความเสี่ยงของซอฟต์แวร์โปรเจคท์ได้ครับ ผมหยิบบทความจาก Metabase ที่ทำการศึกษา 1,000 open source projects ว่ามี bus factor เป็นอย่างไรบ้างมาเล่าให้ฟังกันครับ

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

บทความ: https://www.metabase.com/blog/bus-factor

truckfactor tool: https://github.com/HelgeCPH/truckfactor

SE Corner Podcast ครบ 100 ตอนแล้วครับ! เย้! ใน EP นี้ขอฉลองครบรอบ 100 episodes ด้วยการทำ retrospective ครับ ว่าผมได้ประโยชน์อะไรบ้างจากการทำ SE Corner ในระยะเวลาเกือบ 2 ปีที่ผ่านมา โดยผ่านการทำ retrospective แบบ Glad-Mad-Sad ครับ :-)

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

EP นี้เป็นเรื่องเกี่ยวกับ Developer Productivity แต่ว่าหัวข้อเป็น Technical Debt นะครับ หยิบเอาบทความเรื่อง Defining, Measuring, and Managing Technical Debt ของคุณ Ciera Jaspan กับ Collin Green จาก Engineering Productivity Research Team ของ Google มาเล่าให้ฟังครับ ทีมนี้ทำงานศึกษาวิจัยเกี่ยวกับ technical debt ที่ส่งผลลบต่อประสิทธิภาพการทำงานของ software engineer ที่กูเกิ้ลมาตั้งแต่ปี 2018 และพวกเขาได้ค้นพบ 10 รายการของ technical debt ที่ส่งผลเสียมากที่สุดต่อ engineer ของกูเกิ้ลรายละเอียดเป็นอย่างไร ไปฟังกันใน EP นี้ครับ

บทความต้นฉบับ: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10109339

EP นี้เอาบทความของคุณ​ Bertrand Meyer ศาสตราจารย์ด้านวิศวกรรมซอฟต์แวร์และผู้คิดค้นภาษา Eiffel ใน Communication of thte ACM มาเล่าให้ฟังกันครับ บทความชื่อ "AI Does Not Help Programmers" ซึ่ง อ. Meyer เล่าประสบการณ์การทดลองใช้ ChatGPT เพื่อแก้บั๊กในโปรแกรมภาษา Eiffel แล้วพบว่าโมเดล LLM ณ ปัจจุบัน น่าจะยังไม่ถึงระดับที่จะมาเขียนโปรแกรมแทนโปรแกรมเมอร์จริงๆ ได้

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

บทความต้นฉบับ: https://cacm.acm.org/blogs/blog-cacm/273577-ai-does-not-help-programmers/fulltext?fbclid=IwAR0FESzXaSnR7LYw9koVcVEg35rJjcQB1zcGxHhwzDxZeoHBHklFoh42COI

EP นี้หยิบงานวิจัยของ นศ. ที่สร้างเครื่องมือในการทดสอบระบบ Microservice แบบที่ใช้ Backends for Frontends (BFF) pattern ชื่อ Microusity มาเล่าให้ฟังกันครับ งานวิจัยนี้ได้รับการตีพิมพ์ที่งานประชุมวิชาการ the 31st IEEE/ACM International Conference on Program Comprehension (ICPC '23) ในหมวด Tool Demonstration ครับ โดยวิธีการที่เราใช้ในการทดสอบ BFF microservice นั้น เราใช้เครื่อง RESTful API fuzzing tool ชื่อ RESTler จาก Microsoft ร่วมกับ network monitoring tool ชื่อ Zeek และเราสร้าง algorithm เพื่อทำการติดตาม request ที่เข้าไปยัง BFF ว่าถูกส่งไปที่ microservice ไหนบ้าง ด้านหลัง BFF ครับ นอกจากนี้ยังมี graph visualization ที่ช่วยให้เข้าใจการเดินทางของ request ได้ง่ายขึ้นด้วย เครื่องมือนี้ช่วยให้นักพัฒนา BFF microservice สามารถแก้ไขปัญหา HTTP 500 ที่เกิดขึ้นได้ง่ายมากขึ้น สามารถเข้าไปลองเล่นกันได้ที่ https://microusity.dev/ ครับ

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

หากสนใจงานวิจัย สามารถอ่านเปเปอร์ได้ที่นี่ครับ: https://arxiv.org/abs/2302.11150