แนวคิดระบบที่แทบไม่ทำงาน
(hardcoresoftware.learningbyshipping.com)แนวคิดระบบที่แทบไม่ทำงาน
-
"แค่ทำให้เป็นระบบปลั๊กอินได้"
- แนวคิดคือเมื่อการใช้งานแบบหนึ่งไม่ทำงาน ให้ผู้พัฒนาสามารถเพิ่มการใช้งานใหม่ได้ง่ายขึ้น แต่ในทางปฏิบัติ ระบบ API มักไม่สามารถทำงานได้ง่ายเท่าที่คาดหวัง การทำให้ระบบเป็นปลั๊กอินได้อย่างแท้จริงจำเป็นต้องออกแบบการใช้งานอีกครั้งตั้งแต่ต้นเป็นส่วนหนึ่งของระบบ
-
"แค่เพิ่ม API เข้ามา"
- มักมีการเพิ่ม API เพื่อสร้างแพลตฟอร์มและดึงดูดนักพัฒนา แต่การมี API ต้องใช้ความพยายามต่อเนื่องสำหรับความเข้ากันได้และการทำงานร่วมกันเสมอ และการมี API ไม่ได้หมายความว่าจะมีผู้ใช้ตามมาเสมอไป การสร้างแพลตฟอร์มคือธุรกิจที่จริงจัง และการเพิ่ม API อย่างเดียวจึงยากที่จะสร้างพื้นฐานทางเศรษฐกิจที่ยั่งยืนได้
-
"ลองนามธรรมเพิ่มอีกขั้นหนึ่ง"
- โลกวิทยาการคอมพิวเตอร์พูดเสมอว่าสามารถแก้ปัญหาด้วยระดับการอ้างอิงแบบอ้อมขั้นถัดไป แต่การนามธรรมเร็วเกินไปอาจทำให้การดูแลรักษา ความปลอดภัย และการปรับประสิทธิภาพยากขึ้น การเพิ่มนามธรรมโดยไม่มีแผนจะทำให้การบำรุงรักษาโค้ดยากขึ้นอย่างมาก
-
"ทำให้เป็นแบบอะซิงโครนัส"
- การประมวลผลแบบอะซิงโครนัสเป็นหัวข้อการวิจัยทางวิทยาการคอมพิวเตอร์มานาน เฟรมเวิร์กเว็บสามารถนามธรรมได้ดี แต่หากพยายามจัดการการทำงานแบบอะซิงโครนัสเองนอกเหนือเฟรมเวิร์ก ความเสี่ยงต่อบั๊กที่คาดเดาไม่ได้จะสูงมาก
-
"เพิ่มการควบคุมการเข้าถึงทีหลัง"
- ความปลอดภัยของระบบควรถูกออกแบบตั้งแต่เริ่มต้น แต่โดยมากจะถูกนำไปเพิ่มทีหลังเพื่อเร่งความเร็วในการออกสู่ตลาด หากไม่คิดเรื่องการควบคุมการเข้าถึงตั้งแต่แรกทั้งจากมุมมองลูกค้าและผู้โจมตี โอกาสที่ต้องออกแบบใหม่ทั้งระบบในภายหลังค่อนข้างสูง
-
"ซิงก์ข้อมูลกัน"
- การซิงก์ข้อมูลเป็นปัญหาที่ท้าทายมาก และมีข้อเท็จจริงที่ต้องเรียนรู้ผ่านประสบการณ์เป็นจำนวนมาก การสร้างโซลูชันที่ตั้งอยู่บนการซิงก์ข้อมูลจึงแทบไม่เป็นทางเลือกที่ดี
-
"ทำให้เป็น cross-platform"
- การพัฒนา cross-platform คล้ายกับการสร้างระบบปฏิบัติการ ผู้ให้บริการระบบคลาวด์ หรือเบราว์เซอร์ เมื่อแพลตฟอร์มยังใหม่หรือแอปยังเรียบง่าย อาจใช้ได้ แต่ยิ่งใช้งานไปนานก็ยิ่งยากมากขึ้น
-
"ให้หลุดไป native ได้"
- เมื่อ cross-platform มีข้อจำกัด มักนิยมให้ระบบสามารถหลุดไปใช้คุณสมบัติแบบ native ได้ แต่แนวทางนี้อาจขัดแย้งกับสถานะที่เฟรมเวิร์กดูแล ทำให้เกิดความล้มเหลวได้ถึง 9 จาก 10 ครั้ง
-
บทสรุป
- รูปแบบเหล่านี้ไม่ได้นำไปสู่ความล้มเหลวเสมอไป แต่ส่วนใหญ่มีวิธีที่ดีกว่าเป็นส่วนมาก จึงสำคัญที่ต้องแก้ปัญหาตามหลักการพื้นฐาน และหลีกเลี่ยงรูปแบบซอฟต์แวร์ที่มีแนวโน้มล้มเหลวสูง
2 ความคิดเห็น
กรณีของ Plug สิ่งที่สำคัญที่สุดคือการออกแบบอินเทอร์เฟซโดยคัดกรองเฉพาะการทำงานที่จำเป็นให้ได้มากที่สุด
ถ้าคุณนำโครงสร้างจากโค้ดปัจจุบันมาทำอินเทอร์เฟซแบบหยาบๆ แบบนั้น ก็จะกลายเป็นอินเทอร์เฟซที่ไม่จำเป็นซึ่งผูกมัดกับการใช้งานนั้นอยู่ แต่ก็เป็นสถานการณ์ที่เกิดขึ้นได้บ่อยมากจริงๆ...
ความคิดเห็นจาก Hacker News