🏂🏼 🧗🏼 💆🏽 डेवलपर डायरी या खराब निर्णय 👰 🐤 🤟🏻

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

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

अच्छा, अच्छा। रुको और देखो।

हम एक नई परियोजना शुरू करते हैं। खैर, भगवान का शुक्र है!

और फिर मैंने पहले ही लिगेसी कोड के ऊपर बैठने से काई के साथ कवर किया। मेरी ताकत नहीं है, मैं इस महान पास्ता राक्षस से सामना नहीं कर सकता। मैंने किसी तरह लॉगिन फॉर्म में बटन को स्थानांतरित करने की कोशिश की, इसलिए मुझे मेल मॉड्यूल से त्रुटियां मिलीं। सोचिए कनेक्शन कहां है ...

उन्होंने हमें एक नए कर्मचारी से मिलवाया, हमारे पास एक उत्पाद स्वामी या, रूसी बोलने में, एक ग्राहक प्रतिनिधि होगा। मेरा नाम रीता है। आकर्षक स्त्री। बात करना पसंद करता है।

उससे एक सरल सवाल पूछें, इसलिए वह आधे घंटे के लिए भाषण शुरू करती है। आप उसे देखते हैं और सोचते हैं: "उह, तुम एक बहुत बड़ी बात नहीं समझ रहे हो!"

पांच मिनट बाद, आपको संदेह होने लगता है: "नहीं, यह ऐसा कह रहा है।"

अंत में, आपको एहसास होता है कि आपको अपने प्रश्न का उत्तर नहीं मिला है। तो तुम छोड़ो।

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

हम पहले से ही उससे भी सरल सवाल पूछने से डरते थे। आपको उत्तर मिल सकता है, लेकिन आप मौखिक सागर में डूब सकते हैं।

हां, नौकरशाही वास्तव में कम हो गई है। क्योंकि सभी ने सामान्य रूप से प्रलेखन पर स्कोर किया। अब सूचना मुख्य रूप से मुंह से शब्द द्वारा प्रसारित की जाती है। बेशक, मैं सब कुछ समझता हूं, हम बहुत चुस्त हैं, लेकिन उसी हद तक नहीं ...

कार्य को देखते हुए: गेटवे में क्लाइंट को ग्राफ प्रदर्शित करने के लिए डेटा प्राप्त करने की क्षमता विकसित करने के लिए। आपको सेवा में जाने की जरूरत है, कच्चा डेटा प्राप्त करें, इसे पुन: लिखें और ग्राहक को दें। कोई विनिर्देश नहीं है कि क्या और कैसे गिनना है - कोई नहीं जानता। केवल चार्ट का नाम है। खैर, मुझे यह कैसे करना चाहिए, मुझे आश्चर्य है?

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

मैं आज काम करने के लिए आता हूं, वहां लड़की परीक्षकों ने हमारे स्क्रम मास्टर कोल्या को घेर लिया है, और वे उन्हें समझाने की मांग करते हैं कि नई कार्यक्षमता कैसे काम करती है। मॉनीटर के बारे में और बदलती आवश्यकताओं के बारे में कुछ-कुछ मॉनीटर पर कोल्या टिन की आँखों से देखती है।

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

मैं उनसे आधे घंटे बाद गलियारे में मिला: कोल्या चल रही थीं, लड़कियाँ उनका पीछा कर रही थीं, और हर कोई चकरा रहा था: "नया मॉडल ... पुराना मॉडल ... ग्राहक की आवश्यकताएँ ..."।

गरीब ...

एक समीक्षा के लिए एक पुल अनुरोध मिला। ग्राफ़ को निर्यात करने में त्रुटि: ऊंचाई और चौड़ाई के अनुपात मूल से अलग हैं। यह अजीब है, क्योंकि मैंने एक बार इस समस्या को हल किया था और सभी अनुपातों का ध्यान रखा था ... समस्या को मूल तरीके से हल किया गया था: एक सहकर्मी ने केवल ऊंचाई को 1.25 गुणा किया था।

मैं उससे पूछता हूं:

- इस गुणांक का क्या अर्थ है?
"और यह," वह कहते हैं, "मैंने इसे उठाया।" अब सब ठीक हो जाएगा।

किस समय! उसने उठाया ... और अन्य चार्ट के निर्यात के साथ क्या होगा? वे समझने लगे, यह पता चला कि आपको कॉल के अनुक्रम को थोड़ा बदलना होगा। कुछ बहुत ही दुर्लभ मामलों में, आपकी कैनवास सेटिंग्स का उपयोग किया जाता है, और आपको उसके बाद के अनुपात को पुनर्गणना करने की आवश्यकता होती है।

किसी को यह आभास हो जाता है कि कभी-कभी लोगों को किसी भी तरह से अपने काम पर रिपोर्ट करना महत्वपूर्ण होता है, और अंतिम परिणाम वास्तव में परेशान नहीं करता है ...

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

क्या आप संतुष्ट हैं? हम्म ... मैं परेशान होऊंगा अगर मैंने पाया कि सूची वर्तमान स्थिति के अनुरूप नहीं है ...

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

यह अच्छा है कि हम हवाई जहाज का निर्माण नहीं करते हैं ...

उसने पड़ोसी विभाग में देखा और दहलीज से लगा कि कुछ गड़बड़ है। सभी लोग बैठे हैं, कीबोर्ड पर बुरी तरह से दस्तक दे रहे हैं, और हवा में सामान्य दुर्भाग्य का एक प्रकार है।

अचानक उनके स्वामी मास्टर वाइटया कूदता है और किसी को कैसे चिल्लाता है:
- तुम मुझे क्या लिख रहे हो! इसे मौखिक रूप से कहें!

और फिर वे टूट गए। सभी एक बार चक्कर खा गए। मौखिक रूप से। शोर असाधारण हो गया।

मैं एक मिनट के लिए खड़ा था, खांसी हुई, हर कोई चुप हो गया और मुझे घूरता रहा। मुझे अचानक कुछ असहज लगा।

विक्टर कहते हैं:

- आपने सेवा में प्राधिकरण बदल दिया?
"हां," मैं जवाब देता हूं, "बदल गया।" अब बिना अधिकार वाले उपयोगकर्ता संसाधन नहीं पढ़ सकते हैं। हमें एक अलग तरीके का उपयोग करना चाहिए।
- तो आप बदल गए, - वह कहता है, - और अब आवेदन ने हमारे लिए काम करना बंद कर दिया है।

वह थोड़ी देर के लिए चुप हो गया और जोड़ा:
- आपने सब कुछ ठीक किया, यह हमारी खिचड़ी है। लेकिन हम जानते हैं कि तीन घंटे के बाद रिलीज को समाप्त करने की आवश्यकता है, और हम इतनी जल्दी त्रुटि को ठीक नहीं कर सकते।

मैं उन्हें बताना चाहता था: "ठीक है, नरक, तुमने कभी परीक्षण नहीं चलाया, क्योंकि सप्ताह पहले ही बीत चुका है!", लेकिन उनके चेहरे को देखा, चारों ओर घुमाया और सेवा में रोलबैक करने के लिए चला गया।

प्रमुख ने आज हमें इकट्ठा किया और कहा:

- हम एक महाकाव्य होना चाहिए। हम खोज परिणामों को अनुकूलित करने के लिए मशीन सीखना शुरू करना चाहते हैं।

लोग, निश्चित रूप से, क्या मतलब है और क्या समस्या का वर्णन है में रुचि रखते हैं।

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

फिर मैंने उसके लिंक द्वारा पृष्ठ को देखा: शीर्षक और दो पैराग्राफ। और आपको क्या लगता है कि आपको कैसे ऑर्डर करना चाहिए, अगर यह स्पष्ट नहीं है कि क्या सोचना है?

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

मैं आज गलियारे में विता से मिलता हूं और पूछता हूं:
"ठीक है, क्या आपको कोई गलती मिली?" एक महीना बीत गया। सेवा में प्राधिकरण को बहाल करना आवश्यक होगा, अन्यथा हम एक छेद के साथ रहते हैं।

आदित्य दूर देखता है और कहता है:

- नहीं, अभी तक नहीं मिला। पर्याप्त समय नहीं है ...

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

हां, यहां हमारा नया प्रवेश द्वार पास्ता की एक तंग गेंद में बदल गया है, और छोरों को ढूंढना पहले से ही असंभव है। जल्दी से, हम कामयाब रहे!

मैं अपने सहयोगियों को वर्तमान मामलों के बारे में अपने वरिष्ठों से बात करने के लिए मनाने की कोशिश कर रहा हूं। मेरे दृष्टिकोण से, परियोजना एक विवादास्पद स्थिति में है: विभिन्न टीमें, अपने कार्यों को हल करते हुए, संपादन करते हैं जो अराजकता को बढ़ाते हैं, एन्ट्रोपी बढ़ रहा है। हर बार, समस्याओं को हल करना अधिक से अधिक जटिल हो जाता है।

लोग मुझसे सहमत हैं, लेकिन मेरी पहल मस्त है। और उन्हें समझा जा सकता है: सभी के पास वर्तमान कार्य हैं जिन्हें स्प्रिंट के दौरान हल किया जाना चाहिए। यह दार्शनिकता तक नहीं है, चीजों को किया जाना चाहिए ...

मैं मानता हूं: मैंने इस डायरी का आविष्कार किया। सभी पात्र काल्पनिक हैं, संयोग यादृच्छिक हैं। यह सिर्फ एक मजाक है।

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

हालाँकि, मैं फुर्तीली या विकास तकनीकों के बारे में बात नहीं करना चाहता। मैं उस सॉफ़्टवेयर की गुणवत्ता के बारे में अनुमान लगाना चाहता हूं जो हम बनाते हैं और कैसे खराब निर्णय इस सॉफ़्टवेयर को नष्ट कर सकते हैं।

ब्याज का संघर्ष

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

लेकिन आप उस व्यवसाय के लिए काम करते हैं जिसने आपको काम पर रखा है। व्यवसाय आपकी महत्वाकांक्षाओं में दिलचस्पी नहीं रखता है। एक व्यवसाय का मुख्य लक्ष्य लाभ है, और ठीक है। यहां आप व्यवसाय के साथ एक ही समय पर हैं, क्योंकि आप अपने प्रोजेक्ट का उपयोग करने के लिए अधिक से अधिक लोग चाहते हैं?

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

क्या करें?

सबसे अधिक संभावना है, आपको खुद को तोड़ना होगा, उम्मीद है कि वर्तमान बैसाखी को बाद में हटाया जा सकता है ...

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

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

क्या सफलता संभव है?

विरोधाभास यह है कि इस तरह के उत्पाद कम से कम पहले चरण में व्यावसायिक रूप से सफल हो सकते हैं। ग्राहक, सिस्टम में कई कमियों और विसंगतियों से परेशान हैं, लेकिन, सामान्य तौर पर, उत्पाद उनकी समस्याओं को हल करता है।

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

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

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

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

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

क्या अधिक महत्वपूर्ण है: उत्पाद की गुणवत्ता या बिक्री कौशल?

एक गुणवत्ता उत्पाद, अफसोस, सफलता की गारंटी नहीं है।

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

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

बुरे फैसले

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

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

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

लक्ष नियम

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

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

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

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

नियमों का उल्लंघन

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

अपने सिस्टम में उन समस्याओं के लिए तैयार हो जाएं जो अप्रत्याशित स्थानों पर होंगी।

जटिलता सेटिंग्स

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

समस्या के विश्लेषण का अभाव

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

राजनीतिक निर्णय

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

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

निष्कर्ष

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

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

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

मैं आपके प्रोजेक्ट्स के लिए लंबी उम्र की कामना करना चाहता हूं!

डेवलपर डायरी या खराब निर्णय