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