पीएम एक अत्यधिक जटिल सेटअप के लिए चयन करते हैं जिसका अनुभव किसी के पास नहीं है [बंद]

Question

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

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

---

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

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

---

इससे पहले कि आप "हाँ आपको उन सेवाओं का उपयोग करना चाहिए", ध्यान रखें कि कोई भी इनका उपयोग करना नहीं जानता है या यह भी जानता है कि वे दौड़-हालत से ग्रस्त कोड के अलावा क्या करते हैं।

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

Comments

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

— रिबॉल्डएडीडी

आप एक अनुत्पादक पीएम के साथ काम कर रहे हैं। आप या तो रुक सकते हैं या जा सकते हैं। संभवतः उसी तरह की नीरसता उसी पीएम के तहत अन्य परियोजनाओं के साथ होगी।

— फ्रैंक हिलमैन

क्यों पीएम तकनीकी निर्णय ले रहे हैं ?! यह एक वास्तविक परियोजना गंध है अगर मैं कभी एक गंध था।

— रबरडुक

यह एक बच्चे को जंजीर खरीदने और बाहर जाने के लिए दबाव डालने और पेड़ काटने के लिए दबाव डालने जैसा है, इसलिए यह पैसे की बर्बादी नहीं थी।

— जेफो जूल

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

— ग्रेग बर्गार्ड्ट

Answer 1

एक बार जब हम परियोजना के आधे रास्ते पर थे, पीएम ने कहा कि हमें थ्रेड्स के बजाय थर्ड पार्टी मैसेज कतार क्षमताओं का उपयोग करना था और लोडिंग संतुलन को लागू करना था

यह पीएम के लिए एकतरफा "राज्य" के लिए उचित बात नहीं है। दो कारण:

1. डिजाइन निर्णय एक तकनीकी संसाधन द्वारा किया जाना चाहिए और केवल एनएफआर के जवाब में । इसलिए विनम्रतापूर्वक अपने पीएम से पूछें कि क्या कोई नया एनएफआर है और यदि आप विवरण दे सकते हैं।

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

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

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

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

Comments

ठीक है, यह जवाब है। एक परियोजना प्रबंधक को कभी भी इस प्रकार के निर्णय नहीं लेने चाहिए। पैसे? समय? प्रोजेक्ट प्रबंधन इसे संभालता है। RabbitMQ? कोई मौका नहीं।

— ग्रेग बरगार्ड

मुझे यह जवाब बहुत पसंद है। वहाँ जगह सुनिश्चित करने के लिए नियंत्रण कर रहे हैं कि आप सिर्फ नरक तुम पर गिरा नहीं है। उसके साथ बैठो और इसके बारे में बात करो।

— Rhys जॉन्स

हालाँकि, एक बात यह है कि कभी-कभी यह चूसते समय, आपको बस एक नई तकनीक या पुस्तकालय सीखना होगा। क्या यह समय लगेगा, हाँ, लेकिन यह सिर्फ इसके लायक हो सकता है।

— Rhys जॉन्स

एक प्रोजेक्ट मैनेजर के रूप में, मैं इस जवाब से अधिक सहमत नहीं हो सका।

— जेम्स मैकलियोड

छोटे संगठनों में "प्रोजेक्ट मैनेजर" अक्सर बॉस होता है। उनके पास मालिक के सीईओ के कान हो सकते हैं, और प्रभावी रूप से तकनीकी लीड डेवलपर या वास्तुकार या कुछ अप्रिय संयोजन हो सकते हैं। इस मामले में उनके रिमिट का दायरा स्पष्ट नहीं है।

— स्लेज

Answer 2

क्या बेवकूफी होगी कि खुद को मौत के घाट उतार दिया जाए ।

आप जो वर्णन कर रहे हैं, वह यह है कि आपने महत्वपूर्ण अनुभव खो दिया है। नियंत्रण की कोई भावना नहीं है और इसे वापस करने का कोई स्पष्ट तरीका नहीं है।

आखिरी चीज जो आपको करनी चाहिए वह है कड़ी मेहनत, अपने सिर को नीचे रखें, और चुपचाप पीड़ित रहें जब तक कि वे अंततः स्वीकार न करें कि परियोजना बर्बाद हो गई है।

आपको जो करना चाहिए वह इस बारे में बहुत कठिन है कि आपको क्या उम्मीद है।

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

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

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

अब ध्यान रखना। यह उपकरण नहीं है जो दौड़-हालत से ग्रस्त कोड पेश करता है। आप लोगों ने ऐसा ही किया। आपको यह जानने की ज़रूरत है कि आपने ऐसा कैसे किया ताकि आप उसे पूर्ववत कर सकें।

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

गंभीरता से, बस इस में देना परियोजना के लिए अव्यवसायिक और घातक है।

मैं यहाँ आदमी हूँ। एक बार फिर। यह आपको बेवकूफ महसूस कराता है। वास्तव में ऐसा नहीं है। तुम बस खो गए हो।

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

यदि वह फिर से शुरू करने के लिए पॉलिश का काम नहीं करता है क्योंकि आप जल्द ही इसकी आवश्यकता के लिए जा रहे हैं। इस तरह या किसी और तरह।

Comments

Now keep in mind. It isn't the tools that introduced race-condition plagued code. You guys did that. You need to learn HOW you did that so you can undo that.हाँ, यह हिस्सा विशेष रूप से मुझ पर चिपक जाता है। चाहे वह अजवाइन हो या धागे, किसी भी प्रकार की संगामिति दौड़ की स्थिति का परिचय दे सकती है। वही मुद्दे अच्छी तरह से थ्रेड-आधारित कोड में मौजूद हो सकते हैं।

— इजाकाता

Answer 3

यह वास्तव में workplace.stackexchange.com पर होना चाहिए, क्योंकि समस्या वास्तव में एक सॉफ्टवेयर विकास प्रश्न नहीं है, बल्कि कार्यस्थल संबंधों के बारे में है।

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

Answer 4

आपके प्रबंधन द्वारा संदर्भ और उत्पाद रणनीति का पता नहीं, यह आपके प्रश्न का उत्तर देने में मुश्किल है।

यहाँ कुछ वस्तुनिष्ठ तर्क दिए गए हैं। हालांकि यह संभव है कि यह वह नहीं हो, जिसकी आपको उम्मीद थी:

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

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

Answer 5

तीसरे पक्ष के पुस्तकालयों (और अन्य घटकों) के लिए दो दृष्टिकोण हैं:

1. इनका अधिक से अधिक उपयोग करें
2. उनमें से कम से कम उपयोग करें

मेरा दृष्टिकोण (2) है। ऐसा लगता है कि आपका दृष्टिकोण भी (2) है, लेकिन परियोजना प्रबंधक दृष्टिकोण (1) को पसंद करता है।

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

यदि आप दृष्टिकोण को बदलने के लिए पीएम को आश्वस्त करना चाहते हैं, तो इन तर्कों पर विचार करें:

• सीखने का समय। प्रत्येक बाहरी पुस्तकालय को सीखने के लिए समय की आवश्यकता होती है, उस समय में एक सक्षम प्रोग्रामर वांछित कार्यक्षमता लिख ​​सकता है, खासकर यदि एक विशाल पुस्तकालय को केवल एक बहुत ही सरल काम करने के लिए चुना गया था जो कोड की कुछ सैकड़ों लाइनों में किया जा सकता था।
• Replaceability।यदि आपके पास एक बाहरी पुस्तकालय है, तो आप यह कैसे सुनिश्चित करते हैं कि यदि इसका विकास रोक दिया गया है, तो आप इसे अन्य समान पुस्तकालय से बदल सकते हैं? मेरा समाधान बाहरी पुस्तकालयों से बचने के लिए है जब भी मैं कर सकता हूं, और जब भी यह संभव नहीं होता है, तो मैं अपने इच्छित प्रोग्रामिंग इंटरफ़ेस के भाग को सार करने के लिए एक सरल आवरण लिखता हूं। आमतौर पर मैं जो इंटरफ़ेस चाहता हूं, वह उस लाइब्रेरी की तुलना में बहुत सरल है, जो लाइब्रेरी प्रदान करती है। फिर मेरा कोड केवल इस आवरण के माध्यम से बाहरी पुस्तकालय तक पहुंचता है, जिससे प्रतिस्थापन आसान हो जाता है। कुछ ढांचे पर अपने पूरे आवेदन का निर्माण एक बड़ी संख्या है। सर्वलेट? हां, वे लंबे समय से यहां हैं और भविष्य के लिए यहां बने रहेंगे। टेम्पलेट इंजन? हां, हालांकि वे बिल्कुल बदली नहीं हैं (आप आमतौर पर एक को चुनते हैं और उसी के साथ रहते हैं), वे जो मूल्य लाते हैं वह बहुत बड़ा है, इसलिए सावधानी से चयन करें - और ध्यान रखें कि टेम्प्लेट इंजन को स्विच करते समय, आपके पास एक ही एप्लिकेशन में दो टेम्पलेट इंजन हो सकते हैं, लेकिन आमतौर पर एक ही एप्लिकेशन में आपके दो फ्रेमवर्क नहीं हो सकते। अपाचे स्ट्रट्स? नहीं, फ्रेमवर्क फैशन में आते हैं और जल्दी-जल्दी फैशन से बाहर हो जाते हैं, और आप आमतौर पर एक ही एप्लीकेशन में दो फ्रेमवर्क नहीं रख सकते।
• संस्करण नरक। बाहरी लाइब्रेरी का चयन करके, आपको सुरक्षा कमजोरियों से बचने के लिए इसे अपडेट करना होगा, और इसे अपडेट करने से चीजें टूट सकती हैं। अच्छी तरह से डिज़ाइन किए गए घटक (जैसे जावा जेआरई) विभिन्न संस्करणों के साथ संगत हैं, लेकिन मेरा अनुभव है कि विशाल संस्करण नरक लागू करने के कारण अधिकांश पुस्तकालय बकवास हैं। इसके अलावा, घटक X को Z संस्करण 1 की आवश्यकता हो सकती है और घटक Y को Z संस्करण 2 की आवश्यकता हो सकती है, और आप जरूरी नहीं कि उसी अनुप्रयोग में Z संस्करण 1 और Z संस्करण 2 को लिंक कर सकें।
• सुरक्षा कमजोरियां। एक बाहरी पुस्तकालय का चयन करके, आपके आवेदन के खिलाफ आसानी से शोषक सुरक्षा कमजोरियों की संख्या बढ़ जाती है। कुछ लोग दावा कर सकते हैं कि घर में विकसित कोड अस्पष्टता के माध्यम से सुरक्षा जैसा दिखता है, लेकिन फिर मैं कहूंगा कि यह अभी भी सुरक्षा का एक रूप है।
• लाइसेंस जारी करता है। प्रत्येक बाहरी लाइब्रेरी आपके प्रोग्राम के कुछ हिस्सों पर अपना लाइसेंस लगाती है। उदाहरण के लिए, गैर-जीपीएल कार्यक्रमों में जीपीएल पुस्तकालयों का उपयोग नहीं किया जा सकता है, और एलजीपीएल पुस्तकालयों को बायनेरिज़ के साथ स्रोत कोड के वितरण की भी आवश्यकता होती है, जिसमें काफी मात्रा में बैंडविड्थ हो सकती है।
• अनुप्रयोग स्टार्टअप समय। प्रत्येक बड़ी बाहरी लाइब्रेरी आपके एप्लिकेशन के स्टार्टअप समय को धीमा कर देती है। एक सरल, दुबला पुस्तकालय इन-हाउस लिखकर, आप अपने एप्लिकेशन के स्टार्टअप समय को बहुत तेज कर सकते हैं।
• स्मृति पदचिह्न। X की आवश्यकता होने से Y को Z की आवश्यकता होती है Z को A आवश्यक B की आवश्यकता होती है, आपको एक ही समय में मेमोरी में X + Y + Z + A + B की आवश्यकता होती है। केवल X के समतुल्य को लागू करने से, हम इसे X ', इन-हाउस कहते हैं, आपको मेमोरी में सिर्फ X' की आवश्यकता है। और आमतौर पर X का मेमोरी फुटप्रिंट X के मेमोरी फुटप्रिंट से कम होता है।
• बग जोखिम। बाहरी घटक में जितनी अधिक लाइनें होती हैं, उतना ही उच्च जोखिम होता है कि आप एक बग में चलेंगे जो कि बड़ी मात्रा में कोड के कारण आपको ठीक करना मुश्किल होगा, जिसे आपको समझने की आवश्यकता है। यदि आप इन-हाउस बात करते हैं, तो आप इसे आमतौर पर कोड की कम लाइनों के साथ करते हैं (बस आपको क्या चाहिए, कुछ नहीं करना है), और इस प्रकार, बग का छोटा जोखिम।
• Customizability। यदि मैं स्वयं एसक्यूएल क्वेरी लिखता हूं, तो मुझे पता है कि क्वेरी क्या दिखता है और किसी दिए गए डेटाबेस इंजन पर कितना अच्छा प्रदर्शन करता है और इंडेक्स का सेट दिया गया है। यदि, दूसरी ओर, SQL क्वेरी बाहरी घटक द्वारा लिखी गई है, तो मुझे इसके प्रदर्शन के बारे में कुछ नहीं पता है। मैं एक ऐसी कंपनी में काम करता था जहाँ प्रत्येक वेब पेज को लाने में कई सेकंड लगते थे। मुझे संदेह था कि इसका कारण हाइबरनेट पुस्तकालय था जो डेटाबेस से बहुत अधिक डेटा स्वचालित रूप से प्राप्त करते थे जब आपको आवश्यक एक आइटम नहीं था और इस विशेष आइटम से संबंधित सभी आइटम नहीं थे। मैंने धीमेपन का सही कारण खोजने से पहले कंपनी छोड़ दी, क्योंकि मुझे मौजूदा पुस्तकालयों की बड़ी संख्या का उपयोग करने का दृष्टिकोण पसंद नहीं था।

विशेष रूप से खबरदार अगर एक पुस्तकालय खुद को एक रूपरेखा कहता है । इसका मतलब है कि पुस्तकालय को आपको अपने पूरे आवेदन को अपने चारों ओर बनाने की आवश्यकता है। आप आम तौर पर एक ही आवेदन में दो ढांचे नहीं रख सकते हैं; वे शांति से सह-अस्तित्व के बिना एक-दूसरे के साथ लड़ेंगे। वेब विकास उपयोगिता पुस्तकालय? हाँ कृपया, इनमें से बहुत कम हैं। यदि मुझे कभी भी मेरे द्वारा उपयोग किए जाने वाले पुस्तकालय से बेहतर पुस्तकालय मिल जाए, तो मैं पुराने कोड में पुराने पुस्तकालय का उपयोग जारी रखते हुए नए कोड का उपयोग नए कोड में कर सकता हूं। वेब विकास की रूपरेखा? एक बड़ा सम्मान नहीं!

Answer 6

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

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

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

Answer 7

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

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

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

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

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