अध्याय 7 - गति, प्रदर्शन, ताल, परिनियोजन

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

सॉफ्टवेयर विकास में, टीम को उत्पाद प्रबंधन समूह से उनके निर्देश प्राप्त होते हैं।

एक टीम को इकट्ठा करने, संसाधनों को केंद्रित करने और एक प्रक्रिया का पालन करने के बाद, फिर…

दु: ख के रूपांतरण (मुद्दों के साथ एक रिलीज) को लाभ (कम बग के साथ एक नई रिलीज) में परिवर्तित करने में सामरिक पैंतरेबाज़ी आती है।

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

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

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

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

रिलीज से पहले विचार करें और विचार-विमर्श करें।

एक टीम के रूप में काम करें, जैसे कि वरिष्ठ डेवलपर्स का समर्थन और कनिष्ठ लोगों को सलाह दें। एकल टीम के रूप में आगे बढ़ें, व्यक्तियों के रूप में नहीं।

दूर से काम करते समय ऑनलाइन चैट के माध्यम से स्पष्ट और समझ में आने वाले झंडे और संकेतों का उपयोग करके अक्सर संवाद करें।

एक डेवलपर सुबह सबसे उत्सुक होता है, इसलिए यह "दैनिक स्टैंडअप" के लिए एक अच्छा समय है।

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

यदि वातावरण तैयार नहीं है, ग्राहक तैयार नहीं है, या कोड की गुणवत्ता के बारे में संदेह है तो एक बुद्धिमान टीम रिलीज में देरी करती है।

एक लक्ष्य का पीछा न करें जब गुस्सा मुद्दों को खोजने के लिए उत्सुक हो और गुणवत्ता कम हो

जब कोई सुविधा समाप्त नहीं होती है और क्लाइंट को उच्च उम्मीदें होती हैं तो रिलीज़ का पीछा न करें

किसी लाइव सर्वर पर सीधे कोड को तेजी से हैक न करें, इसके बजाय इसे एक सुविचारित और नियोजित तरीके से सावधानी और चिंता के साथ पैच करें।

हताश टीम लीडर या डेवलपमेंट टीम पर बहुत जोर से दबाव न डालें।

ऐसी है कोडिंग की कला।

अग्रिम पठन

लेखक के बारे में अधिक जानकारी

ग्रेग आउटसोर्स.देव में एक अनुभवी सॉफ्टवेयर पेशेवर और सीटीओ हैं , कई व्यवसायों में काम करने के बाद अब वह दूसरों को सॉफ्टवेयर विकास, प्रबंधन और आउटसोर्सिंग में सफल होने में मदद करने के बारे में भावुक हैं।

अगर आपको यह लेख अच्छा लगा हो तो कृपया ताली बजाएं और मुझे फॉलो करें।