क्या सलाहकार सक्षम है? समस्याएं अनुशंसाएं "पहिया को फिर से न करें"

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

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

लेकिन एक ही समय में, एक प्रमुख कारक जो न केवल सॉफ्टवेयर विकास के लिए विशेषता है, बल्कि किसी भी समस्या को हल करने के लिए भी याद किया जाता है : जब कार्य सेट किया जाता है, तो संदर्भ बदलने पर समाधान भी बदल जाता है ।

इस सिद्धांत की दृष्टि खोने के लिए लागू समस्याओं को हल करने में अपनी स्वयं की अक्षमता स्वीकार करने के समान है।

कुछ मामलों पर विचार करें।

स्रोत

एपीआई पर एपीआई

साइकलिंग के आरोपों के सामान्य मामलों में से एक कुछ सेवा का स्वयं-लेखन एपीआई आवरण है, जिसका कार्यान्वयन पहले से ही उपलब्ध है।

मेरे अभ्यास से एक मामला।

फेसबुक से डेटा के अपलोड को हमारी सेवा में लागू करना आवश्यक था। फेसबुक से मुख्यधारा की भाषा और पुस्तकालय को केवल 2 मिनट में गुगला कर दिया गया।

पुस्तकालय प्रलेखन वर्तमान कार्यक्रम इंटरफ़ेस के अनुरूप नहीं था , प्रत्येक हेरफेर के आसपास बहुत सारे अनावश्यक कार्यों को लपेटा गया था। पुस्तकालय बहुत खराब गुणवत्ता का निकला ।

परिणाम: इसके साथ काम करने के 1.5 घंटे बाद, लॉग इन करना भी संभव नहीं था।

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

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

एक अच्छा सवाल : और क्या, प्रत्येक बार ऐसे रैपर को मैन्युअल रूप से लिखने के लिए?

उत्तर: बड़े रैपरों के लिए एक अधिक मजबूत समाधान एक कोड जनरेटर का उपयोग करना होगा जो विनिर्देशों की व्याख्या करता है।

कोड आधार पर नियंत्रण और दूसरों की गलतियों के लिए जवाब देने से इनकार करना

कंप्यूटर गेम के विकास में wannabe हलकों में, यह वाक्यांश किसी को भी संबोधित किया जाता है जो अपने इंजन को लागू करने की हिम्मत करता है। "पहिया को क्यों मजबूत करना है? एकता ले लो!" । या गेम मेकर, या, भगवान ना करे, डिफॉल्ड।

ऐसा लगता है कि dviglo \ constructor विकास के लिए सभी आवश्यक उपकरण प्रदान करता है। उनमें से कई क्रॉस-प्लेटफ़ॉर्म हैं और आमतौर पर जीवन को सरल बनाते हैं।

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

यह विशेष रूप से उन खेलों में स्पष्ट किया जाता है जो ग्राफिक और / या भौतिक घंटियों और सीटी के साथ संतृप्त नहीं होते हैं - कॉर्नी, इतना नहीं कि सशर्त इंजन खुद को लेता है।

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

उदाहरण के लिए, इस तरह के परिसर के आधार पर, टॉमी रेफनीज ने सुपर मीट बॉय के लिए अपना इंजन लिखा ।

किसी को आपत्ति होगी: "लेकिन भंडार गृह में \ _ कुछ अन्य भंडारण में, प्रीसेट \ टूल्स \ एक्सटेंशन का एक पहाड़ है!" ।

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

काल्पनिक पहचान। कानों से कार्य को खींचना।

कभी-कभी, समस्या को तैयार करने के बाद, यह पता चलता है कि मौजूदा समाधान जो मन में आते हैं ... उपयुक्त नहीं हैं। इसकी "वसा सामग्री" या कार्य की प्रमुख स्थितियों में से एक के असंतोष के कारण ( हाँ, कई हैं )।

अच्छा उदाहरण: क्लूनेट।

अपने लेख में क्लस्टर ने पूरी तरह से स्मार्ट होम प्रोटोकॉल विकसित करते समय उनके द्वारा लिए गए निर्णयों के कारणों का वर्णन किया है। उदाहरण बहुत खुलासा और अच्छी तरह से वर्णित है, मैं इसे खुद को अलग करने की सलाह देता हूं।

निष्कर्ष

किसी समस्या के समाधान की खोज करते समय , संदर्भ और दी गई सभी शर्तों पर विचार किया जाना चाहिए ।

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

या, कप्तान के सामान्यीकरण में:

निर्णय लेने से पहले सोचें।
बोलने से पहले सोचें।
और सामान्य तौर पर - सोचो।