क्या एक डेवलपर को धीमी विकास मशीन देने से परिणाम अधिक तेज / अधिक कुशल हो जाता है? [बन्द है]


130

मान लीजिए मैं अपने डेवलपर्स को एक तेज़ तेज़ मशीन देता हूं। WPF- आधारित VS2010 बहुत जल्दी लोड होता है। डेवलपर तब WPF या WPF / e एप्लिकेशन बनाता है जो उसके बॉक्स पर ठीक चलता है, लेकिन वास्तविक दुनिया में बहुत धीमा है।

इस प्रश्न के दो भाग हैं ...

1) अगर मैं किसी डेवलपर को धीमी मशीन देता हूं, तो क्या इसका मतलब है कि परिणामस्वरूप कोड तेज या अधिक कुशल हो सकता है?

2) 'विशिष्ट' रनटाइम अनुभव देते हुए मैं अपने डेवलपर्स को एक तेज़ आईडीई अनुभव देने के लिए क्या कर सकता हूं?

अपडेट करें:

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


20
शायद वे एक आभासी पीसी में आवेदन का परीक्षण किया है!
मार्क सी

209
मैं अवाक हूँ कि यह एक सवाल भी है। यह धीमा विकास और खराब मनोबल के अलावा और कुछ कैसे कर सकता है?
फॉस्को

76
अत्याधुनिक पर विकसित करें। सबसे खराब मशीन पर परीक्षण करें जो आप पा सकते हैं।
एडम

14
क्या क्लीनर के फर्श में एमओपी परिणाम के बजाय टूथब्रश से फर्श की सफाई की जाती है? ज़रूर करता है, आखिरकार। एक एमओपी ऑपरेटर गंदगी को 150 सेंटीमीटर और साथ ही टूथब्रश ऑपरेटर से 30 सेंटीमीटर दूर नहीं रख सकता है। एक बड़ी मंजिल के साथ कोशिश मत करो।
dbkk

13
स्वयं पर ध्यान दें: कभी भी मेकरोफथिंग्स 7 के लिए काम न करें
मैट बी

जवाबों:


234

पूर्ण रूप से

यह भी सच है कि प्रबंधकों को सुअर-लैटिन में सभी बैठकें आयोजित करनी चाहिए। यह सरल वाक्यों को बोलते समय उन्हें नुकसान पहुंचाने के लिए समग्र रूप से उनके संचार कौशल में सुधार करता है। उन्हें अपनी बात कहने के लिए चेहरे के भाव और शरीर की भाषा पर अधिक निर्भर रहना पड़ेगा और हम सभी जानते हैं कि सभी संचार माध्यमों का कम से कम 70% हिस्सा है।

सीएफओ को केवल एक अबेकस और चाक का उपयोग करना चाहिए। अन्यथा वे 'कच्चे डेटा' पर बहुत अधिक भरोसा करते हैं और उनके 'आंत महसूस' पर पर्याप्त नहीं।

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


85
मुझे व्यंग्य पसंद था। +1
टेरेंस पोंस

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

1
मुझे यहां कोई व्यंग्य नहीं दिखता। +1
फिनकेक

376

जवाब है (मैं बोल्ड और कहूंगा) हमेशा

सं

आप अपने बजट के साथ प्राप्त कर सकते हैं, और उन उपकरणों की न्यूनतम-अधिकतम कल्पना सीमा पर परीक्षण करें, जिन्हें आप तैनात करेंगे।

वहाँ एमुलेटर, वर्चुअल मशीन, परीक्षकों के साथ वास्तविक मशीनें हैं, जो यह देख सकते हैं कि यह एक कारक है या नहीं।


10
यह एक से अधिक बार वोट नहीं दे सकता है, हालांकि मैं चाहता हूं कि मैं कर सकता हूं। मेरे पास एक उम्र बढ़ने वाला कंप्यूटर है जिस पर मैं काम करता हूं और कुछ कार्यों को पूरा करने के लिए VS2010 के लिए समय लगता है (जैसे परियोजना खोलें) बहुत कष्टप्रद हो सकता है।
rjzii

108
क्या आप कृपया कोई बहुत बड़ा और साहसिक कार्य नहीं कर सकते हैं ?
हनीबल लेक्टर

4
आपके द्वारा की जाने वाली स्वीकृति परीक्षण में प्रदर्शन आवश्यकताओं को शामिल किया जाना चाहिए। बीई प्रदर्शन आवश्यकताओं होना चाहिए। यदि आप प्रदर्शन का परीक्षण नहीं करते हैं तो आपके परीक्षक को ग्राहक कहा जाता है (और आप उनसे पैसे वसूलते हैं)।
टिम विस्क्राफ्ट

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

1
जवाब नहीं गलत है। सही उत्तर है नूओहूओ!
पेका P

70

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

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


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

4
एक और बात पर विचार करना उन्हें कम से कम दूसरे पीसी पर एक खाता दे रहा है जिसमें प्रशासनिक विशेषाधिकार नहीं हैं।
डेविड थॉर्नले


33

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


कौन ... एक मिनट रुको। यदि संकलन जल्दी हो जाता है, तो यह अब संभव नहीं होगा: xkcd.com/303
gbjbaanb

32

विकास सबसे अच्छे वातावरण में किया जाना चाहिए जो संभव हो। परीक्षण सबसे खराब वातावरण में किया जाना चाहिए जो संभव है।


27

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


26

एंबेडेड सिस्टम प्रोग्रामर हर समय इस में चलते हैं! और दो भाग समाधान है:

  1. आपकी आवश्यकताओं को Y हार्डवेयर पर X प्रदर्शन निर्दिष्ट करना होगा।
  2. Y हार्डवेयर पर परीक्षण करें, और जब आपको X प्रदर्शन नहीं मिलता है, तो बग दर्ज करें।

फिर इससे कोई फर्क नहीं पड़ता कि आपके डेवलपर्स किस हार्डवेयर पर काम करते हैं।

एक बार जब आप ऐसा कर लेते हैं, तो कहते हैं कि तेज़ उपकरण आपके प्रोग्रामर को दिन में आधे घंटे, या साल में 125 घंटे बचा सकते हैं। और मान लें कि वे प्रति वर्ष $ 100,000 का खर्च और ओवरहेड (सिलिकॉन वैली के लिए हास्यास्पद रूप से कम), या $ 50 प्रति घंटे खर्च करते हैं। वह 125 घंटे * $ 50 / घंटा $ 6250 है। इसलिए यदि आप प्रति प्रोग्रामर के विकास हार्डवेयर पर $ 6250 प्रति वर्ष से कम खर्च करते हैं, तो आप पैसे बचा रहे हैं।

यही आपको अपने प्रबंधन को बताना चाहिए।

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


24 अक्टूबर जोड़ा गया:

मेरे पूर्व-नियोक्ता के पास वह सिद्धांत था, और इसने उन्हें लगभग 100 मिलियन डॉलर की मदद दी।

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

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

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

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


+1 भी कुछ हलकों में तीस मिनट बहुत मामूली अनुमान हो सकता है।
जस्टिन 12

20

प्रोग्रामिंग में, एक पुरानी कहावत है कि " समय से पहले अनुकूलन सभी बुराई की जड़ है "। मुझे लगता है कि आप सफलतापूर्वक सभी बुराई की एक और "जड़" (या कम से कम पहली शाखा) बनाने में कामयाब रहे हैं। अब से, हम कह सकते हैं कि "समय से पहले विकासकर्ता को अपनाना सभी बुराई की जड़ है।"

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

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

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

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

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


"हमें छोटी क्षमताओं के बारे में भूलना चाहिए, समय के 97% के बारे में कहना चाहिए: समय से पहले अनुकूलन सभी बुराई की जड़ है"। कुछ डिज़ाइन करते समय 3% के बारे में 2 मिनट के लिए सोचना एक अच्छा विचार है।
कीयो

15

दिलचस्प पढ़ना, उन सभी जवाब।

लेकिन मुझे लगता है कि यहां जवाब देने वाले अधिकांश लोग इस बिंदु को याद कर रहे हैं। सवाल, जैसा कि मैंने पढ़ा कि यह (केवल कम से कम) डेवलपर्स को वास्तव में तेज कोड बनाने के लिए P1 देने के बारे में नहीं है।

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

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

कुछ हफ़्ते पहले मैंने 1995 से एक लैपटॉप शुरू किया था। विंडोज 3.x कुछ ही समय में ऊपर और ऊपर चल रहा था। डेटाबेस मैं कुछ डेटा आरंभ कुंजी से पूरी तरह से जारी होने से पहले प्राप्त करना चाहिए (लगभग कम से कम)।

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

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

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

और इसी तरह

मुझे अच्छा लगता है :-)


निकर्स चियर्स


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

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

10

1) अगर मैं किसी डेवलपर को धीमी मशीन देता हूं, तो क्या इसका मतलब है कि परिणामस्वरूप कोड तेज या अधिक कुशल हो सकता है?

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

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

2) 'विशिष्ट' रनटाइम अनुभव देते हुए मैं अपने डेवलपर्स को एक तेज़ आईडीई अनुभव देने के लिए क्या कर सकता हूं?

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

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

यदि आपके डेवलपर कोई भी अच्छा काम करते हैं, तो उन्हें आपसे यह सूचित करना चाहिए (यह मानते हुए कि आपने उनसे पूछा है।)


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

1
"2) 'सामान्य' रनटाइम एक्सपीरियंस देते हुए मैं अपने डेवलपर्स को तेज़ आईडीई अनुभव देने के लिए क्या कर सकता हूं? आपको अपने डेवलपर्स से यह पूछना चाहिए।" मेरा मानना ​​है कि यह एक प्रोग्रामर की एसई साइट है, न कि प्रबंधकों की एसई साइट। वह देवों से पूछ रहा था।
स्टिम्पी 77

1
"आप एक 4x4 वाहन का निर्माण करना चाहते हैं जो कठोर परिस्थितियों, बारिश, कीचड़, जो भी हो, के तहत काम कर सकता है। क्या आप अपने इंजीनियरों और असेंबली लाइन को तत्वों के तहत डालने जा रहे हैं ताकि यह सुनिश्चित हो सके कि परिणामस्वरूप वाहन उन पर काम कर सकता है?" <<< सादृश्य प्यार करता हूँ
stimpy77

6

इसका परिणाम बिचिन के डेवलपर्स का एक समूह है। यह सामान काफी कठिन है जैसा कि यह है, चलो अनुभव को बदतर नहीं बनाते हैं।

मैं आपको प्रोत्साहित करूंगा कि आप अपने उपयोगकर्ताओं के लिए एक टेस्ट या QA परिवेश में समान प्रदर्शन मुद्दों पर ध्यान दें। वह एक अच्छा विचार है।


8
डेवलपर्स कि कुतिया? कोई रास्ता नहीं ...
जे क्यू कतार

6

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

घटना में दिलचस्पी जोड़ने के लिए, वहाँ एक अंधा प्रोग्रामर था। मैं पूरी तरह से प्रभावित हुआ।

वैकल्पिक शब्द


3
ब्लाइंड प्रोग्रामर? क्या यह भी संभव है?
वर्नरसीडी

1
@WernerCD, मैं आज भी कोशिश करता हूं और मन की शक्ति की कल्पना करता हूं जो मेरे सिर में कोड की लाइनों का ट्रैक रखने के लिए होनी चाहिए।
जेई क्यू

3
हां, हम में से ज्यादातर सर्वर सॉफ्टवेयर लिख रहे हैं ... +1
goodguys_activate

@ MakerOfThings7, मुझे अपनी स्थानीय मशीन पर किसी भी दिन अधिक सर्वर हार्डवेयर दें, $ खर्च करें जहां यह होना चाहिए (लेकिन मुझे एक बड़ा मॉनिटर दें :)) मुझे अपने दशक पुराने डेल लैटीट्यूड सीपीएक्स के साथ कोई समस्या नहीं है जो बड़ी प्रणालियों के लिए एक डिस्प्ले है। डीसी।
जेई कतार

4
शायद एक अंधा प्रोग्रामर ब्रेल डिस्प्ले का उपयोग कर सकता है?
अंटसन

5

यह एक बुरा विचार नहीं है - लेकिन आप चाहते हैं कि आपके डेवलपर्स को एक तेज़ प्रोग्रामिंग वातावरण मिले।

आप अपने प्रोग्रामरों को दो मशीनें - एक तेज़ देव बॉक्स और परीक्षण के लिए एक धीमी वस्तु बॉक्स (संभवतः आभासी) देकर संभवतः इसे लागू कर सकते हैं।

वीएस बिल्ड प्रक्रिया के कुछ ट्वीटरिंग, दूरस्थ डिबगिंग के साथ, टेस्ट बॉक्स को आदर्श बनाने के लिए तैनाती कर सकते हैं।

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


5

समस्या यह नहीं है कि डेवलपर मशीन एक तेज मशीन पर अक्षम कोड का निर्माण कर रही है, समस्या यह है कि आपने प्रदर्शन मेट्रिक्स को परिभाषित नहीं किया है जिसे इसके खिलाफ मापा जाना चाहिए।

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

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


5

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

यह कहा जा रहा है, मैं ऐसा करने की वकालत नहीं कर रहा हूं, खासकर एक प्रवीण वातावरण में। सबसे पहले, यह demoralizing है। यह तथ्य कि लगभग सभी ने कहा कि विचार का अर्थ यह भी नहीं था कि प्रोग्रामर विचार पर बुरी तरह से प्रतिक्रिया करते हैं।

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

अंत में: उत्पादित कोड तेजी से हो सकता है, लेकिन यह निश्चित रूप से उत्पादन करने में अधिक समय लेता है।


+1 लेकिन मुझे कुछ बिंदुओं पर सहमत नहीं होना है। मैंने एक नेटबुक भी खरीदी, लेकिन मैंने नोट किया है कि गति वास्तविक समस्या नहीं है, यह छोटे स्क्रीन आकार की है। चलते-चलते छोटी परियोजनाओं के लिए 1GHz काफी तेज है, लेकिन 1024x600 बहुत छोटा है।
जो डी

4

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

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


4

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


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

4

मुझे लगता है कि यह एक दिलचस्प सवाल है, और मैं जल्दी से "नहीं" के लिए नहीं जाऊंगा। मेरी राय है: यह इस बात पर निर्भर करता है कि हम किस तरह की विकासशील टीम के बारे में बात कर रहे हैं। उदाहरण: यदि आप एक ऐसे समूह का नेतृत्व कर रहे हैं जो वार्षिक ICFP प्रोग्रामिंग प्रतियोगिता के लिए चल रहा है, तो शायद HPC क्लस्टर पर विकासशील समय की एक छोटी राशि के बाद अच्छे परिणाम होने का मतलब यह नहीं होगा कि आपके द्वारा पाया गया समाधान अच्छा है। वही कहा जा सकता है यदि आप कुछ वैज्ञानिक या संख्यात्मक एल्गोरिदम लिख रहे हैं: 64 एमबी मेमोरी के साथ अपने पुराने एएमडी ड्यूरन 600 मेगाहर्ट्ज पर आप जिस तरह से चीजें कर रहे हैं उसके बारे में सावधान रहने के लिए मजबूर हैं, और यह कुछ डिज़ाइन को भी प्रभावित कर सकता है। विकल्प।

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

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


5
फिर बताओ क्या - एक बहुत अच्छा कंप्यूटर खरीदो, और मैं तुम्हारे साथ स्वैप करूँगा ... :)
विनो द सैन

4

मैं एक पैकेज पर काम करता हूं जिसे मेरी 8 कोर 8 जी मशीन (पूर्ण स्वच्छ बिल्ड) पर बनाने में लगभग एक घंटे का समय लगता है। मेरे पास एक अपेक्षाकृत कम अंत वाला लैपटॉप है जिसका मैं परीक्षण करता हूं। कम अंत लैपटॉप एक कार्य दिवस के दौरान दो पूर्ण बिल्ड का प्रबंधन नहीं करता है।

क्या मैं लैपटॉप पर किए गए कुछ जानबूझकर परीक्षण के साथ फास्ट मशीन पर अधिक उत्पादक हूं, या क्या मुझे लैपटॉप पर अपने सभी बिल्ड करना चाहिए?

ध्यान रखें कि ये नंबर नहीं बने हैं।

यह एक धांधली डेमो है कि मुझे आम तौर पर हर दिन एक स्वच्छ निर्माण करने की आवश्यकता नहीं है (मैं एकल मॉड्यूल पर बहुत परीक्षण कर सकता हूं), लेकिन यहां तक ​​कि आंशिक बिल्ड भी मोटे तौर पर संकलन / लिंक समय में अंतर का एक क्रम दिखाते हैं ।

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

काम पाने के दृष्टिकोण से मैं एक तेज़ मशीन पर विकास करना पसंद करता हूँ। मैं और अधिक मज़बूती से डेडलाइन हिट कर सकता हूं। दूसरी ओर मुझे लगता है कि अगर प्रबंधन ने मुझे मेरी धीमी मशीन पर विकास किया तो मुझे बहुत अधिक वेब ब्राउज़िंग करना होगा, या कम से कम पुस्तक पढ़ना होगा।


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

1
एक कप कॉफी पीने के लिए आपको आधे दिन का समय लगता है? आप सरकार के लिए काम कर रहे होंगे।
फाइननव

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

3

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

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

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

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


3

मैं यहाँ भी प्रवृत्ति को हिरन करने जा रहा हूँ।

किस्सा: मैंने एक डच सॉफ्टवेयर डेवलपमेंट फर्म के लिए काम किया, जिसने 286 कंप्यूटरों को 486-es (हां, मैं वह बूढ़ा हूं) में अपग्रेड किया। हफ्तों के भीतर हमारे सभी इन-हाउस पुस्तकालयों के प्रदर्शन में 50% की गिरावट आई और कीड़े बढ़ गए ... एक छोटे से शोध से पता चला कि लोग अब डिबगिंग प्रक्रिया के दौरान खुद कोड के माध्यम से नहीं सोचते थे, लेकिन 'जल्दी' क्रमिक कोड का सहारा लिया -> संकलन -> परीक्षण -> फिक्स (कोड) आदि चक्र।

संबंधित: जब मैंने संयुक्त राज्य अमेरिका में उसी कंपनी के लिए एक सहायक कंपनी शुरू की, तो मैंने रूसी प्रोग्रामर को काम पर रखना समाप्त कर दिया क्योंकि वे कम सुविधाओं / कम शक्ति वाले पीसी के लिए उपयोग किए जाते थे और बहुत अधिक कुशल कोडर थे।

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

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


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

3

विकास के समय की तुलना में हार्डवेयर कम खर्चीला है।

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


3

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


2

यह एक दिलचस्प विचार है (देवों को एक धीमी मशीन देने से उन्हें अधिक अनुकूलन करने की ओर अग्रसर किया जा सकता है)।

हालांकि, समाधान को बेहतर तरीके से तैयार किया गया है - कार्यक्रमों के लिए आवश्यकताओं में प्रतिक्रिया समय डालें, और परीक्षण के लिए एक कम-अंत मशीन उपलब्ध है।

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


2

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

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

यदि संभव हो तो आप लिनक्स पर विकसित होने देना चाहते हैं। सभी प्रकार के अतिरिक्त कार्यों के लिए उपकरण बहुत बेहतर हैं (बस किसी फ़ाइल में किसी चीज़ के लिए grep, आदि)। इससे एंटी-वायरस से भी छुटकारा मिलता है।


एक तेज़ हार्ड ड्राइव के लाभ को न भूलें: कोडिंगहोरर.कॉम
जिम जी।

2

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


2

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


2

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


2

प्रोग्रामर से पूछना कि क्या प्रोग्रामर को अच्छा हार्डवेयर मिलना चाहिए, एक मोटे आदमी से पूछना पसंद है कि क्या उसे खाना पसंद है। मुझे पता है कि यह व्यक्तिपरक आदान-प्रदान है, लेकिन फिर भी ... सवाल हमें पूछने लायक है? : पी

मैंने कहा कि बेशक मैं बहुमत से सहमत हूं: नहीं

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