हारने वालों के लिए पिछड़ी अनुकूलता

आप इसे सही पढ़ें। यदि आपकी परियोजना का लक्ष्य पिछड़ी अनुकूलता को बनाए रखना है, तो आप असफल हैं। PHP से Microsoft विंडोज तक कई लोकप्रिय परियोजनाएं संस्करणों के बीच पिछड़ी संगतता का दावा करती हैं। और हां, मैं कहना चाहता हूं कि यह सही नहीं है।

वास्तविक संभावनाएँ

ठीक है, मैं यह कहने की कोशिश नहीं कर रहा हूं कि पिछड़े अनुकूलता समर्थन एक बुरा लक्ष्य है। कई मामलों में, यह सभी के लिए आसान बनाता है। हम्म, शायद हमेशा नहीं। अल्पावधि में, पिछड़ी संगतता कोई बड़ी बात नहीं है, लेकिन हर कोई इससे लाभान्वित होता है। यह मेंटर के लिए आसान है, क्योंकि प्रत्येक परिवर्तन छोटा है और तुलना करने के लिए कम है। उपयोगकर्ताओं के लिए यह आसान है क्योंकि अपडेट करना कम दर्दनाक है।

तर्क करने में दोष

पिछड़े संगतता के साथ समस्या यह है कि प्रत्येक रिलीज में बहुत अधिक रद्दी होती है। समय के साथ, यह परियोजना के विकास में एक रुकावट पैदा करेगा और नए विचारों को लागू करते समय स्वच्छ कोड बनाए रखना अधिक कठिन हो जाएगा। यह एक एंकर बनाता है जो परियोजना को पत्थर की उम्र में रखता है।
यह बढ़ते तकनीकी कर्ज का मामला है। इसके बारे में सोचो। यदि आप प्रोजेक्ट के पहले संस्करण में एपीआई के डिजाइन में गलती करते हैं, तो यह गलती आपको MANY संस्करणों के लिए परेशान करेगी। आप केवल इस ऋण को नहीं ले सकते और इसे चुका सकते हैं। और यह एक वैक्यूम में एक गोलाकार घोड़ा नहीं है *। PHP में स्ट्रिंग्स और सरणियों के कार्यों को देखें। इस क्रम में उनके लिए पैरामीटर क्यों इंगित किए गए हैं? क्योंकि यदि आप उन्हें बदलते हैं, तो यह पिछड़ेपन को लाएगा!

दृष्टि

पिछड़ी अनुकूलता की मुख्य समस्या इसकी विचारधारा है - ऐसा माना जाता है कि शुरू में लिखी गई हर बात सही होगी। यदि शुरुआत से सब कुछ सही है, तो संगतता समर्थन सरल है। सिद्धांत रूप में। लेकिन व्यवहार में, ऐसा नहीं है। अन्य चीजों की तरह, हम पहली बार में सब कुछ ठीक नहीं करेंगे।
यही कारण है कि मैं एक नई अवधारणा पेश करना चाहता हूं। क्यों, पिछड़े संगतता की देखभाल करने के बजाय, फॉरवर्ड कम्पेटिबिलिटी प्रदान करें।

अनुवाद अनुकूलता

अवधारणा की मूल बातें:

हम उस कोड की भविष्य की जरूरतों का अनुमान लगाने की कोशिश करते हैं जो हम अभी लिख रहे हैं और इसे लचीले रूप से पर्याप्त रूप से लिखते हैं ताकि बाद में पिछड़े संगतता के बारे में चिंता न करें।

यह एक महान लक्ष्य है ... अनुचित?
खैर, वास्तव में नहीं। हमें पूरी तरह से काम करने के लिए कोड की आवश्यकता नहीं है - हमें इसका कार्य करने की आवश्यकता है। हम एक बेहतर गलती करेंगे और इसे पहली बार में गलत करेंगे, लेकिन यह हमारे लिए भविष्य में आसान होगा कि शुरुआत में यह कल्पना करें कि यह कोड सभी आवश्यक कार्यों को हल करेगा और भविष्य की जरूरतों को पूरा करेगा।

कार्रवाई में

मैं पूरे साल इस विचारधारा का पालन करता हूं। जब मैंने पासवर्ड के लिए एपीआई विकसित किया, तो इस दृष्टिकोण का उपयोग किया गया था। यही कारण है कि $cost और $salt बजाय $options पैरामीटर है। मैंने भविष्य में होने वाले परिवर्तनों को दूर करने की कोशिश की और इसके लिए एपीआई को अनुकूलित किया। क्या मैंने इसे अच्छा किया? हम भविष्य में इस सवाल का जवाब दे सकते हैं। लेकिन मुझे लगता है कि अगर मैं पिछड़ी अनुकूलता की विचारधारा का पालन करता हूं, तो इससे बेहतर है कि (जिसके अनुसार मैं जो चाहूं कर सकता हूं और जैसा कि मैं फिट देखता हूं)।

 function password_hash($password, $algo, array $options = array()) 

टीएल / डीआर

अगली बार, बदलावों का प्रस्ताव करते हुए, इस बारे में सोचें कि भविष्य की जरूरतों के लिए इसे कैसे लागू किया जा सकता है, न कि पिछड़ी अनुकूलता को देखते हुए। पिछड़े अनुकूलता विफलताओं को रोकने का सबसे अच्छा तरीका यह है कि शुरू में उनकी योजना बनाई जाए। मैं यह नहीं कह रहा हूं कि पिछड़ेपन को नजरअंदाज करें, लेकिन भविष्य पर ध्यान देना बेहतर है और अतीत को गिराने देना चाहिए।
भविष्य वही है जो हम प्रभावित कर सकते हैं। गलतियाँ पहले ही की जा चुकी हैं, वे अतीत में हैं। चलो उन्हें हमेशा के लिए साथ न खींचें ...

* मूल: और यह भी एक सैद्धांतिक समस्या नहीं है

इस अनुवाद में स्पष्ट रूप से कई खामियां हैं, मैं केवल भाषा सीख रहा हूं, मैं पीएम में त्रुटियों को इंगित करने के लिए आभारी रहूंगा, धन्यवाद।