UncleQuin

PlanktonSoft

Software & Developer Podcast

  1. สถาปัตยกรรมแบบเติบโตตามธรรมชาติ: ปรัชญา Write First, Organize Later ในโลกของโค้ด EP.36

    1 day ago

    สถาปัตยกรรมแบบเติบโตตามธรรมชาติ: ปรัชญา Write First, Organize Later ในโลกของโค้ด EP.36

    ในวงการพัฒนาซอฟต์แวร์ เรามักถูกสอนให้วางแผนทุกอย่างให้ "เป๊ะ" ตั้งแต่วันแรก ต้องวาด UML Diagram ให้สมบูรณ์แบบ และออกแบบ Database Schema ให้รองรับอนาคตไปอีก 5 ปี... แต่ความจริงที่หลีกเลี่ยงไม่ได้คือ ยิ่งเราพยายามสร้างโครงสร้างที่สมบูรณ์แบบมากเท่าไหร่ ระบบของเราก็ยิ่งเปราะบาง (Fragile) และพังทลายง่ายขึ้นเมื่อ Requirement ทางธุรกิจเปลี่ยนทิศทาง EP.36 นี้ ลุงควิน และ คุณเมย์ (Senior PM) จะพาคุณก้าวออกจากกรอบคิดแบบ Big Design Up Front ไปสำรวจปรัชญาการจัดการความรู้ (Knowledge Management) สไตล์ Utility-first ที่เน้นการ "จดไปก่อน ค่อยจัดระเบียบทีหลัง" (Write First, Organize Later) เราจะนำแนวคิดจากเครื่องมืออย่าง Obsidian มาสกัดเป็นสถาปัตยกรรมซอฟต์แวร์ระดับโลกอย่าง Event Sourcing และ CQRS เพื่อสร้างระบบที่ยืดหยุ่นและเติบโตได้ตามธรรมชาติของพฤติกรรมผู้ใช้งานจริง 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Illusion of Perfect Design: ภาพลวงตาของการออกแบบที่สมบูรณ์แบบ ทำไมการพยายามควบคุมโครงสร้างล่วงหน้าถึงกลายเป็นกรงขังทีมพัฒนาเสียเอง Write First, Organize Later: การปรับ Mindset จากการยึดติดกับ "โฟลเดอร์" มาสู่การบันทึก "ความจริงระดับอะตอม" แล้วปล่อยให้โครงสร้างงอกเงยจากการใช้งานจริง (Self-Organization) Event Sourcing & CQRS: เมื่อซอฟต์แวร์จำลองพฤติกรรมสมุดบัญชีธนาคาร บันทึกแค่เหตุการณ์ดิบ (Raw Events) ที่เกิดขึ้น แล้วค่อยนำข้อมูลมาจัดระเบียบเป็นหน้าตาใหม่ (Projection) ในอนาคต Stoic Architecture: ปรัชญาการยอมรับความไม่รู้ (Embrace Ignorance) และการปล่อยวางจากการพยายามควบคุมอนาคตที่เราควบคุมไม่ได้ "สถาปัตยกรรมที่ยั่งยืน ต้องเป็นสถาปัตยกรรมที่ยอมรับในความไม่รู้... ปล่อยให้โครงสร้างเติบโตจากพฤติกรรม อย่าให้พฤติกรรมถูกจำกัดด้วยโครงสร้างที่ตายตัว"

    9 min
  2. โศกนาฏกรรมของพื้นที่ส่วนกลาง: จัดการ Shared State อย่างไรไม่ให้ระบบและคนตีกันตาย EP.35

    5 days ago

    โศกนาฏกรรมของพื้นที่ส่วนกลาง: จัดการ Shared State อย่างไรไม่ให้ระบบและคนตีกันตาย EP.35

    ในโลกอุดมคติของ Microservices เราใฝ่ฝันถึงสถาปัตยกรรมที่ทุกทีมและทุกเซอร์วิสมีฐานข้อมูลแยกขาดจากกัน (Stateless) แต่โลกความเป็นจริงไม่เคยง่ายดายเช่นนั้น... ธุรกิจล้วนมี "จุดตัด" ที่ต้องใช้ทรัพยากรร่วมกันเสมอ และจุดตัดนั้นคือบอสใหญ่ที่สร้างความปวดหัวให้กับทุกคน นั่นคือ “Shared State” จะเกิดอะไรขึ้นถ้าระบบ Sharing Grocery ในชุมชน มีคน 3 คนพุ่งเข้ามากดแย่ง "กะหล่ำปลีออร์แกนิก 1 หัวสุดท้าย" ในเสี้ยววินาทีเดียวกัน? หากระบบขาดกลไกควบคุมที่รัดกุม ความโกลาหลที่เรียกว่า Race Condition จะบังเกิด และระบบจะโกหกเราด้วยการเสกกะหล่ำปลีทิพย์ขึ้นมา! EP.35 นี้ ลุงควิน และ คุณเมย์ (Senior PM) จะพาไปสำรวจวิธีกำราบโศกนาฏกรรมของพื้นที่สาธารณะ (The Tragedy of the Commons) ในโลกของโค้ด ผ่านเลนส์ปรัชญาการจัดระเบียบอำนาจของ Michel Foucault ผสานกับเทคนิคขั้นสุดยอดจาก Systems Programming 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Illusion of Stateless: ทำไมระบบซอฟต์แวร์ที่แท้จริงถึงหลีกเลี่ยง Shared State ไม่ได้ และเคสศึกษาความพังพินาศจาก Race Condition คุก Panopticon กับ Mutex: การประยุกต์ใช้แนวคิดหอคอยจัดระเบียบของ Foucault มาอธิบายกลไกการล็อกบัตรคิวในภาษา Rust เพื่อเปลี่ยนความโกลาหลให้เป็นระเบียบแถวเรียงเดี่ยว พิสูจน์ความจริงด้วย Type System: ก้าวไปอีกขั้นด้วยการฝัง "อุปนัยเชิงคณิตศาสตร์" (Mathematical Induction) ลงใน Scala เพื่อบังคับให้ Compiler พิสูจน์ความถูกต้องของการเปลี่ยนสถานะตั้งแต่ก่อนรันโปรแกรม Stoic Architecture: ปรัชญาการปล่อยวางสิ่งที่เราควบคุมไม่ได้ (Shared State ภายนอก) และหันกลับมาสร้างปราการที่แข็งแกร่งที่สุดให้กับสิ่งที่เราควบคุมได้ (Local State) "วาทกรรมคือตัวกำหนดความจริง... ในโลกของซอฟต์แวร์ Type System ที่ถูกออกแบบอย่างรัดกุมด้วยคณิตศาสตร์ คือวาทกรรมที่ทรงพลังที่สุดในการสร้างระบอบแห่งความจริงที่เชื่อถือได้"

    8 min
  3. ใครคือเจ้าของความจริง? ถอดรหัส Ownership และอำนาจของข้อมูลในระบบที่กระจัดกระจาย (Shared State in Squads) EP.34

    30 Jun

    ใครคือเจ้าของความจริง? ถอดรหัส Ownership และอำนาจของข้อมูลในระบบที่กระจัดกระจาย (Shared State in Squads) EP.34

    ต่อท่อ API กันเสร็จแล้ว... แต่ปัญหาใหม่ที่ชวนปวดหัวระดับมหากาพย์คือ "แล้วตกลงข้อมูลก้อนนี้ ใครเป็นเจ้าของ?" เมื่อระบบถูกจับแยกย่อยเป็น Squads แบบ Microservices แต่ดันมี Shared State (ข้อมูลส่วนกลาง เช่น โปรไฟล์ลูกค้า หรือ สถานะตะกร้าสินค้า) ที่ทุกทีมอยากรุมเข้ามาอ่านและเขียนพร้อม ๆ กัน จนเกิดปัญหาข้อมูลตีกัน (Race Condition) และลงเอยด้วย "โศกนาฏกรรมของพื้นที่สาธารณะ (The Tragedy of the Commons)" ที่พอระบบพังก็ไม่มีใครยอมรับเป็นเจ้าภาพ! EP.34 นี้ ลุงควิน และ คุณเมย์ (Senior PM) จะพาคุณไปถอดรหัสการจัดการ "ความจริง" ในองค์กร โดยผสานโลกของสถาปัตยกรรมซอฟต์แวร์ระดับลึก (Systems Programming) เข้ากับปรัชญาสังคมวิทยาอย่างคาดไม่ถึง 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Tragedy of the Commons: ทำไมข้อมูลที่ "ทุกคน" เป็นเจ้าของ ถึงกลายเป็นข้อมูลที่ "ไม่มีใคร" ดูแล Rust Philosophy: การประยุกต์ใช้กฎ Ownership (ความเป็นเจ้าของ) และ Borrowing (การยืม) จากภาษา Rust มาใช้จัดการโครงสร้างทีม เพื่อฟันธงว่าใครคือ Source of Truth เพียงหนึ่งเดียว Power / Knowledge: เลนส์ปรัชญาของ Michel Foucault เมื่อ "ใครถือข้อมูล คนนั้นถืออำนาจ" ทำไมแต่ละทีมถึงชอบแอบก๊อปปี้ข้อมูลไปสร้างเอง และเราจะจัดการการแย่งชิงอำนาจนี้อย่างไร Bounded Context: วิธีใช้ Domain-Driven Design (DDD) ตีกรอบขอบเขตความรับผิดชอบ ไม่ให้ก้าวก่ายตรรกะของทีมอื่น "ควบคุมโค้ดในมือคุณ แต่อย่าพยายามครอบครองความจริงที่ไม่ได้อยู่ในขอบเขตของคุณ"

    9 min
  4. ทลายกำแพงมนุษย์ กู้คืนรอยต่อระบบ: ภาคปฏิบัติของการทำ Contract และการสร้าง Platform Team EP.33

    29 Jun

    ทลายกำแพงมนุษย์ กู้คืนรอยต่อระบบ: ภาคปฏิบัติของการทำ Contract และการสร้าง Platform Team EP.33

    จาก EP.32 ที่เราทิ้งระเบิดลูกใหญ่ไว้เกี่ยวกับ "กับดักของการตัดฟีเจอร์แนวตั้ง (Vertical Slicing)" จนเกิดเสียงสะท้อนหลังไมค์ถล่มทลายว่า “ฟังแล้วร้องไห้เลยเพราะมันคือเรื่องจริงในออฟฟิศตอนนี้!” ในเมื่อโลกความเป็นจริงเราไม่สามารถกดปุ่ม Pause เพื่อหยุดวิ่งแล้วรื้อสถาปัตยกรรมใหม่ทั้งหมดได้ มันจึงเหมือนกับการที่เราต้อง "เปลี่ยนล้อรถยนต์ในขณะที่รถกำลังวิ่งด้วยความเร็ว 120 กม./ชม." EP.33 นี้ ลุงควิน และ คุณเมย์ (Senior Product Manager) กลับมาอีกครั้งตามคำเรียกร้อง พร้อมขยับจากพาร์ททฤษฎีเข้าสู่ "ภาคปฏิบัติ (Actionable Steps)" แบบเจาะลึก เจ็บจริง ลงมือจริง เพื่อหาทางออกว่าเราจะเริ่มอุดรอยรั่วตรงรอยต่อของระบบอย่างไร โดยที่แต่ละ Squad ยังคงวิ่งได้ไวเหมือนเดิม! 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: Consumer-Driven Contract (CDC) Testing: วิธีเปลี่ยนการคุยของเดฟให้เป็นแบบ "คู่ค้าทางธุรกิจ" ใช้ Code เป็นตัวล็อกข้อตกลงผ่าน CI/CD Pipeline ตัดปัญหาการแอบแก้โค้ดแล้วทำระบบข้าง ๆ พัง Platform Team ที่ไม่ใช่หอคอยงาช้าง: ถอดบทเรียนวิธีสร้างทีมแนวนอนตามหลัก Team Topologies ที่ไม่ทำตัวเป็นตำรวจคอยจับผิด แต่ทำตัวเป็นคนปูพรมแดง ดึงดูดทีมอื่นด้วย "ความสะดวก" ไม่ใช่ "กฎระเบียบ" Foucault’s Power Dynamic: การประยุกต์ใช้แนวคิดเชิงปรัชญาเพื่อทลายกำแพงระหว่างทีมแนวตั้งและแนวนอน The First Small Step: "ก้าวแรกเล็ก ๆ" ที่คุณสามารถเริ่มลงมือทำได้ทันทีในวันพรุ่งนี้ โดยไม่ต้องลงทุนซื้อทูลราคาแพง "เราเปลี่ยนโครงสร้างองค์กรใหญ่ยักษ์ทันทีไม่ได้ แต่อย่างน้อยเราควบคุมวิธีการปฏิสัมพันธ์ระหว่างเรากับทีมข้าง ๆ ได้" — คิดแบบสโตอิก

    8 min
  5. เมื่อ Squad เป็นเอกราช แต่ระบบภาพรวมพินาศ: กับดักของการตัด Feature แนวตั้ง (Vertical Slicing) EP.32

    25 Jun

    เมื่อ Squad เป็นเอกราช แต่ระบบภาพรวมพินาศ: กับดักของการตัด Feature แนวตั้ง (Vertical Slicing) EP.32

    เคยฝันถึงองค์กรในอุดมคติไหมครับ? ทีมที่ซอยย่อยแบบ Vertical Slicing ตัดฟีเจอร์ตามโดเมนธุรกิจ แต่ละ Squad มีอำนาจเบ็ดเสร็จ มีสิทธิ์เลือก Tech Stack เอง มีอิสระเต็มร้อยจนทำงานเสมือนอยู่กันคนละบริษัท… วิ่งไว คล่องตัว คุยกันจบในทีม แต่ทำไม... พอถึงวันปล่อยของจริง (Deploy) ดินแดนในฝันกลับกลายเป็นฝันร้าย? เมื่อฟีเจอร์ของทีม A และทีม B ต่างคนต่างเคลมว่า "ฝั่งผมเสร็จแล้ว" แต่รอยต่อตรงกลางกลับพังยับเยิน ไม่มีข้อมูลวิ่งข้ามระบบ และที่สำคัญคือ "ไม่มีใครนึกถึง และไม่มีใครรับผิดชอบภาพรวมเลย" EP.32 นี้ ลุงควิน ควงคู่มากับ คุณเมย์ (Senior Product Manager) จะพาคุณไปเจาะลึก "กับดัก" ตัวร้ายที่ชื่อว่า Local Optimization, Global Suboptimization ที่ทำให้ระบบภาพรวมพังพินาศ พร้อมเชื่อมโยงมุมมองสถาปัตยกรรมซอฟต์แวร์เข้ากับปรัชญาของ Michel Foucault และ Stoicism 📌 สิ่งที่คุณจะได้เรียนรู้จากตอนนี้: The Dark Side of Autonomy: ทำไมการให้ทีมอิสระเกินไป ถึงสร้างช่องว่างไร้เจ้าภาพ หรือ Integration Void Regimes of Truth: เมื่อแต่ละ Squad ถือความจริงคนละชุด จนลืมคิดถึง End-to-End User Journey ของผู้ใช้งานจริง 3 แนวทางกู้ชีพสถาปัตยกรรมและโครงสร้างทีม: Contract-Driven Development: เปลี่ยนวิธีคุยของทีมแนวตั้งให้ทำงานร่วมกันเหมือน "คู่ค้าทางธุรกิจ" Horizontal Teams: การใช้ Platform & Enabling Teams ตามหลัก Team Topologies เพื่อสร้างกาวใจและท่อกลางของระบบ Align Incentives: การปรับตัวชี้วัด (Shared OKRs) เพื่อบีบให้ทุกคนต้องหันกลับมารักษารังผึ้งร่วมกัน "สิ่งใดที่ไม่เป็นประโยชน์ต่อรังผึ้ง ย่อมไม่เป็นประโยชน์ต่อตัวผึ้งเช่นกัน" — Marcus Aurelius อย่าปล่อยให้อิสรภาพของทีม กลายเป็นกำแพงที่ทำลายระบบภาพรวมขององค์กร #UncleQuinPodcast #SoftwareArchitecture #Agile #TeamTopologies #ProductManagement #VerticalSlicing #SoftwareDevelopment #TechPodcast

    10 min
  6. คู่มือตรวจรับโค้ดจาก AI: ขุดแนวกันไฟอย่างไร ไม่ให้ระบบลุกพรึบ EP.31

    23 Jun

    คู่มือตรวจรับโค้ดจาก AI: ขุดแนวกันไฟอย่างไร ไม่ให้ระบบลุกพรึบ EP.31

    🔥 EP.31 มาแล้ว! หยุดปล่อยให้ AI เขียนโค้ดจนไฟลามทุ่ง! 🔥 ใครที่กำลังใช้ AI ช่วยเขียนโค้ดเพื่อเร่งสปีดงาน แต่แอบกังวลว่าความเร็วนี้กำลังสะสม "เชื้อเพลิง" (Technical Debt) ก้อนใหญ่รอวันระเบิดหรือเปล่า? ในอีพีนี้ Uncle Quin Podcast จะมาแจกคู่มือภาคปฏิบัติในการ "ตรวจรับโค้ดจาก AI" เพื่อขุดแนวกันไฟให้ระบบของคุณปลอดภัย: ✅ ห้ามดูแค่ Green Test: ทำไมรันผ่านไม่ได้แปลว่าโครงสร้างถูก ✅ Semantic Density Over Verbosity: เทคนิคตัดกิ่งก้านโค้ดส่วนเกินที่ AI ชอบแถมมา ✅ กฎ AI Sandwich: Framework การทำงานร่วมกันระหว่าง มนุษย์-AI-มนุษย์ ที่ถูกต้อง หยุดกดยอมรับโค้ดแบบหลับตา แล้วมาเรียนรู้วิธีเป็น Forest Ranger ควบคุมความสมดุลของ Codebase ไปพร้อมกัน! #UncleQuinPodcast #AIDrivenCoding #SoftwareArchitecture #CodeReview #Programming #DeveloperLife

    8 min
  7. เมื่อ AI จุดไฟป่าใน Codebase: เร่งสปีด Rewrite หรือก้าวสู่ความโกลาหล? EP.30

    18 Jun

    เมื่อ AI จุดไฟป่าใน Codebase: เร่งสปีด Rewrite หรือก้าวสู่ความโกลาหล? EP.30

    ยุคนี้ใคร ๆ ก็ใช้ AI เขียนโค้ด! จากที่เคยต้องใช้เวลาเป็นเดือนในการ Rewrite ระบบ ตอนนี้ AI สามารถเสกโค้ดใหม่ให้เราได้ในไม่กี่นาที แต่คำถามคือ... ความเร็วระดับ "เวทมนตร์" นี้ กำลังซ่อน "ระเบิดเวลา" เอาไว้ใน Codebase ของคุณหรือเปล่า? ในอีพีนี้ ลุงควิน และ ฟ้า กลับมาสานต่อเรื่องราวจากตอนที่แล้ว (EP.29 - ทุบโต๊ะเขียนใหม่ หรือ ค่อย ๆ ปรับ? ถอดรหัสซอฟต์แวร์ด้วยกฎ Power Laws) โดยพาทุกคนไปสำรวจปรากฏการณ์ใหม่เมื่อ "AI เข้ามาเปลี่ยนสมการการเขียนโค้ด" พร้อมเปรียบเทียบการเติบโตของซอฟต์แวร์ยุคนี้กับวัฏจักรของ "ไฟป่า" (Forest Fire) เราจะมาเจาะลึกกันว่า: ทำไมการใช้ AI เจนโค้ดอย่างรวดเร็ว (โดยขาดความเข้าใจ) ถึงเป็นการสะสม "เชื้อเพลิง" ชั้นดีที่รอวันไฟลามทุ่ง? จะเกิดอะไรขึ้นเมื่อ "ความเร็วในการสร้างโค้ด" แซงหน้า "ความเข้าใจของมนุษย์" แล้ววันหนึ่งมีบั๊กวิกฤต (สายฟ้าฟาด) ถล่มลงมากลางระบบ? ทำไม Developer ยุคนี้ถึงต้องเปลี่ยนบทบาทจาก "คนปลูกป่า" มาเป็น "เจ้าหน้าที่ป่าไม้" (Forest Ranger)? เทคนิค Controlled Burning (การชิงเผาควบคุม) และการใช้ AI ทำ Micro-Refactoring อย่างไรไม่ให้ไฟลามทำลายสถาปัตยกรรมหลัก หยุดเร่งสปีดแบบหลับหูหลับตา แล้วมาเรียนรู้วิธีควบคุม "แนวกันไฟ" ในซอฟต์แวร์ของคุณไปพร้อมกันในอีพีนี้ครับ! #UncleQuinPodcast #AIDrivenCoding #SoftwareArchitecture #Refactoring #PowerLaws #DeveloperLife #TechPodcast

    9 min
  8. ทุบโต๊ะเขียนใหม่ หรือ ค่อย ๆ ปรับ? ถอดรหัสซอฟต์แวร์ด้วยกฎ Power Laws EP. 29

    16 Jun

    ทุบโต๊ะเขียนใหม่ หรือ ค่อย ๆ ปรับ? ถอดรหัสซอฟต์แวร์ด้วยกฎ Power Laws EP. 29

    โปรแกรมเมอร์ทุกคนต้องเคยเจอโมเมนต์นี้... เปิด Codebase มาแล้วเจอโค้ดเน่า ซับซ้อน พันกันยุ่งเหยิงจนอยากจะกราบอ้อนวอนขอ "ล้างไพ่เขียนใหม่ทั้งหมด" (The Big Rewrite) เพราะคิดว่ามันน่าจะเร็วกว่า แต่อย่างที่รู้กัน ส่วนใหญ่ความฝันนี้มักจบลงด้วยโศกนาฏกรรมทางสถาปัตยกรรม! ในอีพีนี้ ลุงควิน ซอฟต์แวร์สถาปนิกวัยเก๋า และ ฟ้า นักพัฒนาซอฟต์แวร์รุ่นใหม่ จะพาทุกคนไปท่องโลกปรัชญาซอฟต์แวร์ผ่านกฎธรรมชาติที่เรียกว่า Power Laws (กฎพาวเวอร์ลอว์) หรือกฎ 80/20 ที่จะมาเปลี่ยนวิธีมองโค้ดเน่าของคุณไปตลอดกาล เราจะมาหาคำตอบกันว่า: ทำไมการ Rewrite ใหม่หมดถึงเป็นกับดักที่น่ากลัว? กฎ Power Laws ช่วยให้เรามองเห็น "จุดยุทธศาสตร์" ใน Codebase ได้อย่างไร? พลังของดอกเบี้ยทบต้นจากการทำ Continuous Micro-Refactoring (รีแฟกเตอร์จุดเล็ก ๆ บ่อย ๆ) จะช่วยเซฟทั้งแรงและเซฟเงินบริษัทได้อย่างไร? ถ้าโครงสร้างมันพังจนต้อง Rewrite จริง ๆ รูปแบบ Strangler Fig Application Pattern (ต้นไทรพันหลัก) จะเข้ามาช่วยลดความเสี่ยงได้อย่างไร? หยุดสู้กับโค้ดแบบไร้กระบวนท่า แล้วมาวางกลยุทธ์ทำความสะอาดโค้ดอย่างมีชั้นเชิงไปพร้อมกันในอีพีนี้ครับ!

    11 min
See All (36)

About

Software & Developer Podcast

Information

  • Creator
    PlanktonSoft
  • Years Active
    2k
  • Episodes
    36
  • Rating
    Clean
  • Copyright
    © PlanktonSoft
  • Show Website
    UncleQuin