आपने एक कोर्स पूरा कर लिया है, यूट्यूब पर वीडियो की एक श्रृंखला देखी है, या आईओएस विकास के बारे में लेखों की एक श्रृंखला पढ़ी है, और अब आप अपना पहला पालतू प्रोजेक्ट लिखने के लिए तैयार महसूस करते हैं।

सबसे पहले, शाबाश! वह तो कमाल है। तुम बहुत खूब हो! 💪

दूसरे, एक पालतू परियोजना आपके कौशल को शानदार बढ़ावा देती है। जब आप निर्देशों का पालन किए बिना अपने आप कुछ करना शुरू करते हैं - तो आपको बहुत सारा समय और प्रयास खर्च करना पड़ता है, Google पर बहुत कुछ करना पड़ता है, ढेर सारी नई जानकारी पढ़नी पड़ती है, और उसे फ़िल्टर करके अपने मामले में सटीक रूप से फिट करने का प्रयास करना पड़ता है। संक्षेप में, यह पहले से ही एक वास्तविक कार्य है जो आपको पाँच गुना बढ़ा देगा।

हालाँकि, अधिकांश शुरुआती लोग मुख्य चीज़ों को नज़रअंदाज कर देते हैं (अपनी पहल के कारण नहीं, बल्कि उनके महत्व को समझे बिना)। पिछले छह महीनों से मैं सक्रिय हूं सलाह और नए लोगों को उनके प्रश्नों और समस्याओं में मदद करना, जिसमें प्रमुख परियोजनाएँ भी शामिल हैं।

मैंने शीर्ष 3 बिंदुओं की पहचान की है जिन्हें आपको, एक नौसिखिया के रूप में, अपनी आवश्यक सूची में शामिल करना चाहिए, मास्टर करना चाहिए, समझना चाहिए और उपयोग करना चाहिए।

पहुंच स्तर

सबसे पहले, लगभग कोई भी private संशोधक पर ध्यान नहीं देता है। इस बीच, यदि आप उन्हें आधी रात में जगाते हैं तो हर कोई तुरंत SOLID समझा सकता है। विभिन्न स्मार्ट लेख पढ़ने के बाद, लोग एस (एकल जिम्मेदारी) के विचार के अनुसार कक्षाओं का एक समूह बनाने का प्रयास करते हैं।

और फिर, स्पष्ट विवेक के साथ, वे class A की संपत्ति को class B से बदल देते हैं और इसके विपरीत।

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

सामान्य तौर पर, यदि यह अभी भी अस्पष्ट है, तो यहां योजना है: हमेशा हर जगह private लिखें , और जब संकलक शिकायत करता है - सोचें, क्या इस संपत्ति या फ़ंक्शन को बाहर से एक्सेस करना ठीक है? और यदि यह है - private हटा दें ।

जब आप सोचें, तो वास्तविक दुनिया की तुलनाओं से स्वयं का मार्गदर्शन करें। उदाहरण के लिए, यदि आपकी कक्षा एक स्टोर है, तो goods संपत्ति स्पष्ट रूप से बाहरी ग्राहक के लिए पहुंच योग्य होनी चाहिए। लेकिन moneyInCashRegister स्पष्ट रूप से केवल एक आंतरिक स्टोर कर्मचारी द्वारा ही बदला जा सकता है।

आख़िरकार, ग्राहक को कैश रजिस्टर तक पहुंच नहीं मिलनी चाहिए, यहां तक कि put के साथ भी, fetch तो बात ही छोड़ दें।

कोई यह तर्क दे सकता है, "मैं पूरी तरह से अच्छी तरह समझता हूं कि किस संपत्ति को छुआ जा सकता है और किसको private संशोधक के बिना भी नहीं छुआ जा सकता है"। हालाँकि, एक्सेस लेवल संशोधक लिखना डिज़ाइन का हिस्सा है। मुझे यकीन है कि आप ऐसे घर का खाका नहीं बनाएंगे, जिसका दरवाजा तीसरी मंजिल पर बाहर की ओर हो।

और फिर, बस याद रखें कि इसे न खोलें। आख़िरकार, यह संभावना है कि अन्य लोग भी आपके कोड का उपयोग करेंगे।

वैसे, ऐसी ही स्थिति var और let के साथ भी मौजूद है। दोबारा, हमेशा let उपयोग करें जब तक कि आप तुरंत आश्वस्त न हों कि आप मूल्य बदल देंगे।

वास्तुकला सादगी

मैंने एक प्रवृत्ति देखी है जहां शुरुआती लोग हर चीज़ की पहले से योजना बनाने की कोशिश करते हैं। हालाँकि यह सराहनीय है, अनुभव की कमी के कारण डेवलपर्स अक्सर गलतियाँ करते हैं। वे अत्यधिक जटिल प्रबंधकों को पहले से तैयार करते हैं (आमतौर पर इसकी नकल की जाती है)। स्टैक ओवरफ़्लो ) कई जटिल तरीकों के साथ, जिनका वे अंततः कभी उपयोग नहीं करते। परिणामस्वरूप, कोड की मात्रा और जटिलता बढ़ जाती है।

एक सुविधाजनक, तैयार सेवा की तरह लगने के बजाय, हमारे प्रोग्रामर को केवल समस्याएं और गलतफहमियां ही मिलीं। यही बात वास्तुकला के लिए भी लागू होती है।

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

इस मुद्दे को हल करने के लिए, संरचित प्रोग्रामिंग उभरी - कार्य और प्रक्रियाएं जो कार्यक्रमों को छोटे, प्रबंधनीय भागों में विभाजित करने की अनुमति देती हैं। कोड मॉड्यूलर, पुन: प्रयोज्य और अधिक समझने योग्य बन गया।

संरचना के आगमन से कार्यक्रमों में और वृद्धि हुई जब तक कि वे फिर से अपने आकार और जटिलता की सीमा तक नहीं पहुंच गए। इसलिए, 1970 के दशक के अंत और 1980 के दशक की शुरुआत तक, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग दृष्टिकोण का गठन किया गया था। इस समाधान ने तेजी से जटिल कार्यों को संबोधित करते हुए लचीली और स्केलेबल प्रणालियों के निर्माण को सक्षम किया।

अगले दशक में, हमने कंप्यूटर गेम में उछाल देखा। उपयोगकर्ता क्रियाओं (क्लिक, प्रेस) पर प्रतिक्रिया महत्वपूर्ण साबित हुई, जिससे इवेंट-संचालित प्रोग्रामिंग का उदय हुआ।

और वेब और डेस्कटॉप अनुप्रयोगों में कोड व्यवस्थित करने के लिए - जब एक ही डेटा को विभिन्न दृष्टिकोणों से पुनर्व्यवस्थित करने की आवश्यकता होती है - एमवीसी पैटर्न (यानी, मॉडल को उसके दृश्य प्रतिनिधित्व से अलग करना) उभरा।

आपने मुख्य विचार समझ लिया है: एक समस्या उत्पन्न होती है, -> एक समाधान निकलता है। समस्या -> समाधान.

तो फिर शुरुआती प्रोग्रामर अब ऐसे समय में समाधान (आर्किटेक्चर) लागू करना क्यों शुरू करते हैं जब समस्याएं अभी पैदा ही नहीं हुई हैं? ट्यूटोरियल तुरंत कम से कम एक एमवीपी चुनने का सुझाव देते हैं। एक/दो स्क्रीन के लिए परीक्षण कार्य हमेशा एमवीसी का उपयोग न करने के लिए निर्दिष्ट करते हैं।

साक्षात्कार के दौरान, एक व्यक्ति जिसने समान एक/दो स्क्रीन के साथ कुछ प्रमुख परियोजनाएँ लिखी हैं, उससे VIPER समस्याओं के बारे में पूछा जाता है। वह समस्याओं के बारे में कैसे जान सकता है यदि उसने अभी तक समस्याओं का सामना ही नहीं किया है?

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

वे एमवीपी योजना को सरल शब्दों में समझा सकते हैं, लेकिन जब ViewInput और ViewOutput जैसे समान नामों वाले प्रोटोकॉल की बात आती है तो वे अक्सर भ्रमित हो जाते हैं। गहराई से, वे पहले से ही इस सब को कुछ ओवरहेड के रूप में देखते हैं 🙄🤯

निष्कर्ष: अपने लिए समस्याएँ पैदा न करें। एमवीसी से शर्मिंदा मत होइए। जब आपका नियंत्रक बहुत बड़ा हो जाता है, या आपको असुविधाओं का सामना करना पड़ता है, तो आप समझेंगे कि नए तरीकों की तलाश करने का समय आ गया है।

यूआई सरलता

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

इसके अलावा, जटिल सुविधाएँ जटिल यूआई का अनुसरण करती हैं। भले ही स्विफ्टयूआई आज कार्य को सरल बनाता है, फिर भी कोई वास्तविक प्रगति किए बिना घंटियाँ और सीटियाँ जोड़ने में बहुत समय व्यतीत कर सकता है।

मैंने आईओएस डेवलपमेंट एक कोर्स के दौरान सीखा, जहां हमने टीमें बनाईं और एक ही प्रोजेक्ट पर काम किया। मेरी टीम में, एक व्यक्ति ने डार्क मोड के लिए फ़ॉन्ट और रंग चुनकर हमारा ऐप डेवलपमेंट शुरू करने का सुझाव दिया।

कुल मिलाकर, उन्होंने इस पर पूरा पाठ्यक्रम बिताया, और यह ध्यान देने योग्य है कि फ़ॉन्ट और रंग शानदार बने। हालाँकि, उस व्यक्ति ने उस पूरे समय के दौरान वास्तविक कोड की लगभग शून्य पंक्तियाँ लिखीं।

निस्संदेह, आपके एप्लिकेशन की सुंदरता और कार्यक्षमता महत्वपूर्ण है। आख़िरकार, आपको इस पहलू पर समय बिताना होगा। किसी आसान चीज़ से शुरुआत करना बेहतर है। एक एमवीपी (न्यूनतम व्यवहार्य उत्पाद) विकसित करें, सबसे महत्वपूर्ण सुविधाओं पर ध्यान केंद्रित करें और वहां से लॉन्च करें।

80-20 नियम यहां लागू होता है - एप्लिकेशन का मूल तत्व बनाएं, और फिर अतिरिक्त जोड़ें। विपरीत दृष्टिकोण जटिल बारीकियों से जूझने और लगातार मुख्य कार्यक्षमता से निपटने की ओर ले जाएगा जो टूटती रहती है।

मोबाइल विकास में नए लोगों के लिए, जटिल समाधानों को समय से पहले अपनाने का जोखिम है। जबकि फ्रंट-एंड डेवलपमेंट के दृश्य पुरस्कार आकर्षक हो सकते हैं, एक साधारण एमवीपी से शुरुआत करना अक्सर समझदारी भरा होता है।

ऐतिहासिक रुझान सुझाव देते हैं कि वास्तविक चुनौतियों के जवाब में समाधान विकसित होने चाहिए।

मूलभूत सिद्धांतों को समझना और वास्तविक दुनिया की समस्याओं के उत्पन्न होने पर उनका समाधान करना प्रभावी विकास के लिए महत्वपूर्ण है।

यहाँ भी प्रकाशित किया गया