On framework dependencies
Based on article here, I just want to add that internal frameworks, rules and tech stack do play same effect as standard/framework, maybe even worse. This is one of the biggest trap.
Abstract away outside framework with internal framework only have benefit when in-house framework is easier to understand and be communicated than third-party framework.
This normally can be achieved by using domain-specific word and vocabulary among internal devs, and simplify functionality of third-party to just only minimal and specific usage.
จากบทความที่ลงตะกี้เกี่ยวกับที่ว่า Architecture ที่ดีจะต้องไม่ขึ้นอยู่กับ Interface ของ Framework, tech stack, 9ล9มีเรื่องนึงที่คิดได้และอยากเขียนถึง
สิ่งนึงที่ต้องระวังและตกหล่มได้ง่าย คือ Framework, Library, Tech stack ในที่นี้มันไม่ได้หมายถึงแค่ Framework ภายนอกเท่านั้น แต่มันรวมถึงสิ่งที่เราคิดกันเองภายในด้วยนะ
คือ ถ้าเราคิด Structure ของเราเอง in-house เพื่อไปครอบ Framework ข้างนอกเพื่อให้โค้ดเราไม่ขึ้นกับ Framework ภายนอก โอเค ก็ดี แต่มันไม่ได้แปลว่าโค้ดของเราไม่ขึ้นกับ Framework เป็นอิสระจาก Framework อย่าพึ่งเข้าใจไปทางนั้น
มันแปลว่าโค้ดของเราขึ้นอยู่กับ Structure และ Framework ที่เราคิดกันเองใน in-house ต่างหาก!!
ซึ่งมัน “มัก” จะมีประโยชน์ก็เพราะ Framework หรือ Structure ที่เราคิดกันภายใน มีโอกาสที่จะทำความเข้าใจง่ายกว่า มีโอกาสที่จะง่ายต่อการสือสารให้ทีมทำงานภายในเข้าใจกันได้มากกว่าของข้างนอก และการควบคุมการเปลี่ยนแปลงก็ทำได้ง่ายกว่า โอกาสพังเพราะอัพเดทมีน้อยกว่า
แต่มันไม่ใช่ Benefit เสมอไป ถ้าเราไม่ได้ใช้ Benefit ของมันเต็มที่
ยกตัวอย่างง่ายๆ สมมติเราบอกว่าเราไม่อยากขึ้นกับ Redux, React เราก็ต้องคิดหาอะไรซักอย่างมาครอบ ให้โค้ดของเราขึ้นอยู่กับสิ่งที่ครอบนั้น ซึ่งวิธีนี้ มันจะมีประโยชน์ต่อเมื่อสิ่งที่ครอบนั้น มันเข้าใจง่ายกว่าตัว Redux, React เอง หรือถ้าตัว React, Redux เองมี Breaking changes บ่อยๆ
แต่ถ้าเราไม่เข้าใจและออกแบบมันซะซับซ้อนกว่าตัว Redux, React เอง ก็กลายเป็นว่าให้โค้ดเรา Depends on React, Redux อาจจะยังดีซะกว่า
ถามว่าทำไงให้เข้าใจง่ายกว่าซับซ้อนน้อยกว่า ปกติก็มีสองสิ่งหลักๆ ที่มักจะปรับได้ (โดยส่วนใหญ่ ไม่ใช่ทุกครั้ง)
อย่างแรก เราใช้คำศัพท์ที่ Domain-specific เกี่ยวกับ Business problem ที่เรากำลังแก้โดยตรง หรือไม่ก็หันไปใช้ศัพท์ที่ใช้กันภายในบ่อยๆ จนคนทำงานในทีม อ่าน Requirement บ่อยๆ คุยกับเพื่อนบ่อยๆ เข้าใจได้ทันทีโดยแทบไม่ต้องศึกษา Document เพิ่มเติม แทนที่จะไปใช้ศัพท์ที่มัน Generic แบบ Standard framework พวก Controller, Component, Factory, etc.. ที่ต้องไปนั่งอ่าน Reference มากมายก่อนที่จะเริ่มใช้
อย่างที่สองคือเราตัด Functionality ที่ไม่จำเป็นที่เราไม่ใช้ทิ้งไปให้หมด ให้เหลือทางเลือกน้อยจนเพื่อนร่วมทีมไม่สับสน และตัด Use-case ให้ตรงกับสิ่งที่เราใช้งาน
ข้อแรกทำให้ผมมักจะบ่นบ่อยๆ ว่า Code ที่ Architecture ดี จะมีศัพท์เทคนิคน้อย
แน่นอนในโค้ดที่ใหญ่และซับซ้อนมากๆ เราหลีกเลี่ยงการสร้าง Concept เฉพาะบางอย่างไม่ได้ และหลีกเลี่ยงการใช้ศัพท์เฉพาะทางไม่ได้หรอก แต่ก็ควรจะพยายาม Minimize ให้มากที่สุด
ประเด็นหลักที่ผมอยากจะชี้คือ ถ้าเราจะ Abstract 3rd-party dependency ออกไปโดยการสร้างอะไรครอบ มันจะเวิร์คและมีประโยชน์ก็ต่อเมื่อของที่ครอบมันดีกว่าในบริบทของโจทย์ที่เรากำลังแก้ เราแลกความ Generic ของมันไปแล้วทำตัวครอบให้มัน Specific มากขึ้น เพื่อให้เข้าใจง่ายขึ้น ใช้ง่ายขึ้น
(ถ้ามันดีกว่า In general ก็ Open-source ซะแล้วเตรียมดังได้เลย)
นั่นคือสิ่งนึงที่น่าพิจารณาเป็นอย่างมาก
