कोडिंग प्राथमिकताएं: प्रदर्शन, रखरखाव, पुन: प्रयोज्यता?

Question

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

प्रदर्शन हमेशा पहले आते हैं? मुख्य प्राथमिकता के रूप में प्रदर्शन के साथ कई उत्तरों प्रदान किए जाते हैं। मेरे उपयोगकर्ता इस बात से अधिक चिंतित हैं कि कोड को कितनी जल्दी संशोधित किया जा सकता है। तो एक रिपोर्ट चलाने के बजाय 12 सेकंड के लिए 15 सेकंड लगते हैं। वे तब तक रह सकते हैं जब तक मैं समाधान प्रदान न करने के लिए बहाना नहीं कर रहा हूं।

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

यह सब कहा जा रहा है, मैं आदेश दूंगा: रखरखाव (परिवर्तन जीवन का एक तथ्य है।), प्रदर्शन (कोई भी घंटा का चश्मा देखने के लिए पसंद नहीं करता है।), पुन: प्रयोज्यता (निर्धारित करने में मुश्किल है कि कौन से कोड का उपयोग किया जाना चाहिए।) ।

Answer 1

1. रखरखाव: यदि कोड गैर-पठनीय है तो यह बेकार है, चाहे कितना तेज़ हो। और यह निश्चित रूप से फिर से इस्तेमाल नहीं किया जाएगा।

2. Reusability: नहीं सभी कोड पुन: प्रयोज्य है, लेकिन यह का एक बहुत है। यदि आप कर सकते हैं, हर तरह से अपना कोड सरल बनाते हैं। सबसे आसान विभाजन और जीत है। उदाहरण के लिए, उन साधारण घटकों को बनाएं जिन्हें आप बार-बार उपयोग करेंगे। यूआई विजेट सबसे आम हैं। लेकिन यह यूटिलिटीज के साथ ही है। साथ ही, आपके कोड में संरचना/ढांचा बनाने में मदद मिलती है। त्रुटि सत्यापन कोड, आदि

3. प्रदर्शन: आम तौर पर अधिकांश कोड पर्याप्त प्रदर्शन करने वाला होता है। और यदि नहीं, तो कोड प्रोफाइलर का उपयोग करें। बाधा से अधिक अक्सर किसी भी छोटे कोड अनुकूलन से अधिक होगा जो आप पठनीयता या पुन: उपयोगिता की लागत पर कर सकते थे।

Answer 2

संपादित 2010-03-02: प्रश्न मूल रूप से शुरू कर दिया:

हर किसी को नासा के लिए काम करता है? क्या प्रदर्शन हमेशा पहले आता है? बहुत सारे जवाब ...

हम में से अधिकांश नासा के लिए काम नहीं करते हैं।

नहीं: विश्वसनीयता और रखरखाव प्रदर्शन से आगे आती है। पुन: प्रयोज्यता भी अच्छी है।

व्यापक सीमाओं के भीतर, प्रदर्शन महत्वपूर्ण नहीं है।

Answer 3

चूसने वाला उत्तर निश्चित रूप से है, "यह निर्भर करता है"।

लाइन-ऑफ-बिजनेस एप्लिकेशन के मामले में शामिल गतिविधि के लिए प्रतिक्रिया समय आवृत्ति के विपरीत आनुपातिक होने की आवश्यकता है जिसके साथ यह चल रहा है। यदि यह एक ऐसा फ़ंक्शन है जिसे उपयोगकर्ताओं को 4 या 5 बार एक घंटे तक पहुंचने की आवश्यकता होती है तो उस महीने की अंत रिपोर्ट को खींचने से बेहतर स्नैपियर होता।

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

Answer 4

वे किसी अन्य समारोह या उप दिनचर्या या यूडीएफ बुला प्रदर्शन

गलत सोच है कि में बाधा आएगी सोचा।

मैं आदेश दूंगा: रखरखाव, प्रदर्शन, पुन: प्रयोज्यता।

कभी कभी (आमतौर पर IMO) पुनर्प्रयोग रख-रखाव की है: क्योंकि आप कुछ है कि आप "एक आसानी से पहचान की जगह में परिवर्तन करने के लिए और उन सभी स्थानों soneone की नकल की और कोड चिपकाया का पीछा नहीं कर" कर रहे हैं पुन: उपयोग किया बस।

Answer 5

I नासा में काम करते हैं। हालांकि, मैं (वर्तमान में वैसे भी) वास्तविक समय कोड या किसी भी चीज को बनाए रखने या विकसित करने के लिए महत्वपूर्ण नहीं करता हूं। नासा में किए गए अधिकांश सॉफ्टवेयर शायद नहीं हैं। मेरे दिन में कुछ भयानक कोड देखने के बाद, मैं जोनाथन के विश्वसनीयता और रखरखाव के जवाब के साथ प्रदर्शन के बाद और फिर अधिकांश अनुप्रयोगों के लिए पुन: प्रयोज्यता के साथ जाऊंगा।

Answer 6

मैं नासा ठेकेदार हूं और मुख्य रूप से प्रशासनिक उद्देश्यों जैसे कि रिपोर्ट चलाने और ट्रैकिंग परियोजनाओं के लिए सॉफ्टवेयर विकसित और बनाए रखता हूं।

मैं लगभग 1.5 वर्षों तक वहां काम कर रहा हूं और मेरा मानना ​​है कि उनकी मुख्य चिंता रखरखाव है और आप उस नई सुविधा या मॉड्यूल को कितनी तेजी से प्राप्त कर सकते हैं।

प्रश्न में कहा गया है कि जब तक सॉफ़्टवेयर असाधारण समय नहीं लेता है, तो वे दिमाग में नहीं लगते हैं।

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

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

Answer 7

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

1. एक वास्तविक समय और बहुत काम यह सुनिश्चित करते हुए अपने प्रदर्शन उम्मीद के मुताबिक, (जरूरी तेजी से बिजली नहीं) है, लेकिन परिवर्तन एक प्रमुख मुद्दा नहीं है में चला जाता है, यह केवल काफी बदल जाता है जब IETF परिवर्तन/आरएफसी को अप्रचलित करता है और इसका थोड़ा सा संकेत मिलता है। (उसने कहा, मुझे अपने रखरखाव के स्तर पर बहुत गर्व है)।

   • एक और ऐप ने कभी-कभी 1 दिन के डेटा को संसाधित करने के लिए 16 घंटे लगते हैं। पूर्ण प्रदर्शन कहने की जरूरत नहीं है जल्दी ही सर्वोच्च प्राथमिकता बन गई।लेकिन इस ऐप के भीतर भी प्रति-क्लाइंट-कोड, प्रति-कार्य-कोड, प्रति-फ़ाइल-कोड, प्रति-रिकॉर्ड-कोड, प्रति-बैच-कोड के माध्यम से प्रति-बैच-कोड में 'महत्वपूर्ण नहीं' से नाटकीय रूप से भिन्नता भिन्न होती है। प्रति-बाइट-कोड में फ़ील्ड-कोड 'बेहद महत्वपूर्ण' है।

   • अंतिम एप्लिकेशन व्यापार तर्क की ज्यादा होता है, प्रदर्शन कभी नहीं एक मुद्दा, रख-रखाव और चपलता कर रहे हैं के लिए महत्वपूर्ण हैं और सभी फैशनेबल तरीके से इस एप्लिकेशन को लाभ सबसे,, जब मैं सिर्फ खर्च किया है हफ्तों या महीनों रिफैक्टरिंग है, लेकिन प्रदर्शन के लिए "string1 + string2 + string3 + string4" लिखना बहुत मुश्किल है, भले ही वह सबसे अधिक पठनीय और प्रदर्शन अप्रासंगिक है।

Answer 8

प्रदर्शन doesnt't भी नासा में पहले आओ,! नासा में, यदि कोड सही और भरोसेमंद नहीं है, तो लोग मर जाते हैं।

इसके अलावा, मेरे अनुभव में, जब प्रदर्शन मूल्यवान है, यह एक बिंदु तक है; आमतौर पर एक प्रदर्शन स्तर होता है कि आगे बढ़ने में बहुत कम या कोई अतिरिक्त मूल्य नहीं होता है। इसके विपरीत, शुद्धता में सुधार करने के लिए अतिरिक्त मूल्य है इससे कोई फर्क नहीं पड़ता कि कोड का एक टुकड़ा कितना विश्वसनीय है; कोड का एक टुकड़ा वास्तव में अपेक्षाकृत काम नहीं कर सकता है।

मेरे लिए आदेश होगा:

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

Answer 9

मेरी पसंदीदा उद्धरण में से एक ... SICP से है

"कंप्यूटर प्रोग्राम मनुष्य द्वारा पढ़ा जा करने के लिए और संयोग से कंप्यूटर द्वारा दौड़ा डिजाइन किए हैं।"

मैं अपने काम के इन सभी पहलुओं को रेट करता हूं; लेकिन मेरे कोड के पठनीयता (कुछ शब्द अभिव्यक्ति का उपयोग करते हैं) और जिनके साथ मैं काम करता हूं, वे मेरी महत्व की सूची में सबसे ऊपर हैं।

बस मेरे 2 सी, एक सुंदर सप्ताहांत है!

Answer 10

मुझे लगता है कि आप सूची में से किसी एक को याद किया: विश्वसनीयता;

तो मेरे आदेश

• विश्वसनीयता और सटीकता
• अनुरक्षणीयता
• Reusability है
• प्रदर्शन

यह कोई फर्क नहीं पड़ता कितनी तेजी से कोड है जब यह सही नहीं है , सबसे पहले कोड विश्वसनीय होना चाहिए।

प्रदर्शन सूची के नीचे है। कभी भी बहुत जल्दी ऑप्टिमाइज़ न करें, और प्रदर्शन की समस्या होने पर केवल प्रदर्शन में सुधार करें।

मैं भी है कि पर्यावरण के प्रदर्शन में उड़ान के अनुकरण सहित रियल-टाइम प्रणालियां पर काम किया है, और ध्यान में रखा लेकिन एक अधिभावी प्राथमिक चिंता का विषय नहीं है।

मैं कहूंगा कि मेरे अनुभव में मुझे केवल कोड के 1% से भी कम अनुकूलित करना पड़ा है।

---

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

Answer 11

एक अलग उत्तर में, प्रदर्शन लगभग हमेशा पहले आ जाएगा।

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

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

रखरखाव को हल करना काफी हद तक आपका काम है: क्या सवाल आप एक इकाई से पूछते हैं जिसे अलग किया जाना चाहिए?

पठनीयता अधिकतर किया जाता है, बाकी आपका काम है। उत्तर देने पर हम आमतौर पर उत्तर को समझने में आपकी रुचि रखते हैं, इसलिए इसे कम से कम आपके लिए पठनीय करने की आवश्यकता है। यदि आप उस कोड को उस कोड में कॉपी करते हैं और // That weird query पर टिप्पणी करते हैं, तो मेरी समस्या नहीं।

इस तथ्य को जोड़ें कि प्रदर्शन आसान समझ में आता है: दो कार्यात्मक रूप से समकक्ष उत्तरों से आप हमेशा "जोस उत्तर की तरह, लेकिन थोड़ा तेज़" कहेंगे, जब तक यह एम + आर विभाग में बड़ी गलती नहीं करता ।

---

अब यह लिखना ऐसा लगता है कि समयपूर्व अनुकूलन आकर्षक है। यह कुछ कारणों से गलत प्राथमिकता है।

अनुकूलन के लिए

कम प्राथमिकता दो प्रमुख कारण है, हालांकि है:

Answer 12

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

• आवश्यक से अधिक नहीं कोड लिखें।
• लीवरेज मानक पुस्तकालय।
• चतुरता के लिए पारदर्शिता पसंद करते हैं।
• छोटे, टेस्टेबल फ़ंक्शन लिखें।

Answer 13

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

हमारे क्लाइंट में से एक ऑनलाइन ट्रेडिंग साइट थी। पीक लोड के तहत एक औसत लेनदेन कुछ ऐसा ले जाएगा जहां लगभग 14 एमएस मिडलवेयर स्तर पर पूरा हो। कुछ समय बाद आवेदन के प्रदर्शन में गिरावट आई (कुछ कारणों से) और लेनदेन औसत समय 24 एमएस तक बढ़ गया। अब एक सामान्य डेवलपर के रूप में हम सोचेंगे कि 10 एमएस इतनी खतरनाक नहीं है। लेकिन अगर हम व्यापार परिप्रेक्ष्य से सोचते हैं तो यह खतरनाक है। कैसे? आइए विश्लेषण करें:

आइए मान लें कि चरम भार के तहत, संसाधनों का पूरी तरह से उपयोग किया जाता है और 14ms के साथ हम 100 लेनदेन करने में सक्षम थे। अब प्रदर्शन में गिरावट के साथ लेनदेन 10 एमएमएस अतिरिक्त है जो 71.42% अतिरिक्त समय है। अब इसका मतलब यह होगा कि हम केवल 100 लेनदेन के बजाय 28.58 लेनदेन करने में सक्षम होंगे। इसका मतलब व्यापार के लिए गंभीर नुकसान है।

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

मैं महत्व के क्रम को निर्दिष्ट नहीं करता क्योंकि यह संदर्भ विशिष्ट है।

Answer 14

यहाँ टैग गणना के आधार पर परिणाम हैं: - 952

Reusability (कई संबंधित टैग) -

• प्रदर्शन 43
• अनुरक्षणीयता - 14

क्या मतलब है: प्रदर्शन महत्वपूर्ण होना चाहिए? प्रदर्शन कठिन है, इसलिए अधिक प्रश्न पूछे जाते हैं। प्रदर्शन प्रश्न इस साइट पर पूछने के लिए अधिक विशिष्ट/एप्रोप्रेट हैं?