क्या सॉफ्टवेयर कंपनी के पास अनुसंधान और / या उपयोगिता पुस्तकालयों के लिए एक समर्पित टीम होनी चाहिए?


15

मैं एक ऐसी कंपनी में काम करता हूं जो विभिन्न बैंकों और कुछ छोटी ई-दुकानों के लिए वेब अनुप्रयोग करती है। हम लगभग 20 डेवलपर्स को रोजगार देते हैं और किसी भी समय विकास में 4-5 परियोजनाएं रखते हैं। हमारी विकास टीमें अधिक बातचीत नहीं करती हैं और बहुत सी समान समस्याएं विभिन्न तरीकों (अच्छे से बुरे) में की जाती हैं।

मैं सोच रहा था कि क्या किसी कंपनी के लिए ऐसे प्रोग्रामर्स की टीम का होना अच्छा होगा जो करंट फ्रेमवर्क पर रिसर्च करते हैं और फंक्शन्स की कॉमन लाइब्रेरी में लगातार सुधार करते हैं और करंट और फ्यूचर प्रोजेक्ट्स को बनाने के लिए एक कॉमन फ्रेमवर्क को ज्यादा तेजी से और ज्यादा कुशलता से बनाते हैं।

इस तरह की एक टीम कितनी बड़ी होनी चाहिए?

इसके साथ ही इसमें स्थायी सदस्य होने चाहिए जो दूसरों को प्रशिक्षित करें या इसे लोगों को घुमाना चाहिए?

अद्यतन: मैं एक आम परियोजना के बारे में सोच रहा था कि लोग मज़े के लिए काम कर सकते हैं जो कुछ रुचि पैदा कर सकता है। ऐसा लगता है कि जब लोगों के पास नौकरी के दबाव होते हैं तो वे जो समाधान लेते हैं वे सबसे अच्छे नहीं होते हैं।


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

जवाबों:


19

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

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


2
व्यवस्थित रूप से उगाए जाने के लिए +1। इन चीजों को टीमों पर थोपना बहुत मुश्किल है।
जॉन हॉपकिंस

मैं कार्बनिक ढांचे से सहमत हूं, यही मैं वास्तव में सोच रहा था :) इसे कलात्मक रूप देने के लिए धन्यवाद।
Liviu टी।

+1। आप हमेशा फ्रेमवर्क को रिफ्लेक्टर कर सकते हैं, लेकिन इसे सामने से डिजाइन करने से भी चीजों का उपयोग किया जा सकता है क्योंकि वे वहां हैं भले ही नौकरी के लिए सही उपकरण न हो।
लैरी कोलमैन

वास्तविक जरूरतों के लिए ढांचा बनाएं, नकली नहीं।
ट्यूलेंस कोर्डोवा

9

मेरी भावना नहीं है।

मुझे संदेह है कि अगर आपको ऐसा लगता है कि आपने ऐसा किया है कि पुस्तकालयों का निर्माण करने वाली व्यक्तिगत टीमों के बजाय जो कि उस टीम का उपयोग नहीं करता है, तो आपके पास एक विशेष टीम होगी जो पुस्तकालयों का निर्माण करेगी जिसका उपयोग टीम के बाहर कोई नहीं करता (और ऐसा कर रहा है काफी अतिरिक्त लागत पर)।

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

आपके पास समस्या यह नहीं है कि कौन पुस्तकालयों का निर्माण करता है (उन चीजों की आवाज़ से जो आपके पास पहले से ही इन समस्याओं के कई समाधान हैं, इसलिए कोई और कैसे मदद करने जा रहा है?), यह है कि टीमें बात नहीं कर रही हैं और बातचीत नहीं कर रही हैं।

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

मैं सुझाव देता हूं:

  • परियोजनाओं के बीच टीमों को घुमाएं
  • इंटर टीम लंच और चर्चा समूह रखें
  • प्रोजेक्ट प्रॉजेक्ट्स की समीक्षा करें कि समस्याओं को कैसे हल किया गया (अन्य टीमों द्वारा भाग लिया गया)
  • विकी आउटलाइनिंग कोड का एक क्षेत्र सेट करें जो पुन: प्रयोज्य हो सकता है (और जो इसके बारे में बात करना है)
  • अच्छे री-यूज़ को प्रोत्साहित करने के बारे में सोचें - वास्तव में लोग इसे करने के लिए अतिरिक्त भुगतान करते हैं। यदि किसी घटक का पुनः उपयोग करने से लागत में 5 दिन और $ 2000 की बचत होती है, तो परियोजना के अंत में एक रात के लिए टीम को अतिरिक्त लाभ देने वाले $ 200 क्यों नहीं दिए जाते हैं (जब आपने बचत को मान्य किया था तो बचत वास्तविक थी)

एक पुस्तकालयों की टीम होगी, मुझे संदेह है, कोई फायदा नहीं हुआ।

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

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


3

वह एक वास्तुकार का काम है ।

सॉफ्टवेयर आर्किटेक्ट की मुख्य जिम्मेदारियों में शामिल हैं:

  • अनुप्रयोग विकास को आगे बढ़ाने का एक मानक तरीका चुनकर विकास के दौरान उपलब्ध विकल्पों को सीमित करना
  • एप्लिकेशन के लिए एक एप्लिकेशन फ्रेमवर्क बनाना, परिभाषित करना या चुनना
  • संगठन में या व्यापक प्रणाली पर्यावरण को देखने और समझने के द्वारा संगठन में संभावित पुन: उपयोग को पहचानना
  • संगठन में अन्य अनुप्रयोगों के ज्ञान वाले घटक डिजाइन बनाना

इसके बारे में और पढ़ें: - सॉफ्टवेयर आर्किटेक्ट - सॉल्यूशन आर्किटेक्ट - एंटरप्राइज आर्किटेक्ट


प्रत्येक प्रोजेक्ट के लिए एक सॉफ्टवेयर आर्किटेक्ट होना चाहिए, केवल एक युगल जो कई प्रोजेक्ट्स या एक प्रति कंपनी को हैंडल करे?
लिविउ टी।

यह इस बात पर निर्भर करता है कि परियोजनाएँ कितनी बड़ी हैं। एक एंटरप्राइज़ आर्किटेक्ट के साथ शुरू करें यदि उसे और अधिक किराए की ज़रूरत है। एक एंटरप्राइज आर्किटेक्ट के पास प्रोजेक्ट्स में स्ट्रैटेजिक थिंकिंग है। कृपया आर्किटेक्ट प्रकारों के बारे में अधिक पढ़ें। आपको वास्तुकारों के मिश्रण की आवश्यकता हो सकती है। en.wikipedia.org/wiki/Software_altect
अमीर रज़ाई

3

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

कार्यात्मकताओं को ढांचे में विकसित करने के मुख्य कारण हैं

1. यह डेवलपर के लिए उपयोगी है।
जहां यह उपयोगी
हो गया है, वहां कुछ मामले हैं। यह दूसरों के लिए उपयोगी हो सकता है

जब आप 2 हिट करते हैं, तो कार्यक्षमता पहले से ही है, आप इसे किसी और को कैसे पारित कर सकते हैं?


3

मुझे खेल में थोड़ी देर हो गई है लेकिन मुझे ऐसा लगा जैसे कोई इसे संबोधित नहीं कर रहा है:

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

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


2

मुझे लगता है कि यह एक अच्छा विचार नहीं है , क्योंकि पुस्तकालयों के लिए उपयोगी होने के लिए उन्हें वास्तविक परियोजना की समस्याओं को हल करने में आपकी मदद करनी होगी, और आप केवल उन्हें जानने के लिए, अच्छी तरह से ... वास्तविक परियोजनाओं में काम कर रहे हैं।

अन्यथा आप "सैद्धांतिक रूप से" बहुत अच्छे पुस्तकालय के साथ समाप्त हो सकते हैं!


1

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

मैं जो होने की उम्मीद कर रहा हूं, वह यह है कि उपकरण समूह अपने छोटे से कार्यक्रम पर जा रहा है, ऐसे कार्यों का उत्पादन करेगा जो वास्तव में उपयोगी नहीं थे, लेकिन जिसने एपीआई को अव्यवस्थित किया और पर्याप्त उपयोग किया, ताकि वे आसानी से नहीं हो सकें हटा दिया। वे पर्याप्त रूप से दस्तावेज नहीं करेंगे।

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


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

0

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

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