SE CORNER

EP นี้อ่านหนังสือ A Philosophy of Software Design กันต่อในบทที่ 20 เรื่อง Designing for Performance กันครับ เนื้อหาในบทนี้เน้นเรื่องการรีดประสิทธิภาพของซอฟต์แวร์ออกมาให้มากที่สุดแต่ในขณะเดียวกันก็ยังคงการออกแบบที่ดีไว้อยู่

จะทำได้อย่างไร ไปฟังคำแนะนำใน EP นี้กันครับ

EP นี้อ่านบทที่ 19 ของหนังสือ A Philosophy of Software Design เรื่อง Software Trends ครับ ผู้เขียนได้เลือก 6 เทรนด์ใน software development ในช่วงหลายสิบปีที่ผ่านมาและนำมาวิเคราะห์ในแง่มุมของ software design ว่าเทรนด์เหล่านั้นช่วยส่งเสริมให้ software design ดีขึ้น หรือทำให้ software design แย่ลงกันแน่ มีบางเรื่องที่ผมเห็นด้วยและก็บางเรื่องที่ผมไม่เห็นด้วยครับ

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

EP นี้ เอาบทความเรื่อง "What Do Developers Want from AI?" จาก IEEE Software มาเล่าให้ฟังกันครับ เป็นบทความที่เขียนโดยทีมจาก Google ที่ไปสัมภาษณ์นักพัฒนาซอฟต์แวร์ที่กูเกิ้ลเพื่อทำความเข้าใจว่า จริงๆ แล้ว developers อยากได้ AI มาช่วยทำอะไรบ้าง

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

บทความ (Open Access): https://www.computer.org/csdl/magazine/so/2024/03/10493171/1VTvfCwygyk

EP นี้เล่าเรื่องเนื้อหาจากบทที่ 18 ในหนังสือ A Philosophy of Software Design เรื่อง “Code Should Be Obvious” ให้ฟังกันครับ เรามาดูว่าเราจะเขียนโค้ดอย่างไรให้มีความชัดเจน อ่านเข้าใจง่าย และหลีกเลี่ยงข้อผิดพลาดที่อาจจะเกิดขึ้นได้ โดยหนังสือในบทนี้ได้ให้ตัวอย่างทั้งแบบที่ดีและไม่ดีเอาไว้ให้ไปปรับใช้กันดูด้วย

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

Apple Podcast: https://podcasts.apple.com/th/podcast/se-corner/id1579358417 

Spotify: https://open.spotify.com/show/0hyZX5MY0khHqOY8NaEvUX 

Google: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy82MDlmZjJiYy9wb2RjYXN0L3Jzcw== 

Spotify for Podcaster: https://podcasters.spotify.com/pod/show/se-corner 

YouTube: https://www.youtube.com/@secorner9359 

Pocket: https://pca.st/5mzikb1e 

Radio Public: https://radiopublic.com/se-corner-WRm71e

EP นี้เล่าเรื่อง automated program repair ให้ฟังกันครับ พอดีมี blog จาก Replit ที่อธิบายงานวิจัยของบริษัทตัวเองที่ทำ Code Repair tool ออกมาโดยใช้ LLM มาเทรนเพิ่มบนข้อมูล error และ bug fix ที่บริษัทมีเก็บไว้ เห็นว่าน่าสนใจดีครับ นอกจากนี้ผมยังเล่าเรื่องของเทคนิค automated program repair สมัยๆ แรกมาจนถึงยุคของ LLMs อีกด้วย

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

EP นี้นำงานวิจัยล่าสุดที่เพิ่งได้รับการตอบรับตีพิมพ์ในวารสารวิชาการ Empirical Software Engineering ไปเมื่อต้นเดือนมาเล่าให้ฟังกันครับ งานวิจัยนี้ชื่อว่า "Adoption of Automated Software Engineering Tools and Techniques in Thailand" ซึ่งเราได้สำรวจนักพัฒนาในประเทศไทยจำนวน 103 คน เกี่ยวกับความรู้และการใช้งานเครื่องมือวิศวกรรมซอฟต์แวร์แบบอัตโนมัติ หรือ automated software engineering สี่ด้าน ได้แก่ software measurement, static code analysis, testing และ continuous integration

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

EP นี้สรุปเนื้อหาจากบทที่ 17 ในหนังสือ A Philosophy of Software Design เรื่อง "Consistency" ครับ โดยผู้เขียนบอกว่าการพัฒนาซอฟต์แวร์ด้วยวิธีการที่สม่ำเสมอและสอดคล้องกัน จะทำให้ความซับซ้อนของซอฟต์แวร์น้อยลง และทำให้ดูแลรักษาได้ง่ายขึ้น

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

EP นี้มาต่อที่บทความเดิมนะครับ "Software Principles" จาก IEEE Software แต่มาดูอีก 10 หลักการด้านวิศวกรรมซอฟต์แวร์ที่ไม่ได้อยู่ใน 201 รายการเดิมในหนังสือ 201 Principles of Software Development แต่ได้มาจากการสำรวจนักพ้ฒนาซอฟต์แวร์ทั่วโลก ซึ่งจากที่อ่านผมคิดว่า 10 หลักการนี้ก็สำคัญไม่แพ้กันไม่เลยครับ

ไปฟัง 10 หลักการนี้ใน EP นี้กันครับ

EP นี้หยิบบทความจาก IEEE Software เรื่อง "Software Principles" มาเล่าให้ฟังกันครับ โดยตอนนี้เป็น EP แรกและจะมีอีก EP ต่อมานะครับ ใน EP นี้เล่าให้ฟังว่า หลักการ (principle) สำคัญ 10 อย่างที่คงอยู่มานาน 30 ปีในวิศวกรรมซอฟต์แวร์มีอะไรบ้าง โดยเป็นหลักการที่เลือกมาจากหนังสือ 201 Principles of Software Development ซึ่งเขียนโดย Alan Davis ผ่านการสำรวจนักพัฒนาซอฟต์แวร์ทั่วโลก

มีหลักการอะไรที่เราควรคิดถึงบ้าง ไปฟังกันใน EP นี้ครับ

กลับมาอ่านหนังสือ A Philosophy of Software Design กันต่อใน Chapter ที่ 16 ครับ เรื่อง Modifying Existing Code โดยผู้เขียนให้หลักการสำคัญๆ หลายข้อในการแก้ไขโค้ดเดิมที่มีอยู่แล้ว แต่พยายามรักษาดีไซน์ที่ดีเอาไว้ หรือทำให้ดียิ่งขึ้นกว่าเดิม

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

ผมหยิบบทความของ Bertrand Meyer ใน CACM เรื่อง "Sensibles of Software Engineering, 1 and 2" (https://cacm.acm.org/blogs/blog-cacm/278608-sensibles-of-software-engineering-1-and-2/fulltext) มาเล่าให้ฟังกันครับ ว่าหลักคิดพื้นฐานที่จำเป็นกับทุกๆ งานในด้านวิศวกรรมซอฟต์แวร์สองข้อที่ Prof. Meyer อยากให้ทุกคนนึกถึง คืออะไร

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

บทที่ 15 จากหนังสือ A Philosophy of Software Design บอกเราว่าควรลองเขียนคอมเม้นต์ก่อนจะเขียนโค้ดดู เพราะจะทำให้เราได้คอมเม้นต์ที่ดีมีคุณภาพ อ่านง่ายขึ้น นอกจากนี้การเขียนคอมเม้นต์ก่อนเขียนโค้ดทำให้เราได้ทบทวนการออกแบบของเราและทำให้การเขียนคอมเม้นต์เป็นเรื่องสนุกขึ้นได้ครับ

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

EP นี้นำเนื้อหาจากงานศึกษาของ Google ชื่อ Project Aristotle ที่พยายามหาปัจจัยสำคัญในการสร้าง engineering team ที่มีประสิทธิภาพมาเล่าให้ฟังกันครับ Google ศึกษาทีมในบริษัทกว่า 180 ทีม และพบว่ามี 5 ปัจจัยที่สำคัญที่ทำให้ทีมทีมหนึ่งมีประสิทธิภาพสูงกว่าทีมอื่นๆ

5 ปัจจัยนั้นคืออะไร ไปฟังกันครับ

EP นี้อ่านหนังสือ A Philosophy of Software Design ในบทที่ 14 เรื่อง Choosing Names ครับ การเลือกชื่อตัวแปรให้ดี มีผลกับ Software Design เช่นกัน และชื่อตัวแปรที่ไม่ดีก็ส่งให้เกิดปัญหาในการเข้าใจหรือแม้กระทั่งบั๊กได้

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

EP นี้หยิบบทความจาก IEEE Software เรื่อง "Developer Productivity for Humans, Part 7: Software Quality" จากทีมนักวิจัยที่ Google มาเล่าให้ฟังกันครับ บทความนี้อธิบายให้เห็นว่า Software Quality อาจจะมองได้หลายมุมมองขึ้นอยู่กับว่าคนที่มองเป็นใครใน stakeholder ที่เกี่ยวข้อง ทำให้เราต้องแบ่ง Software Quality ออกเป็นสี่ด้าน ได้แก่ Process Quality, Code Quality, System Quality และ Product Quality

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

EP นี้กลับมาอ่านบทที่ 12 ในหนังสือ A Philosophy of Software Design กันต่อครับ เป็นเรื่องเกี่ยวกับการเขียนคอมเม้นต์ในโค้ด ซึ่งผู้เขียนได้ยก 4 ข้ออ้างที่พบบ่อยๆ เวลานักพัฒนาไม่อยากเขียนคอมเม้นต์มาเล่าให้ฟัง พร้อมทั้งให้ข้อโต้แย้งว่าข้ออ้างดังกล่าวมีปัญหาอย่างไร และใน EP หน้าเราจะมาดูกันว่าวิธีการเขียนคอมเม้นต์ให้ดี เป็นอย่างไรครับ

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

สวัสดีปีใหม่ 2024 ครับทุกคน! EP นี้เป็นตอนต่อจาก EP ที่แล้วที่เราคุยกันเรื่องการวัด developer productivity ที่มีรายงานจาก McKinsey ออกมาว่าสามารถหา metrics เพื่อวัด producitivity ได้แล้ว และใช้งานแล้วกว่า 20 บริษัท ใน EP นี้หยิบบทความจาก The Pragmatic Engineer ชื่อ "Measuring developer productivity? A response to McKinsey" โดย Gergely Orosz และ Kent Beck มาเล่าสรุปให้ฟังกันครับ ทั้งคู่ไม่คิดว่า metrics ที่ McKinsey เสนอจะมีประโยชน์หรือใช้ได้จริง และเสนอว่าจริงๆ แล้วเราควรวัด developer productivity อย่างไรกันแน่

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

บทความ: https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity

EP สุดท้ายส่งท้ายปี 2566 ขอเป็นเรื่องเกี่ยวกับ developer productivity ครับ ใน EP นี้หยิบรายงานจาก McKinsey เรื่อง "Yes, you can measure software developer productivity" และ feedback ที่ตามมาจากรายงานนี้ใน software developer community มาเล่าให้ฟังกัน เนื้อหาน่าสนใจมากๆ ครับ

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

รายงานจาก McKinsey: https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/yes-you-can-measure-software-developer-productivity#/

LinkedIn Post ของ Kent Beck: https://www.linkedin.com/posts/kentbeck_mckinsey-claims-its-possible-to-measure-activity-7099764438496407552-v8P2/

EP นี้พามาอ่านต่อบทความเรื่อง "Survey reveals AI’s impact on the developer experience" จาก GitHub ในส่วนที่สอง ว่าการใช้ AI Coding Tools เช่น GitHub Copilot จะสามารถช่วยเพิ่ม developer experience ได้อย่างไรบ้าง

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

ผลการสำรวจ: https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience

Developer Experience หรือ DevEx เป็นเรื่องที่องค์กรซอฟต์แวร์กำลังให้ความสำคัญกันครับ EP นี้จะพาไปดูผลการสำรวจ Developer กว่า 1,000 คนจาก 500 บริษัทในสหรัฐอเมริกา ว่า Developer อยากได้อะไร และตรงกับที่องค์กรให้เค้าอยู่ในปัจจุบันหรือไม่ครับ

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

ผลการสำรวจ: https://github.blog/2023-06-13-survey-reveals-ais-impact-on-the-developer-experience

EP นี้หยิบผลของ Wrapped 2023 for Podcaster ของ Spotify มาเล่าให้ฟังกันครับ ปีนี้ผลลัพธ์ออกมาดีเลยทีเดียวครับ ไม่ว่าจะเป็นจำนวนผู้ฟังที่เพิ่มมากขึ้น จำนวนแฟนที่ติดตามก็เพิ่มมากขึ้น ทำให้มีกำลังใจที่จะทำต่อไปเรื่อยๆ เลยครับ :-)

ไปฟังรายละเอียดของผล Wrapped 2023 ของ SE Corner กันใน EP นี้นะครับ

EP นี้หยิบบทความจาก IEEE Spectrum เรื่อง "How Coders Can Survive—and Thrive—in a ChatGPT World" มาเล่าให้ฟังกันครับ ในโลกที่ ChatGPT เข้ามามีบทบาทสำคัญในการพัฒนาซอฟต์แวร์และดูเหมือนมันก็จะเก่งขึ้นเรื่อยๆ ด้วย นักพัฒนาซอฟต์แวร์อย่างเราจะทำอย่างไรเพื่อให้เราอยู่รอดและเติบโตขึ้นได้ในยุคแห่ง AI แบบนี้ บทความนี้จะเล่าให้ฟังกันครับ

บทความ: https://spectrum.ieee.org/ai-programming

EP นี้กลับมาอ่านหนังสือ A Philosophy of Software Design กันต่อใน Chapter 11 เรื่อง "Design in Twice" ครับ Prof. Ousterhout บอกว่าการออกแบบซอฟต์แวร์ เป็นงานที่ต้องคิดหลายๆ รอบ ค้นหาความเป็นไปได้หลายๆ แบบ เปรียบเทียบกัน จะทำให้ได้ผลลัพธ์ที่ดีและประหยัดเวลาในระยะยาวได้มากกว่า

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

EP นี้หยิบบทความจาก IEEE Software เรื่อง Generative AI for Software Practitioners โดยคุณ Christof Ebert และคุณ Panos Louridas มาเล่าให้ฟังกันครับ เราไปดูกันว่า Generative AI จะมาช่วย software developers ได้อย่างไรบ้าง ทั้งตอนนี้และในอนาคต รวมถึงเราจะต้องพัฒนาตัวเองอย่างไรหากการเขียนโค้ดไม่ใช่เรื่องที่มีแค่มนุษย์ทำได้เท่านั้นแล้ว

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

EP นี้หยิบชวนคุยเรื่องความนิยมที่ลดลงของ Stack Overflow ซึ่งสวนทางกับความนิยมที่เพิ่มขึ้นของ Copilot และ ChatGPT โดยอ้างอิงจากบทความเรื่อง "ChatGPT vs. CoPilot: Is Stack Overflow Losing Its Charm in the Age of AI?" ของคุณ Amit Kumar

ในช่วงระยะเวลาที่ Copilot และ ChatGPT เปิดตัวมา Stack Overflow มีจำนวน traffic ลดลงอย่างต่อเนื่อง แถมตอนนี้ยังมีนโยบายแบนการตอบคำถามด้วย AI อีก หรือว่าสถานการณ์ของ Stack Overflow จะไม่ค่อยดีซะแล้ว

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

บทความ: https://medium.com/data-arena/chatgpt-or-copilot-is-stackoverflow-becoming-old-school-in-the-new-ai-era-2195024f3098

EP นี้กลับมาอ่านหนังสือ A Philosophy of Software Design ใน Chapter ที่ 10 เรื่อง Define Errors Out Of Existence ที่ผู้เขียนพยายามโน้วน้าวให้เห็นว่า การจัดการกับ exception เป็นต้นเหตุหนึ่งของความซับซ้อนของซอฟต์แวร์ และแนะนำสี่หลักการในการบริหารจัดการ exception ให้โค้ดของเราซิมเปิ้ลและบริหารจัดการง่ายที่สุด

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

EP นี้มาคุยต่อเรื่อง pair programming จากบทความ “On Pair Programming” ครับ เป็นตอนที่เราจะมาคุยเรื่องประโยชน์และความท้าทายในการทำ pair programming ว่ามีอะไรบ้าง และมีวิธีการใดบ้างที่เราจะลดหรือหลีกเลี่ยงปัญหาที่อาจจะเกิดขึ้นได้

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

บทความ: https://martinfowler.com/articles/on-pair-programming.html?utm_source=pocket_saves

EP นี้ชวนคุยต่อเรื่องการทำ pair programming ครับ โดยผมหยิบบทความจาก martinfowler.com เรื่อง "On Pair Programming" โดย Birgitta Böckeler และ Nina Siessegger มาเล่าให้ฟังกัน โดยบทความนี้เป็นตอนที่ 1 ที่จะอธิบายให้ฟังว่าเราควรจะทำ pair programming อย่างไร โดยเร่ิมจากสไตล์ในการทำ pair programming, mindset ที่ต้องมี, รวมถึงส่ิงที่ควรหลีกเลี่ยงในขณะที่ทำ pair programming ครับ

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

บทความ: https://martinfowler.com/articles/on-pair-programming.html?utm_source=pocket_saves

EP นี้หยิบเรื่อง Green IT และ Green Software ที่น่าจะกลายเป็นเทรนด์ใหม่ของโลกในเร็วๆ นี้มาเล่าให้ฟังกันครับ จากบทความใน IEEE Software ที่ชื่อ "Green IT and Green Software" ที่อธิบายว่าในอนาคตจะมีการเปลี่ยนแปลงสำคัญสามครั้ง (paradigm shifts) ที่จะส่งผลให้ Green IT และ Green Software มีความสำคัญมากขึ้นเรื่อยๆ และยกตัวอย่างแนวทางว่านักพัฒนาซอฟต์แวร์อย่าเราจะทำอะไรได้บ้างเพื่อช่วยรักษ์โลกของเรา

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

EP นี้กลับมาอ่าน Chapter 9 ของหนังสือ A Philosophy of Software Design นะครับ เรื่อง Better Together Or Better Apart? ซึ่งให้คำแนะนำว่าถ้าเรามีโค้ดที่เราไม่แน่ใจว่า ควรจะเก็บไว้ด้วยกันหรือแยกมันออกเป็นส่วนย่อยๆ จะดีกว่า เราควรจะดูที่ว่า หากรวมหรือแยกแล้วทำให้ complexity ลดลงหรือไม่ครับ

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

EP นี้ผมชวนไปฟังบทสัมภาษณ์คุณศราวุทธ์ แสงอรุณ Head of Automation Engineering ที่ Krungsri Nimble กันครับ ตอนแรกตั้งใจสัมภาษณ์ให้นักศึกษาวิชา Software Quality Assurance and Testing ที่สอนอยู่ฟัง แต่คิดว่ามีประโยชน์มาก เลยนำมาเผยแพร่ให้ฟังกันทางนี้ด้วยครับ เราคุยกันเรื่อง Software quality, QA roles and skills และ career path ของ QA ครับ

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

EP นี้หยิบเอาบทความเรื่อง "Pair Programming: Best Practices and Tools" มาเล่าให้ฟังกันครับ ผมคิดว่า pair programming น่าจะเป็นหลักการที่ยังใช้กันไม่แพร่หลายนักในประเทศไทย แต่มีบริษัทขนาดใหญ่บางบริษัทที่ใช้อยู่เป็นประจำ (เช่น Thoughtworks เท่าที่เคยได้ยิน) ใน EP นี้มาดูกันว่า pair programming คืออะไร มีประโยชน์อย่างไร ความเข้าใจผิดๆ เกี่ยวกับเรื่องนี้มีอย่างไรบ้าง และวิธีการที่จะทำ pair programming ให้ดีมีอะไรบ้างครับ

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

บทความ: https://dev.to/documatic/pair-programming-best-practices-and-tools-154j

EP นี้ยังอยู่กับหนังสือ A Philosophy of Software Design ใน Chapter 8 เรื่อง Pull Complexity Downwards กันครับ ผู้เขียนบอกว่าเวลาเราเขียนโมดูลใดๆ แล้วเจอกับจุดที่ยากๆ ต้องตัดสินใจหรือกำหนดค่าใดๆ เราควรจะต้องพยายามที่สุดที่จะจัดการความยากเหล่านั้นภายในโมดูลเอง แทนที่จะโยนออกไปให้คนที่ใช้งานต้องเป็นคนตัดสินใจหรือรับผิดชอบ ซึ่งการทำแบบนี้จะทำให้โมดูลเรา deep ขึ้น แต่ interface มันง่ายลง และใช้งานง่ายขึ้นครับ

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

EP นี้อ่านหนังสือ A Philosophy of Software Design ใน Chapter 7 เรื่อง Different Layers, Different Abstraction กันครับ ผู้เขียนยกปัญหาอีกเรื่องที่มักพบได้บ่อยในการพัฒนาซอฟต์แวร์ คือ โค้ดที่เขียนในคนละชั้น (layer) ของการทำงาน แต่กลับมี abstraction (ตัวอย่างเช่น รูปแบบลักษณะการทำงาน การมองข้อมูล) ที่เหมือนกัน โดยผู้เขียนแบ่งเป็น 4 รูปแบบ พร้อมแนะนำวิธีการป้องกันหรือแก้ไขปัญหาเหล่านี้มาให้ด้วยครับ จะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ Apple Podcast: https://podcasts.apple.com/th/podcast/se-corner/id1579358417 Spotify: https://open.spotify.com/show/0hyZX5MY0khHqOY8NaEvUX Google: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy82MDlmZjJiYy9wb2RjYXN0L3Jzcw== Spotify for Podcaster: https://podcasters.spotify.com/pod/show/se-corner YouTube: https://www.youtube.com/@secorner9359 Pocket: https://pca.st/5mzikb1e Radio Public: https://radiopublic.com/se-corner-WRm71e

EP นี้หยิบบทความจาก IEEE Software เรื่อง "The Next Frontier in Software Development: AI-Augmented Software Development Processes" มาเล่าให้ฟังกันครับ คุณ Ipek Ozkaya ซึ่งเป็นบรรณาธิการวารสาร IEEE Software ได้ให้ความเห็นว่าการทำงานที่เป็น AI-Augmented Software Development หรือมีเครื่องมือ AI มาช่วยในการพัฒนาซอฟต์แวร์นั้น อาจจะยังไม่ใช่จุดเปลี่ยนสำคัญ เพราะเครื่องมือเหล่านี้มีมาอย่างต่อเนื่องยาวนานก่อนยุคของ LLMs เช่น ChatGPT หรือ GitHub Copilot แต่ต้องเป็นการเปลี่ยนแปลงกระบวนการพัฒนาซอฟต์แวร์ (software development process) จึงจะทำให้มีการเปลี่ยนแปลงขนาดใหญ่ (ระดับ X10 ได้จริงๆ ครับ)

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

บทความ: https://www.computer.org/csdl/magazine/so/2023/04/10176194/1OAJtH6yQak

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

EP นี้หยิบเรื่องของ Large Language Models (LLMs) ที่เข้ามาใกล้ตัวนักพัฒนาซอฟต์แวร์ขึ้นเรื่อยๆ เพราะสามารถนำมาใช้ช่วยในการเขียนซอฟต์แวร์ได้แล้วในปัจจุบัน บทความเรื่อง "Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications" ของคุณ​ Ipek Ozkaya หยิบประเด็นที่น่าสนใจถึงความเสี่ยงที่เราควรนึกถึง และโอกาสที่เราจะได้ประโยชน์จาก LLM เหล่านี้มีอะไรบ้าง

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