𝗖𝗼𝗱𝗲 𝗗𝘂𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗜𝘀 𝗖𝗵𝗲𝗮𝗽𝗲𝗿 𝗧𝗵𝗮𝗻 𝗪𝗿𝗼𝗻𝗴 𝗔𝗯𝘀𝘁𝗿𝗮𝗰𝘁𝗶𝗼𝗻𝘀
डेव्हलपर्सना DRY तत्त्व खूप आवडते.
तुम्हाला स्वतःची पुनरावृत्ती टाळायची असते. तुम्हाला मोहक (elegant) आणि पुन्हा वापरण्यायोग्य (reusable) कोड हवा असतो.
पण या ध्येयामुळे अनेकदा एक सापळा लागतो: अकाली ॲब्स्ट्रॅक्शन (premature abstraction).
कोडची पुनरावृत्ती करणे चुकीचे वाटते. मात्र, चुकीच्या ॲब्स्ट्रॅक्शनपेक्षा डुप्लिकेशन करणे अनेकदा स्वस्त असते.
आपण परिपूर्ण मॉड्युलर सिस्टम्स तयार करण्याचा प्रयत्न करतो. गुंतागुंत व्यवस्थापित करण्यासाठी आपण पॅटर्न शोधतो आणि लॉजिक वेगळे करतो.
चांगल्या प्रकारे डिझाइन केलेले ॲब्स्ट्रॅक्शन्स सॉफ्टवेअरला स्केल करण्यास मदत करतात.
पण अनेक ॲब्स्ट्रॅक्शन्स खूप लवकर तयार केली जातात. जर तुम्हाला समस्या पूर्णपणे समजली नसेल, तर तुमचे ॲब्स्ट्रॅक्शन तुमच्यासाठी ओझे (liability) बनते.
चुकीच्या ॲब्स्ट्रॅक्शनमुळे अनेक समस्या निर्माण होतात:
- ओव्हर-इंजिनिअरिंग (Over-engineering): तुम्ही साध्या समस्यांसाठी जटिल उपाय तयार करता.
- ताठरता (Rigidity): तुमचा कोड बदलणे कठीण होते कारण तो अशा भविष्याचा अंदाज घेण्याचा प्रयत्न करतो जे कधीच घडणार नाही.
- अस्पष्ट उद्देश (Obscured Intent): बिझनेस लॉजिक जेनेरिक इंटरफेसच्या थराखाली लपून जाते. यामुळे डीबगिंग करणे कठीण होते.
- टाइट कपलिंग (Tight Coupling): तुमच्या सिस्टमचे भाग स्वतः ॲब्स्ट्रॅक्शनलाच चिकटून राहतात.
याची किंमत मोठी असते. वापरकर्त्यांच्या समस्या सोडवण्याऐवजी तुम्ही तुमच्या स्वतःच्या आर्किटेक्चरशी लढण्यात वेळ घालवता. यामुळे तुमच्या टीमचा वेग मंदावतो आणि रिफॅक्टरिंग करणे कठीण होते.
मी तुम्हाला सर्व काही कॉपी आणि पेस्ट करायला सांगत नाहीये. मी एक व्यावहारिक (pragmatic) दृष्टिकोन सुचवत आहे.
नियंत्रित डुप्लिकेशनचा एक साधन म्हणून वापर करा. जिथे आवश्यकता वेगाने बदलतात किंवा जिथे अनिश्चितता असते, तिथे याचा वापर करा.
ॲब्स्ट्रॅक्शन तयार करण्यापूर्वी तुम्हाला पॅटर्न स्पष्टपणे दिसेपर्यंत प्रतीक्षा करा.