मैं छह साल से iOS डेवलपर के रूप में काम कर रहा हूं। मैं कई अलग-अलग कंपनियों और टीमों में काम करने के लिए हुआ। मैंने आउटसोर्स और आउटस्टाफ दोनों में काम किया, मुझे स्टार्टअप में भाग लेने का भी मौका मिला। और अब, कई वर्षों के व्यावसायिक विकास के बाद, साथ ही साथ विश्वविद्यालय में प्रोग्रामिंग के कुछ वर्षों के बाद, मैंने आवेदन विकास के लिए गुणात्मक दृष्टिकोण के लिए कुछ सिद्धांतों या नियमों का एकल करना शुरू किया। सबसे पहले यह मेरे दोस्त को सलाह थी। उसे सलाह देते हुए, मैंने सोचा कि मुझे ऐसी सलाह की कमी है जब मैं सिर्फ अपना विकास पथ शुरू कर रहा था। मैं क्या कह सकता हूं, कुछ क्षण जिन्हें मैंने हाल ही में अपने लिए महसूस किया है, और कुछ पहले से ही एक नए स्थान पर हैं। और इसलिए यह विचार उन सुझावों की एक सूची बनाने के लिए आया, जिन्हें मैं पांच से छह साल पहले खुद के साथ साझा करना चाहूंगा। मुझे यकीन है कि अगले पाँच वर्षों में मुझे आज खुद से कुछ कहना होगा। लेकिन हम शायद भविष्य के लिए इसे छोड़ देंगे।
आपका कोड खराब है
और पहली बात मैं अपने आप से पहले जैसा कहना चाहूंगा: "आपका कोड खराब है!"। आम लोगों में, "गोवनोकॉड"। और विकास कार्यशाला में मेरे विदेशी सहयोगियों के पास "बंदर कोड" है।
नहीं, यह आपने नहीं सोचा था। मैं इस बात पर जोर नहीं देना चाहता कि मैं एक बुरा कोडर हुआ करता था, और अब मेरा कोड एकदम सही है। मैं इस संदेश को फिर से लिखना चाहता हूं और इस सलाह के अर्थ में तीन प्रमुख बिंदुओं को बताना चाहता हूं।
"आपका कोड था और बुरा होगा!"पहला क्षण: कोई आदर्श कोड नहीं है, कोई भी आदर्श वास्तुकला को नहीं देता है और ऐसा कोई कोड नहीं है जिसमें कोई बग न हो। मुझे लगता है कि कई लोगों ने यह सोचकर खुद को पकड़ा कि वे नई लाइब्रेरी या नई तकनीक का पता नहीं लगा सकते। या हम में से कुछ ओओपी, एसओएलआईडी के सभी सिद्धांतों का पालन करते हुए, फीचर को पूरी तरह से लिखने की कोशिश में चरम सीमा पर चले गए हैं। जिसके कारण बहुत समय बीत गया और कभी-कभी एक मृत अंत हो गया। कभी-कभी, सही कोड लिखने के प्रयासों में, राक्षसों का जन्म हुआ जो उन पैटर्न की पूरी सूची को ले गए जिन्हें डेवलपर जानता है, या शायद और भी।
अपने वाक्यांश के साथ, मैं यह विचार व्यक्त करना चाहूंगा कि आपको सबसे पहले चिंता नहीं करनी चाहिए, अपने कोड की गुणवत्ता के बारे में घबराएं। हर चीज की भविष्यवाणी करना असंभव है। और बस आराम करना, आसान लिखना, और जैसा कि आप जानते हैं, व्यर्थ में पीड़ित और चिंता करना बेहतर है। अनुभव के साथ, निर्णय खुद ही आ जाएंगे। कभी-कभी यह "नागोवनोडोडिट" के लिए आवश्यक होता है, वे उन समस्याओं का सामना करेंगे जो इस शिटकोड के कारण और एक बार समझ में आएंगे और यह बेहतर होगा कि ऐसा न करें।
दूसरा क्षण, जिसका मैंने पहले उल्लेख किया है, वह यह है कि हर चीज की भविष्यवाणी करना लगभग असंभव है। हां, अनुभव से समझ में आता है कि आप क्या कर रहे हैं और आप परियोजना के विकास पथ की भविष्यवाणी कर सकते हैं। लेकिन यह अनुभव के साथ आता है। और यदि अनुभव पर्याप्त नहीं है, तो आपको कोड को सार्वभौमिक बनाने का प्रयास नहीं करना चाहिए। आपकी सुविधा के दौरान अक्सर ऐसे मामले होते हैं, जिनके बारे में आपने लंबे समय तक सोचा था और पहली बार ध्यान से लिखा गया था, और फिर लिखा गया था, बस आवेदन से बाहर निकाल दिया गया है। इसके अलावा, ऐसे मामले भी होते हैं जब आवेदन केवल इसलिए बदलते हैं क्योंकि ग्राहक के दिमाग में यह सब अलग-अलग लगता था। और इंटरफ़ेस से कोड तक इंटरफ़ेस के श्रमसाध्य हस्तांतरण के लंबे घंटों के बाद, 100,500 परिवर्तन अचानक दिखाई देते हैं। यह केवल शुरुआत है, क्योंकि पहले रिडिंग के बाद, अधिक से अधिक नए संपादन आएंगे। और उस मामले में जब डेवलपर के पास पर्याप्त अनुभव नहीं है, इस प्रक्रिया में न केवल बहुत समय लग सकता है, बल्कि सबसे सुखद संवेदनाएं भी नहीं ला सकता है, जो अप्रिय विचारों द्वारा मन के गुप्त कोनों में कहीं डाल दिया जाता है, विकास की प्रक्रिया को एक मजेदार सबक से नारकीय दर्द में बदल देता है। इसलिए, अपनी नसों का ख्याल रखें और आदर्श के अनुरूप न हों। कभी-कभी आप थोड़ी बात कर सकते हैं।
तीसरा बिंदु: यह फिर से एक विशुद्ध मनोवैज्ञानिक क्षण है, अर्थात् अन्य डेवलपर्स से आलोचना। जैसा कि सभी जानते हैं, सभी घरेलू डेवलपर्स किसी अन्य कोड - शिट कोड पर विचार करते हैं। यहां तक कि अगर उसे अपना कोड दिखाया जाता है, जिसे वह नहीं पहचानता है, तो वह उसे बकवास कह सकता है। अक्सर ऐसी आलोचना स्वयं आलोचक की नैतिक संतुष्टि के साथ होती है। जैसा कि अनुभवी डेवलपर्स ने नोट किया है, यह उन लोगों को है जो अक्सर किसी और के कोड govnodkod को कॉल करते हैं, जो एक समय में एक से अधिक novnokovodil होते हैं। और जोर से कोई व्यक्ति "गोवनोकॉड" चिल्लाता है, उसके "केक" जितना अधिक वह अपने रास्ते में छोड़ देता है।
इसके अलावा, जो भी कुंवारी लड़कियां खुद को याद करती हैं, उन्हें जरूरी मानना चाहिए कि वह प्रसिद्धि के लिए एक नवोदित कलाकार रही हैं।
इसलिए, मैं आपको सलाह देता हूं कि "हमेशा आपका कोड था और एक बकवास होगा" अभिव्यक्ति का उपयोग करने के लिए, हमेशा रचनात्मक आलोचना से एक ढाल के रूप में। मैं यह भी नोट करना चाहता हूं कि आपका कोड हमेशा गंदगी रहेगा क्योंकि विकास अभी भी खड़ा नहीं है। हर साल आपके कोड की गुणवत्ता में सुधार होता है। इसलिए वर्तमान कोड अंततः गोवनोकॉड में बदल जाएगा।
फूट डालो और जीतो
मैं नहीं चाहता कि ऐसा लगे कि मैं केवल गोवनोकॉड को सलाह देता हूं, इसलिए मैं उस बुरे कोड से बचने के बारे में सलाह देना शुरू कर दूंगा। और मैं उस सिद्धांत से शुरू करना चाहूंगा जिसे मैंने खुद के लिए अलग रखा है। नहीं, यह विरासत या बहुरूपता नहीं है, और ना ही SOLID के सिद्धांतों में से एक है। मैं इस सिद्धांत को डिवाइड एंड कॉन्कर कहता हूं।
हां, सड़न जैसी चीज है।
अपघटन - भागों में संपूर्ण का विभाजन। इसके अलावा, अपघटन एक वैज्ञानिक विधि है जो समस्या की संरचना का उपयोग करती है और आपको छोटे कार्यों की एक श्रृंखला के साथ एक बड़ी समस्या के समाधान को बदलने की अनुमति देती है, यद्यपि परस्पर संबद्ध, लेकिन सरल।
जैसा कि विकिपीडिया कहता है। लेकिन यह केवल मेरे सिद्धांत के अर्थ में रखा गया हिस्सा है। निश्चित रूप से हाँ, आपको परियोजना और कार्यों को छोटे भागों में विभाजित करने की आवश्यकता है। लेकिन मेरा मतलब है कि परियोजना में तार्किक समूहों के अलगाव के लिए वैचारिक दृष्टिकोण।
और पहली चीज जो मैं इस सिद्धांत को संदर्भित करता हूं, वह है यूजर इंटरफेस और एप्लिकेशन के व्यावसायिक तर्क को अलग करना। ऐसा लगता है कि मैं अब प्रत्यक्ष साक्ष्य का कप्तान हूं। लेकिन! व्यवहार में, इन सीमाओं को अक्सर धुंधला कर दिया जाता है और यह पता चलता है कि ViewController या गतिविधि में व्यावसायिक तर्क का एक टुकड़ा होता है।
मुझे लगता है कि "लॉगिन" स्क्रीन का एक उदाहरण सरल और समझने योग्य होगा। यहाँ डेवलपर MVC आर्किटेक्चर को लागू करना शुरू करता है। ऐसा लगता है कि एक अलग दृश्य है, जैसे मॉडल के साथ नियंत्रक भी जोड़ता है, जैसा कि यह होना चाहिए। लेकिन कुछ बिंदु पर वे सोचते हैं: "मुझे एक ही बटन के साथ स्क्रीन के लिए कई कक्षाएं जोड़ने की आवश्यकता क्यों है?" और इस समय मैं दृढ़ता से ऐसे शातिर विचारों को त्यागने की सलाह देता हूं और यूआई और व्यावसायिक तर्क को अलग करने के लिए "फूट डालो और जीतो" के सिद्धांत का सख्ती से पालन कर रहा हूं। और यहां तक कि अगर आर्किटेक्चर को ViewModel क्लास के अतिरिक्त की आवश्यकता होती है, जिसमें कोड की एक दो लाइनें होंगी, तो आपको ऐसा करना चाहिए। क्योंकि अक्सर ऐसे मामले होते हैं जब एक स्क्रीन जिसमें मूल रूप से एक बटन होता था, समय के साथ, अकल्पनीय कठिनाइयों में बढ़ता है। यदि आप पहले से तार्किक घटकों के अलगाव का पालन करते हैं, तो यह भविष्य में जीवन को बहुत सुविधाजनक बना देगा।
आप विशेष रूप से यूआई और तर्क के सख्त अलगाव का सार महसूस कर सकते हैं, ऐसे मामलों में जहां आपको स्क्रीन को एक परियोजना से दूसरे में स्थानांतरित करना होगा। या ऐसी स्थिति में, जहां विभिन्न परिस्थितियों में, व्यापार तर्क में विभिन्न एल्गोरिदम का उपयोग किया जाता है। उदाहरण के लिए, प्राधिकरण स्क्रीन को घटकों में विभाजित करके, हम भविष्य में एक घटक को दूसरे को प्रभावित किए बिना प्रतिस्थापित कर सकते हैं। हम एक ही डेटा के लिए नए प्राधिकरण तरीकों के साथ व्यू या मॉडल को बदल सकते हैं।
केवल इन दो परतों को "विभाजित और जीत" के सिद्धांत को सीमित न करें। सख्त जुदाई के लिए, मैं मोबाइल एप्लिकेशन के लिए स्क्रीन और नेविगेशन तर्क को अलग कर दूंगा। मुझे इससे क्या मतलब है?
मेरे अभ्यास ने मुझे अलग से नेविगेशन लॉजिक को निकालकर किसी विशेष स्क्रीन के लिए कोड करना आसान बनाने के लिए प्रेरित किया है। IOS के लिए एक स्क्रीन, विशेष रूप से देखें, एक UIViewController है, और कभी-कभी एक UIView, और Android गतिविधि, या फ़्रैगमेंट के लिए, उन्हें स्वयं को प्रदर्शित करने के लिए एक फ़ंक्शन में संलग्न नहीं होना चाहिए, साथ ही साथ अन्य स्क्रीन पर स्विच करना चाहिए। इन कक्षाओं में से प्रत्येक को केवल एक विशेष स्क्रीन पर क्या हो रहा है, इसकी परवाह करनी चाहिए, या केवल एक विशिष्ट स्क्रीन को प्रस्तुत करने और व्यावसायिक तर्क वर्ग (प्रस्तुतकर्ता, ViewModel और अन्य) के साथ बातचीत करने के लिए।
ये कई उदाहरणों में से केवल दो हैं जहां आपको अलगाव का मूल रूप से पालन करने की आवश्यकता है। इस सिद्धांत का पालन करने से परियोजना के साथ आगे काम करने में बहुत सुविधा होगी। भले ही गोवनोकॉड किसी भी अलग घटक में मिला हो।
एकल शैली
पिछली सलाह से आगे बढ़ते हुए, मैं अगले एक पर जाना चाहता हूं, अर्थात् परियोजना में एकल शैली का सख्त पालन।
मुझे इससे क्या मतलब है?
शुरू करने के लिए, यहां महत्वपूर्ण शब्द सख्त है, शब्द से बिल्कुल। प्रारंभ में, हम एक परियोजना के आयोजन के लिए, फ़ाइल प्रबंधन के लिए, कोड शैली के लिए, और इसी तरह एक एकल दृष्टिकोण का चयन करते हैं। यह परियोजना की सामान्य उपस्थिति में काफी सुधार करेगा और परियोजना के नेविगेशन की सुविधा प्रदान करेगा, कोड द्वारा खोज करेगा, और परियोजना के लिए एक नए डेवलपर को पेश करने की प्रक्रिया को गति देगा। मुझे लगता है कि यह याद दिलाने लायक नहीं है कि थोड़ी देर बाद हम खुद ही अपने पुराने कोड के साथ इस नए व्यक्ति के रूप में बन सकते हैं।
वास्तुकला का विकल्प और इसके बाद
फिर, पिछली सलाह से आगे बढ़ते हुए, हम आसानी से अगले एक के लिए आगे बढ़ते हैं, वास्तुकला का विकल्प। और मुख्य विचार जो मैं व्यक्त करना चाहता हूं वह सबसे अच्छा आर्किटेक्चर के बारे में बात करना या यह कहना नहीं है कि आपको इसे चुनने की आवश्यकता है और दूसरे को नहीं। नहीं! शुरू करने के लिए, कोई आदर्श वास्तुकला नहीं है जो परियोजना में सभी संभावित मामलों को पूरी तरह से कवर करेगा। मैंने एक बार इन शब्दों को सुना: "यदि एक आदर्श वास्तुकला थी, तो हम डेवलपर्स को अनावश्यक रूप से निकाल दिया जाएगा और आदर्श वास्तुकला को बनाने वाली लिपियों के साथ बदल दिया जाएगा।"
मुख्य बिंदु, मेरा मानना है कि सर्वश्रेष्ठ वास्तुकला का विकल्प नहीं है, लेकिन फिर से उस वास्तुकला का सख्त पालन करना जो पहले से ही चुना गया है और लागू किया जाना शुरू हो गया है। यह VIPER, REDUX, MVP या MVC हो। उपरोक्त सभी आर्किटेक्चर में प्रत्येक कोर्स के पेशेवरों और विपक्ष हैं। समय के साथ, परियोजना के वास्तुकला के डिजाइन के लिए अधिक से अधिक नए दृष्टिकोण।
मैं अपने विचार के बारे में विशेष रूप से कहूंगा। यदि आपने पहले ही VIPER का उपयोग शुरू कर दिया है, तो इसके सिद्धांतों का सख्ती से पालन करें। यहां तक कि अगर ऐसा लगता है कि एक-बटन स्क्रीन के लिए कोड की लाइनों की इकाइयां बनाने के लिए बहुत सारी फाइलें हैं, तो इन परिस्थितियों में इन नियमों को बायपास न करें। क्योंकि, ऐसे क्षणों में, गोवनोकॉड का जन्म होता है, जो तब, एक स्नोबॉल की तरह, सब कुछ बढ़ता है और बढ़ता है।
मैं आपको सलाह देता हूं कि आप सबसे लोकप्रिय आर्किटेक्चर से परिचित हों और एक नया प्रोजेक्ट शुरू करने से पहले आपको जो पसंद हो या जो सबसे ज्यादा पसंद हो, उसे चुनें। मैं दृढ़ता से दूसरा विकल्प चुनने की सलाह देता हूं, अर्थात् सबसे लोकप्रिय वास्तुकला के साथ शुरू करना, जैसा कि कई सवालों के जवाब ढूंढना आसान होगा। आर्किटेक्चर चुनते समय, इस आर्किटेक्चर के मिनस पर विशेष ध्यान दिया जाना चाहिए और ऐसे मामलों में इसे इस्तेमाल करने की सलाह दी जाती है।
उदाहरण के लिए, यदि एक छोटी परियोजना, जिस पर एक दो डेवलपर्स हैं, तो आपको इस तथ्य के कारण VIPER नहीं लेना चाहिए कि यह एक बोझिल वास्तुकला है, जो बड़ी परियोजनाओं और बड़ी टीमों में बहुत अच्छा है। इसलिए कि कोई मामला नहीं है जब VIPER बनाने का कोड व्यवसाय तर्क के कोड से कई गुना अधिक हो।
व्यक्तिगत रूप से, मैं अब MVVM + राउटर आर्किटेक्चर को पसंद करता हूं। यह एक छोटे से प्रोजेक्ट पर अच्छी तरह से काम करता है जहां मैं एकल डेवलपर हूं।
नीचे की रेखा: मुख्य बात यह नहीं है कि आपने किस वास्तुकला को चुना है, लेकिन आप वास्तव में इसका पालन कैसे करते हैं।
मैं यह भी जोड़ना चाहता हूं, अगर परियोजना को खरोंच से विकसित नहीं किया जा रहा है, तो सबसे पहले आपको वर्तमान वास्तुकला और परियोजना की सामान्य शैली के साथ खुद को परिचित करने की आवश्यकता है, और इसका पालन करना शुरू करें। आपको चीखों के साथ बाहर नहीं निकलना चाहिए कि गोवनोकॉड (पहली सलाह पर वापस लौटना) है और सब कुछ फिर से शुरू करना है। एक अपवाद परियोजना पर एक पूर्ण अराजकता या एक सामान्य शैली की कमी हो सकती है।
रिफ़ेक्टिंग पॉज़
अंत में, मैं कहना चाहता हूं कि रिफैक्टिंग के लिए रुकना एक अच्छा तरीका है। Refactoring गुणवत्ता अनुप्रयोग विकास का एक बहुत महत्वपूर्ण हिस्सा है। हां, हम एकदम सही कोड नहीं लिखते हैं, लेकिन इसे छोड़ना भी अच्छा नहीं है। यह अक्सर ऐसा होता है कि मूल कार्यान्वयन में नई सुविधाओं को पेश करने की आवश्यकता होने पर पैमाने की क्षमता नहीं होती है। आखिरकार, परियोजना के भविष्य के संस्करणों में सभी संभावित परिवर्तनों की भविष्यवाणी करना लगभग असंभव है। इसके अलावा, कोई भी आर्किटेक्चर सभी मामलों की 100% कवरेज की गारंटी नहीं देता है। इसलिए, नई विशेषताओं के अनुकूल होने के लिए मौजूदा कोड में बदलाव करना महत्वपूर्ण है।