Code Pattern & Architecture
เวลาผมอ่านความเห็นทั่วไปเกี่ยวกับโค้ด Pattern หรือ Architecture ไม่ว่าจะเป็น CQRS, MVC, OOP, DI ผมมักจะเห็นความเห็นสองสุดทาง Spectrum
- Pattern เหล่านี้มันจำเป็นคุณต้องเรียนรู้ไว้ไม่งั้นทำงานเป็นโปรแกรมเมอร์ที่ห่วย
- Pattern เหล่านี้มันไม่จำเป็น ดูโค้ดหน้างานแล้วเขียนให้อ่านง่ายเอาสิ
ผมถือ Stance ที่ไม่ตรงกับทั้งคู่
ผมถือว่า Pattern คือเครื่องมือทำงานร่วมกัน ทำให้ทำงานเป็นทีมง่ายขึ้น
นั่นหมายความว่าคุณควรจะรู้ Pattern ที่ทำให้ทำงานกับคนอื่นได้โดยไม่ต้องสอนจากศูนย์ แต่ในทางกลับกัน ถ้า Pattern นั้นทำให้ “ทีม” ทำงานยากในโดเมนนั้น ก็ปรับซะ
Pattern คือเครื่องมือสื่อสาร คือเกมแพลน ถ้ามองในแง่นี้ ยอมรับสิ่งนี้เป็นเป้าหมายของ Pattern ต่างๆ คุณจะเห็นว่าทำไมแนวคิดสุดโต่งทั้งสองแบบมันไม่เวิร์ค
ปัญหาของแนวคิดแบบแรกอย่างสุดโต่ง บอกว่าต้องใช้ Pattern ที่ดีเหล่านี้เท่านั้น ไม่ใช้ไม่ได้นะอย่าเขียนมั่ว คือคุณอาจจะฝืนใช้ในจังหวะที่มันไม่เหมาะก็ได้ และในทีนี้คำว่าไม่เหมาะนิยามตามเป้าหมายเลย “ทีมทำงานยากขึ้น”
ปัญหาของแนวคิดสองแบบสุดโต่งคือ แต่ละคนต่างมี Intuition ของตัวเอง โค้ดที่อ่านง่ายของผม ไม่ได้อ่านง่ายสำหรับคนอื่น การไม่ Formalize ว่าอ่านง่ายแปลว่าอะไรแล้วทำให้ Explicit ทำให้มันชัดเจนร่วมกันจนทุกคนเข้าใจตรงกัน มันก็ทำให้ “ทีมทำงานยากขึ้น” เช่นกัน
สุดท้ายแล้วการทำงานเขียนหนังสือหรือเขียนโค้ดร่วมกัน มันต้องมีโครงสร้างวางไว้บ้างจะได้ไม่เหยียบเท้ากัน แต่กลับกัน โครงสร้างไม่ควรจะทำให้เขียนออกมาแล้วเละ
เราจะเอาโครงสร้างสากลมาวางไว้แล้วหนังสือสำหรับกลุ่ม Niche ผลงานที่ได้ก็อาจจะเขียนออกมาแปร่งๆ ลองนึกภาพนิยาย Harry Potter ที่เริ่มจากคำนำ สารบัญ จุดประสงค์ มันก็แปร่งมากเนอะ
ตรงข้าม ถ้าเราจะบอกว่าทุกคนเขียนอะไรที่คิดว่าดีก็เขียนไป พอร้อยออกมาเป็นนิยายเนื้อเรื่องรวมก็คงเละเทะไม่ปะติดปะต่อเช่นกัน
สำหรับกลุ่มที่ไปทางหนึ่งมากไป ผมก็จะบอกว่า เอา Pattern มาใช้ไม่ได้แปลว่าโค้ดจะดูแลง่ายแต่อย่างใดหรอกนะ ลองถามทีมสิว่ามันจริงมั้ยผลลัพธ์เป็นยังไง
สำหรับกลุ่มที่ไปทางสองมากไป ผมจะบอกว่า เราหลีกเลี่ยงการมี Pattern ทำงานร่วมกันไม่ได้ ลองร่วมกันนิยามกับทีมสิว่า Pattern แบบไหนคืออ่านง่ายพอสำหรับทุกคน
ถ้า Pattern หรือ Absence of Pattern ทำให้ทำงานร่วมกันยาก ก็ต้องปรับ ผมจะยึดตรงนี้ไว้เสมอ
มาถึงตรงนี้คำถามอาจจะเป็น “แล้วจะทำยังไง”
คำตอบที่ผมมีคือ “ทำงานกับเพื่อนร่วมทีม”
และถ้าคำถามต่อมาของคุณคือ “จะให้ทำงานกับเพื่อนร่วมทีมมนุษย์เนี่ยนะ มัน Bias เยอะวุ่นวายจะตาย มันยึดเป็นหลักไม่ได้ คุยกันก็ยาก ตกลงกันยังไงก็ไม่จบ”
คำตอบของผมคือ “ใช่แล้ว และวันนี้ผมกำลังบอกคุณว่า โปรแกรมเมอร์ที่จะเก่งไปอีกขั้นได้ จำเป็นต้องทำงานกับมนุษย์ตดเหม็นเอาแน่เอานอนไม่ได้พวกนี้ได้ดี ไม่ต่างกับอาชีพนักขาย นักพูด, BA, PO, Support ครับ เขาก็ต้องตกลงกับลูกค้า มนุษย์มันมีความสามารถในการตกลงและคุยกันได้อยู่แล้ว”
ซึ่งถ้าคุณไม่เชื่อ ผมก็ได้แต่บอกว่า ยิ่งคุณยอมรับสิ่งนี้ได้เร็วเท่าไหร่ คุณก็จะยิ่งเก่งเร็วขึ้นเท่านั้น
จะเชื่อหรือไม่ก็แล้วก็สุดแล้วแต่ครับ
ช่วงโฆษณา ผมสอน OOP The right way โดยถือตามความเชื่อนี้ทุกประการ OOP ไม่ได้เทพ แต่เป็นเครื่องมือทำงานร่วมกันที่คนยอมรับ ดังนั้นเรียนสิ่งนี้ไว้ก็จะทำงานร่วมกับทีมหลายๆ ทีมในอุตสาหกรรมได้ง่ายหน่อย
แล้วผมสอนโดยอิงว่าแต่ละอย่าง Abstraction, Inheritance, Polymorphism มันทำให้เพื่อนมนุษย์เขียนโค้ดร่วมกันง่ายขึ้นยังไง ไม่ได้สอนแค่ว่ามันคืออะไร ถ้าสนใจก็ลงได้ครับ
