🤹🏿 👦🏾 🐱 प्रोग्रामिंग आक्रोश से कैसे बचें? इंटीग्रेटर टिप्स 🏁 ✌🏼 🦋

एक में पिछले लेख एक मामले का अध्ययन के रूप में औद्योगिक उद्यमों में ईआरपी शुरू करने की समस्याओं के बारे में, बिंदुओं में से एक में लाया गया था "प्रोग्रामेटिक अराजकता।"

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

विषय प्रासंगिक है, और मैंने इसके बारे में एक अलग लेख लिखने का फैसला किया है।

यह क्या है?

जब आप "प्रोग्रामेटिक लॉलेसनेस" वाक्यांश सुनते हैं तो आपकी कल्पना किस तरह की पेंटिंग करती है?

एक विचारशील चतुर टकटकी वाला दाढ़ी वाला शख्स आंसू वाले मुख्य लेखाकार को नट की मात्रा से मारता है, कहता है: “कोपेक, आप कहते हैं कि आप चालान पर सहमत नहीं हैं? कंसाइनरी सेल में फिट नहीं होता है? अब हम इसे एक पुस्तक के साथ जोड़ देंगे और सब कुछ फिट हो जाएगा! ”

, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»

यह घटना कम रंगीन है जितना आप कल्पना कर सकते हैं, लेकिन अधिक भयानक है। अंत में, मुख्य लेखाकार शांत हो सकता है, आँसू पोंछ सकता है और एक मनोवैज्ञानिक को भेज सकता है, स्वामी को एक कुर्सी से निकाल दिया जा सकता है और काम पर भेजा जा सकता है। लेकिन इंवेंटट्रांस में पोस्टिंग घटता है और समाधान आर्किटेक्चर में गलतफहमी के कारण निष्क्रिय हो जाता है और अनावश्यक सुधार मनोवैज्ञानिक ठीक नहीं करेंगे।

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

मैं आपको कुछ उदाहरण देता हूं:

, , . - , .
. , , «» . . , , .

मैं लेख "प्रोग्रामर अराजकता का नाम देना चाहता था। रो रही है इंटीग्रेटर ”, लेकिन महसूस किया कि कोई भी हमारे आँसू की परवाह नहीं करता है। लेकिन इस तरह की स्थितियों से कैसे बचा जा सकता है, इस बारे में सुझाव दिए गए हैं।

मैं अग्रिम में अपनी सिफारिशों की सीमाओं को रेखांकित करने की कोशिश करूंगा - हम बात कर रहे हैं:

प्रोग्रामर जो ईआरपी-सिस्टम के कार्यान्वयन या रखरखाव में शामिल हैं। मुझे लगता है कि उनकी तुलना में थोड़ी अलग आवश्यकताएं हैं, उदाहरण के लिए, एक नए उत्पाद या प्रौद्योगिकी के डेवलपर्स;
प्रोग्रामर जो क्लाइंट के साथ काम करते हैं। इंटीग्रेटर डेवलपर्स को "नाराजगी" कम होती है।

तो इस घटना के कारण क्या हैं और इसके बारे में क्या किया जा सकता है?

प्रक्रिया के सार को देखने की अनिच्छा या अक्षमता

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

"और क्या आप इस गुणांक के लिए दशमलव स्थानों की संख्या 4 तक बढ़ा सकते हैं?" - "बेशक"। लेकिन कुछ भी नहीं जो इस गुणांक का उपयोग पैरामीटर को अनुक्रमित करने के लिए किया जाता है, जिसमें 1 दशमलव स्थान की सटीकता होती है, और मान 50 से अधिक नहीं होते हैं? सभी गुणांक सटीकता गोलाई में जाएंगे। तो शायद ऐसा न करना बेहतर है?

"नामकरण संदर्भ में इस प्रकार का एक नया क्षेत्र जोड़ें" - "अच्छा। 15 मिनट की जटिलता। ” तो, आपको नामकरण में इस क्षेत्र की आवश्यकता क्यों है? यह एक विशेषता है जो पार्टी से पार्टी में भिन्न होती है। शायद इस क्षेत्र को पार्टियों की निर्देशिका में जोड़ना बेहतर है?

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

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

सब कुछ पुराने तरीके से छोड़ने की इच्छा के खिलाफ लड़ाई में सहनशक्ति का अभाव

यह ऐसा मामला है जब प्रोग्रामर मेस डेवलपर्स द्वारा नहीं बनाया जाता है, लेकिन उनके सानिध्य के साथ।

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

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».

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

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

प्रोग्रामिंग द्वारा सभी समस्याओं को हल करने की आदत

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

, , . , , , . . , . , , . : .

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

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

आत्मविश्वास

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

कम स्पष्ट स्थान हैं जहां आपको चढ़ाई नहीं करनी चाहिए। और एक अनुभवी प्रोग्रामर को शुरुआती से अलग करने का एक शानदार तरीका यह है कि इस तरह की कार्यक्षमता को निखारने की पेशकश करें: एक अनुभवी व्यक्ति आश्चर्यचकित होगा और मना कर देगा, व्यवसाय प्रक्रिया को अनुकूलित करने की सलाह दे सकता है, और शुरुआत करने वाला कहेगा: "चलो।"

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

विकास के नियमों का अभाव

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

इसलिए, इस तथ्य के बारे में बात न करें कि "प्रोग्रामिंग एक कला है। यह विनियमित नहीं है "," लेकिन चुस्त के बारे में क्या? और बस यही। यदि आप विकास कर रहे हैं, तो एक विनियमन होना चाहिए। और यह 3 अंक नहीं है:

विकास देव अनुप्रयोग पर किया जाता है;
परीक्षण आवेदन पर परीक्षण किया जाता है;
कोड में टिप्पणियां होनी चाहिए।

यह खंडों के साथ दस पृष्ठों वाला पूर्ण दस्तावेज़ होना चाहिए:

विकास अनुप्रयोगों के लिए आवश्यकताएँ।
समस्या का विवरण लिखने के लिए आवश्यकताएँ।
कोड लिखने के लिए आवश्यकताएँ।
परीक्षण आवश्यकताओं।
अनुप्रयोगों के बीच प्रवासन की आवश्यकताएं।

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

अकेलापन और नियंत्रण की कमी

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

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

विकास की गुणवत्ता पर नियंत्रण;
कम अनुभवी प्रोग्रामर को प्रशिक्षित करें।

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

निष्कर्ष

इस प्रकार, "प्रोग्रामेटिक लॉलेसनेस" की संभावना को कम करने के लिए, आपको निम्नलिखित नियमों के अनुसार अपना आंतरिक विकास विभाग बनाने की आवश्यकता है:

यह कम से कम 3 लोगों की टीम होनी चाहिए।
इस टीम में से कम से कम एक ईआरपी प्रणाली को लागू करने या बनाए रखने में अनुभव होना चाहिए, यह उसकी nth परियोजना होनी चाहिए, जहां n> 3।
विकास विभाग को आदर्श रूप से सीधे सीईओ को रिपोर्ट करना चाहिए।
अंतिम उपयोगकर्ताओं को कभी-कभी यह शिकायत करनी चाहिए कि प्रोग्रामर उनकी कुछ आवश्यकताओं को लागू करने से इनकार करते हैं।
यहां तक कि इस तरह के एक छोटे से विभाग के लिए, नियमों को विकसित किया जाना चाहिए, जिसके उल्लंघन के लिए दंडित किया जाना चाहिए।

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

प्रोग्रामिंग आक्रोश से कैसे बचें? इंटीग्रेटर टिप्स