क्या एक डेवलपर को धीमा कर सकता है? [बन्द है]

Question

एक डेवलपर को धीमा करने के लिए क्या चीजें होती हैं?

कृपया उत्तर पोस्ट करने से बचने की कोशिश करें:

• अब धीमी हैं, लेकिन सुविधा में उपयोगी हैं। (टीडीडी, रिफ़ेक्टिंग, ...)
• ध्यान भंग करना ।

Comments

@ मर्क ट्रैप: हुह ?! यह बिल्कुल भी डुप्लिकेट नहीं है ...: -एस

— तमारा विजसमैन

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

— तमारा विजसमैन

हुह, URL मंग गया। डुप्लिकेट क्या प्रोग्रामिंग के दौरान विचलित हो सकता है?

प्रश्न को खुला छोड़ने के लिए चुना क्योंकि यह उन चीजों के बारे में है जो विचलित नहीं हैं ...

— तमारा विजसमैन

Stackoverflow, SuperUser, Programmers ... हाँ, मूल रूप से इस तरह की साइट्स :)

— bedwyr

Answer 1

ओह यह आसान:

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

Comments

संक्षेप में: प्रबंधन? ; ओ)

— n1ckp

@ n1ck नहीं, नहीं। अच्छा प्रबंधन एक डेवलपर को गति दे सकता है। प्रोग्रामर के समय की खराब समय-सारणी (यानी प्रबंधक होने का एक पहलू) वास्तव में विकास को धीमा कर सकता है।

— गेहूं

जब मेरी कंपनी ऐसा करती है तो मुझे क्या मारता है: बैठकें, अधिक बैठकें, अंतिम बैठक के बारे में बैठकें, बैठक करने के लिए तैयार करना, बैठक में चर्चा करना कि हम कुछ भी पूरा क्यों नहीं कर सकते। हम कुछ भी पूरा क्यों नहीं कर सकते? आपको सुनकर एक कमरे में बैठे चौदह देवता मिले हैं !!

— माइक एम।

कृपया ध्यान दें कि यह उत्तर पावरपॉइंट स्लाइड पर लगभग फिट होगा ।

Answer 2

एक धीमा कंप्यूटर

Comments

यहाँ भी यही समस्या है

— pramodc84

मैं खुद को एक लैपटॉप ASAP खरीदता हूं और उस पर काम करता हूं, अगर मैं उस स्थिति में था, तो कंपनी ने इसे टीसी की अनुमति दी।

— शाम 5:00

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

— eda-qa mort-ora-y

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

— मेटलमेस्टर

Answer 3

कुछ भी जो संदर्भ स्विचिंग का कारण बनता है ।

Comments

कीबोर्ड पर टाइप करना पसंद है?

Answer 4

StackOverflow, programmers.stackexchange.com, आदि :)

Comments

असहमत! StackOverflow मुद्दों को हल करने में मदद करता है, इसलिए यह विकास को गति देता है!

— जादूगर

आपत्तिजनक चुगली। हर मिनट के लिए मैंने SO पर 'बर्बाद' कर दिया है, इसने मुझे 20 वापस खरीद लिया है।

— MIA

+1। आक्रामक बिल्कुल नहीं। एसओ शिथिलता के लिए बहुत अच्छा है। यह मेरा नया फेसबुक है। :)

— बैक 2 डोस

@ back2dos कृपया एसओ की अशिष्टता की तुलना उस टुकड़े से न करें .. जो कि फेसबुक है।

— adamk

Answer 5

मैं कहूंगा कि बर्नआउट।

Answer 6

एक प्रक्रिया का पालन करने का कोई भी प्रयास जो हाथ में लिए कार्य के अनुकूल नहीं है।

यह सभी प्रकार की चीजें हो सकती हैं, लेकिन आम लोग जो मुझे देखते हैं उनमें शामिल हैं:

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

ये सभी चीजें कुछ परियोजनाओं पर या कुछ स्थितियों में बेहद सार्थक हो सकती हैं, लेकिन कुछ संगठन हर चीज को एक तरह से करने की कोशिश करते हैं और इससे अन्य परियोजनाओं पर खराब असर पड़ता है जो अक्सर उत्पादकता की मौत होती है।

Answer 7

राजनीति

उदाहरण: जब एक से अधिक व्यक्ति आवश्यकताओं (या बदतर, दो अलग-अलग निहित स्वार्थों) के मालिक होते हैं, और वे विकास की आवश्यकताओं के अनुसार प्रतिस्पर्धा और परस्पर विरोधी परिवर्तन करते हैं।

Answer 8

दूसरों की बातचीत

और सामान्य रूप से शोर

कई जवाब संदर्भ-स्विच करने और ज़ोन से बाहर निकलने के बारे में बात करते हैं, और शोर, विशेष रूप से बातचीत, उन चीजों में से एक है जो मेरे लिए उन लोगों की ओर जाता है।

मेरे घुन में, मैं हर तरफ शोर और बातचीत से घिरा हुआ हूं। एक पंक्ति में, मेनफ्रेम टीम घन पंक्ति में लगातार नियोजन बैठकें करती है। कभी-कभी, वे दीवार के साथ एक कार्यालय में सलाहकारों के साथ मिलेंगे, और वह ज़ोर से हूटिन और 'हॉलरिन' और 'लफ़िन' की ओर जाता है और मुझे उनके दरवाजे बंद करने के लिए कहना होगा।

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

" क्या आप केवल शोर-रद्द करने वाले हेडफ़ोन प्राप्त नहीं कर सकते हैं " का तत्काल और स्पष्ट उत्तर, जब आप चाहते हैं तो मौन होने पर मदद नहीं मिलती है।

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

यदि आप चाहते हैं कि आपके प्रोग्रामर वे काम करें जो उन्हें करने की ज़रूरत है, जो कि मुख्य रूप से सोच और विचार करना और विचार करना है, तो उन्हें एक वातावरण की आवश्यकता होती है जहां वे ऐसा कर सकते हैं।

Comments

शायद ही कभी यह बहुत शांत हो जाता है जहां मैं हूं। मैं हर किसी के माउस क्लिक और भारी सांस लेने वाले लोगों आदि पर ध्यान केंद्रित करना शुरू कर देता हूं ... यह बिस्तर पर लेटने और क्रिकेट सुनने जैसा है।

— kirk.burleson

Answer 9

पर्याप्त परीक्षणों के बिना कोड की बहुत सी पंक्तियाँ लिखना।

Comments

यह मेरे अनुभव में बाधा डालने वाली चीजों का नंबर एक कारण है।

— Paddyslacker

@Paddyslacker: अधिक परीक्षण = अधिक उत्पादक? है ना? केवल उन लोगों के लिए जो पहली बार प्रोग्रामिंग में नहीं होना चाहिए। टेस्ट उपयोगी हो सकता है लेकिन "चीजों को रोकने के लिए नंबर एक का कारण"? क्या आप गंभीर हैं?

— n1ckp

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

— Paddyslacker

@ IPaddyslacker: मुझे नहीं पता। कभी उन्हें कोड नहीं देखा। हो सकता है कि वे आपके विवरण से प्रबंधन में बेहतर हों? और ठीक परीक्षण की कमी के कारण कोड क्यों अप्राप्य हैं? टेस्ट खराब कोड को किसी तरह के जादू से महान बना सकता है?

— n1ckp

@ n1ck, परीक्षण शुरू में कोड लिखते समय भुगतान नहीं करते हैं, लेकिन बाद में कोड बनाए रखने के लिए बहुत अधिक अंतर करता है।

Answer 10

उच्च गुणवत्ता वाली कॉफी का अभाव।

Comments

या अच्छे सोडा की कमी है। मुझे बहुत डिकैफ़िनेटेड डाइट चेरी कोक याद आती है! मेरे देश में मुझे केवल डाइट कोक, या डिकैफ़िनेटेड कोक, और चेरी कोक बिल्कुल नहीं मिल सकता है :-(

— जादूगर

@ छिपकली - मैं एक कंपनी के लिए काम करता हूं जो डाइट चेरी कोक प्रदान करती है। यकीन नहीं होता कि मैंने क्यों छोड़ा। अगर आपका दर्द महसूस होता है।

— जेफ़ो

@ छिपकली: बस मार्शिनो चेरी का एक जार खरीदें और अपने पेय में कुछ सिरप जोड़ें। अब आप इसे जितना चाहें उतना मजबूत बना सकते हैं ... (वैनिला के लिए एक ही चाल: असली वेनिला कोक पूर्व मिश्रित सामान से कहीं बेहतर है)

— शोग

@श्री। सी: समस्या यह है कि मुझे आहार + डेका कोक की आवश्यकता है, एक संयोजन जो मेरे देश में उपलब्ध नहीं है।

— जादूगर

Answer 11

सही अनुमान लगाने के बाद कि एक बार विकास शुरू होने से पहले वीरानी नहीं होनी चाहिए, यह मेरी राय में चिकन-अंडे का परिदृश्य है

Comments

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

— एमआईए

ओह, मैंने पहले एक का उपयोग किया है, प्रतिक्रिया हमेशा यह है कि मैं अनुमान लगाने में बुरा हूं, अगर इसे दृश्यमान 2-4 घंटे के कार्यों में नहीं तोड़ा जा सकता है तो मैं इसे गलत तरीके से कर रहा हूं

— मेटागुरु

Answer 12

किसी और की टूटी हुई इमारत को ठीक करना

Comments

लगता है जैसे कोई अपने सहकर्मी को अच्छी तरह से सलाह नहीं दे रहा है।

— प्रदर्शित नाम

@ बॉल्ड: यह स्वाभाविक रूप से एसिंक्रोनसिटी से हो सकता है। मान लें कि दैनिक बिल्ड कटऑफ का समय सुबह 5 बजे है, और आप 9:00 पर नवीनतम संस्करण की जांच करते हैं। (दूसरे शब्दों में, आप लोगों को जल्दी काम पर आने से नहीं रोक सकते।)

— 22

Answer 13

बिना किसी एजेंडे के बैठकें।

एक धीमी मशीन।

एक दूसरे मॉनिटर की कमी।

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

मशीन पर इंटरनेट एक्सेस की कमी, MSDN / stackoverflow / आदि को थोड़ा दर्द देते हुए क्वेरी करना।

Comments

नो एजेंडा मीटिंग से संबंधित मीटिंग हाइजैकर है। आप जानते हैं ... आप इसे एक घंटे के लिए कैलेंडर पर रखते हैं, लेकिन भले ही विषय 20 मिनट में लिपटा हो, फिर भी उस आदमी को 20 मिनट भरने के लिए अन्य विषयों को ढूंढना पड़ता है। मैं आपको उभार दूंगा, लेकिन फिर मुझे आपको एक धीमी गति के रूप में "दूसरे मॉनिटर की कमी" पर उतारना होगा। यह सुविधाजनक है, लेकिन इस अवसर पर नहीं होने से मुझे धीमा नहीं पड़ा है।

— MIA

Answer 14

बहुत ज्यादा समय प्रोग्रामिंग में बिताया

यहां तक ​​कि अगर आप वास्तव में प्रोग्रामिंग पसंद करते हैं, तो उस पर बहुत अधिक समय बिताना अंततः आपको जला देगा ...

Answer 15

आपको "ज़ोन" से बाहर निकलने वाली हर चीज़ से बचें। इसका मतलब है कि आपका ईमेल इनबॉक्स, आपका ट्विटर पॉपअप एप्लिकेशन, आपकी कॉर्पोरेट चैट आदि।

एक के बाद शांत काम कर हालत है कि डेस्कटॉप से बचने का मतलब है शोर भी।

Answer 16

कोई भी परिवर्तन अनुरोध जिसे लागू करने में आसान होता अगर आप इसके बारे में हाथ से पहले जानते थे।

Comments

"पानी पर चलना और एक विनिर्देशन से सॉफ्टवेयर को विकसित करना आसान है अगर दोनों जमे हुए हैं"

— बैक 2 डोस

सिली बोली। बर्फ पर चलना हमेशा आसान नहीं होता है।

— पीटर बॉटन

@Peter Boughton: यदि हम एक पैमाना चुनते हैं, जहाँ उतार-चढ़ाव वाले चश्मे से सॉफ्टवेयर विकसित करना कठिन है और जमे हुए लोगों से आसान है, तो बर्फ पर चलना हमेशा आसान होता है। आप ऐसा करने के लिए एक 6 साल की उम्र सिखा सकते हैं। लेकिन मुझे लगता है कि आप जानते हैं कि, आप सिर्फ स्मार्ट गधे से आनंद लेते हैं।

— back2dos

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

— पीटर बॉटन

Answer 17

गरीब कोड।

किसी और के हिस्से को फिर से लिखना, जो पहली जगह में काम कर सकता था, वह सबसे बड़ा समय सिंक है जिसकी मैं कल्पना कर सकता हूं।

Answer 18

बहुत ज्यादा यह आपके लिए धीमा है, इसके लिए एक अच्छा ब्लॉग पोस्ट है।

...

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

...

यह अपरिहार्य है कि उत्पाद और नवाचार गैर-विभेदक कार्यों पर डेवलपर्स द्वारा खर्च किए गए समय को कम करने में मदद करेंगे। सवाल यह है कि उन सेवाओं और उपकरणों को किस रूप में लिया जाएगा।

...

Comments

+1: शानदार जवाब। मैंने नौकरी छोड़ दी क्योंकि कंपनी तकनीकी ऋण को कम करने के लिए समय देने के लिए तैयार नहीं थी। डेवलपर्स को "कोर इन्फ्रास्ट्रक्चर-स्तर की विशेषताओं को बार-बार दोहराने" के लिए मजबूर किया गया था।

— जिम जी

Answer 19

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

Comments

ऐसा लगता है कि आप टीम के सदस्यों के बीच बहुत कम काम फैलाने के कारण आने वाली अड़चनों के बारे में बात कर रहे हैं।

— एमआईए

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

— HLGEM

Answer 20

इस तरह से stackexchange.com पर प्रश्नों के उत्तर देना।

Comments

आप अपने स्पर्श टाइपिंग कौशल में सुधार पर विचार कर सकते हैं।

Answer 21

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

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

स्पष्ट रूप से परिभाषित आवश्यकताओं का अभाव, जिसके कारण उन्हें चीजों का पता लगाने या निर्णय लेने की आवश्यकता होती है।

Answer 22

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

मैं जा सकता था, लेकिन यह शुक्रवार है और मैं काम के बारे में भूलना चाहता हूं।

Comments

लगता है जैसे आपको वहाँ से निकलने की ज़रूरत है!

— adamk

Answer 23

• प्रलेखन की कमी (सिस्टम, कंपनी, आदि)
• टिप्पणी कोड की कमी
• व्यवस्था की अधूरी समझ
• राजनीति (यानी अनावश्यक बैठकें, कागजी कार्रवाई, प्रबंधन द्वारा बाधाएं ...)
• अपूर्ण आवश्यकता प्रलेखन
• फेसबुक!
• बहुत नींद आती है?

Answer 24

परियोजना पर बहुत से लोग।

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

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

Answer 25

दूसरों द्वारा बताई गई बातों के अलावा, अपने कोड को संकलित करने और चलाने और एक सकारात्मक / नकारात्मक परिणाम प्राप्त करने का निर्णय लेने के बीच का लंबा रास्ता । आदर्श रूप से, यह RTT सिर्फ एक सेकंड होगा, लेकिन मैंने घंटों का एक उदाहरण देखा है। BTW, यूनिट परीक्षण इस समस्या से निपटने की कोशिश करता है।

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

Answer 26

• अत्यधिक कागजी कार्रवाई

• किसी ऐसे व्यक्ति पर निर्भरता होना जो कभी आस-पास न हो (जैसे कि आपका बॉस - यदि आपको कोई प्रश्न पूछने की आवश्यकता है लेकिन वह हमेशा बैठकों में है)

• अपर्याप्त उपकरण और उपकरण।

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

• टूटी हुई कॉफी मशीन

• गलत कार्य सौंपे जा रहे हैं

Answer 27

एयर कंडीशनिंग काम करने में विफल।

तो सर्दियों में -5 की गर्मियों में कार्यालय में तापमान 40 डिग्री तक बढ़ जाता है।

-5 टाइपिंग के लिए अच्छा नहीं है, क्योंकि मैं दस्ताने और प्रकार नहीं पहन सकता। 40, बस मेरी सोच को धीमा कर देती है।

Answer 28

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

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

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

जल्दी से काम कर कुछ प्राप्त करें और इसे सुधारें।

Comments

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

— adamk

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

— होमडे

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

— माइक एस

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

— '19

Answer 29

प्रोग्रामर का ब्लॉक : अन्य धीमी गति के विपरीत, यह एक को हल करना कठिन है।