SE CORNER

SE CORNER

By Chaiyong RagkhitwetsagulTechnology
Download on the App Store

SE CORNER episodes

  • EP136 - แก้ไขโค้ดเดิมอย่างไรให้ design ไม่แย่ลง? - สรุปจากหนังสือ A Philosophy of Software Design

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

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

    9 min
  • EP135 - หลักคิดพื้นฐานสองข้อของ Software Engineering

    ผมหยิบบทความของ 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 นี้ครับ

    6 min
  • EP134 - มาลองเขียน comment ก่อนเขียนโค้ดกัน - สรุปจากหนังสือ A Philosophy of Software Design

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

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

    9 min
  • EP133 - 5 ปัจจัยในการสร้าง engineering ทีมที่มีประสิทธิภาพ

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

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

    11 min
  • EP132 - คิดให้ดีก่อนตั้งชื่อตัวแปรสักตัวหนึ่ง - สรุปจากหนังสือ A Philosophy of Software Design

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

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

    9 min
  • EP131 - Software Quality ในมุมของ Google คืออะไร?

    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 นี้ครับ

    13 min
  • EP130 - คำแนะนำการเขียน Code Comment ที่ดี - สรุปจากหนังสือ A Philosophy of Software Design
    EP นี้มาต่อกันที่ Chapter 13 จากหนังสือ A Philosophy of Software Design เรื่องการเขียนโค้ดคอมเม้นต์ที่ดีครับ โดยหนังได้ให้คำแนะนำว่าคอมเมนต์นั้นควรจะอธิบายส่ิงที่โค้ดไม่สามารถอธิบายได้ เช่น เหตุผลในการตัดสินใจบางอย่างของนักพัฒนา และหนังสือให้คำแนะนำในการเขียนคอมเม้นต์ใน 3 ระดับ คือ interface, implementation, และ cross-module documentation
    รายละเอียดไปฟังกันใน 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
    12 min
  • EP129 - 4 ข้ออ้างของ Developers เวลาไม่อยากเขียน Code Comment - สรุปจากหนังสือ A Philosophy of Software Design

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

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

    11 min
  • EP128 - McKinsey บอกว่าหาวิธีวัด Developer Productivity ได้แล้ว? (ตอน 2)

    สวัสดีปีใหม่ 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

    20 min
  • EP127 - McKinsey บอกว่าหาวิธีวัด 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/

    17 min

About SE CORNER

From the publisher's feed

SE Corner "มุมซอฟต์ๆ ของวิศวกรรมซอฟต์แวร์" โดย ชัยยงค์​ รักขิตเวชสกุล