आयओएस आर्किटेक्चर डिझाइन करीत आहे: प्रेरणा

चला या लेखाच्या मालिकेत स्वतःचे आर्किटेक्चर तयार करण्याच्या विषयाकडे जाऊया.

आर्किटेक्चर म्हणजे काय?

आर्किटेक्चर सिस्टम डिझाइनची उच्च पातळी आहे.

सिस्टम डिझाइन हा अनुप्रयोगासाठी कोडचे उत्पादन सुलभ करण्याचा एक मार्ग आहे.

अनुप्रयोग (व्यवसाय) ध्येय पूर्ण करण्यासाठी आवश्यक असे एक माध्यम आहे.

मी ते वगळू शकतो?

आपण अ‍ॅप तयार करण्यापूर्वी सिस्टम डिझाइन तयार करत नसलात तरीही कोणताही कोड लिहिण्यापूर्वी आपल्याला विचार करावा लागतो आणि याला अपघाती सिस्टम डिझाइन म्हणतात, ज्यामुळे अपघाती आर्किटेक्चर (एए) होते.

अपघाती वास्तुकला शोधणे सोपे आहे:
प्रश्न: आमचा कोड इतका कुरूप का आहे?
उत्तरः ऐतिहासिक कारणे ...

मी काय मिळवू?

कोडिंग सामग्रीमध्ये उडी मारण्याऐवजी औपचारिक आर्किटेक्चरची स्थापना करण्याचा उद्देश मार्गदर्शक तत्त्वे, बंधने आणि नमुने स्थापित करणे हा आहे ज्यानुसार कोड वाढणार आहे.

कोडच्या मार्गावर रेल्वेने जाण्यासाठी रेलमार्ग घालून आर्किटेक्चर बसविण्याचा विचार करा.

मी स्वत: ला का रोखू?

मार्गदर्शक तत्त्वे, प्रतिबंध आणि नमुने यास मदत करतात:

  • किमान आश्चर्यचकित तत्त्व अनुसरण कोड;
  • विद्यमान प्रणाली कशी कार्य करते ते समजून घ्या;
  • चाक reinventing टाळण्यासाठी;
  • समाजात कार्यरत कल्पनांचा प्रसार करा.

मी इंटरनेटवरून त्यापैकी एक वापरू शकतो?

आपण त्यांच्याकडून शिकले पाहिजे, परंतु ते सर्व बर्‍याच समस्यांनी ग्रस्त आहेत:

  • वाढीची रणनीती देऊ नका;
  • अ‍ॅप्स आणि कार्यसंघाच्या केवळ एका आकारासाठी चांगले फिट;
  • घटक अमूर्तता आणि संप्रेषणाची यादृच्छिक पातळी;
  • भूमिकांचे अस्पष्ट वितरण (मी आपल्याकडे “कामगार” पहात आहे);
  • अक्षम्य आणि धर्मांध;)

ते डिझाइन करण्यासाठी माझ्याकडे पुरेशी कौशल्ये आहेत?

कोणाकडेही पुरेसे नाही, परंतु आपल्याकडे जितके जास्त असेल तितक्या बोगद्याच्या शेवटी प्रकाश पाहणे तितके सोपे आहे.
आपल्याला मदत करेल ते येथे आहेः

  • सिस्टम डिझाइन आणि नमुन्यांविषयी जुनी पुस्तके आणि श्वेत पत्रे वाचा;
  • आपल्याला चांदीची गोळी विकायचा प्रयत्न करीत नवीन लेख टाळा;
  • उत्पादनातील इतरांसाठी काय कार्य करते ते जाणून घ्या;
  • इतर प्लॅटफॉर्मचा प्रेरणा स्त्रोत म्हणून वापरा;
  • घरी कल्पना वापरुन पहा, जर ते काम करत असतील तर त्यांना कामावर आणा;
  • जर तुम्हाला शंका असेल तर निर्णय पुढे ढकलून घ्या (त्यादरम्यान एक मुर्ख वस्तू बनवा);
  • इतरांसह कल्पना आणि अंमलबजावणीबद्दल चर्चा करा.

कोठे सुरू करावे?

ध्येयातून आलेल्या आवश्यकतांचे (कोणत्याही परिपक्व प्रयत्नांप्रमाणे) विश्लेषण करून आपण नेहमीच सुरुवात केली पाहिजे.

कार्यात्मक आवश्यकता.

सर्वात वाईट परिस्थितीत आपण यासारखे उच्च-स्तरीय कार्यात्मक तपशील मिळवू शकता:

  • खरेदी सूची अनुप्रयोग;
  • याद्यांसह सहयोग करण्याची क्षमता;
  • इंटरनेट कनेक्शनशिवाय वापरण्याची क्षमता.

या टप्प्यावर, व्यवसायाला वाटेल की आवश्यकता पुरेसे आहेत, आणि उद्भवलेल्या प्रश्नांची उत्तरे शोधण्याची आपली जबाबदारी आहे, उदाहरणार्थः

  • यूआय कसा दिसेल?
  • अ‍ॅपला कोणत्या डिव्‍हाइसेसचे समर्थन करावे आहे?
  • मला सर्व्हर-साइड देखील तयार करावे लागेल?

जेव्हा आपण विचारण्यासाठी इतर प्रश्नांचा विचार करू शकत नाही, तेव्हा पुढच्या टप्प्यावर जाण्याची वेळ आली आहे.

संस्थात्मक आवश्यकता.

जर तो ग्रीनफील्ड प्रकल्प नसेल तर आपल्या आर्किटेक्चर निवडीवर बरेच प्रतिबंध असू शकतात, किमान या प्रश्नांची उत्तरे देण्याचा प्रयत्न करा:

  • माझी टीम कोण आहे?
  • आमच्या आर्किटेक्चरमधून त्यांना काय अपेक्षा आहे?
  • आपल्याकडे साधने आणि भाषा स्थापित आहेत?
  • आम्ही अस्तित्त्वात असलेल्या आर्किटेक्चरचा पुन्हा वापर करू शकतो?

मी शेवटी आर्किटेक्चर बनवू शकतो?

होय आपण हे करू शकता! कार्यात्मक आणि संस्थात्मक गरजा एकत्र ठेवून, आपण आपल्या कल्पनांची रूपरेषा सुरू करू शकता आणि नंतर एक औपचारिक आर्किटेक्चर तयार करू शकता! पण सांगायची ही एक पूर्णपणे वेगळी कहाणी…

मी आता घरी जाऊ शकतो?

आपण आपल्या कल्पना जंगलात घेण्यापूर्वी, मी सुचवितो की तुमच्या सोयीसाठी मी संकलित केलेल्या सर्वसमावेशक चेकलिस्टच्या विरूद्ध त्यांच्यावर ताण-चाचणी घ्या.

चेकलिस्ट कशी वापरायची?

आपल्या उमेदवाराचे आर्किटेक्चर घ्या आणि चाचणी घेण्यासारख्या प्रश्नांची उत्तरे देऊन त्याचे वकील असल्याचे भासवा (iOS समुदायाची ज्यूरी कल्पना मदत करते).

वाचल्याबद्दल धन्यवाद!

प्रतिसादासाठी मला ट्विटरवर संदेश द्या.

येथून कुठे जायचे?

विद्यमान iOS आर्किटेक्चर्सचे विहंगावलोकन.
एमव्हीसी पॅटर्नचा आढावा.