कोड को तेज़ कैसे करें (गुणवत्ता का त्याग किए बिना) [बंद]


144

मैं कई सालों से एक पेशेवर कोडर हूं। मेरे कोड के बारे में टिप्पणियां आम तौर पर एक ही रही हैं: महान कोड लिखते हैं, अच्छी तरह से परीक्षण किए जाते हैं, लेकिन तेज हो सकते हैं

तो गुणवत्ता का त्याग किए बिना मैं एक तेज कोडर कैसे बन सकता हूं ? इस प्रश्न के लिए, मैं गुंजाइश को C # तक सीमित करने जा रहा हूं, क्योंकि यह मुख्य रूप से I कोड (मौज-मस्ती) के लिए है - या जावा, जो कि कई मायनों में समान है।

चीजें जो मैं पहले से कर रहा हूं:

  • न्यूनतम समाधान लिखें जो काम करेगा
  • स्वचालित परीक्षणों का विवरण लिखें (प्रतिगमन को रोकता है)
  • सभी प्रकार की चीजों के लिए पुन: प्रयोज्य पुस्तकालयों को लिखें और उनका उपयोग करें
  • अच्छी तरह से ज्ञात तकनीकों का उपयोग करें जहां वे अच्छी तरह से काम करते हैं (जैसे। हाइबरनेट)
  • डिज़ाइन पैटर्न का उपयोग करें जहां वे जगह में फिट होते हैं (जैसे। सिंगलटन)

ये सभी महान हैं, लेकिन मुझे ऐसा नहीं लगता कि मेरी गति समय के साथ बढ़ रही है। मैं परवाह करता हूं , क्योंकि अगर मैं अपनी उत्पादकता को बढ़ाने के लिए कुछ कर सकता हूं (यहां तक ​​कि 10% तक), तो यह मेरे प्रतियोगियों की तुलना में 10% तेज है। (ऐसा नहीं कि मेरे पास कोई है।)

इसके अलावा, मैंने अपने प्रबंधकों से लगातार यह शुल्क वापस लिया है - चाहे वह छोटे पैमाने पर फ्लैश विकास हो या उद्यम जावा / सी ++ विकास।

संपादित करें: मुझे लगता है कि उपवास से मेरा क्या मतलब है, और मुझे कैसे पता है कि मैं धीमा हूं, इसके बारे में बहुत सारे प्रश्न हैं। मुझे कुछ और विवरणों के साथ स्पष्ट करें।

मैंने विभिन्न परियोजनाओं और विभिन्न तकनीकों (फ्लैश, ASP.NET, जावा, C ++) पर विभिन्न कंपनियों में छोटी और मध्यम आकार की टीमों (5-50 लोगों) में काम किया। मेरे प्रबंधकों का अवलोकन (जो उन्होंने मुझसे सीधे कहा था) यह है कि मैं "धीमा" हूं।

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

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

क्यों? मैं क्या खो रहा हूँ? मैं इसमें बेहतर कैसे हो सकता हूं?

मेरा अंतिम लक्ष्य सरल है: अगर मैं आज 40 घंटे में उत्पाद एक्स बना सकता हूं, और मैं किसी तरह अपने आप को बेहतर बना सकता हूं, ताकि मैं उसी उत्पाद को 20, 30 या कल भी 38 घंटे बना सकूं, यही मैं जानना चाहता हूं - मैं वहां कैसे पोहोंचूं? मैं लगातार सुधार करने के लिए किस प्रक्रिया का उपयोग कर सकता हूं? मैंने सोचा था कि यह कोड के पुन: उपयोग के बारे में है, लेकिन यह पर्याप्त नहीं है, ऐसा लगता है।


4
क्या अन्य लोग समान गुणवत्ता में आपसे अधिक तेज़ी से कोड करते हैं? यदि नहीं, तो अपने रखरखाव रिकॉर्ड और बग रिपोर्ट को इंगित करें कि गति एक मुद्दा नहीं है।
माइकल के

3
संभावित डुप्लिकेट: प्रोग्रामर
कॉर्बिन मार्च

1
दौड़ जीतने की कोशिश करने के लिए, कुछ अपने सबसे तेज घोड़ों का चयन करेंगे और उन्हें तेजी से जाने के लिए हरा देंगे। कोई सवाल?
पॉल

24
मेरे पास आपके लिए कोई उत्तर नहीं है, लेकिन मेरे पास कुछ ऐसा है जिससे आप बेहतर महसूस कर सकते हैं। हालाँकि, आप एक प्रोग्रामर के रूप में धीमे हो सकते हैं, हालाँकि आप जो महसूस कर सकते हैं, वह अक्षम है, आपका प्रबंधक बहुत बुरा है। किस तरह के बेवकूफ कहते हैं, "हे बॉब, तुम बहुत धीमे हो" बिना सुधार के मदद करने के लिए? साथ ही आपको बता सकता है कि आप बहुत कम हैं। यह नेतृत्व नहीं है, यह सिर्फ भारी है। मुझे लगता है कि मेरे पास एक सुझाव है: एक सक्षम प्रबंधक के साथ एक नौकरी ढूंढें, जो आपकी कमियों को दूर करने के लिए आपके साथ काम करेगा।
मालवोलियो

1
सभी जवाब मुझे दुखी करते हैं। यदि आप केवल चरण noob-> औसत दर्जे चाहते हैं तो शायद एक काम करना ठीक है। लेकिन औसत दर्जे-> विशेषज्ञ को हमेशा सब कुछ सीखने की आवश्यकता होती है। आपको अपने VCS, अपने संपादक, अपनी प्रोग्रामिंग भाषा और अपने ढांचे को गहराई से सीखना होगा। आपको कठिन और दिलचस्प चरणों को दोहराने की ज़रूरत है जो आप उन्हें बिना सोचे समझे कर सकते हैं। और फिर आपको संदर्भ लागू करने का एक तरीका खोजने की ज़रूरत है, जैसे ग्राहक की ज़रूरतों और आपके सहकर्मी की ज़रूरतों के बीच अंतर, आपका दैनिक मूड कोड / डिज़ाइन / चर्चा करने की आपकी क्षमता को कैसे प्रभावित करता है। यदि आप 1 चीज़ चाहते हैं तो यह करें: सब कुछ सीखें।
एरिकबवर्क

जवाबों:


158

मुझे इस पर जेफ एटवुड का दृष्टिकोण पसंद है जो यहां पाया जा सकता है http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html

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

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

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


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

4
मैं प्रोग्रामिंग प्रोग्रामिंग अनुभव के लिए 20 कचरा बर्तनों के साथ ठीक हूं। यह मेरे पेशेवर प्रोग्रामिंग अनुभव के साथ भी मेरी मदद करता है; इसके अलावा, कहीं शुरू होगा।
ashes999

23
मैं सिर्फ सतह के मूल्य के लिए इसे देखना पसंद करता हूं, "अभ्यास परिपूर्ण बनाता है।" बहुत गहरा मत देखो;)
क्रिस

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

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

72

एक संभावना है कि किसी और का उल्लेख नहीं लगता है कि आप ठीक कर रहे हैं और आपके प्रबंधक बहुत अच्छे नहीं हैं। वे उत्पादकता कैसे माप रहे हैं? क्या वे आपको विशिष्ट उदाहरण दे सकते हैं या यह केवल एक सामान्य धारणा है? क्या उन्होंने आपकी तुलना में अन्य लोगों के काम को ठीक करने में बिताए समय को ध्यान में रखा है?

मैंने देखा है कि बहुत से लोगों को सामान प्राप्त करने का श्रेय मिलता है, जबकि उनकी टीम के बाकी सदस्य उस गड़बड़ को ठीक कर देते हैं जिसे उन्होंने पीछे छोड़ दिया है।


1
यह शायद समस्या का एक बड़ा हिस्सा है। रेट्रोस्पेक्ट में इसे देखते हुए, यह बहुत ही आकस्मिक लगता है कि मैं हमेशा उन लोगों की तुलना में हूं जो मेरी कंपनी के वर्षों में मेरे मुकाबले लंबे समय तक काम कर रहे हैं। हम्म ...
ashes999

अगर ऐसा है, तो मेरी सलाह है कि मेरे पहले दो प्रश्नों को सीधे पूछें और देखें कि आपको क्या प्रतिक्रिया मिलती है, इसे वहां से ले जाएं
pdr

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

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

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

39

ज्यादातर लोग जो सोचते हैं वह महत्वपूर्ण नहीं है। टाइपिंग की गति महत्वपूर्ण नहीं है। तेज़ मशीन या उपकरण महत्वपूर्ण नहीं हैं। हम टाइपिस्ट या मशीन ऑपरेटर नहीं हैं। हम विचारशील कार्यकर्ता हैं। हम निर्णय लेने वाले हैं

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

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

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

* http://codekata.pragprog.com/


क्या आप अन्य साइटों / शर्तों को Google को सुझा सकते हैं? मुझे लगता है कि एक सप्ताह में एक अजीब चुनौती से निपटना मेरे मस्तिष्क को विभिन्न आयामों में आगे बढ़ सकता है।
राख 10

मेरा हाल के एक पसंदीदा है pragprog.com/titles/btlang/seven-languages-in-seven-weeks
रीन Henrichs

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

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

@INTPnerd मैं सहमत हूं। यदि आप यह सोचने में समय व्यतीत करते हैं कि आपकी स्क्रीन पर "थ्रो" शब्द कैसे आता है ("मुझे वहां माउस ले जाने की आवश्यकता है, तो क्लिक करें, फिर मुझे अपने कीबोर्ड पर 't' को ढूंढना होगा") आपके मस्तिष्क के पास भी समय नहीं है वास्तविक निर्णयों पर विचार करें।
erikbwork

25

यह काफी संभव है कि वास्तव में, आपको अधिक गति के लिए, कुछ गुणवत्ता का त्याग करने के लिए कहा जा रहा है ।

कुछ विकास वातावरण 1 में , यह कुछ पॉलिश करने के लिए अतिरिक्त समय के लायक नहीं है, जब "बस बहुत अच्छा होगा"।


1 - मैं विशेष रूप से "आंतरिक टूलस्मिथ" के बारे में सोच रहा हूं, लेकिन संभवतः अन्य हैं।


5
यही कारण है कि मैंने अपनी शुरुआती नौकरियों से निष्कर्ष निकाला - अन्य लोग महान गति की कीमत पर, काफी कम गुणवत्ता लिख ​​रहे थे। वह मेरी एड़ी है; मुझे बुरा कोड लिखना बहुत मुश्किल है जो मुझे पता है कि मुझे बाद में काटेगा।
19

जिसे हल करना एक आसान समस्या है। आपको अपने सॉफ़्टवेयर वातावरण को बदलने की आवश्यकता है। आपको ऐसे वातावरण में काम करने की आवश्यकता है जहां इसे सही तरीके से प्राप्त करने की तुलना में यह अधिक मूल्यवान हो। वहाँ काम कर रहे हैं जहां यह मायने रखता है।
माइकल शॉ

उन वातावरणों में काम करने के बाद, जहां दोनों समान रूप से मूल्यवान हैं, उन सभी के बीच जो इसे सही पाते हैं - जो इसे सही तरीके से प्राप्त करते हैं, वे उन लोगों की पिटाई कर रहे हैं जो इसे सही धीमी गति से प्राप्त करते हैं। और मुझे लगता है कि मैं बाद वाले समूह में हूं।
ashes999

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

1
@ ashes999: अभ्यास और अनुभव और धैर्य के साथ आप बाद वाले समूह से पूर्व समूह में चले जाएंगे। वहाँ कोई जादू की गोली लेने के लिए है कि आप रात भर संक्रमण होगा।
FrustratedWithFormsDesigner

12

ऐसा लगता है कि आप सभी अच्छे काम कर रहे हैं - कि मध्यम अवधि में आप तेजी से आगे बढ़ेंगे, इसलिए यह स्पष्ट नहीं है कि क्या आप वास्तव में धीमा हैं। केवल आप वास्तव में जानते हैं कि। (लेकिन यह एक बहुत ही वास्तविक संभावना है - PeopleWare एक ही कार्य के लिए डेवलपर्स के बीच 10X उत्पादकता अंतर तक का दावा करता है)।

इसलिए मेरे पास आपके लिए कुछ सुझाव हैं:

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

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

  3. एक "तेज गुणवत्ता" डेवलपर के साथ कुछ जोड़ी प्रोग्रामिंग करें यह देखने के लिए कि क्या आप अंतर को देख सकते हैं।


8

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

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

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

संक्षेप में:

  • अनुभव ऐसे लक्षण पैदा करता है जो आत्मविश्वास और बेहतर सॉफ्टवेयर को बढ़ावा देते हैं।

पुनश्च: अनुभव भी दूसरों से सीखने से आता है। जैसे एसओ, पेयर प्रोग्रामिंग, पीयर रिव्यू आदि से मदद। यदि आपको पीछे मुड़कर देखने और गलतियों से सीखने (या किसी ने आपके प्रयास को कभी चुनौती नहीं दी) तो आपको कोई अनुभव नहीं हो सकता है।


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

@ ashes999, ok! खाली समय कोडिंग के साथ, क्या आप अपने काम की समीक्षा करते हैं? मेरा कहना है कि, कोड के अनुकूलन पर काम करने और इसे प्राप्त करने का समय होना चाहिए। हम सभी कोड कर सकते हैं, लेकिन हम अनुकूलन के लिए खुद को कितनी बार देते हैं?
बुहके सिंडी

@TEG मैं परियोजनाओं के बीच इसकी समीक्षा करता हूं; जैसे। अगर मैं प्रोजेक्ट # 1 पर एक निश्चित तरीके से कुछ कोड करता हूं, तो समान प्रोजेक्ट # 2 पर, मैं डिज़ाइन की खामियों और रिफ्लेक्टर पर बहुत कुछ प्रतिबिंबित कर सकता हूं।
ashes999

@ डैश - "रिफैक्टर ए लॉट" का मतलब है कि आपके पास एक समय सिंक है, क्योंकि आपका प्रारंभिक डिज़ाइन इष्टतम नहीं था। यदि आपका बॉस नहीं जानता है कि आपको यह बताने में समस्या है कि घंटे कहाँ गए। यदि बॉस को पता है, तो आपको यह समझाने में समस्या है कि आपने अपने डिजाइन की समीक्षा किसी अनुभवी सहकर्मी से क्यों नहीं की।

@ माफ करना, मुझे निर्दिष्ट करना चाहिए - शौक परियोजनाओं पर मैं बहुत कुछ रिफ्लेक्टर करता हूं। काम के दौरान, मैं हल्के से रिफ्लेक्टर करता हूं, या दिखाई देने वाले कार्यों को बनाता हूं ताकि मेरे प्रबंधक को पता चल जाए कि मैं रिफलेक्टर कर रहा हूं।
ashes999

8

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

दूसरे शब्दों में, इस तरह के उच्च गुणवत्ता के अपने सावधानी से गढ़ी गई बग फिक्स (परीक्षण मामलों और प्रलेखन सहित) है में यह है कि outweighs बग अपने तेजी से सह कार्यकर्ताओं द्वारा किए गए सुधारों को बनाए रखने के लिए होने की लागत?

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

यदि नहीं, तो आपको दृढ़ता से विचार करना होगा कि ऐसा क्यों है:

  • क्या आप भी अनुभवहीन हैं?
  • क्या आप बहुत अधिक समय उन चीजों को करने में खर्च करते हैं जो अनुरोध नहीं है जो आपको लगता है कि होना चाहिए?
  • क्या आपके पास फिक्सिंग समाप्त होने पर एक कठिन समय निर्धारित करना है?
  • क्या आपके सोचने के बाद आपका कोड कम गुणवत्ता का है?
  • क्या आपको एक अलग तरीके से कोड विकास का दृष्टिकोण करना चाहिए क्योंकि जिस तरह से आप इसे करते हैं उसे गति देने के लिए उठने में आपको बहुत लंबा समय लगता है?
  • क्या आप इस साइट जैसी चीजों पर बहुत अधिक समय बिताते हैं?

इस पर विचार करें और अपने निष्कर्षों के साथ अपने प्रश्न को संपादित करें।


8

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

1) कभी भी सीखना बंद न करें: सामान्य रूप से प्रोग्रामिंग और कंप्यूटर का उपयोग करने के बारे में सब कुछ जानें। उन क्षेत्रों का पता लगाएं, जिनमें आप कमजोर हैं और उन्हें सीखें। यहां तक ​​कि अगर यह आपके काम और सी # से पूरी तरह से असंबंधित लगता है, तो मैं गारंटी देता हूं कि यदि आप इसकी तलाश कर रहे हैं, तो आप अक्सर इसे लागू करने के तरीके पाएंगे जो आप करते हैं। सीखना अनुभव के बारे में भी है, इसलिए केवल सामान न पढ़ें बल्कि इसे आज़माएं और अपने कौशल का विस्तार करें। यदि आप विंडोज का उपयोग करने के लिए उपयोग किए जाते हैं, तो यूनिक्स या इसके विपरीत प्रयास करें। यदि आप सामान्य रूप से आईडीई की कोशिश कमांड लाइन टूल और टेक्स्ट एडिटर या इसके विपरीत का उपयोग करना पसंद करते हैं। यदि आप किसी ऐसे उपकरण या तकनीक के बारे में सुनते हैं जिसे आपने पहले नहीं सुना है या उसके बारे में ज्यादा नहीं जानते हैं, तो आगे बढ़ने का प्रलोभन न दें। इसे देखो! बॉक्स के बाहर सोचने और प्रायोगिक नई तकनीकों को सीखने से डरो मत जो दूसरों को कहती हैं कि वे अव्यावहारिक हैं;

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

3) पोमोडोरो तकनीक का उपयोग करें और जो आपके लिए काम नहीं करता है उसे अनुकूलित / बदल दें। यदि आप इसे इस सूची में नंबर 2 के साथ जोड़ते हैं, तो आपको एक बड़ी उत्पादकता को बढ़ावा मिलेगा।

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

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

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


5

अपने मस्तिष्क का अधिक उपयोग करें और परीक्षण कम करें। ईमानदार होने के लिए, परीक्षण का अपना स्थान है, लेकिन यह महंगा है।

इसके अलावा, यूनिक्स प्रोग्रामिंग की कला (नि: शुल्क ऑनलाइन, मूल्य की पुस्तक) पढ़ें

अंत में, आप सही जगह पर नहीं हो सकते हैं। चौकोर नौकरी आदि में गोल खूंटी।

अंततः यह स्कूल की तरह है: "आउटपुट जो शिक्षक चाहता है" आउटपुट "वह बन जाता है जो प्रबंधन पूछता है और भुगतान करता है"।


3
परीक्षण मुझे तेज बनाता है, धीमा नहीं। कम परीक्षण का मतलब है कि अधिक प्रतिगमन लंबे समय तक अप्रकाशित रहते हैं और ठीक करने के लिए कठिन होते हैं, क्योंकि आप "कुछ टूट सकता है" के डर से कोड में बड़ी छलांग नहीं लगा सकते हैं।
ashes999

मेरे लिए स्वचालित परीक्षण कोड गंध है। इसका मतलब है कि कोड पर्याप्त सरल नहीं था।
क्रिस्टोफर महान

6
यदि आपका कोड इतना सरल है कि उसे परीक्षण की आवश्यकता नहीं है तो यह कुछ भी दिलचस्प नहीं करता है।
हेन हेनरिक्स

तुम्हें कैसे पता, बिल्कुल? ओह, फिर से मानते हुए ... मैं आपको नियम के नियम का उल्लेख करूंगा: स्वच्छ इंटरफेस द्वारा जुड़े सरल भागों को लिखें। (द आर्ट ऑफ यूनिक्स प्रोग्रामिंग से)
क्रिस्टोफर महान

मुझे लगता है कि तुम कुछ हो सकता है, वहाँ, क्रिस्टोफर। यह यहाँ है जहाँ as99 बहुत समय व्यतीत कर रहा है, उदाहरण के लिए "slew"। किसी भी चीज की अति बुरी चीज है। इस मामले में, जब तक आप उड़ान नियंत्रण प्रणालियों के लिए कोडिंग सही नहीं करते हैं, तब तक आप अपने परीक्षण की मात्रा पर फिर से विचार कर सकते हैं। या उस तरह के क्षेत्र में जाएं।
user21007

5

यदि आप एक लार्जिश, समाप्त परियोजना लेते हैं और प्रति व्यक्ति घंटे की "अंतिम" लाइनों की संख्या प्राप्त करते हैं, तो आप पाएंगे कि प्रोग्रामर कोड MUCH धीमी की तुलना में आप कल्पना कर सकते हैं।

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

आपने पुरानी कहावत सुनी होगी - यदि आप इसे टाइप करते समय कोई त्रुटि पकड़ लेते हैं, तो यह आपको 10 गुना समय बचा लेगा यदि आपने इसे बिल्ड टाइम पर पकड़ा है, जो कि QA के दौरान इसे पकड़ने से 10x बेहतर है, जो 10x बेहतर है रिलीज के बाद इसे पकड़ने से ..

तो आप इसे कैसे गति देते हैं? मैं टाइपिंग गति के किसी भी रूप पर ध्यान केंद्रित नहीं करूंगा - त्रुटियों को कम करना और आपके कोड के साथ अन्य "भविष्य के इंटरैक्शन" को बेहतर बनाना आपके समय का बहुत बेहतर निवेश होना चाहिए।

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

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

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

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


3

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

एक बार जब आप वास्तव में HOW के बारे में अधिक जान जाते हैं तो आप अपना समय व्यतीत करते हैं आप बेहतर विचार प्राप्त कर सकते हैं कि क्या सुधार करने की आवश्यकता है और अपने प्रयासों पर ध्यान केंद्रित करें।

आदर्श रूप से आप अपने कुछ सहकर्मियों को भी ऐसा करने के लिए चुनौती दे सकते हैं, अपने परिणामों की तुलना कर सकते हैं, और एक दूसरे से विचार प्राप्त कर सकते हैं। आपके पास शायद कुछ ताकतें हैं जिनसे वे भी लाभ उठा सकते हैं।

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

या हो सकता है कि आपको पता चले कि परीक्षण में आपके विचार से अधिक समय लग रहा है और आपको अपनी इस धारणा पर पुनर्विचार करना होगा कि यह आपको और तेज बना रहा है।

अगर और कुछ नहीं तो यह आपको कुछ बेंचमार्क देता है, जिनके खिलाफ आप काम कर सकते हैं।


3

अपनी सूची से आप ठीक कर रहे हैं।

यदि आपके सहकर्मी एक उच्च सीआरएपी नंबर के साथ कोड बना रहे हैं, तो वे तेजी से जाएंगे। CRAP साइक्लोमैटिक कॉम्प्लेक्सिटी और टेस्ट कवरेज का एक मीट्रिक नाम है।

ऐसा कोड न लिखें, जो आपके लिए अधिक CRAP हो। ;)

पुस्तकालयों का उपयोग करने के लिए सुझाव देने के लिए मेरा एकमात्र परिवर्तन है, उन्हें तब तक न लिखें जब तक कि:

  1. आपकी कंपनी लाइब्रेरी बेचती है
  2. आपने एक पुस्तकालय में पुनरावर्ती कोड को फिर से बनाया है

आप पढ़ रहे हैं और कर रहे हैं और यह बहुत अच्छा है। लेकिन आप खरीददार या OO कोड के बारे में सोचते हुए फंस सकते हैं, क्या आपने खुद को फंक्शनल प्रोग्रामिंग (Haskell?) और Prolog कहा है?

अपने OO प्रोग्रामिंग तकनीक को तेज करने के लिए, क्या आपने Smalltalk / Squeak के साथ खेला है?

और अंत में, सिद्धांत। क्या आपके पास ग्राफ सिद्धांत की कम से कम एक अल्पविकसित समझ है? (कुछ कार्यक्रम कुछ बिंदुओं पर पेड़ों, DAG या सिर्फ सादे रेखांकन के साथ काम करते हैं। नेटवर्क ग्राफ़ हैं)


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

3

मैं अंकल बॉब को उद्धृत करने जा रहा हूँ :

तेजी से जाने का एकमात्र तरीका अच्छी तरह से जाना है।

हर बार जब आप गति के लिए गुणवत्ता का व्यापार करने का प्रलोभन देते हैं, तो आप धीमे हो जाते हैं। हर बार।

- "वीहेमेंट मेडियोरिटी", रॉबर्ट सी। मार्टिन


3

जहाँ तक मुझे पता है कि यह है:

  1. अच्छा
  2. उपवास
  3. सस्ता

एक प्रबंधक के रूप में, आप किसी भी 2 को चुन सकते हैं।

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


2

मुख्य बातें जो मैं सोच सकता हूं, वे इस प्रकार हैं

  • अपनी टाइपिंग स्पीड बढ़ाएं।
  • ऐसे उपकरण का उपयोग करें जो उत्पादकता लाभ प्रदान करते हैं। उदाहरण के लिए ReSharper।
  • तेज़ मशीन या उपकरण। अधिक रैम या एक ठोस राज्य ड्राइव की तरह।

मुझे यकीन है कि कुछ चीजें हैं जो आप कोडिंग कौशल क्षेत्र में भी कर सकते हैं, लेकिन ऐसा लगता है कि आप उन सभी प्रकार की चीजों से अधिक हैं। ऊपर बताई गई बातें आमतौर पर डेवलपर्स द्वारा अनदेखी की जाती हैं।


मैं अपने सहकर्मियों के साथ इन चीजों के संबंध में एक स्तर के खेल के मैदान में हूं (शायद मुझे टाइपिंग की गति में बढ़त है); वे अभी भी तेजी से, किसी भी तरह। अनुभव, शायद?
19

1
एक न्यूनतम न्यूनतम "शिकार और पेक" के ऊपर, टाइपिंग की गति सीमित कारक नहीं है।

2
आपके पास उपकरण (जैसे, रिचार्पर) होने में उनके साथ स्तर हो सकता है , लेकिन क्या आप जानते हैं कि उन्हें प्रभावी ढंग से कैसे उपयोग किया जाए? मैंने बहुत से लोगों को Resharper स्थापित करने के लिए देखा है और फिर यह नहीं सीखा कि 80% सुविधाओं का उपयोग कैसे करें। उस बात के लिए, सुनिश्चित करें कि आप Visual Studio के सभी रीफैक्टरिंग और शॉर्टकट विशेषताओं को समझें। मुझे अपने कार्यालय में पूरे दिन कीबोर्ड पर अपने हाथों को रखने से किसी और पर 2-3% की बढ़त मिलती है। चूहे धीमे हैं :)
EZ हार्ट

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

हम सभी स्तर के हैं। हम में से कोई भी उपकरण नहीं है :)
ashes999

2

आप स्पीड-टाइपिंग का कोर्स कर सकते हैं। मुझे नहीं पता कि टाइपिंग तेज है तो समस्या है लेकिन "कोडिंग भी धीरे धीरे" केवल धीमी टाइपिंग स्पीड के कारण हो सकती है।

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

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


आपके प्रश्न के संपादन के आधार पर, ऐसा लगता है कि आप या तो अपने कुछ सहकर्मियों के मार्ग को ले सकते हैं और एक साथ त्वरित समाधान कर सकते हैं जो काम करेगा - और प्रलेखन और क्यूए को शापित किया जाएगा!

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


यह समयरेखा नहीं है; अन्य सहकर्मी समान कार्य तेजी से कर सकते हैं। शायद यह अनुभव हो। टाइपिंग की गति के लिए +1; मैं लगभग 100WPM टाइप कर सकता हूं, इसलिए ऐसा नहीं है।
as999999

@ ashes999: और यदि वे लोग जो तेजी से एक ही काम कर सकते हैं, वे अधिक अनुभवी हैं, तो आप शायद सिस्टम के साथ अधिक अनुभव से सबसे अधिक लाभान्वित होंगे। अनुभव के लिए समय चाहिए ...
FrustratedWithFormsDesigner 19

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

2

मुझे ओपी के "गति के लिए बलिदान की गुणवत्ता" पर आपत्ति है।

पेशेवर कोडर्स (प्रोग्रामर) को 3 वस्तुओं को संतुष्ट करने की आवश्यकता है:
1) कोड को
2 उद्देश्य के अनुसार चलना चाहिए ) डिलीवरी समय
3 में होनी चाहिए ) अच्छी गुणवत्ता, प्रलेखन, आदि
4) अन्य आदि।

मुझे लगता है, ओपी को शायद इसलिए धीमा बताया गया क्योंकि ओपी ने समय पर काम नहीं किया था।


2

यह एक ऐसा कैच है जो 22 के आसपास होना मुश्किल है। हालाँकि आपको अभी भी अनुभव की कमी हो सकती है और पहले से ही कई पहलुओं में कुछ मात्रा में ज्ञान सबसे अधिक तेज है, पकड़ यह है कि इसे मापना कठिन है

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

मैंने पाया कि मेल रूकावट की वजह से मेल खाने की तुलना में मैं बहुत ज्यादा खा रहा था। अब मैं केवल दिन में दो बार मेल का जवाब देता हूं और कुछ दिनों में लगभग 1 घंटे की उत्पादकता प्राप्त करता हूं। पोमोडोरो जैसी विधियों का प्रयास करें , मैंने इसका उपयोग एक उपाय के रूप में किया। नियमित अंतराल पर (15 मिनट) मैं यह नोट करूंगा कि मैं उस समय क्या कर रहा था। इसने मुझे यह देखने की अनुमति दी कि मेरे दिनों को कैसे संरचित किया गया था और अधिकतम दक्षता के लिए मैं क्या कर सकता था।


तो आप कह रहे हैं कि आप अपने आप को ओएस-सैंपल की तरह है? दिलचस्प। :)
sum1stolemyname

वास्तव में यह एक समय ट्रैकिंग विधि का एक साइड इफ़ेक्ट था जिसे मैंने कुछ समय के लिए आज़माया ( davidseah.com/tools/ett/alpha )। कुछ दिलचस्प और अप्रत्याशित डेटा रुझानों को चालू किया जब मैंने इसे समय ट्रैकर भाग से परे देखना शुरू किया। इसके बाद मैंने पोमोडोरो, जीटीडी और इस तरह के बारे में सीखा।
न्यूटोपियन

0

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

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

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