SE CORNER

SE CORNER

By Chaiyong RagkhitwetsagulTechnology
Download on the App Store

SE CORNER episodes

  • EP46 - Case study การบริหารจัดการ documentation ที่ Google

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

    Riona MacNamara ที่ป็น Google g3doc lead แล้วเอามาเล่าให้ฟังใน EP นี้แทนครับ 

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

    9 min
  • EP45 - กระบวนการ Code Review ที่ Google - คำแนะนำจากหนังสือ Software Engineering at Google

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

    1. Code review ที่ Google จะต้องมีการตรวจสอบสามอย่าง คือ correctness (ความถูกต้อง), comprehension (ความเข้าใจง่าย ), และ consistency
    2. บางครั้ง ทั้งสามอย่างมีใน reviewer คนเดียว
    3. Code review ช่วยทำให้เกิด shared ownership ของโค้ดร่วมกันภายในทีม
    4. Code review ช่วยทำให้เกิดการแบ่งปันควารู้ภายในทีม
    5. Change ที่จะมารีวิวไม่ควรใหญ่มาก (ไม่เกิน 200 lines)

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

      17 min
    6. EP44 - ลด Tech Debt ด้วยการสร้าง Tech Wealth

      เราน่าจะรู้จักหนี้ทางเทคโนโลยี 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 นี้ครับ

      8 min
    7. EP43 - เขียน requirements ให้ดีขึ้นได้ ด้วยเทคนิค EARS
      EP นี้พาไปรู้จักกับเทคนิคการเขียน requirements ที่ดีและถูกใช้กันอย่างแพร่หลาย ชื่อว่า EARS (Easy Approach to Requirements Syntax) ซึ่งถูกสร้างขึ้นโดย Alistair Mavin และมีแพทเทิร์นการเขียนที่สำคัญ 5 แบบ คือ
      1. Ubiquitous requirements
      2. State-driven requirements
      3. Event-driven requirements
      4. Optional feature requirements
      5. Unwanted behaviour requirements
      หากเราเขียนให้ดี requirements ทุกอันจะสามารถเลือกให้เข้ากับแพทเทิร์นใดแพทเทิร์นหนึ่งในห้าแบบนี้ได้เสมอ และจะทำให้ requirements ของเรา สั้น กระชับ เข้าใจง่าย และไม่กำกวม
      รายละเอียดจะเป็นอย่างไร ไปฟังกันใน EP นี้ครับ
      12 min
    8. EP42 - โค้ดจาก GitHub Copilot ดีแค่ไหน?

      EP นี้หยิบงานวิจัยใหม่เอี่ยมจาก Mining Software Repositories (MSR '22) ชื่อ "An Empirical Evaluation of GitHub Copilot’s Code Suggestions" โดย Nhan Nguyen and Sarah Nadi จาก University of Alberta มาเล่าให้ฟังกันครับ ทีมวิจัยนี้ศึกษาความถูกต้องและความเข้าใจง่าย (understandability) ของโค้ดที่แนะนำมาจาก GitHub Copilot โดยได้ใช้ตัวอย่างคำถาม 33 คำถามจาก LeetCode ซึ่งเป็น website สำหรับฝึกฝนการเขียนโปรแกรม และให้ Copilot สร้างคำตอบใน 4 ภาษา ได้แก่ภาษา Python, ภาษา Java, ภาษา Javascript และภาษา C

      ทีมวิจัยพบว่าในแง่ของความถูกต้อง คำตอบของ Copilot ในภาษา Java นั้นถูกต้องมากที่สุด (ผ่าน test cases ทั้งหมดใน LeetCode 100%) จำนวน 57% ของคำตอบทั้งหมด ตามมาด้วย Python (42%), C (39%) แต่ Javascript ทำได้ไม่ดีนักที่ 27%

      ในแง่ของความเข้าใจง่าย ทีมวิจัยใช้ค่า cognitive complexity กับ cyclomatic complexity ของโค้ดที่ Copilot แนะนำให้เป็นคำตอบ ผลพบว่าโค้ดจาก Copilot ส่วนใหญ่มีค่า complexity ต่ำ หรือเข้าใจได้ง่ายนั่นเอง

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

      12 min
    9. EP41 - เพิ่ม Developer Experience (DX) ได้ ถ้าเข้าใจตรงจุด

      EP นี้ชวนคุยเรื่อง developer experience หรือ DX ครับ คุณ Jean Yang เจ้าของบริษัท Akita ให้ความเห็นว่าต่อไปในอนาคต DX จะมีส่วนสำคัญอย่างมาก เพราะจำนวน developers ในโลกนี้เพิ่มขึ้นเรื่อยๆ (ตอนนี้มีจำนวนมากกว่าคนออสเตรเลียทั้งประเทศ!) เราจะสร้าง developer tools ที่ดีอย่างไร? เพื่อให้นักพัฒนามี DX ที่ดี และมีความสุขระหว่างการทำงาน

      เธอบอกว่านักพัฒนาซอฟต์แวร์จะต้องเจอกับซอฟต์แวร์ที่ซับซ้อนขึ้นเรื่อยๆ และเครื่องมือที่จะช่วยได้ดีที่สุด คือ เครื่องมือที่ทำให้พวกเขาเข้าใจความซับซ้อนของซอฟต์แวร์ได้มากขึ้น เครื่องมือเหล่านี้จะต้องเข้ากับ workflow และเครื่องมืออื่นๆ ที่ใช้ได้เป็นอย่างดี รวมถึงช่วยในการ package software และจัดลำดับความสำคัญของผลลัพธ์ที่อยากจะดูได้

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

      12 min
    10. EP40 - Coding Style สำคัญอย่างไร? (ตอนที่ 2) - คำแนะนำจากหนังสือ Software Engineering at Google

      EP นี้ไปอ่านบทที่ 8 ของหนังสือ Software Engineering at Google กันต่อ มาดูกันว่า Google สร้าง Style Guide ขึ้นมาจากหลักการทั้ง 5 ที่กล่าวไปก่อนหน้าได้อย่างไร? กฎทั้งหลายใน Style Guide สามารถเปลี่ยนได้หรือไม่และมีวิธีการอย่างไร? การนำกฎไปใช้ นำไปใช้ตอนไหนและใช้อย่างไร?

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

      16 min
    11. EP39 - Coding Style สำคัญอย่างไร? - คำแนะนำจากหนังสือ Software Engineering at Google

      EP นี้กลับมาอ่านหนังสือ Software Engineering at Google ต่อ ในบทที่ 8 "Style Guides and Rules" ที่พูดถึงเรื่องการกำหนดแนวทางการเขียนโค้ดในบริษัทกูเกิ้ล EP จะเป็นตอนที่ 1 ที่พูดถึงหลักการสำคัญ 5 ประการในการกำหนด coding styles and guides ซึ่งได้แก่

      1. Pull their weight - styles guide ควรมีแค่สิ่งที่สำคัญและจำเป็นจริงๆ
      2. Optimize for the reader - style guide ควรคำนึงถึงผู้อ่านมากกว่าผู้เขียนโค้ด
      3. Be consistent - style guide ควรทำให้โค้ดมีความสม่ำเสมอ ตรงกัน 
      4. Avoid error-prone and surprising constructs - style guide ควรทำให้นักพัฒนาหลีกเลี่ยงการใช้ code ที่ทำให้เกิดปัญหาหรือความเข้าใจผิดได้ง่าย
      5. Concede to practicalities when necessary - หากจำเป็นจริงๆ ก็สามารถแหกกฎบางส่วนได้ เช่น เพื่อ performance หรือเพื่อการรองรับแพลตฟอร์มที่หลากหลาย

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


        Google coding style guide: https://google.github.io/styleguide/

        17 min
      6. EP38 - "To Microservices and Back Again" เมื่อไมโครเซอร์วิสไม่ตอบโจทย์

        EP นี้หยิบบทความเรื่อง "To Microservices and Back Again - Why Segment Went Back to a Monolith" ซึ่งเล่าตัวอย่าง case study ของบริษัท Segment ที่เคยพยายามจะแก้ปัญหา Environment Isolation ของซอฟต์แวร์ตนเองด้วยไมโครเซอร์วิส แต่สุดท้ายกลับพบว่าเจอปัญหาที่บริหารจัดการได้ยากกว่าเก่า และสุดท้ายเลือกที่จะกลับมาใช้สถาปัตยกรรมแบบ Monolith อีกครั้งหนึ่ง

        ปัญหาเริ่มต้นคืออะไร ทำไมย้ายไปไมโครเซอร์วิสแล้วไม่เวิร์ค ไปฟังกันใน EP นี้ครับ

        9 min
      7. EP37 - Code Review เมื่อส่ิงที่หวัง กับ สิ่งที่ได้ อาจจะไม่ตรงกัน

        EP นี้หยิบงานวิจัยที่เก่าหน่อยแต่ยังมีประโยชน์อยู่มาเล่าให้ฟังกันครับ เป็นงานวิจัยของ Alberto Bacchelli และ Christian Bird ที่ Microsoft ชื่อว่า "Expectations, Outcomes, and Challenges Of Modern Code Review" ซึ่งเป็นงานวิจัยที่ศึกษาจากนักพัฒนาของไมโครซอฟต์และพยายามเข้าใจ 3 อย่าง คือ (1) ความคาดหวังจากการทำ code review, (2) ผลที่ได้จากการทำ code review และ (3) ปัญหาหรือความท้าทายในกระบวนการ code review

        ส่วนใหญ่ทุกคนน่าจะคิดว่าการทำ code review มีเป้าหมายหลักอยู่ที่การหาบั๊กในโค้ดที่เขียนขึ้นใหม่หรือโค้ดที่ถูกแก้ไข นักพัฒนาที่ไมโครซอฟต์ก็คิดแบบนั้น แต่ผลลัพธ์ที่ได้จริงกลับพบว่าการหาบั๊กไม่ใช่ผลลัพธ์อันดับแรกๆ แต่กลับเป็น code improvement หรือการปรับปรุงการเขียนโค้ด 

        ทำไมสิ่งที่หวังกับสิ่งที่ได้จึงไม่ตรงกัน? ไปหาคำตอบใน EP นี้ครับ

        อ่านงานวิจัยฉบับเต็ม: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/ICSE202013-codereview.pdf

        13 min

      About SE CORNER

      From the publisher's feed

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