उत्पादन में यह मत करो

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

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

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

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

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

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

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

नए डेवलपर को क्या करना है?

इंटरनेट पर इसका जवाब तलाशना स्वाभाविक है। यह पता चला है कि यह अविश्वसनीय रूप से प्रभावी है ।

लेकिन यह अविश्वसनीय रूप से खतरनाक भी है ।

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

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

लेकिन ये लाइनें मुझे सीधे उत्पादन में कोड बेस से देख रही हैं।

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

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

लेकिन इन डेवलपर्स के पास क्या विकल्प था? उन्हें कुछ जारी करने की आवश्यकता थी, और उन्होंने उत्पादन में एक आवेदन जारी करने से पहले कभी नहीं किया था। इसलिए, उन्होंने वही किया जो कोई भी समझदार व्यक्ति करने की कोशिश करेगा - और रास्ते में सीखा।

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

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

समस्या लोगों में नहीं है।

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

यदि आप यहां उत्तर की उम्मीद करते हुए पढ़ते हैं, तो मुझे खेद है: मेरे पास एक सरल उत्तर नहीं है। इस समस्या को हल करना मुश्किल है। समाधान एक लेख के लिए बहुत बड़ा है, यह हर दिन बदलता है और प्रत्येक परियोजना के लिए बारीकियों में भिन्न होता है।

इस समस्या ने मुझे एक ब्लॉग शुरू करने के लिए प्रेरित किया। मैं लगभग बीस वर्षों तक अविश्वसनीय रूप से प्रतिभाशाली गुरु, लेखकों और सहकर्मियों से सीखने के लिए भाग्यशाली रहा। इन लोगों की सलाह के बिना, मैं अभी भी QBasic (brrr) में GOTO निर्देश लिख रहा हूँ। यह गेंद लेने और आक्रामक पर जाने का समय है।

संक्षेप में देना।

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