"उचित" प्रोग्रामिंग अब क्या मायने रखती है?


49

मैं अपने खाली समय में एक Android गेम बना रहा हूं। यह libgdx लाइब्रेरी का उपयोग कर रहा है इसलिए मेरे लिए काफी भारी लिफ्टिंग की गई है।

विकास करते समय, मैंने लापरवाही से कुछ प्रक्रियाओं के लिए डेटाटिप्स का चयन किया। मैंने हैशटेबल का उपयोग किया क्योंकि मुझे एक सहयोगी सरणी के करीब कुछ चाहिए था। मानव पठनीय प्रमुख मूल्य। इसी तरह की चीजों को प्राप्त करने के लिए, मैं एक वेक्टर का उपयोग करता हूं। मुझे पता है कि libgdx में वेक्टर 2 और वेक्टर 3 कक्षाएं हैं, लेकिन मैंने कभी उनका उपयोग नहीं किया है।

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

for(int i = 0; i < items.length; i ++)
{
    // do something
}

मुझे पता है कि यह हर पुनरावृत्ति पर item.length का मूल्यांकन करता है। हालांकि, मुझे यह भी पता है कि आइटम कभी भी 15 से 20 से अधिक आइटम नहीं होंगे। तो क्या मुझे ध्यान देना चाहिए कि क्या मैं हर पुनरावृत्ति पर आइटम्स का मूल्यांकन करता हूँ?

मैंने यह देखने के लिए कुछ परीक्षण चलाए कि ऐप किस विधि का उपयोग करता है जिसे मैंने केवल उचित बनाम वर्णित किया है, ट्यूटोरियल का पालन करें और समुदाय द्वारा सुझाए गए सटीक डेटा प्रकारों का उपयोग करें। परिणाम: एक ही बात। औसत 45 एफपीएस। मैंने फोन और गैलेक्सी टैब पर हर ऐप खोला। कोई फर्क नहीं।

इसलिए मुझे लगता है कि मेरा सवाल आपसे यही है: क्या कोई सीमा है जब यह उचित नहीं है? क्या यह कहना ठीक है - "जब तक यह काम पूरा हो जाता है, मुझे परवाह नहीं है?"


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

8
यदि आपकी भाषा में वास्तविक लूप था, तो वह बहु मूल्यांकन मूल्यांकन नहीं होगा। दुर्भाग्य से, सी सिंटैक्स को इसकी आवश्यकता होती है, क्योंकि यह वास्तव में एक लूप नहीं है; यह एक विग और बड़ी नाक वाले चश्मे पहने हुए एक लूप लूप है, और लूप लोन के लिए किसी भी मनमानी स्थिति (या बिल्कुल भी नहीं) को स्वीकार करना आवश्यक है।
मेसन व्हीलर

2
मैं आपका संपादन देख रहा हूं, लेकिन अगर आप इस मामले को बनाने की कोशिश कर रहे हैं कि नशे में होना और लापरवाह होना किसी भी संदर्भ में ठीक है, एक निर्दिष्ट ड्राइवर के साथ शुक्रवार की रात को पार्टी करने के अलावा, आप शायद गलत पेड़ को भौंक रहे हैं।
रॉबर्ट हार्वे

17
आप कैसे जानते हैं कि यह प्रत्येक पुनरावृत्ति पर 'item.length' का मूल्यांकन करता है। कंपाइलर बहुत स्मार्ट हैं। और यहां तक ​​कि अगर यह बार-बार item.length प्राप्त करता है, तो क्या? मुझे 'int itemsLength = items.length' जैसा कोड देखने से नफरत होगी; (; i <आइटम्सलेंग्थ; ...) 'के लिए जब तक कि एक मापा प्रदर्शन समस्या नहीं थी।
केविन क्लाइन

6
आपके आइटम्स। लर्निंग चीज़ का "उचित प्रोग्रामिंग" से कोई लेना-देना नहीं है। यह एक माइक्रो-ऑप्टिमाइज़ेशन है, और अच्छे प्रोग्रामर उन पर समय बर्बाद करने से बेहतर जानते हैं जब तक कि वे एक प्रोफाइलर नहीं चलाते हैं और जानते हैं कि वास्तविक समस्याएँ कहाँ हैं। माइक्रो-ऑप्टिमाइज़ेशन और अच्छी प्रोग्रामिंग शैली अक्सर विपरीत होती है, एक ही चीज़ नहीं।
माइकल बोर्गवर्ड

जवाबों:


65

आप किसी समस्या को हल करने के लिए एक प्रोग्राम लिखते हैं। यह समस्या इसे हल करने के लिए आवश्यकताओं के एक विशिष्ट सेट के साथ है। यदि उन आवश्यकताओं को पूरा किया जाता है, तो समस्या हल हो जाती है और उद्देश्य प्राप्त होता है।

बस।

अब, कारण यह है कि सर्वोत्तम प्रथाओं का पालन किया जाता है क्योंकि कुछ आवश्यकताओं को बनाए रखने, परीक्षण करने, प्रदर्शन की गारंटी और आगे के साथ क्या करना है। नतीजतन, आपके पास मेरे जैसे pesky लोग हैं जिन्हें उचित कोडिंग शैली जैसी चीजों की आवश्यकता होती है। यह आपके टी और डॉट को आपके I को पार करने के लिए उतना अधिक प्रयास नहीं करता है, और यह उन लोगों के लिए सम्मान का एक संकेत है जिन्हें आपके कोड को बाद में पढ़ना है और यह पता लगाना है कि यह क्या करता है।

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

स्पेक्ट्रम के विपरीत छोर पर वे वन-ऑफ यूटिलिटीज हैं, जिन्हें आप एक विशेष समस्या को हल करने के लिए लिखते हैं, यूटिलिटीज जिन्हें आप फिर कभी उपयोग नहीं करेंगे। उन मामलों में, शैली और सर्वोत्तम अभ्यास पूरी तरह से अप्रासंगिक हैं; आप चीज़ को एक साथ हैक करते हैं, उसे चलाते हैं, और अगली चीज़ के साथ आगे बढ़ते हैं।

इसलिए, जैसा कि सॉफ्टवेयर डेवलपमेंट में बहुत सारी चीजें हैं, यह निर्भर करता है।


1
मैं सहमत हूं। काम पर मैं सवाल नहीं पूछता, यह पार और बिंदीदार है। लेकिन इस बात पर विचार करें कि मैं काम के लिए बहुत सी चीजें कर रहा हूं जो वास्तव में बनाए रखने की जरूरत नहीं है। पासिंग ट्रेंड तरह की चीजें। जन्मदिन ऐप, सामान जो आते हैं और जाते हैं। वहाँ सब ठीक है, लेकिन वे वास्तव में होने की जरूरत नहीं है।
काई क्विंग

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

2
@KaiQing किसी को आपको 5mloc विरासत एप्लिकेशन को सौंपने की आवश्यकता है जो पास्कल में पैदा हुई थी और जब से इस अनुप्रयोग पर किसी भी कार्यक्षमता को जोड़ने या बदलने का आपका पहला प्रयास है, आपको तुरंत एहसास होगा कि क्यों सर्वोत्तम प्रथाओं मौजूद हैं और प्रबुद्ध हैं।
जिमी होफा

5
@KaiQing, एंग्री बर्ड्स को कई प्लेटफार्मों पर चलना होता है, और अगर गेम 2 सेकंड के लिए लटका हुआ है तो दर्शकों का% x उस पर छोड़ देने वाला है, जो एंग्री बर्ड्स लोगों के लिए कम डॉलर y का अनुवाद करता है। मुझे यकीन है कि यह बहुत ही सावधानी से लिखा गया है। शायद यह आपके सवाल का जवाब दे। यदि कोड सिर्फ आपके लिए है, तो आपको क्या करना है? अगर दांव पर पैसा या अन्य लोगों का समय है तो आप बेहतर, बहुत सावधान रहें।
चार्ल्स ई। ग्रांट

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

18

एक पुरानी पुरानी बोली है: "पुराने लोगों के बुद्धिमान लोगों के नक्शेकदम पर न चलें। जो उन्होंने चाहा, वह प्राप्त करें।" 'उचित' कोडिंग के सभी नियमों के कारण हैं। यह जानना कि वे नियम क्यों मौजूद हैं, यह जानना अधिक महत्वपूर्ण है कि वे नियम क्या हैं।

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

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

वास्तविक उचित प्रोग्रामिंग अच्छे नियमों का पालन करने के बारे में है जो एक बुद्धिमान तरीके से समझ में आता है।


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

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

1
यदि ऐसा लगता है कि मैं आपको नियम तोड़ने के लिए कह रहा था, तो मैंने इसे बुरी तरह से समझा। जिन चीजों के बारे में आपने बात की, उनमें से कोई भी ऐसी चीज नहीं है जिस पर मुझे आपत्ति हो। मैं यह इंगित करने की कोशिश कर रहा था कि "कानून की भावना" "कानून के पत्र" से अधिक महत्वपूर्ण है।
माइकल शॉ

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

10

इसे देखने का उचित तरीका कम रिटर्न है: अतिरिक्त विकास की लागत के लिए कार्यक्रम को विकसित करने के अतिरिक्त लाभ की तुलना करना।

जब सीमांत लाभ सीमांत समय / प्रयास से कम हो, तो रिटर्न कम हो जाता है।

क्या आप लूप से items.lengthबाहर निकलने के लिए व्यावसायिक मामला बना सकते हैं for? आर्थिक रूप से, क्या यह समय इसे सही ठहराने की कोशिश कर रहे समय को भी सही ठहरा सकता है? चूंकि उपयोगकर्ता के अनुभव में कोई अंतर नहीं है, इसलिए आपको कभी भी खर्च किए गए समय (याद करने के लिए एक उपयोगी सबक के अलावा) के लिए कुछ भी नहीं मिलेगा। उपयोगकर्ता उस परिवर्तन के परिणामस्वरूप किसी भी कार्यक्रम को पसंद नहीं करेंगे, और अधिक प्रतियां नहीं बेची जाएंगी।

इसका मूल्यांकन करना हमेशा आसान नहीं होता है, क्योंकि व्यवसाय के मामले अज्ञात और जोखिमों से भरे होते हैं, और इस प्रकार यह उन गैर-जिम्मेदार कारकों के शिकार होने की आशंका होती है जो केवल दृष्टिहीनता में स्पष्ट हो जाएंगे। प्रस्तावित परिवर्तन पूरी तरह से निर्विवाद हो सकते हैं, जैसे कि वे एक बड़ा बदलाव करते हैं।

सोच-समझकर रिटर्न कम करने के बहाने कुछ कार्रवाई न करने के बहाने शिकार हो सकता है, और जोखिम लेने से बचना चाहिए, जो कि हादसे में छूटे हुए अवसरों की एक कड़ी साबित हो सकता है।

लेकिन कभी-कभी यह स्पष्ट होता है जब कुछ करने के लिए नहीं । यदि विकास के कुछ टुकड़े को विकास की लागत के लिए भुगतान करने के लिए आर्थिक चमत्कार की आवश्यकता होती है (यहां तक ​​कि ब्रेक), तो यह संभवतः एक बुरा विचार है।


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

वास्तव में। हम हमेशा किसी प्रकार का वस्तुनिष्ठ मामला नहीं बना सकते। हर कोई इस तरह से कार्यक्रम को महत्व नहीं देता है। मान लीजिए कि कार्यक्रम में मुख्य उपयोगिता उस पर काम करने में खुशी है। इसका किसी और को कोई लाभ नहीं हो सकता है और कोई भी सुधार के लिए भुगतान नहीं करेगा (यदि प्रोग्रामर के अलावा उपयोगकर्ता भी हैं), लेकिन यह किसी भी तरह से इसे सुधारने का औचित्य साबित करने के लिए पर्याप्त है।
काज

आपके बहुत ही लिखित उत्तर में जोड़ने के लिए दो उपयोगी शब्द - "सट्टा निवेश" - आप इसे करते हैं क्योंकि आप अनुमान लगाते हैं कि भविष्य में वापसी होगी।
मटनज़

@ मट्टनज़ - आप जो कहते हैं वह सच है कि कोई भी बिना किसी रिटर्न के लिए कुछ करता है, भले ही रिटर्न एक अच्छी हंसी हो। मेरी लगभग सभी निजी परियोजनाएं हास्य के लिए की जाती हैं। उनमें से लगभग सभी अपनी आवश्यकताओं को सही ठहराने के लिए पर्याप्त हैं। उनमें से किसी ने भी मुझे पद छोड़ने के लिए सक्षम नहीं किया।
काई किंग

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

3

जब आपको अपने कोड के "उचित" होने की परवाह नहीं करनी चाहिए

  • यदि आप व्यावसायिक लक्ष्य का जवाब देने का प्रबंधन करते हैं, और इसे कम ओवरहेड के साथ समय पर रखें। (उपयोगकर्ता आपके भुगतान करने से पहले स्रोत नहीं देखते हैं)
  • MVP / POC - यदि उचित कोड लिखने का अर्थ है कि किसी अवधारणा पर समय बर्बाद करना, इससे पहले कि आप जानते हैं कि इससे पैसे कैसे कमाए जाएं (यदि आप सालों खर्च करते हैं और 45 मिलियन डॉलर अपना ऐप लिखते हैं और समापन की दुकान समाप्त हो जाती है क्योंकि इसका कोई बाजार नहीं था, तो कोई भी परवाह नहीं करता है कि कैसे उचित कोड था)
  • जब जीवन के लिए खतरनाक स्थिति हो (उदाहरण के लिए लौह पुरुष प्रोटोटाइप 1 एक गंदा हैक था, लेकिन यह उसे गुफा से बाहर निकल गया?)
  • या यदि आप आसानी से उचित कोड लिखना नहीं जानते हैं (अगर किसी को आज के बेरोजगारी में जीवित लेखन को गैर-उचित कोड बनाना है, तो मैं कहता हूं, बेघर होने की तुलना में बेहतर कोड लिखना)
  • यदि आप आसानी से जानते हैं कि आपका क्या कर रहा है या आपको लगता है कि आप इसे दिखावा कर सकते हैं

जब उचित कोड लिखने के लिए

  • यदि यह एक महत्वपूर्ण व्यवसाय प्रभाव होगा, उदाहरण के लिए प्रदर्शन राजस्व को प्रभावित करेगा, या बिक्री को रोक देगा
  • यदि यह उचित नहीं है तो कोड को बनाए रखना एक व्यावसायिक मुद्दा (उच्च रखरखाव लागत) बन जाता है
  • यदि आप एक बड़े ओपन सोर्स प्रोजेक्ट पर काम करने वाले एक ज्ञात प्रोग्रामर हैं
  • एक बड़ी कंपनी के लिए एक घर में दुनिया में एक पुस्तकालय का योगदान है
  • यदि आप भविष्य के साक्षात्कार में एक पोर्टफोलियो के रूप में अपना काम दिखाना चाहते हैं

1
दुःख की बात है कि उचित सूची में नहीं होने के कारण एक और व्यक्ति है जिसे न जाने कितने लोगों का आशीर्वाद प्राप्त है: जब कोई ग्राहक आपकी देखभाल में पुरानी प्रणाली को उलट देता है और आपको बताता है कि उन्हें एक सप्ताह में इसकी आवश्यकता है। कभी-कभी समय और / या बजट खुद को उचित कोडिंग के लिए उधार नहीं देते हैं और परियोजना पर आपका ध्यान व्यापारिक लेनदेन की तुलना में अधिक है। उदाहरण के लिए, यदि उनका कोड बड़े पैमाने पर पदावनत विधियों का उपयोग करता है, लेकिन कुछ पैचिंग (वेब ​​परिदृश्य में बोलना) की आवश्यकता होती है। पूरी बात ठीक नहीं कर सकते। गंदा होना चाहिए।
काई क्विंग

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

2

क्या प्रदर्शन आपकी मुख्य चिंता है? क्या आप अधिकतम करने की कोशिश कर रहे हैं?

यदि ऐसा है, तो सीखने के लिए एक बुनियादी सबक है, और यदि आप करते हैं, तो आप कुछ में से एक होंगे।

इसे तेजी से बनाने के लिए आपको क्या करना चाहिए, यह सोचने की कोशिश मत करो - यह अनुमान लगा रहा है। यदि आप पूछ रहे हैं "क्या मुझे इस कंटेनर क्लास या उस एक का उपयोग करना चाहिए?", या "क्या मुझे lengthलूप कंडीशन में रखना चाहिए ?", आप एक डॉक्टर की तरह हैं जो एक मरीज को देखता है और यह तय करने की कोशिश करता है कि वास्तव में बिना उपचार के क्या देना है? रोगी से पूछताछ या जांच करना।

ऐसा अनुमान है। हर कोई इसे करता है, लेकिन यह काम नहीं करता है।

इसके बजाय, प्रोग्राम को स्वयं बताएं कि उसकी समस्या क्या है। यहाँ एक विस्तृत उदाहरण है।

आपको फर्क दिखता हैं?


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

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

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

2

आपका सवाल है "जब तक यह काम पूरा हो जाता है, मुझे परवाह नहीं है?"

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

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

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


1

जवाब है कि यह कभी मायने नहीं रखता, और यह हमेशा मायने रखता है ...।

यह कभी भी मायने नहीं रखता क्योंकि प्रोग्रामिंग, उचित या नहीं, लक्ष्य प्राप्त करने का एक तरीका है, अपने आप में लक्ष्य नहीं। यदि वह लक्ष्य "उचित" प्रोग्रामिंग के बिना प्राप्त किया जाता है जो ठीक है (व्यावसायिक दृष्टिकोण से यह अक्सर सबसे अच्छा है यदि लक्ष्य बिना प्रोग्रामिंग के प्राप्त किया जा सकता है)।

यह हमेशा मायने रखता है क्योंकि उचित प्रोग्रामिंग एक उपकरण है जो आपके लक्ष्यों को प्राप्त करने में आपकी सहायता करेगा। चीजों को करने का उचित तरीका बस एक मान्यता है कि इसे दूसरे तरीके से करने से लंबे समय तक अधिक दर्द होता है, जितना कि यह बचाता है।

जो इस सवाल का जवाब देता है कि आप इसे कब अनदेखा कर सकते हैं - जब आपको यकीन हो कि लंबे समय में एक और रास्ता आसान हो जाएगा (संभवतः क्योंकि कोई लंबा रन नहीं होगा)।

एक बंद उपकरण आमतौर पर जितना जल्दी हो सके उतना जल्दी और गंदा किया जाता है, जिसमें कोई त्रुटि जाँच या अन्य सत्यापन नहीं होता है, अपवादों का कोई लॉगिंग नहीं होता है, मामूली परिवर्तनों के साथ कट-एन-पेस्ट कोड या सामान्य कार्यों के बजाय कोई परिवर्तन नहीं होता है, और इसके आगे ।

जरा ध्यान से देखें: कभी-कभी वे त्वरित और गंदे ऐप अपने स्वयं के जीवन को संभाल लेते हैं, जिसका अर्थ है कि सभी शॉर्ट कट आपको में काटते हैं ...


1
"कभी नहीं" और "हमेशा" एक दूसरे को रद्द करें। अपना जवाब अच्छा और बुरा दोनों बनाना।
ट्यूलेंस कोर्डोवा

@ user1598390: उनका एक दूसरे को रद्द करना बिंदु था। हठधर्मिता को रद्द करें, और आप उपयोगी होने के साथ छोड़ दिए गए हैं। और आप इसे गलत समझेंगे और उससे सीखेंगे।
jmoreno

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

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

1

या यहां तक ​​कि इस तरह से कुछ तुच्छ:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

मुझे पता है कि यह हर पुनरावृत्ति पर item.length का मूल्यांकन करता है। हालांकि, मुझे यह भी पता है कि आइटम कभी भी 15 से 20 से अधिक आइटम नहीं होंगे। तो क्या मुझे ध्यान देना चाहिए कि क्या मैं हर पुनरावृत्ति पर आइटम्स का मूल्यांकन करता हूँ?

वास्तव में अंतिम कोड में, आइटम्स.लम्बेंसी का मूल्यांकन हर पुनरावृत्ति में नहीं किया जाएगा क्योंकि कंपाइलर इसका अनुकूलन करता है। और यहां तक ​​कि अगर यह नहीं थे, तो लंबाई सरणी वस्तु में एक सार्वजनिक क्षेत्र है; इसे एक्सेस करने की लागत नहीं है।

इसलिए मुझे लगता है कि मेरा सवाल आपसे यही है: क्या कोई सीमा है जब यह नहीं रह जाता है> उचित होना मायने रखता है? क्या यह कहना ठीक है - "जब तक यह काम पूरा हो जाता है, मैं> परवाह नहीं करता?"

यह वास्तव में इस बात पर निर्भर करता है कि आप अपने अंतिम उत्पाद से क्या उम्मीद करते हैं; एक औसत उत्पाद और एक महान उत्पाद के बीच का अंतर विवरण में निर्भर करता है। टाटा नैनो जैसी कार और मर्सिडीज एस जैसी कार "काम पूरा हो जाता है" - यह आपको एक जगह से दूसरी जगह ले जाती है। अंतर विवरण में निर्भर करता है: इंजन की शक्ति, आराम, सुरक्षा और अन्य। यह किसी भी उत्पाद के साथ समान है जो सॉफ्टवेयर उत्पादों सहित मौजूद है; उदाहरण के लिए, कोई भी ओरेकल, आईबीएम या माइक्रोसॉफ्ट को ओरेकल डेटाबेस, डीबी 2 या एमएस एसक्यूएल सर्वर के लिए भुगतान क्यों करेगा क्योंकि MySQL और Postgre स्वतंत्र हैं?

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


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

@ कै किंग एक एकल वर्ग (या नहीं करना चाहिए) से बहुत फर्क पड़ता है। मैंने यह कहा: यदि आप अपने उत्पाद को उच्च-गुणवत्ता वाला उत्पाद होने की उम्मीद करते हैं, तो विवरणों पर ध्यान दें (भले ही इसका मतलब थोड़ा अनुकूलन या एक केयरफुल डिज़ाइन हो); दूसरी ओर यदि केवल एक चीज जो आप चाहते हैं वह एक कार्यात्मक प्रणाली है, तो शायद आपको छोटे विवरणों पर अधिक ध्यान नहीं देना चाहिए।
m3th0dman

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

1

यदि आप अपने लिए घर पर प्रोग्रामिंग कर रहे हैं, तो शायद आप कुछ कोनों को काट सकते हैं; और जब आप प्रयोग कर रहे हों और चीजों को आज़मा रहे हों तो यह पूरी तरह से उचित है।

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

आपके द्वारा की जाने वाली कोई भी प्रोग्रामिंग और प्रोग्रामिंग के बारे में आपके द्वारा की गई कोई भी सोच व्यायाम है। इसे सार्थक बनाओ, अन्यथा यह वापस आ जाएगा और आपको काटेगा।

हालांकि अच्छी तरफ देखें। आपने इस बारे में पूछा है इसलिए शायद आप पहले से ही उस बिंदु से अवगत हैं जो मैं बना रहा हूं।


1
हाँ, मैं अवगत हूँ, लेकिन सवाल का मुद्दा यह है कि छोटे, निहित संदर्भ में ऐसा प्रतीत नहीं होता है कि यह उचित है। प्रोग्रामिंग के मेरे सभी वर्षों में, वास्तव में हमें काटने के लिए बहुत सारी कमी नहीं हुई है। मुझे संदेह है कि हम इतने उचित हैं। मुझे लगता है कि यह सामान्य भाषा की तरह भाषा और अपेक्षाएं बदलती हैं। कुछ दूसरों की तुलना में कम। लेकिन अंत में एक परियोजना की अक्षमता केवल तभी महसूस की जा सकती है जब परियोजना अतीत में हो और अब जरूरी न हो। यह इतना कठोर होने के सिरदर्द को सही ठहराना कठिन बनाता है।
काई क्विंग

यह एक उचित बिंदु है। आज के नियम कल के प्रतिबंध हो सकते हैं। मुझे नहीं बताया जा रहा है कि मुझे क्या करना है, लेकिन मेरे पास दूसरों के लिए सम्मान है जो पहले चले गए हैं और कठिन तरीका सीखा है। कभी-कभी हालांकि यह पता लगाना दिलचस्प हो सकता है कि कौन से नियम उपयोगी हैं और अब उनकी बिक्री की तारीख क्या है।
डैनियल हॉलिनरेके 22

1

यदि एक फर्नीचर निर्माता फर्नीचर का एक टुकड़ा बनाने के लिए इस्तेमाल किया जा रहा था, जहां गुणवत्ता का अत्यधिक महत्व नहीं था या जहां गुणवत्ता पर किसी का ध्यान नहीं जा सकता है, तो क्या उन्हें अभी भी अपने कटौती को सीधे करने की कोशिश करनी चाहिए, और टुकड़ों को मिलाकर एक उचित काम करना चाहिए?

कई लोग सॉफ्टवेयर को शिल्प कौशल के रूप में देखते हैं। हम जो निर्माण करते हैं वह केवल एक कार्य नहीं करना चाहिए, यह विश्वसनीय, बनाए रखने, मजबूत करने की आवश्यकता है। ऐसे सॉफ़्टवेयर बनाने के लिए कौशल की आवश्यकता होती है, और यह कौशल अभ्यास से आता है।

इसलिए, भले ही आप आज जो काम कर रहे हैं उसके लिए एक लूपिंग कंस्ट्रक्शन का विकल्प मायने नहीं रखता, लेकिन यह तथ्य कि आप हर समय उचित निर्माणों का उपयोग करने का प्रयास करते हैं, समय के साथ आपको एक बेहतर प्रोग्रामर बनाते हैं।


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

यहां तक ​​कि अगर आप जिस सॉफ्टवेयर का निर्माण सही कर रहे हैं , उसे बनाए रखने की आवश्यकता नहीं है, तो सॉफ्टवेयर को लिखना जैसे कि यह आपके कोडिंग कौशल को मजबूत करता है। जब आपको आखिरकार बनाए रखने योग्य कोड लिखना होगा, तो आप इसे अधिक आसानी से कर पाएंगे।
ब्रायन ओकले

मुझे हर समय मेंटेन करने योग्य कोड लिखना है। बस कुछ मामलों में यह होना जरूरी नहीं है। हालाँकि, मेरे पास बहुत अनुभव है इसलिए मैं आमतौर पर जानता हूं कि कोनों को कब और कहां से काटना है। इस पोस्ट का उद्देश्य सिर्फ जो भी उद्देश्य के लिए उचित और सुस्त की दहलीज के बारे में बातचीत को उत्तेजित करना था। मेरा उदाहरण केवल उस पर हल्के से ब्रश करता है क्योंकि दिए गए उदाहरण में एक छोटे से अनुप्रयोग में ज्यादातर हानिरहित है। हालाँकि, अगर मैं बैंक सॉफ्टवेयर लिख रहा होता तो मैं इतना लापरवाह नहीं होता।
काई किंग
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.