เคยมั้ยครับ เวลาเรา Discussion ในทีมเกี่ยวกับวิธี Implementation ของฟีเจอร์หนึ่งๆ แล้วเราหรือแม้แต่คนอื่นในทีมจะมีโมเม้นต์ประมาณว่า “กับฟีเจอร์นี้นะ เราเคยทำแบบนี้ A B C D นะ ต้องทำอย่างนี้สิ เราเคยทำมาแล้วมันเวิร์ค” แล้วหลังจากนั้นทีมก็ตกลงทำฟีเจอร์ด้วยวิธีนี้แล้วผ่านไปก็ค้นพบว่า ทำไมพอจะทำอะไรๆ ต่อมันยากไปหมดนะ

รู้จักกับ Second-System Effect

สถานการณ์แบบที่กล่าวมาข้างต้นนั้น ไม่ใช่เรื่องใหม่ครับและ ไม่ใช่เรื่องใหม่ในวงการ Software ด้วย ย้อนไปในปี 1975 Fred Brooks ได้พูดถึง Second-System Effect ไว้ในหนังสือ The Mythical Man-Month ว่า

งานแรกของ Architect มักจะค่อนข้างกั๊ก เค้าจะรู้ตัวว่าเค้าไม่รู้อะไรบ้างในงานที่เค้าทำ เลยทำให้เค้ามีความระวังค่อนข้างมากเป็นพิเศษ

ระหว่างที่เค้า Design งานตัวเองไป เค้าจะค้นพบท่าใหม่ๆ ทีละเล็ก ทีละน้อยแต่ก็จะยังไม่เอามาใช้เต็มที่และเก็บเอาไว้ใช้ “คราวหน้า” ผ่านไปไม่นาน ระบบแรกก็จะเสร็จและ Architect ที่เต็มไปด้วยความภูมิใจและมั่นใจในการสร้างระบบก็พร้อมที่จะสร้างระบบที่สองละ

ระบบที่สองที่ Architect ออกแบบจะเป็นระบบที่อันตรายที่สุดที่เค้าเคยออกแบบ เมื่อเค้าออกแบบระบบที่ 3 และต่อๆ ไป ประสบการณ์ก่อนหน้านั้นจะช่วยยืนยันตัวเองว่า ระบบหนึ่งๆ นั้นมีความแตกต่างกันในแต่ละส่วนและไม่สามารถที่จะทำให้เหมือนกันได้

ซึ่งหลายๆ ครั้งพอเป็นระบบแนวๆ ที่เราเคยทำมาแล้ว เราก็มักจะเลือกวิธีที่เราเคยทำใช่มั้ยครับ เพราะเรารู้รายละเอียดที่สุด แต่ต้องระวังว่า ในความเหมือนนั้น มันก็จะมีความแตกต่างอยู่ และหลายๆ ครั้งเรามักจะ Over Design เกินกว่าความเป็นจริงไปโดยไม่รู้ตัว

เราจะหลีกเลี่ยง Second-System Effect ได้ยังไง

แน่นอนครับว่า ถ้าเราเป็น Architect เราหนีไม่พ้นแน่ๆ ที่จะต้อง Design ระบบที่ 2 (คงไม่มีใคร Design โปรเจ็คแรกเสร็จแล้วเปลี่ยนไปทำงานอย่างอื่นหรอก ใช่มั้ยนะ)

ในหนังสือแนะนำประมาณว่า ให้เราพยายามมีสติเวลาเจอกับความประหลาดๆ ของ requirement ของระบบ พยายามมีวินัยไม่ลองท่าแปลกๆ มากเกินไป หลีกเลี่ยงการบิด requirement เพื่อให้เข้ากับท่าที่เราอยากลองหรือเคยทำ

แต่ท่าที่ผมชอบที่สุดคือ การให้คุณค่าของฟังก์ชั่นหนึ่งๆ ครับ โดยให้ ความสามารถของฟังก์ชั่นเป็น x ที่ไม่มากไปว่า m bytes ของหน่วยความจำและจำนวนการเรียกใช้ที่ n microseconds ครับ ซึ่งมันคือการวัดจริงๆ เลยว่าของที่เราทำมันมีคุณค่าจริงๆ แบบจับต้องได้ครับ

นอกจากนี้ยังมีท่าแนะนำให้ Project Manager ป้องกัน Second-System effect จาก Architect ในทีมด้วยนะครับ โดยให้พยายามระวัง design ที่มันมีความต้องการแปลกๆ หรือคุณ PM นี่อาจจะถามคำถามเพิ่มเพื่อให้เข้าใจไอเดียที่อยู่เบื้องหลัง design ก็ได้เพื่อเช็คว่า design นั้นเนี่ยถูกออกแบบมาเพื่อตอบโจทย์ที่ต้องการจริงๆ โดยไม่มี Hidden Agenda อยู่เบื้องหลัง

YAGNI

อีกวิธีที่จะช่วยป้องกัน Second-System Effect ได้คือ You Arent Gonna Need It หรือ YAGNI ครับ ซึ่งเป็น Practice มาจากฝั่ง Extreme Programming ซึ่งตามประโยคเต็มๆ ครับ หรือจะนิยามสั้นๆ ว่า

จงทำสิ่งที่จำเป็นในเวลาที่จำเป็น ไม่ใช่ตอนที่คิดว่าจะเป็น

ซึ่งนี่เป็นวิธีการตั้งคำถามที่ฉลาดมากครับ เพราะหลายๆ ครั้งในชีวิตการออกแบบโปรแกรมเรา เรามักจะ “เผื่อ”​ ไปหาอนาคตว่า นี่แหละมันต้องใช้แน่ๆ แต่หลายๆ ครั้งพอถึงเวลาจริงๆ เราอาจจะไปอีกทางเลยก็ได้ครับ ซึ่งเหตุผลหลักที่เราควรตั้งคำถาม YAGNI กับงานที่เราทำบ่อยๆ คือมันช่วยให้เรา โค้ดเราสะอาดและประหยัดเวลาที่จะเขียนโค้ดที่ไม่จำเป็นที่จะไม่ได้ใช้ในอนาคตไปได้เยอะเลยครับ

ส่วนตัวผมเคยมีประสบการณ์นี้แบบจำได้แม่นๆ เมื่อหลายปีก่อนครับ ผมเป็นคนเชื่อมันใน Asynchronous Queue/Worker มากว่ามันตอบโจทย์หลายๆ อย่าง ซึ่งระบบแรกที่ผมทำ ตัว Asynchronous Queue เราค่อนข้างจะเอาอยู่ว่ามันจะเกิดอะไรขึ้นบ้าง แล้วช่วยให้ Performance โดยรวมของระบบดีขึ้นยังไง

พอถึงระบบที่สองที่ผมเริ่มประยุกต์เอา Asynchronous Queue มาใช้แรกๆ ก็เหมือนจะดีเอาอยู่ครับ แต่พอเวลาผ่านไปด้วย Nature ของระบบที่มันต่างกันทำให้ Async Queue เราเริ่มเอาไม่อยู่ ต้องใช้เวลา Processing หลายชั่วโมงจน Scale ไม่ทัน ไม่พร้อมรับ Usage Pattern แบบที่เจออยู่ จนต้องปวดหัวไปหลายเดือนในการ Optimize กับ Scaling ตัว Asynchronous Queue ตัวนี้ครับ

ซึ่งก็หวังว่าถ้าได้อ่านเรื่องนี้ หลายๆ คนน่าจะฉุกคิดและระลึกถึงประสบการณ์ตัวเองที่ผ่านมานะครับ หรือถ้าใครยังไม่มีโอกาส Design system การได้รู้จักเรื่องนี้พอถึงเวลาก็หวังว่ามันจะคอยช่วยเราไม่ให้ลงหลุมเหมือนที่ผมเจอนะครับ ใครเจอประสบการณ์ Second-System Effect มาแล้วก็ลองแบ่งปันกันดูครับ ผมอยากฟัง!

Original post at: https://yothinix.medium.com/อย่าเผลอรัก-design-ตัวเอง-มาทำความรู้จักกับ-second-system-effect-กัน-543d1d26c5be