วันนี้มีโอกาสมาแบ่งปันเรื่อง วิธีการเขียนโค้ดที่แย่ๆ
ในงาน Java Boot Camp ครั้งที่ 2 ตั้งตึก Park Venture
โดยสิ่งที่มาแบ่งปันนั้นประกอบไปด้วย
- การตั้งชื่อแย่ๆ
- การซ่อนหรือปิดบังความผิด
- การออกแบบโค้ดที่ผิด
- ไม่ต้องเขียน test
และปิดด้วยการอธิบายเรื่อง code ที่ดี ซึ่งประกอบไปด้วย
- จะต้องทำงานตรงกับความต้องการของลูกค้า นั่นคือมี test และต้องทำงานผ่านนะ
- สิ่งที่ออกแบบกับสิ่งที่พัฒนาขึ้นมา ต้องไปด้วยกันสิ
- ลดความซ้ำซ้อนของโค้ด
- พยายามทำให้ส่วนต่างๆ เช่น class, method มีขนาดเล็กมากที่สุดเท่าที่จะเป็นไปได้
โดยทั้ง 4 ข้อนี้คือ Simple Design Rule นั่นเอง
Slide การแบ่งปันอยู่ที่นี่
มาดูบรรยากาศของงาน Java Boot Camp กันบ้าง
เริ่มต้นด้วยการลงทะเบียน ซึ่งผมมาไม่ทัน .. แต่ขอถ่ายรูปหน่อย
เปิดตัว web และ facebook group ของ Java Boot Camp
- Facebook Group ของ Java Boot Camp
- Office website ( ยังไม่เสร็จนะ ) เอาไว้สำหรับเขียน blog ต่างๆ
เข้าสู่ session การ brain storm 2 เรื่อง
- หลักการการเขียน code ที่ดี
- หลักการการเป็น Enterprise Java Developer ที่ดี
- แล้วให้แต่ละกลุ่มออกมา present แนวคิดต่างๆ ที่คิดออกมา
- โดยส่วนใหญ่ก็จะได้แนวคิดดีๆ มากมาย เช่น
- การใช้งาน Design Pattern
- Clean code
- การเขียน Comment
- การเขียน code ให้ง่ายง่าย
- การใช้งาน Coding Convention
- ต้องมีความรู็ความเข้าใจในเรื่อง
- Architect
- Network
- Database
- Logging
- Knowledge Management
ซึ่งผมชอบแนวคิดนี้มากๆ ดังรูป
ในช่วงบ่าย
เริ่มการแบ่งปันในเรื่องที่ผมพูด กับเรื่อง SonarQube โดย @nuboat
และปิดท้ายด้วยการพูดคุยเรื่องของ Enterprise Requirement
สิ่งที่น่าสนใจคือ DSL ( Domain Specific Language )
จะทำให้ระบบที่ออกมามันง่าย ( Simple )
ส่งผลให้คนทำหรือใช้งาน ไม่จำเป้นต้องรู้ภาพใน และใครๆ ก็สามารถสร้างได้
สุดท้ายจะได้ Modeling ของธุรกิจหรือ Domain นั้นๆ
แต่ถ้าจะคิดหรือเอามาทำได้ จะต้องคิดและทำซ้ำๆ อยู่บ่อยๆ จนตกผลึกออกมา
โดยต้องออกมาจากคนที่อยู่ภายใน domain นั้นจริงๆ รู้เรื่อง operation ต่างๆ ได้ดี
จะทำให้ระบบงานออกมาได้ตรงกับความต้องการมากที่สุด
และให้เชื่อเถอะว่า ไม่มีทางที่จะทำถูกต้องแต่ครั้งแรก มันต้องทำหลายๆ ครั้ง
สุดท้ายคือ คิด ก่อน ทำ และลงมือทำเลยครับ …
เจอกันในครั้งต่อๆ ไปครับ
โดยน่าจะให้ทุกคนออกมาแบ่งปันกัน ในเรื่องต่างๆ
และมีการพูดคุย และ feedback กันแบบสองทาง หรือ หลายๆ ทางน่าจะดีกว่านี้
เพราะว่า ในครั้งนี้แต่ละคนที่มานั้น จะเงียบมากๆ
