एक टीम के रूप में एप्लिकेशन आर्किटेक्चर में निरंतरता कैसे रखें?


46

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

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

मैं निरंतरता लागू करने के बारे में कैसे जाऊँ? यह मेरे लिए महत्वपूर्ण लगता है, लेकिन मेरी टीम के सदस्य "अगर यह काम करता है, तो यह काम करता है" की सदस्यता लेता है।

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


8
क्या आप हमें अपनी मौजूदा SDLC प्रक्रिया के बारे में बता सकते हैं? क्या आप झरना, फुर्तीली आदि हैं? क्या आप TFS या कार्य प्रबंधन का उपयोग करते हैं? क्या आप कोड समीक्षा करते हैं या FxCop या कोड सत्यापन के अन्य रूपों का उपयोग करते हैं? क्या आप डिजाइन प्रलेखन का उत्पादन करते हैं? क्या आपके पास एक निर्दिष्ट वास्तुकार की भूमिका है?
जॉन वू


1
@gnat: नहीं एक महान डुप्लिकेट, अगर जवाब किसी भी संकेत हैं।
रॉबर्ट हार्वे

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

1
यह सॉफ्टवेयर इंजीनियरिंग की पवित्र कब्र (दूसरी पवित्र कब्र से अलग है, जिसकी सटीक आवश्यकता है)।
PMF

जवाबों:


52

क्या तुम्हें इतना खास बनाता है?

मेरा सीपीयू कहता है कि यह काम करता है और मैं घर जाना चाहता हूं। मुझे क्यों परेशान कर रहे हो?

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

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

सबसे अच्छा तरीका यह है कि जल्दी से संवाद करें। मुझे मत बताओ "हम इस दुकान में हमारे DB प्रकारों के लिए तार का उपयोग नहीं करते हैं" 6 महीने बाद मैं विचार पर बस गया। यह बताना कि इसे 2 साल के लिए दफन कर दिया गया है, मुझे ऐसा करने का कोई औचित्य नहीं है।

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

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

क्यों? हर सेकंड जो मैं कोड लिखने के बाद गुजरता है तेजी से इसे बदलने की लागत बढ़ाता है। ऐसा इसलिए है क्योंकि कोड की मेरी मेमोरी में आधा जीवन है। मैं उस क्षण को भूलने लगता हूं जब मेरा मूत्राशय टूटने की मांग करता है।

उन चीजों को कम करें जिन्हें आप उनके अंतर्निहित सिद्धांतों के बारे में परवाह करते हैं। मुझे अनुसरण करने के लिए 101 नियमों की एक सूची के साथ हिट करने के बजाय, मुझे 10 सिद्धांत दें जो वे उल्लंघन करते हैं, इसलिए मैं यह पता लगा सकता हूं कि 102 क्या नियम अपने दम पर होना चाहिए।

मुझे अपना दर्शन देने में मदद करें कि मैं आपको देखूं और हम महान बनेंगे।

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

फिर हुक्म चलाना नहीं है! इसे सकारात्मक अनुभव बनाएं। यह कुछ नया युग हिप्पी बकवास नहीं है। यह बुनियादी मनोविज्ञान है। आप मानव व्यवहार को संशोधित करने की कोशिश कर रहे हैं। यादृच्छिक और सकारात्मक सबसे मजबूत है (बस लास वेगास से पूछें)। यदि आप नकारात्मक जाते हैं तो आपको अपने सुदृढीकरण के अनुरूप होना होगा। यह एक असहनीय दर्द है। सकारात्मक रहें क्योंकि आप ज्ञान का प्रसार करते हैं और आप इसके बारे में आकस्मिक हो सकते हैं।

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

इसे सही करें और आप छुट्टी पर जा सकते हैं और यह अभी भी काम करेगा। कैसे? न केवल एक नेता होने के नाते, बल्कि दूसरों को भी नेता बनने के लिए। एक बार जब आप अपनी दृष्टि को टीम में स्थापित कर लेते हैं, तो वे काम कर सकते हैं, जबकि आप बस यह कर रहे हैं कि आप क्या कर रहे हैं। न्यूबॉइंट्स को ढालें ​​और उन्हें दूसरों के साथ-साथ कदम बढ़ाने और प्रभावित करने के लिए प्रोत्साहित करें।

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


4
यह बहुत स्पष्ट है कि आप "कोड पीछा" से क्या मतलब है ... लेकिन Google मुझे दुनिया भर के अपराध कानून के अलावा कुछ भी नहीं देता है।
जेरेमी

3
सूची में "कोडिंग मानक" जोड़ें
B codовић

5
चूंकि मुझे लगता है कि मैं इस शब्द को 'कोड स्टैकिंग' की व्युत्पत्ति देता हूँ। मैंने कुछ कोड में जाँच की थी कि यह टाइमस्टैम्प प्राप्त करने के लिए एक अमूर्त कारखाने का उपयोग करता है। एक सहकर्मी डेवलपर (चेक कोड इन) को मर्ज करने की कोशिश कर रहा था और अपने चेक आउट के बाद से कोड में बदलाव कर रहा था। उसने मेरे कारखाने पर ध्यान दिया और सोचा कि यह उत्सुक था। उसे यकीन नहीं था कि मैं ऐसा क्यों कर रहा था। तो वह मेरे ऊपर चली गई और मुझसे पूछा। जब मैंने उलझन में देखा तो उसने कहा, "ओह, मैं सिर्फ कोड आपको घूर रहा था"। फेसबुक हमारी शब्दावली बदल रहा है।
कैंडिड_ओरेंज

1
सच! " मुझे देखने के लिए अपनी खुद की दृष्टि को लागू करने में मेरी मदद करें और हम आपके साथ मिलेंगे। " मुझे कविता, कोड और दर्शन के मिश्रण से प्यार है।
पेड्रो लोबिटो

@candied_orange: मैं पूरी तरह से "कोड डंठल" चीज से चकित हूं। क्या तुम सिर्फ उसे सजा दे रहे थे? आपके उत्तर के संदर्भ में, ऐसा लगता है कि वह आपको घूर रहा होगा।
रॉबर्ट हार्वे

23

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

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

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

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


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

6

कोड की समीक्षा हर बार जब कोई कोड को मुख्य शाखा / ट्रंक में मर्ज करना चाहता है और कोड की समीक्षा करते समय उन मानकों को रखता है।

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

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


मुझे लगता है कि मेरे सवाल का एक बड़ा हिस्सा इस तरह के मानकों की अपेक्षा करना मेरे लिए अवास्तविक है। मैं एक तानाशाह के रूप में आने के विचार के साथ संघर्ष करता हूं जो रचनात्मकता को
प्रभावित करता है

3
@ मैथ्यू, जबकि मैं आमतौर पर आपके साथ सहमत हूं, मैं इसे रिवर्स ऑर्डर में करूंगा। डिज़ाइन समीक्षा पहले, और दिशा-निर्देश डिज़ाइन समीक्षाओं के दौरान / से उभरते हैं। यदि आप वास्तुकार / लीड पर ऊपर की ओर सब कुछ लिखने का बोझ डालते हैं, तो यह बोझ को हस्तक्षेप करने वाले के लिए स्थानांतरित कर रहा है
निक अलेक्सीव

@ डीकॉर: आपको अपनी लड़ाई चुननी होगी। पता लगाएँ कि आपको अपना पैर किस चीज़ पर रखना है, और वह दस्तावेज़। आपको सब कुछ
रॉबर्ट हार्वे

2
@Deekor, आप "रचनात्मकता के बिना" मानक और सामान्य कोडिंग प्रथाओं को लागू कर सकते हैं। यह वैसे भी एक चतुर तर्क है। सामान्य कोडिंग मानकों से सॉफ्टवेयर को आसानी से बनाए रखा जा सकता है। फ्री-फॉर-ऑल कोडिंग से बुरे सपने आते हैं।
मैथ्यू

1
@ निक एलेक्सिव, मैं सहमत हूं; संपादित करेंगे।
मैथ्यू

1

जहाँ संभव हो, आप अपनी परियोजनाओं का स्वचालित रूप से विश्लेषण करने के लिए उपकरण / स्क्रिप्ट लिख सकते हैं और यह निर्धारित कर सकते हैं कि परियोजना किस मानकों, उपकरणों और तरीकों का उपयोग कर रही है। आप एक सीआई उपकरण के भाग के रूप में एक कस्टम टूल चलाकर ऐसा कर सकते हैं।

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

आपके पास मैन्युअल रूप से अपडेट किए गए कॉलम भी हो सकते हैं, लेकिन सौभाग्य उन्हें अद्यतित रखता है: डी


0

जवाब के अलावा मैं कहता हूँ तुम चाहिए प्रदान की शिक्षित क्या आप सॉफ्टवेयर विकास पेशेवर के रूप में उनमें से उम्मीद करते हैं, पल वे कंपनी में शामिल होने के साक्षात्कार कर रहे हैं से शुरू की अपनी टीम।

1 - कोडबेस कन्वेंशन बनाएं और फॉलो करें

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

2 - स्पष्ट सॉफ्टवेयर आर्किटेक्चर लागू करें

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

3 - कम बेहतर है: भाषाएँ, रूपरेखा और उपकरण

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

4 - सिस्टम डिजाइन निर्णयों में अपनी टीम को शामिल करें

एक साझा ज्ञान वातावरण बनाने का सबसे प्रभावी तरीका टीम को सभी सिस्टम डिज़ाइन निर्णयों में शामिल करना है। लाभ बहुत हैं:

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

5 - सभी नियम

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

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


मैंने हाल ही में इस विषय के बारे में एक ब्लॉग पोस्ट लिखा है, आप इन विषयों पर विस्तृत जानकारी पा सकते हैं: https://thomasvilhena.com/2019/11/system-design-coherence

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