ถ้าใครดู LIVE: Uncle Bob on Software Fundamentals in the Age of AI กับคุณ Matt Pocockจะมีสิ่งหนึ่งที่น่าสนใจคือ แนวทางในการตรวจสอบสิ่งที่ AI สร้างขึ้นมายิ่งเป็น source code ด้วย ว่ามันมีคุณภาพ และ ทำงานได้ตามที่ต้องการหรือไม่ ?แน่นอนว่า ถ้า code ไม่เยอะ คนเราน่าจะ review เองได้แต่ชีวิตจริงมันเยอะมาก ๆ ดังนั้น จำเป็นต้องมีเครื่องมือมาช่วยนั่นเอง
มีโอกาสได้แบ่งปันประสบการณ์ ของการเขียน program อีกครั้งจึงคิดว่า จะแบ่งปันเรื่องพื้นฐานดีกว่า (พอดีทำเป็นแต่เรื่องพื้นฐาน)นั่นก็คือ การเขียน code ที่น่าจะดีขึ้นกว่าเดิม ไม่มากก็น้อยประกอบด้วยแนวคิดต่าง ๆ เหล่านี้น่าจะพอมีประโยชน์บ้าง
วันนี้กลับไปดูเรื่อง Wrting Code for Humans อีกรอบ เพื่อสรุปประเด็นที่น่าสนใจเพิ่มเติม หนึ่งในนั้นคือ แนวทางในการเขียน code ที่ดี เพื่อลดสิ่งรบกวน หรือ code แย่ ๆ รูปแบบต่าง ๆ ใน code ลงไป นั่นคือแนวทางที่เรียกว่า TED rule
วันนี้ทางทีมมีคุยกันเรื่อง Technical Debt หรือหนี้เชิงเทคนิค แน่นอนว่า ที่มาที่ไปนั้น เพื่อทำให้เข้าใจว่า สิ่งที่สายงานเชิงเทคนิคในการพัฒนา software อธิบายในมุมมองของการเงิน เพื่อให้เข้าใจมากยิ่งขึ้น ว่าสิ่งที่ทำลงไป มันก่อนให้เกิดหนี้หรือไม่ ? แน่นอนว่า ตามลักษณะของหนี้ย่อมไม่ได้มาแบบฟรี ๆ แต่มาพร้อมกับเงินต้น และ ดอกเบี้ย หนี้อาจจะเกิดขึ้นได้ง่าย ๆ คำถามคือ คุณจ่ายคืนไหน ดังนั้นถ้าเราไม่จ่ายหนี้ดอกมันก็จะแบ่งบาน จนสุดท้ายอาจจะทำให้ลูกหนี้มีปัญหาขึ้นมาได้
จากบทความเรื่อง Don’t Use Boolean Arguments, Use Enums เป็นบทความที่อธิบายให้เห็นว่า การใช้ boolean นั้น มีข้อดีและข้อเสียอะไรบ้าง เป็นสิ่งที่นักพัฒนาควรเข้าใจว่า ทำไมเราต้องใช้ และ ทำไมเราจึงต้องหลีกเลี่ยง จึงทำการสรุปไว้นิดหน่อย รวมกับสิ่งที่เจอมาในระบบงานต่าง
พอดีเจอ code ที่น่าสนใจ ซึ่งเป็น code ที่ดีมาก ๆ แต่สิ่งที่น่าสนใจกว่านั้นคือ คนในทีมหรือคนที่ดูแลต่อไม่เข้าใจ ว่าทำไมต้องเป็นแบบนี้ ว่าทำไมต้องทำให้ยาก ว่าทำไมแค่แก้ไขปัญหาที่ไม่ซับซ้อน ต้องเยอะแบบนี้ด้วย ว่าทำไมต้องทำเรื่องง่ายให้เป็นเรื่องยาก
เห็นบทความเรื่อง Code: Align the happy path to the left edge ที่กลุ่ม Golang Thailand ผู้พูดคือ คนเขียนหนังสือ Go Programming Blueprints นั่นเอง ซึ่งพูดในงาน Golang UK Conference ตั้งแต่ปี 2016 เห็นว่าน่าสนใจจึงนำมาสรุปไว้นิดหน่อย มาเริ่มกันเลย
หลังจากทำการ review code ไปนิดหน่อย พบว่าได้เจอ code ที่น่าสนใจ เนื่องจากจะขัดกับ Law of Demeter พอควร ผลที่ตามมาคือ code ทำงานได้ แต่มีการเรียกต่อกันเป็นทอด ๆ ยาวมาก ๆ ยกตัวอย่างเช่น game.Board.Size.X และ g.Board.Slots[i][j].Number เป็นต้น แต่ตามจริงเราต้องการเพียงค่าสุดท้ายเท่านั้นเอง ทำไมเราต้องเขียน code ยาวขนาดนี้กันด้วย ? น่าคิดมาก ๆ หรือเราคิดว่า มันคือเรื่องปกติ เพราะว่า โครงสร้างของระบบเราเป็นแบบนี้ ? ดังนั้นมาปรับปรุง code ชุดนี้กันหน่อยดีไหม
วันนี้เห็น tweet ใน Twitter เรื่อง Seven Ineffective Coding Habits of Many Programmers ทำการสรุป 7 อุปนิสัยที่ไม่ดีสำหรับการ coding เก่าหน่อยแต่ก็ยังมีประโยชน์ เนื่องจากการพัฒนา software ซึ่งมีความซับซ้อนนั้น นักพัฒนาต้องมีอุปนิสัยที่ดี เพื่อที่จะได้นำมาใช้ในการพัฒนา software ได้อย่างคล่องแคล่วและเป็นธรรมชาติ ทั้งการตั้งชื่อ ทั้งรูปแบบของ code ทั้งโครงสร้างที่ดี ทั้งการ comment เพื่ออธิบาย code ทั้งการเขียน unit testing ทั้ง … มันเยอะมาก ยากนะ ดังนั้นใน VDO นี้จะทำการอธิบาย 7 อุปนิสัยที่ไม่ดีซึ่งไม่ควรทำ จึงสรุปไว้นิดหน่อย
จากบทความในโค้ดทัวร์ ตอน 1 ทำการอธิบาย code ที่เขียนด้วยภาษา Go มีรูปแบบหรือ pattern ที่น่าสนใจหลายตัว หนึ่งในนั้นคือ NewEntry(url string) ทำให้นึกถึงเรื่องของ A Theory of modern Go ซึ่งอธิบายถึงเกี่ยวกับ Global state/variable จึงนำมาสรุปไว้นิดหน่อย