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

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

विरोधाभास के कारण के बारे में

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

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

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

दिन का एक हिस्सा हम अपने लिए काम करते हैं, और नियोक्ता या ग्राहक के लिए दिन का हिस्सा। मैं मूल्य के निम्नलिखित सूत्र के साथ इसे व्यक्त करने की अनुमति दूंगा:

जहाँ

c निश्चित पूंजी है , अर्थात संगठन उपकरण जो इसे अपनी गतिविधियों (कंप्यूटर, सॉफ्टवेयर, आदि) को पूरा करने की अनुमति देते हैं।
v - कर्मचारियों का वेतन।
मीटर उन लोगों की संवैधानिक लाभ है जो उत्पादन करते हैं।

सॉफ्टवेयर विकास के मामले में, बारीकियां हैं - यदि सॉफ्टवेयर एक व्यवसाय का एक सेवा हिस्सा है जो लगातार विकसित हो रहा है, तो आपको प्रत्यक्ष व्यापार से संबंधित समाधान के लिए कुछ काम करना होगा। अंतर महसूस करें - कम कौशल के कुछ लोगों पर खर्च किया जा सकता है " भविष्य के काम के लिए काम पर खर्च किया जाता है।" यदि हम इसे सूत्र में स्थानांतरित करते हैं, तो इसका मतलब है कि हम निरंतर पूंजी c के पक्ष में काम कर रहे हैं, हमें किसी के वेतन v से , लाभ m से या माल W की लागत से पैसा खर्च करना होगा । अधिक विस्तार से विचार किया जाना चाहिए।

इसलिए, उदाहरण के लिए, यदि आप अपने मोनोलिथ के आर्किटेक्चर को काम करने और माइक्रोसेर्विस में तोड़ने का प्रस्ताव रखते हैं, लेकिन आपके ग्राहक को इसके लिए कोई प्रत्यक्ष आवश्यकता नहीं है, तो इंजीनियरिंग परिष्कार उसे क्या देगा?

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

  
  

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

  
  

• v - आप किसी और के वेतन को छोड़ सकते हैं, और विकल्प हैं।
  1) तुम अपना बलिदान दोगे। आप एक ओपन सोर्स प्रोजेक्ट को प्रोसेस करेंगे या करेंगे जो आपको काम करने में मदद करेगा।
  2) आप किसी और के काम को स्वचालित करते हैं, जो कम लोगों को इसका उपयोग करने की अनुमति देगा।

  
  

  मेरे जैसे भोले लोग दुर्भाग्य से विकल्प 1 चुनते हैं। लेकिन यदि आप 2 में सफल होते हैं, तो आप उत्पादन श्रृंखला को गुणात्मक रूप से बदल रहे हैं: उसे सिर्फ काम करने वाले हाथों की तुलना में कम की आवश्यकता है, और अधिक से अधिक लोगों को विशेषज्ञता के साथ जो प्रक्रियाओं को बना सकते हैं और सही ढंग से संशोधित कर सकते हैं।

  
  

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

आवश्यकताओं का विरोध

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

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

एक सामान्य भाजक को खोजने के लिए, मेरा सुझाव है कि ग्राहक को प्रत्येक नई परियोजना से पहले निम्नलिखित प्रश्न पूछें:

• हम वास्तव में ग्राहक के लिए क्या कर रहे हैं, अपेक्षित लाभ क्या है?
• इस समाधान की प्रयोज्यता की आवृत्ति।
• परिवर्तन / विस्तार आवश्यकताओं की संभावना।
• क्या अन्य प्रणालियों / सेवाओं / संदर्भों के साथ कोई संबंध है?

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

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

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

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

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

तकनीकी चक्र निर्धारित करता है (एक ही समय सीमा पर) विकास - विकास के अगले चरण में प्रवेश करने के लिए, वर्तमान तकनीकी प्रक्रिया की सीमाओं से परे जाना आवश्यक है। यानी अपनी प्रथाओं का विस्तार करें, कुछ नया आज़माएं, नियंत्रित प्रयोग स्थापित करें।

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

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

आवश्यकताओं के संतुलन से लेकर कार्य संतुलन तक

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

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

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

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

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

निष्कर्ष

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

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

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