आपको सॉफ्टवेयर आर्किटेक्ट के रूप में टेबल पर क्या लाना चाहिए? [बन्द है]


20

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

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

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

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

संगठन के आधार पर यह काम नहीं कर सकता है। एक SA जो TFS पर निर्भर करता है वह सब कुछ लागू करने के लिए एक नियोक्ता पर अपनी योजना को लागू करने के लिए संघर्ष कर सकता है जो केवल StarTeam का उपयोग करता है। इसी तरह, एसए को परियोजना के चरण के आधार पर लचीला होना चाहिए। यदि यह एक नई परियोजना है, तो उनके पास अधिक विकल्प हैं, जबकि वे मौजूदा परियोजनाओं के लिए कम हो सकते हैं।

यहाँ कुछ SA कहानियाँ दी गई हैं, जिन्हें मैंने उम्मीद में कुछ पृष्ठभूमि साझा करने के तरीके के रूप में अनुभव किया है, जो मेरे सवालों के जवाब भी इन मुद्दों पर कुछ प्रकाश डाल सकते हैं:

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

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

  • एसए जो सभी परियोजनाओं के लिए डीटीओ, डीओ, बीओ, सेवा परतों और इतने पर उपयोग को लागू करेगा। नए देवों को इस वास्तुकला और एसए को दृढ़ता से लागू किए गए दिशानिर्देशों को सीखना था। उपयोग दिशानिर्देशों के अपवाद तब बनाए गए थे जब दिशानिर्देशों का पालन करना बिल्कुल कठिन था। एसए उनके दृष्टिकोण में आधारित था। डीटीओ और सभी सीआरयूडी संचालन के लिए कक्षाएं कोडस्मिथ के माध्यम से उत्पन्न की गईं और डेटाबेस स्कीमा मोम की एक और समान गेंद थी। हालाँकि, इस सेटअप का उपयोग हर जगह होने के बाद, SA, LINQ to SQL या Entity फ्रेमवर्क जैसी नई तकनीकों के लिए खुला नहीं था।

मैं इस पोस्ट को वेंटिंग के लिए एक मंच के रूप में उपयोग नहीं कर रहा हूं। ऊपर बताई गई SA कहानियों के साथ मेरे अनुभवों के सकारात्मक और नकारात्मक पहलू थे। मेरे सवाल उबलते हैं:

  1. SA को टेबल पर क्या लाना चाहिए?
  2. वे अपने निर्णय लेने में संतुलन कैसे बना सकते हैं?
  3. क्या एक एसए नौकरी (जैसा कि पहले परिभाषित किया गया है) को इस मानसिकता के साथ लागू करना चाहिए कि उन्हें कुछ जमीनी नियमों को लागू करना चाहिए?
  4. और कुछ भी विचार करने के लिए?

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


यदि SA FXCop का उपयोग कर रहा था, तो वह अपंग क्यों होगा? एफएक्सकोप के साथ सबसे बड़े एप्लिकेशन की समीक्षा के लिए कुछ मिनट से अधिक समय नहीं लेना चाहिए।
रॉबर्ट हार्वे

दूसरी गोली सिर्फ यह लगती है कि एसए ने गलती की है, हालांकि यह एक बुरा है। यदि वह उन लोगों के लिए पर्याप्त बनाता है जो कंपनी को एक नया SA मिल जाता है।
रॉबर्ट हार्वे

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

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

SA को टेबल पर क्या लाना चाहिए? व्हिस्की का एक गिलास, एक बंदूक और दो गोलियां।
एडम क्रॉसलैंड

जवाबों:


23

एक सिस्टम आर्किटेक्ट चाहिए:

  1. उच्च-स्तरीय वास्तुकला निर्दिष्ट करें
  2. कोड समीक्षाओं में भाग लें
  3. स्वीकृत तकनीकों का उपयोग करें
  4. अपने कोडिंग प्रयास में डेवलपर्स की सहायता करें
  5. विकास अनुसूची को बनाए रखना और उसकी निगरानी करना
  6. UML आरेख, गैन्ट चार्ट और जैसे जैसे SA कलाकृतियों का निर्माण करें।

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

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

सभी मनुष्यों की तरह, SA कर सकते हैं और गलतियाँ करते हैं। अच्छे लोग उन गलतियों से सीखते हैं, और बेहतर SA बन जाते हैं।


5. प्रोजेक्ट मैनेजर के लिए होना चाहिए, नहीं?
B20овиЈ

8

मैं एक वास्तुकार में कभी नहीं चला, जो उपयोगी था, मुख्यतः क्योंकि वे व्यावहारिक नहीं थे।

मेरे लिए मेरे द्वारा देखे गए सबसे बड़े मुद्दे हैं:

  • नेत्रहीन प्रक्रिया के लिए प्रक्रिया का पालन करना
  • समस्या जानने से पहले तकनीक के बारे में अंधा पूर्वाग्रह
  • एक अच्छा औचित्य के बिना नियमों का निर्माण और प्रवर्तन
  • rewrite from scratch मानसिकता

सबसे अच्छा "आर्किटेक्ट्स" जिसे मैंने टेबल पर लाया है:

  • प्रश्न जो समस्या की बेहतर समझ और संभावित समाधानों की ओर ले जाते हैं।
  • डिजाइन विकल्प / प्रौद्योगिकी और उनके व्यापार-नापसंद।
  • डिजाइन और प्रौद्योगिकियों की निंदा और समर्थन दोनों के लिए स्पष्ट और तर्कसंगत स्पष्टीकरण।

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


-1 आपने स्पष्ट रूप से अच्छे वास्तुकारों के साथ काम नहीं किया है। मैं जिन आर्किटेक्ट के साथ काम करता हूं, वे पहले चार बिंदुओं में से कोई भी नहीं करते हैं।
स्टीफन

7

1 टेबल पर एसए को क्या लाना चाहिए?

  • एक मोटी त्वचा
  • अच्छी बातचीत कौशल
  • विभिन्न सॉफ्टवेयर स्तरों की एक अच्छी समझ (चक्करदार AJAX अच्छाई से निम्न स्तर नेटवर्किंग I / O तक)। जरूरी नहीं कि आप विशेषज्ञ हों, लेकिन आप इस बारे में महत्वपूर्ण निर्णय लेने वाले हैं कि किस सॉफ्टवेयर को किस लेयर पर निष्पादित किया जाना चाहिए।
  • कोड में अपने हाथों को गंदा करने की इच्छा, सफेद कागज के डिजाइन बस इसे काट नहीं करते हैं।
  • सॉफ्टवेयर शिल्प कौशल को प्रोत्साहित करना - जब भी संभव हो चीजों को सही तरीके से करने के लिए जयजयकार करें और सबसे अच्छा तरीका अन्य मामलों में सीमाएं दें। इसलिए सोर्स कंट्रोल, टीडीडी, बिल्ड और सीआई, कोडिंग डीओजेओ, कोड रिव्यू, एक अच्छा अंक ट्रैकिंग सिस्टम आदि जैसी चीजें

2 वे अपने निर्णय लेने में संतुलन कैसे बना सकते हैं?

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

3 क्या एक एसए नौकरी (जैसा कि पहले परिभाषित किया गया है) इस मानसिकता के साथ होनी चाहिए कि उन्हें कुछ जमीनी नियमों को लागू करना चाहिए?

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

वहाँ बहुत अधिक है, मुझे लगता है कि इस के लिए आने वाले कुछ बहुत अच्छे जवाब होने जा रहे हैं।


आपकी बातों के लिए +1। वे बहुत स्पष्ट करते हैं कि क्या आवश्यक है और अच्छी, छोटी, अच्छी तरह से एकीकृत टीमों में जाता है।
टेलोंक्स

3

1. SA को टेबल पर क्या लाना चाहिए?

"क्या उन्हें 'कानून को खत्म करने' की मानसिकता के साथ आना चाहिए ... या उन्हें प्रारंभिक दिशा और रणनीति को निर्दिष्ट करना चाहिए और फिर जहाज की दिशा को सही करने के लिए आवश्यकतानुसार वापस कूदना चाहिए?"

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

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

2. वे अपने निर्णय लेने में संतुलन कैसे बना सकते हैं?

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

3. क्या एक एसए नौकरी (जैसा कि पहले परिभाषित किया गया था) के साथ दृष्टिकोण है कि उन्हें कुछ जमीनी नियमों को लागू करना चाहिए?

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

4. कुछ और विचार करें?

  • अपने दूसरे उदाहरण के संदर्भ में: ऐसा लगता है कि परियोजना की टीम ने एक इन-हाउस सबसिस्टम पर एक बहुत अच्छी तरह से निर्भरता का गठन किया। ढीले कपल्ड facades सिर्फ तीसरे पक्ष के कोड के लिए नहीं हैं। उस सबसिस्टम के लिए एक अमूर्त बनाना, उस पुस्तकालय का उपयोग करने के लिए एक आसान संक्रमण की अनुमति दे सकता था अगर घर में समाधान विफल रहा। यह अकेले एक सॉफ्टवेयर आर्किटेक्ट के लिए एक तार्किक समाधान है, लेकिन टीम अभिव्यक्ति की चिंताओं के साथ परियोजना प्रबंधक का एक रूप होने के नाते, यह दोगुना होना चाहिए ताकि एक स्पष्ट समाधान हो।
  • अपने तीसरे उदाहरण के संदर्भ में: सॉफ्टवेयर बनाने के लिए एक ज्ञात वास्तुकला या प्रक्रिया का होना कोई बुरा विचार नहीं है (हालाँकि, माना जाता है कि आपने 'सभी प्रोजेक्ट्स' कहा था)। यह क्या काम करता है के लिए चिपके हुए है। इसके साथ ही कहा, ऐसे अवसर होने चाहिए, जहां नई तकनीकों को देखने का प्रयास किया जा सके कि क्या वे अतिरिक्त मूल्य लाते हैं। इन-हाउस सॉफ़्टवेयर, या छोटे दायरे वाली परियोजनाएँ जहाँ इन तकनीकों का प्रयास किया जा सकता है, वे आदर्श स्थान हैं। हालांकि, ध्यान रखें कि प्रौद्योगिकियों को अपनाने के लिए शोध और पुष्ट प्रदर्शनों / तर्कों को प्रदान करने के लिए विकासकर्ता भी है। और SA को हर प्रतिस्पर्धी ORM और उसकी खूबियों और कमजोरियों को जानने की उम्मीद नहीं की जा सकती है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.