[KBTG-GO#01] Introduction

Blog นี้เขียนมาจดอะไรนิดหน่อยๆ เผื่อลืมครับ สำหรับ Week แรกของ GO จะเรียนเรื่อง Git & Collaboration โดยผมจดมาประมาณนี้

Git

เหมือนจะมีเขียน Blog ไว้ เอาของเดิมแปะไปก่อน

• How to setup GIT with SSH Authenication | naiwaen@DebuggingSoft
• Git Command 101 | naiwaen@DebuggingSoft

แต่ที่ฟังๆมา มี History ที่น่าสนใจนะ ตอนแรกเข้าใจว่าก่อนจะมี Git ตัดแปะไฟล์ไปๆมาๆ แล้วมี Git มาแก้ปัญหาเลย ทว่าที่มีของ Git เรียกว่ายังไงดี มาจากดราม่าตอนทำ Linux Kernel จะใช้ตัว BitKeeper แต่มันไม่ได้เป็น Open-Source ดังนั้น linus torvalds เลยสร้างเองซะเลย

Branching Strategy / Workflow

พยายามเน้นตัว Short Live-Branch + Engineerinng Practices ที่ดีพวก Test / Design มาช่วย

Pattern ที่นิยมกันมี

• Trunk Based เหมาะสำหรับ
  - ทีมมี Skill เท่ากัน และจำนวนน้อย
  - Short Live-Branch ปกติอายุหลักวัน เน้นทำ feature toggle + Engineerinng Practices ที่ดีพวก Test เพื่อให้มั่นใจ Quality
  - review code ตอนไหน ? > pair programming ตอน code + discuss ตอนนั้น
• Git Flow เหมาะสำหรับ
  - ทีมมี Skill ไม่เท่ากัน และทีมงานจำนวนเยอะ
  - มีการพัฒนาที่ซับซ้อน และมียอมให้มี Short Live-Branch ที่นานกว่าปกติ
  - แยก Branch main (build stable) / develop / release / bugfix / support / feature เป็นต้น
  - มี Flow Review ที่ชัดเจน

ผมเองมี Flow ที่เอามาปรับใช้นะ มาตามดูได้ใน Blog [GIT] แบ่งปัน Git Flow ที่ได้ใช้งานจริง
ปล. ล่าสุดระยะ Release Branch จาก 1 เดือน เหลือ 1 Week และ

• GitHub Flow มาลดความซับซ้อนของ Git Flow ลง
  - มี Branch main (build stable)
  - Branch feature - Short Live ไม่ได้ถี่มาก อายุยาวนานขึ้น แต่ไม่เท่ากับ Git Flow เอามาแก้ไข และทดสอบ deploy
  - ทำเสร็จ เปิด PR / MR เข้า main

feature toggle

ใช้เปิด-ปิด Feature ให้พร้อมตอน Deploy โดยตัวอย่าง เช่น mobile มันมีขั้นตอนการตรวจที่ซับซ้อนกว่า web เพราะมี review จาก IOS/ Android เป็นปัจจัยที่ทำให้ release feature ช้าได้ และใช้ api เดวกัน ด้วย ถ้าเปิด-ปิด Feature จะสะดวกกว่า

• ข้อดี ลด flow ที่ซับซ้อน ลด Long Live Branch แตกที่แยก Brach Deploy ทำ Config คุมไว้แทน แล้ว Release ตามเงื่อนไข และ Roll Back ได้แก้ Config
• ข้อเสีย ระวัง Logic ตัว Technical Debt นั้นเอง นานไปแล้วคนจะงงด้วย + Performance / Feature หลุด

Pair programming

• Ping-pong style
  - สลับกันเขียน โดยจะไปในแนว TDD คนแรกเขียนเทส คนที่สองมาเขียนต่อ
• Driver/navigator style
  - Driver คน Code
  - navigator คน มองภาพรวม

Key: Pair rotation ทำให้เกิด knowledge transfer

Sensible Default

• ปรับ Enviroment ให้มัน Engineerig Practice ที่เข้าใจตรงกัน พวก Cross Functional Team / Platform Engineering
• pre-define เพื่อให้ทัมเลือก ใช้ ช่วยเรื่อง Unit Test / Argon2 /Dev Style ลดเวลา switching maintenance
• Architecture Dezion Record (ADRs) Why Decision ให้คนรู่นหลังรู้ว่า Gen แรกคิดยังไง

Generative AI

• เอามาช่วยงานด้วย Coding หรือ จะใช้ prompt มาช่วยสร้าง Assets ICON / Web Image เป็นต้น หรือเป็นการด้าน System Design / Prototype ได้
• แต่ระวัง ถ้า Fundamental เราไม่ดี อาจจะหลุด Maintainability / Security / Bias ref lib //ตอนผมใช้ GitHub Copilot ก็เจอ รวมถึงด้านจริยธรรม
• Tools Codeium / GitHub Copilot