क्या एक समाधान के लिए एक कुशल होना महत्वपूर्ण है?


9

मैं कई समस्याओं को हल करता हूं, ज्यादातर टॉप कोडर से। मुझे कई के जवाब मिलेंगे, लेकिन ज्यादातर बार मैं एक अक्षम समाधान के साथ समाप्त होता हूं।

वास्तविक दुनिया के कार्यान्वयन में - क्या यह वास्तव में मायने रखता है कि समस्या का समाधान कुशल है? यदि ऐसा है तो मैं इसे कैसे सुधार सकता हूं?


4
क्या आप एक प्रतियोगिता के दृष्टिकोण या वास्तविक दुनिया के कार्यान्वयन के दृष्टिकोण से पूछ रहे हैं?
rjzii

@RZZ: वास्तविक दुनिया में कार्यान्वयन
चींटी का

1
"वास्तविक दुनिया" में बहुत सारी जमीन शामिल है। एंबेडेड? सर्वर अनुप्रयोग? मोबाइल एप्लीकेशन? सिंगल-यूजर पर्सनल कंप्यूटर सॉफ्टवेयर? वैज्ञानिक सिमुलेशन? जवाब जरूरी नहीं कि उनके लिए समान हो।
डेविड थॉर्नले

जवाबों:


34

सबसे अच्छा समाधान वह है जो (बढ़ते महत्व के क्रम में) कुशल, बनाए रखने योग्य और संपन्न हो

^ ^ ^ यह केवल एक चीज है जिसे आपको वास्तव में इस उत्तर से लेने की आवश्यकता है। ^ ^ ^

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

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


3
हाँ। और एक बहुत ही अकुशल कार्यक्रम जो सही और पूर्ण दोनों है, आपको अपने सुधारों के परीक्षण के लिए कुछ देता है।
माइक शेरिल 'कैट रिकॉल'

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

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

8

मैं माइक सेलिनी के साथ सहमत था, एक चीज जो मैं जोड़ूंगा।

क्या कुछ "कुशल पर्याप्त" है? उपयोगकर्ता के दृष्टिकोण से उदाहरण के लिए, एक फ़ंक्शन के बीच बहुत अंतर नहीं है जो 0.00001 सेकंड में पूरा होता है या जो 0.1 सेकंड में पूरा होता है, भले ही एक दूसरे से बहुत अधिक कुशल हो। एक फ़ंक्शन जो 10 मिनट में पूरा होता है, वह 12 मिनट में पूरा होने वाले के लिए (उपयोगकर्ता के लिए) बहुत अलग नहीं है। दोनों ही मामलों में उपयोगकर्ता को एक कप कॉफी मिलेगी या दूसरे कार्य के साथ मिलेगी।

मैं दक्षता को "एक कुशल उपयोगकर्ता" के रूप में देख रहा हूं।


अंगूठे का नियम मैंने सुना है कि एक उपयोगकर्ता द्वारा 20% सुधार देखा जा सकता है। उन दोनों को अर्हता प्राप्त लगती है, मुझे लगता है कि उपयोगकर्ता वास्तव में .1 और .00001 सेकंड के बीच जवाबदेही में अंतर महसूस कर सकता है।
क्रिस पिटमैन

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

2

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

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

  • कुछ छात्रों ने एक सरल लूप का उपयोग किया और यह सुनिश्चित करने के लिए कि नंबर सही थे या नहीं, यह जांचने के लिए प्रदान किया गया फॉर्मूला, धीमी गति से लेकिन काम पूरा कर लिया, O (n ^ 3)
  • अन्य छात्रों ने अपना शोध किया और एक सूत्र पाया कि जाँच का बेहतर काम यह सुनिश्चित करने के लिए था कि एक दी गई संख्या वैध थी, ये कार्यक्रम बहुत तेज़ी से चले, O (n ^ 2)।
  • एक छात्र ने मूल्यों को उत्पन्न करने के लिए धीमे सूत्र का उपयोग किया और फिर उन्हें अपने कोड में एक स्थिर सरणी में कॉपी किया और उस सामग्री को प्रदर्शित किया, O (n)।

प्रोफेसर द्वारा अंतिम समाधान को सबसे कुशल माना गया था। यह बताता है कि समस्या वास्तव में समस्या को पूरी तरह से समझने और केवल बाहर जाने और सबसे कुशल समाधान खोजने की कवायद थी।

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

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


2

यह प्रतियोगिता की संरचना पर निर्भर करता है, लेकिन आम तौर पर, हाँ: प्रदर्शन ज्यादातर समय उनके प्रलेखन के अनुसार एक विचार है । कभी-कभी, बाद की कड़ी में, आपको शिकार करना होगा, लेकिन उद्धृत करने के लिए:

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

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

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

अंत में, कंप्यूटर विज्ञान पाठ्यक्रम तेजी से ऑनलाइन उपलब्ध हैं , और उस पृष्ठभूमि को कवर करेंगे जिसे आपको सुधारने की आवश्यकता है।


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

नहीं, मैंने केवल पहले एक को सूचीबद्ध किया था जो मुझे अमेज़ॅन पर मिला था, और यह जांचने से परेशान नहीं था कि यह दूसरा संस्करण था।
डैनियल पिटमैन

1

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

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

अपने कोड को अधिक कुशल कैसे बनाएं:

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

अनुकूलन के लिए एक संपूर्ण क्षेत्र है, लेकिन ऊपर दिए गए दो सुझाव कम से कम आपको आरंभ करने चाहिए।


1

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.