😐 ☔️ 🐘 द गुड, बैड एंड द अग्ली कोड 👩🏾‍⚕️ 👨🏿‍🌾 🍼

अच्छा कोड या बुरा? मेरे लिए व्यक्तिगत रूप से, एक अच्छे कोड में निम्नलिखित गुण हैं:

विभिन्न कौशल के डेवलपर्स के लिए कोड समझना आसान है और अच्छी तरह से संरचित है
कोड को संशोधित करना और बनाए रखना आसान है।
आवेदन अपने कार्यों को करता है और कार्यों की वर्तमान सीमा के लिए पर्याप्त दोष सहिष्णुता है

इन तीन स्थितियों को कैसे प्राप्त किया जाए, इसके संक्षिप्त विवरण के बावजूद, कई मोटी किताबें लिखी गई हैं।

आखिर ये मापदंड क्यों? तुरंत एक आरक्षण करें, हम अब व्यवसाय के लिए सॉफ्टवेयर विकसित करने के बारे में बात कर रहे हैं (उद्यम अनुप्रयोग) । वास्तविक समय प्रणाली, विमान, जीवन समर्थन प्रणाली और आईएसएस के लिए कोड मूल्यांकन मानदंड अलग हैं।

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

केस नंबर 1

प्रपत्र में एक पाठ इनपुट फ़ील्ड (textarea) है। आप वहां 100500 वर्ण दर्ज कर सकते हैं और हमारा आवेदन "अधिकतम अनुरोध की सीमा पार हो चुकी है" अपवाद के साथ नीचे गिर जाएगा।

क्या यह हमारा मामला है? शायद ही। यदि यह सार्वजनिक हिस्सा है, तो यह एक जावा-स्क्रिप्ट सत्यापनकर्ता को डालने और ऐसे रूपों को पोस्ट करने की अनुमति नहीं देने के लायक है। उन लोगों के लिए एक अतिरिक्त सर्वर सेट करना जिनके पास जावा-स्क्रिप्ट अक्षम है, बस समय की बर्बादी है, जिसका अर्थ है बजट। हम ऐसा नहीं करेंगे। हां, हमारे आवेदन में एक संभावित त्रुटि है। क्या किसी को ठीक करने की जरूरत है? नहीं।

केस नंबर 2

क्लाइंट से एक अनुरोध आता है: हमें एक सहयोगी पृष्ठ की आवश्यकता है। इस पृष्ठ में उनमें से प्रत्येक के बारे में संक्षिप्त जानकारी और उस पृष्ठ का एक लिंक होगा जिस पर हमें साथी के साइट से पेज को iffame में एम्बेड करना होगा।

एक दिलचस्प मामला। हमें संभवतः डेटाबेस में बदलाव करने की आवश्यकता है, साझेदार इकाई को जोड़ें, हम डीबी-इकाई को व्यू द्वारा डिज़ाइन नहीं करते हैं, इसलिए हमें डीटीओ, डीबी-इकाई से डोपो के लिए एक मैपिंग फ़ंक्शन और ऑटो तैनाती के लिए डेटाबेस माइग्रेशन की आवश्यकता है। हम्म, हमें अभी भी एक साथी जोड़ने के लिए व्यवस्थापक पैनल में एक पृष्ठ की आवश्यकता है। नियंत्रक के लिए मार्ग के बारे में मत भूलना, ताकि वहाँ / भागीदार / <PARTNER_NAME> बहुत सारे काम हो ...

10,000 भागीदारों के लिए सच है। आइए रुचि लेते हैं: "कितने भागीदार होंगे" ? यदि उत्तर है "यह वर्ष तीन है।" हमें अपने विचारों पर पुनर्विचार करना चाहिए। यह फिर से समय और बजट की बर्बादी है। केवल 3 साथी?

namespace Habrahabr.Models.Partner { public class PartnerViewModel { public string Name { get; set; } public string WebSiteUrl { get; set; } public string ShortDescription { get; set; } public string FullDescription { get; set; } } } using System.Web.Mvc; using Habrahabr.Models.Partner; namespace Habrahabr.Controllers { public class PartnerController : Controller { private static PartnerViewModel[] partners = new[] { new PartnerViewModel() { Name = "Coca-Cola", WebSiteUrl = "http://coca-cola.com/partner", ShortDescription = "Coca-cola short description", FullDescription = "Coca-cola full description" }, new PartnerViewModel() { Name = "Ikea", WebSiteUrl = "http://ikea.com/partner", ShortDescription = "Ikea short description", FullDescription = "Ikea full description" }, new PartnerViewModel() { Name = "Yandex", WebSiteUrl = "http://yandex.ru/partner", ShortDescription = "Yandex short description", FullDescription = "Yandex full description" } }; public ActionResult Index() { // TODO: populate partners from database if a lot of partner required return View(partners); } // TODO: refactor this if a lot of partner required [ActionName("Coca-Cola")] public ActionResult CocaCola() { return View("_PartnerDetail", partners[0]); } public ActionResult Ikea() { return View("_PartnerDetail", partners[1]); } public ActionResult Yandex() { return View("_PartnerDetail", partners[2]); } } } @model IEnumerable<Habrahabr.Models.Partner.PartnerViewModel> <ul> @foreach (var p in @Model) { <li> <h3>@Html.ActionLink(p.Name, p.Name, "Partner")</h3> <div>@p.ShortDescription</div> <p class="info">@Html.ActionLink("Partner page", p.Name, "Partner")</p> </li> } </ul> @model Habrahabr.Models.Partner.PartnerViewModel <h2>@Model.Name</h2> <div>@Model.FullDescription</div> @if (!string.IsNullOrEmpty(Model.WebSiteUrl)) { <iframe width="100%" height="500" src="@Model.WebSiteUrl"></iframe> }

सब कुछ के बारे में सब कुछ के लिए - एक घंटे का अधिकतम समय, ग्रंथों के इनपुट को ध्यान में रखते हुए। हमने एक अच्छा साथी पृष्ठ विकसित किया है। क्या यह हमारे मानदंडों को पूरा करता है:

स्पष्ट और संरचित - हाँ
बदलने में आसान - हाँ
विश्वसनीय पर्याप्त - हाँ

डोमेन, डेटा एक्सेस और एप्लिकेशन आर्किटेक्चर

फाउलर ने अपनी पुस्तक एंटरप्राइज पैटर्न ऑफ एंटरप्राइज एप्लीकेशन आर्किटेक्चर में सही ढंग से उल्लेख किया है कि "आर्किटेक्चर" शब्द अविश्वसनीय रूप से धुंधला है:

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

भागीदारों के साथ उपर्युक्त वर्णित दृष्टिकोण में एक महत्वपूर्ण सीमा है। आप इस शैली में लगातार आवेदन कोड नहीं लिख सकते हैं। जल्दी या बाद में, सिस्टम बढ़ेगा। इस मामले में, हमने एप्लिकेशन लॉजिक को "सिले" किया। इन नियंत्रकों में से एक जोड़ी और सिस्टम को समझना काफी मुश्किल होगा, खासकर नए डेवलपर्स के लिए।
फिलहाल जब यह पता चला कि 3 भागीदार नहीं होंगे, लेकिन 100,500 और सभी को नहीं दिखाया जाना चाहिए, लेकिन केवल उन लोगों को, जिन्होंने शुक्रवार से शनिवार (13 से 14) की रात को भुगतान किया और 6 कुंवारी कन्याओं का बलिदान किया, और पृष्ठों को घुमाया जाना चाहिए बृहस्पति के संबंध में शुक्र की स्थिति का अनुपालन (वास्तविक जीवन में, मामले, निश्चित रूप से अलग हैं, लेकिन यह कुछ भी नहीं है कि वे डेवलपर के लिए कहते हैं कि "व्यावसायिक तर्क" की तुलना में अधिक अतार्किक नहीं है, जिसमें पूरी तरह से अपवाद और विशेष मामले शामिल हैं)। आपको शब्द के दोनों इंद्रियों में वास्तुकला के बारे में सोचने की आवश्यकता है।

हमने पहले ही आवेदन में "सीम" छोड़ दिया, हम उन्हें अलग करना शुरू कर देंगे और आवश्यक टुकड़ों को सीवे देंगे। हम ORM का उपयोग करेंगे, भागीदार दृश्यमॉडल का नाम बदलकर भागीदार करेंगे और भागीदार वर्ग को डेटाबेस में मैप करेंगे। मैंने कभी भी डेटाबेस-प्रथम का उपयोग नहीं किया और कोड-प्रथम दृष्टिकोण के साथ संस्करण जारी होने तक एंटिटी फ्रेमवर्क को गंभीरता से नहीं लिया। इस मामले में, मुझे PartnerViewModel में भागीदार को मैप करने की आवश्यकता नहीं है। हां, शब्दार्थ ये संस्थाएं अलग-अलग कार्य करती हैं और सामान्य तौर पर, PartnerViewModel अलग हो सकता है, लेकिन अभी तक एक ही वर्ग लिखने का एक भी कारण नहीं है। जब आप दृश्य में तर्क को घसीटे बिना इसके बिना नहीं कर सकते, तब Mapit ViewModel समझ में आता है। आमतौर पर, ViewModels की आवश्यकता तब उत्पन्न होती है जब इंटरफ़ेस को एक जटिल रूप दिखाना होता है जो एक ही बार में डोमेन की कई संस्थाओं के साथ काम करता है, या मॉडल गुणों के लिए System.Web असेंबली से विशेषताओं का उपयोग करने की आवश्यकता होती है। बाद के मामले में, मैं इस निर्भरता को एक विषय क्षेत्र के साथ विधानसभा में खींचने के लिए इच्छुक हूं, अगर मुझे यकीन है कि अगले छह महीनों में मुख्य वेब एप्लिकेशन को छोड़कर, आवेदन में एक नया प्रवेश बिंदु नहीं होगा।

एक परियोजना जिसमें मैंने भाग लिया था, डेटा को एक्सेस करने के लिए एक सेवा को कॉल करना आवश्यक था जो कि मुखौटा को एक्सेस करता था, जो बदले में डीएएल परत को एक्सेस करता था जिसे एंटिटी फ्रेमवर्क कहा जाता था। अग्रभाग और DAL अलग-अलग विधानसभाओं में थे, और EF ने डेटाबेस-प्रथम दृष्टिकोण का उपयोग किया। डीएएल ने आमतौर पर सभी तर्क दिए, और बाकी परतें 90% मामलों में परिणाम को बिल्कुल समान डीटीओ में बदल देती हैं । इसी समय, सिस्टम में कोई अन्य क्लाइंट नहीं था और सेवा उद्देश्यपूर्ण रूप से अनावश्यक थी। जब मैंने पूछा कि "ऐसा ओवरहेड क्यों है", तो डेवलपर ने प्रोजेक्ट पर काम किया है, ने कहा: "मुझे नहीं पता, हमारे अन्य प्रोजेक्ट इस तरह लिखे गए हैं, हमने इसे सादृश्य द्वारा करने का फैसला किया है।" हां, इस "अन्य परियोजना" में 20 अनुप्रयोग शामिल थे और इसे तैनात करने में केवल 2 दिन लगे। इस एप्लिकेशन के एपीआई में कई ग्राहक हैं। इस तरह की एक जटिल संरचना एक आवश्यकता थी। हमारे मामले में, यह गौरैया पर एक तोप से शूटिंग कर रहा था।

लेकिन वापस हमारे ~~राम~~ भागीदारों के लिए। यह समझने के लिए बना रहता है कि प्रदर्शन के लिए आवश्यक भागीदारों को चुनने के लिए जिम्मेदार कोड कहां लिखना है। मैं आपको याद दिलाता हूं कि अब हमें शुक्र और बृहस्पति पर विचार करना चाहिए। सबसे खराब जगह नियंत्रक है। ऐसा करने से, हम एप्लिकेशन के तर्क को इसके विभिन्न भागों में बिखेर देते हैं, और नए डेवलपर्स को हैरी पॉटर की तरह इसे (तर्क) इकट्ठा करना होगा, जिन्होंने क्रूस का संग्रह किया था।
एक अच्छा विकल्प विनिर्देश ~~रिपॉजिटरी~~ पैटर्न का उपयोग ~~करना है~~ ।

आईओसी / डि

एप्लिकेशन की वृद्धि के साथ, इसे बहुत कसकर जुड़े होने का खतरा है, और यह सिस्टम को धीमा कर देगा और कोड परिवर्तनों में हस्तक्षेप करेगा।

मैं एक बार फिर वर्णन नहीं करूंगा कि IOC / DI क्या है और इसके साथ क्या खाया जाता है, आपको बस इसे एक नियम के रूप में लेने की आवश्यकता है:

स्पष्ट रूप से निर्भरता न बनाएं
आईओसी कंटेनरों का उपयोग करें

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

परीक्षण

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

प्रणाली का और विकास

यदि आवेदन बढ़ना जारी है, तो विशिष्ट सलाह देना मुश्किल है: विचार करने के लिए बहुत सारे कारक हैं। बहुत कुछ परियोजना की बारीकियों पर निर्भर करता है। एक अच्छा समाधान SOA हो सकता है। सामान्य तौर पर, किसी भी बड़ी प्रणाली का अपघटन एक महान विचार है। दस परियोजनाएं आपके आईडीई या सौ पर अपलोड की जाती हैं - अंतर बहुत बड़ा है। इस पैमाने के सॉफ्टवेयर को विकसित करते समय, स्क्रिप्ट, इंस्टॉलर और रिलीज प्रबंधन को तैनात करना अपरिहार्य है, लेकिन यह पूरी तरह से अलग कहानी है ...

लैम्ब्डा, पहलू, कार्यक्षमता और अन्य होलीवर

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

प्रतिमानों को संयोजित करने से डरो मत, अगर यह इसके लायक है। अपने आप से सवाल पूछें "कार्य के लिए कितना मंच / भाषा / ओएस उपयुक्त है?" और "क्या तकनीक मुझे कार्य को यथासंभव कुशलता से पूरा करने में मदद करेगी?" मेरी बात एक इलियकान उद्धरण द्वारा सबसे अच्छी तरह चित्रित की गई है:

मुझे लगा कि एर्लैंग सीखने के लिए तेज़ होगा या जावा को तेज़ी से काम करने के लिए मिलेगा और एर्लैंग को सीखने का फैसला किया

द गुड, बैड एंड द अग्ली कोड