प्रभावी डिजाइन का भ्रम: डिजाइन

यह पोस्ट एक अनुवर्ती है: प्रभावी विकास का भ्रम: प्रबंधन

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

परफेक्ट कोड चर्च

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

पेपर हवाई जहाज से लेकर शटल तक

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

दीवार की बाइक

आज हमारे पास github.com, sourceforge.net आदि जैसी कई बेहतरीन परियोजनाएं हैं, विशिष्ट भाषाओं के लिए कोड रिपॉजिटरी का उल्लेख नहीं करना। और यह उनकी उपस्थिति थी जिसने इस विश्वास को स्थापित करने के संदर्भ में महत्वपूर्ण भूमिका निभाई कि साइकिल खराब हैं और हमेशा तैयार समाधान है। बेशक, यदि आप विंडोज़ के लिए अपने gui टूलकिट या php के लिए एक टेम्पलेट इंजन लिखने का निर्णय लेते हैं, तो मैं सभी अधूरे व्यवसाय को छोड़ दूंगा, उठो, मेरी पैंट को जकड़ना और बहुमत की राय व्यक्त करते हुए अपने क्षेत्र से दूर जाना।
लेकिन जैसे ही हम उपरोक्त चीजों की तुलना में कुछ अधिक असामान्य हो जाते हैं, हम उन पुस्तकालयों की गुणवत्ता की पूर्ण पैमाने पर समस्या का सामना करेंगे जो इतने सुलभ लगते हैं। गुणवत्ता से, मेरा मतलब है 3 चीजें:

• कार्यक्षमता - आपको व्यक्तिगत रूप से उस क्षण को महसूस करने की आवश्यकता होती है जब यह पता चलता है कि चयनित पुस्तकालय में 10% कार्यात्मक नहीं है, जिस पर आपका 90% प्रोजेक्ट आयोजित किया जाएगा। डेवलपर्स आपके जैसे लोग हैं, और आमतौर पर ये बहुत आवश्यक 10% में सबसे गंदा काम शामिल है जो कोई भी नहीं करना चाहता है।
• प्रलेखन - खराब प्रलेखन केवल सभी युवा परियोजनाओं का संकट है, और इसके बिना, कोड में आपका स्वागत है
• कोड की गुणवत्ता - खराब और लापता प्रलेखन के मामले में एपीआई के विस्तार और या यहां तक ​​कि सीखने की संभावना को निर्धारित करता है

यदि आप पुस्तकालयों की गुणवत्ता को गंभीरता से देखते हैं, तब भी आप विकल्प को अनुमति दे सकते हैं जब आपको स्वयं एक एनालॉग लिखना होगा। सिर्फ इसलिए कि यह आसान हो जाएगा। यह तेज और अधिक कुशल होगा। तो यह गलत होगा। और आपकी बाइक वास्तव में विशेष हो सकती है - इस अर्थ में कि यहां तक ​​कि समाधानों की काल्पनिक प्रचुरता के साथ, उनमें से कोई भी आपको पूरी तरह से सूट नहीं करेगा। यद्यपि आप अपने संस्करण को गिथब पर पोस्ट करके इस संस्कार के लिए भोग प्राप्त कर सकते हैं। ताकि दूसरे लोग उस पर भड़क जाएं या अपना लिखें। और अनुप्रयोग परिनियोजन समय पुस्तकालयों की संख्या के लिए सीधे आनुपातिक है जिन्हें इसके साथ तैनात करने की आवश्यकता है।
अलग से, एक नई परियोजना के बीच चयन करने या मौजूदा समाधान विकसित करने की समस्या है। यह पसंद वेब-प्रोग्रामर पर भारी पड़ती है - वेब पर प्रोजेक्ट्स के शेरों की हिस्सेदारी बहुत विशिष्ट होती है, जिसके लिए सीएमएस, वेब-शॉप्स, सोशल नेटवर्क आदि के इंजन होते हैं। पहली नज़र में, यह हमेशा लगता है कि ToR की आवश्यकताओं के लिए मौजूदा समाधान को खत्म करना तर्कसंगत है, अपने खुद के लिखने से। खरोंच से बाइक। एक पंक्ति में एक ही इंजन पर कई परियोजनाओं को अंजाम देने के बाद यह विशेष रूप से तर्कसंगत लगता है, और जल्दी और शान से। हालांकि, आप जलाए जा सकते हैं, वास्तुकला की सीमा में या एक फैंसी लेआउट में आराम कर सकते हैं, या यहां तक ​​कि उस गति में जिसके साथ काम पूरा होने के बाद सब कुछ काम करेगा। अपने लिए, मैंने अंगूठे के एक नियम को काट दिया - यदि परियोजना मेरे अनुमानों के अनुसार, एक महीने से अधिक समय तक चलती है, तो खरोंच से या सामान्य ढांचे पर लिखना बेहतर है। ठीक है, सबसे अच्छा - मैं बेहतर हूं, और आपको अपने नियमों को प्राप्त करना होगा जो आप के साथ काम कर रहे हैं उसके आधार पर।
बस याद रखें कि ऐसे समय होते हैं जब नियमित अभिव्यक्तियों के साथ xml को पार्स करना libxml के लिए बाध्यकारी का उपयोग करना बेहतर होता है, और एक आसान सा ऑनलाइन स्टोर लिखना Yii पर PrestaShop के आधार पर आसान होगा। सब कुछ, ज़ाहिर है, हमारे सामने पहले से ही आविष्कार किया गया है, लेकिन यह सब इस तरह से कोड में सन्निहित नहीं है कि इसे आसानी से उपयोग किया जा सके।

तकनीक में सबसे आगे

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

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

फिर, इस बात से अवगत रहें कि आपने नई वाई तकनीक को क्यों चुना है, यदि आपके पास एक्स तकनीक है जो पहले से ही अच्छी तरह से परीक्षण किया गया है, एक समुदाय है, और आमतौर पर हर जगह है।

सिद्धांत और अभ्यास

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

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

इसलिए जैसा आप चाहते हैं उन्हें समझें। और ओलंपियाड और औद्योगिक प्रोग्रामिंग के बीच अंतर को याद रखें।

सिर्फ गलती नहीं है

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

तिमलिद - हमारे राजा, पिता और भगवान

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

निष्कर्ष

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