दस्तावेज़ीकरण आपका सबसे अच्छा मित्र क्यों है?

(और ऐसे समाधान कैसे बनाएं जो अपडेट के बाद भी काम करते रहें)

“ऐप्स केवल सार्वजनिक एपीआई का उपयोग कर सकते हैं और उन्हें वर्तमान शिपिंग ओएस पर चलना चाहिए।” ऐप्पल ऐप समीक्षा दिशानिर्देश

यदि आपने कभी किसी नए ढांचे के साथ काम करना शुरू किया है और खुद को यह सोचते हुए पाया है: “अब मैं खुद ही सब कुछ समझ लूंगा, दस्तावेज पढ़ना बहुत लंबा है,” आप निश्चित रूप से अकेले नहीं हैं। हममें से कई लोगों में स्वाभाविक खोजी प्रवृत्ति होती है: पहले प्रयास करें, और उसके बाद ही निर्देशों को देखें। और यह बिल्कुल सामान्य है.

हालाँकि, इस स्तर पर बहक जाना और ऐसी स्थिति में पहुँचना आसान हो सकता है जहाँ कोड बढ़िया काम करता है, लेकिन शायद सिस्टम की गैर-स्पष्ट विशेषताओं पर निर्भर करता है।

कभी-कभी केवल “इसे स्वयं ही समझ लेना” पर्याप्त क्यों नहीं होता?

फ्रेमवर्क, विशेष रूप से बंद फ्रेमवर्क, जटिल और बहुस्तरीय सिस्टम हैं। वे अक्सर आंतरिक तर्क और अनुकूलन छिपाते हैं:

*सार्वजनिक दस्तावेज़ीकरण में वर्णित नहीं हैं;
*इस बात की गारंटी न दें कि व्यवहार भविष्य में भी बना रहेगा;
* नए संस्करण जारी होने के साथ बदल सकता है;
* इसमें डेवलपर्स को ज्ञात विशेषताएं शामिल हो सकती हैं जिन्हें अभी तक ठीक नहीं किया गया है।

जब हम सहज ज्ञान से कार्य करते हैं, तो दस्तावेजी नियमों के बजाय यादृच्छिक अवलोकनों पर वास्तुकला का निर्माण करने का जोखिम होता है। यह कोड को अपडेट के प्रति अधिक संवेदनशील बना सकता है।

दस्तावेज़ीकरण एक सीमा नहीं है, बल्कि एक विश्वसनीय समर्थन है

फ़्रेमवर्क डेवलपर हमारी सहायता के लिए मैनुअल बनाते हैं। दस्तावेज़ीकरण के अंतर्गत कार्य करते हुए, हमें मिलता है:

* स्थिरता;
* सहायता;
* पूर्वानुमेय सिस्टम व्यवहार।

इन सीमाओं से परे जाकर, हम अतिरिक्त जोखिम उठाते हैं, और ऐसे कोड को बनाए रखना अधिक कठिन हो जाता है।

प्रयोग? निश्चित रूप से। लेकिन सीमाओं की समझ के साथ.
किसी डेवलपर में जिज्ञासा होना एक महान गुण है। नई चीज़ों की खोज करना और उन्हें आज़माना नितांत आवश्यक है। लेकिन यहाँ एक छोटी सी इच्छा है:

प्रयोग करने का सबसे आरामदायक तरीका सर्वोत्तम प्रथाओं पर भरोसा करना है।

दस्तावेज़ीकरण एक मानचित्र है जो दिखाता है कि कौन से पथ सबसे सुरक्षित हैं और रचनाकारों द्वारा समर्थित हैं।

एक बाहरी परिप्रेक्ष्य: विशेषज्ञ की सलाह

हम अक्सर अनुभवी सहकर्मियों से सीखते हैं:

*वे उपयोगी पाठ्यक्रम संचालित करते हैं,
*सम्मेलनों में बोलें,
*अद्भुत किताबें और ब्लॉग लिखें,
* उनके अनूठे दृष्टिकोण को साझा करें।

उनमें से कई सचमुच मूल्यवान अनुभव साझा करते हैं। लेकिन यह याद रखने योग्य है: यदि लेखक के दृष्टिकोण आधिकारिक दस्तावेज़ीकरण के विपरीत हैं, तो वे नाजुक हो सकते हैं।

ऐसे “अनुभवजन्य पैटर्न” कभी-कभी:

* केवल ढांचे के एक विशिष्ट संस्करण पर काम करें;
* अद्यतनों के प्रति संवेदनशील;
* असामान्य परिस्थितियों में अप्रत्याशित व्यवहार कर सकता है।

समुदाय से सीखना महान और लाभदायक है। लेकिन किसी भी सलाह, यहां तक ​​कि सबसे आधिकारिक सलाह को भी हमेशा आधिकारिक मैनुअल के साथ सावधानीपूर्वक जांचा जाना चाहिए।

SOLID के बारे में थोड़ा

SOLID सिद्धांतों के तीन विचार इस दृष्टिकोण को पूरी तरह से पूरक करते हैं:

* खुला/बंद सिद्धांत: सार्वजनिक एपीआई के माध्यम से व्यवहार को बढ़ाने का प्रयास करें और, यदि संभव हो तो, छिपे हुए कार्यान्वयन पर निर्भर न रहें।
* लिस्कोव प्रतिस्थापन सिद्धांत: अनुबंध पर भरोसा करें, विशिष्ट कार्यान्वयन पर नहीं। अन्यथा, हुड के नीचे परिवर्तन अप्रत्याशित कठिनाइयों का कारण बन सकता है।
* निर्भरता व्युत्क्रमण: विवरणों पर नहीं, अमूर्तताओं पर निर्भरताएँ बनाएँ।

व्यवहार में, इसका मतलब यह है कि ढांचे के आंतरिक, गैर-दस्तावेज विवरण से बंधा होना सिस्टम को भंगुर बना देता है।
सार्वजनिक इंटरफ़ेस और अनुबंधों के आधार पर, हमें मिलता है:

* फ्रेमवर्क में बदलाव से कोड का बेहतर अलगाव;
* परीक्षण में आसानी;
* वास्तुकला की पूर्वानुमेयता और विश्वसनीयता।

अगर कोई बग है तो क्या होगा?

ऐसा भी होता है कि सब कुछ नियमों के अनुसार किया जाता है, लेकिन परिणाम उम्मीदों के अनुरूप नहीं होता है। ढाँचे विकसित होते रहते हैं और हमेशा सही नहीं होते। इस तरह के मामलों में:

* एक न्यूनतम उदाहरण बनाएं जो समस्या को पुन: उत्पन्न करता हो।
* सुनिश्चित करें कि केवल प्रलेखित एपीआई का उपयोग किया जाए।
* बग रिपोर्ट भेजें – विकास टीम निश्चित रूप से आपके काम की सराहना करेगी और मदद करने का प्रयास करेगी।

यदि उदाहरण वर्कअराउंड पर निर्भर करता है, तो डेवलपर्स के लिए सहायता प्रदान करना अधिक कठिन होगा।

फ़्रेमवर्क से अधिकतम लाभ कैसे प्राप्त करें

*दस्तावेज़ देखें.
* लेखकों के मार्गदर्शकों और अनुशंसाओं का पालन करें।
* वर्णित कार्यक्षमता के भीतर प्रयोग करें।
* आधिकारिक स्रोतों के साथ इंटरनेट से सलाह की जाँच करें।
* फ्रेमवर्क अनुबंधों का सम्मान करते हुए बग्स का स्थानीयकरण करें।

निष्कर्ष

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

मैनुअल और दस्तावेज़ीकरण उत्कृष्ट समर्थन हैं जो वास्तव में विश्वसनीय समाधान बनाने में मदद करते हैं।

स्रोत

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM