वेगवान तंत्रज्ञानाच्या जगात, संघांना बर् याचदा 'विकासाची गती' - वैशिष्ट्ये द्रुतपणे शिप करण्याची ड्राइव्ह - आणि 'कोड मेंटेनबिलिटी' - अद्यतनित करणे सोपे आहे असे स्वच्छ, स्केलेबल कोड लिहिण्याची प्रथा यांच्यातील रस्सीखीचा सामना करावा लागतो. वेग आज बाजारपेठेतील हिस्सा जिंकत असताना, देखभाल हे सुनिश्चित करते की उद्या उत्पादन त्याच्या स्वत: च्या वजनाखाली कोसळणार नाही.
ठळक मुद्दे
वेगामुळे तुम्हाला बाजारात वेळ मिळतो, पण देखभालक्षमता तुम्हाला दीर्घायुष्य मिळवून देते.
अनियंत्रित वेग 'लेगसी कोड' कडे नेतो जो अखेरीस सुधारित करणे अशक्य होते.
देखभाल ही एक गुंतवणूक आहे जी नंतर विकासाच्या वेळी 'नकारात्मक' व्याज देते.
सर्वात यशस्वी संघांना एक 'स्थिर राज्य' सापडते जे दोन्ही घटकांना संतुलित करते.
विकासाचा वेग काय आहे?
एक संघ ज्या वेगाने एखाद्या संकल्पनेपासून उत्पादनात लाइव्ह, फंक्शनल वैशिष्ट्याकडे जाऊ शकतो.
वापरकर्त्याचा त्वरित अभिप्राय गोळा करण्यासाठी अनेकदा 'किमान व्यवहार्य उत्पादन' (एमव्हीपी) वैशिष्ट्यांना प्राधान्य दिले जाते.
शॉर्टकट, हार्ड-कोडेड मूल्ये वापरणे किंवा व्यापक चाचणी सूट वगळणे समाविष्ट असू शकते.
भांडवल संपण्यापूर्वी व्यवसाय मॉडेल सिद्ध करणे आवश्यक असलेल्या स्टार्टअपसाठी महत्त्वपूर्ण आहे.
जलद प्रोटोटाइप आणि तयार तृतीय-पक्ष एकत्रीकरणावर मोठ्या प्रमाणात अवलंबून असते.
'तांत्रिक कर्ज' होऊ शकते, जे खराब लिखित कोडवर आर्थिक व्याजासारखे कार्य करते.
कोड देखभाल काय आहे?
सॉफ्टवेअर त्याच्या संपूर्ण जीवनचक्रात समजून घेतले जाऊ शकते, दुरुस्त केले जाऊ शकते आणि वर्धित केले जाऊ शकते.
स्वच्छ कोड तत्त्वे, मॉड्यूलर आर्किटेक्चर आणि सुसंगत नामकरण परंपरांवर जोर देते.
प्रतिगमन टाळण्यासाठी व्यापक दस्तऐवजीकरण आणि उच्च स्वयंचलित चाचणी कव्हरेज आवश्यक आहे.
दीर्घकालीन प्रकल्पात सामील होणार् या नवीन विकसकांसाठी 'ऑनबोर्डिंग टाइम' कमी करते.
भविष्यातील बग फिक्स करून मालकीची एकूण किंमत कमी करते.
हे सुनिश्चित करते की सिस्टम एकूण पुनर्लेखनाची आवश्यकता न घेता अधिक वापरकर्त्यांना हाताळण्यासाठी स्केल करू शकते.
तुलना सारणी
वैशिष्ट्ये
विकासाचा वेग
कोड देखभाल
प्राथमिक उद्दीष्ट[संपादन]
टाइम-टू-मार्केट
दीर्घकालीन स्थैर्य
कोड कॉम्प्लेक्सिटी
उच्च (स्पॅगेटी कोड जोखीम)
कमी (संरचित आणि मॉड्यूलर)
किंमत प्रोफाइल
कमी आगे, नंतर उच्च
उच्च आगे, नंतर कमी
चाचणी कठोरता
किमान / मॅन्युअल
व्यापक/स्वयंचलित
दस्तऐवजीकरण
विरळ किंवा अस्तित्त्वात नसलेले
सर्वसमावेशक आणि स्पष्ट
जोखीम घटक
प्रणाली नाजूकपणा
चुकलेल्या बाजारपेठेच्या खिडक्या
तपशीलवार तुलना
तांत्रिक कर्जाचा परिणाम
पूर्णपणे वेगावर लक्ष केंद्रित केल्याने तांत्रिक कर्ज तयार होते, जे 'द्रुत आणि घाणेरडे' निराकरण आहेत ज्याकडे नंतर लक्ष दिले जाणे आवश्यक आहे. जर एखादा संघ खूप जास्त काळ वेगाने पुढे जात असेल तर प्रत्येक नवीन वैशिष्ट्य तयार होण्यास दहापट जास्त वेळ घेईपर्यंत कर्ज जमा होते कारण अंतर्निहित कोड इतका नाजूक आहे. देखभाल काळजीपूर्वक डिझाइनद्वारे हे कर्ज आगाऊ फेडण्याचा प्रयत्न करते.
स्केलेबिलिटी आणि उत्क्रांती
वेगासाठी तयार केलेली प्रणाली बर् याचदा 'छत' मारते जिथे ती क्रॅश न करता अधिक डेटा किंवा वापरकर्त्यांना हाताळू शकत नाही. देखभाल करण्यायोग्य कोड अमूर्त स्तरांसह तयार केला गेला आहे जो विकसकांना घटकांची अदलाबदल करण्यास किंवा कमीतकमी घर्षणासह पायाभूत सुविधा श्रेणीसुधारित करण्यास अनुमती देतो. ही मॉड्युलॅरिटी म्हणजे प्रोटोटाइपला व्यावसायिक एंटरप्राइझ अनुप्रयोगापासून वेगळे करते.
विकासकाचे मनोबल आणि उलाढाल
उच्च-वेग, कमी-देखभाल वातावरणात काम केल्याने बग्सच्या सतत 'अग्निशामक' मुळे विकसक बर्नआउट होतो. याउलट, देखभाल करण्यायोग्य कोडबेस अभिमानाची भावना वाढवतात आणि विकसकांना समान तुटलेल्या तर्काचे निराकरण करण्याऐवजी नवीन गोष्टी तयार करण्यावर लक्ष केंद्रित करण्याची परवानगी देतात. शीर्ष अभियांत्रिकी प्रतिभा टिकवून ठेवण्यासाठी स्वच्छ कोडबेस हे एक उत्तम साधन आहे.
कालांतराने व्यवसाय मूल्य
वेगाचे व्यवसाय मूल्य फ्रंट-लोडेड आहे; हे आपल्याला शर्यत जिंकण्यास मदत करते. तथापि, देखभालीचे व्यवसाय मूल्य घातांकीय आहे; हे सुनिश्चित करते की आपण शर्यतीत रहाल. बर् याच यशस्वी कंपन्या अखेरीस त्यांच्या मुख्य मालमत्तांचे संरक्षण करण्यासाठी 'वेगवान हालचाल' मानसिकतेतून 'स्थिर वाढ' टप्प्यात संक्रमण करतात.
गुण आणि दोष
विकासाचा वेग
गुणदोष
+बाजारपेठेत जलद प्रवेश
+कमी प्रारंभिक खर्च
+त्वरित अभिप्राय
+उच्च चपळता
संरक्षित केले
−नाजूक प्रणाली
−भविष्यातील महागड्या फिक्स
−मोजणे कठीण आहे
−हाय देव बर्नआउट
कोड देखभाल
गुणदोष
+मोजणे सोपे आहे
+कमी उत्पादन बग
+जलद ऑनबोर्डिंग
+स्थिर कामगिरी
संरक्षित केले
−प्रारंभिक प्रक्षेपण संथ
−उच्च आगाऊ खर्च
−अति-अभियांत्रिकी जोखीम
−विलंबित अभिप्राय
सामान्य गैरसमजुती
मिथ
देखभाल करण्यायोग्य कोड लिहिण्यास नेहमीच दुप्पट वेळ लागतो.
वास्तव
सुरुवातीला अधिक विचार करावा लागतो, परंतु अनुभवी विकसक बर् याचदा 'गोंधळलेल्या' कोडच्या समान वेगाने देखभाल करण्यायोग्य कोड लिहितात कारण ते प्रस्थापित नमुने वापरतात जे परिपत्रक तर्काच्या त्रुटींना प्रतिबंधित करतात.
मिथ
तांत्रिक कर्ज ही नेहमीच वाईट गोष्ट असते.
वास्तव
तांत्रिक कर्ज हे एक धोरणात्मक साधन असू शकते. व्यवसाय कर्जाप्रमाणेच, जोपर्यंत आपल्याकडे व्याज प्रकल्प खराब होण्यापूर्वी परत देण्याची स्पष्ट योजना आहे तोपर्यंत ते आपल्याला आता बाजारात 'खरेदी' करण्याची परवानगी देते.
मिथ
मेंटेन करण्यायोग्य कोड म्हणजे 'बग नाही'.
वास्तव
कोणत्याही सिस्टममध्ये बग अपरिहार्य आहेत. तथापि, देखभाल करण्यायोग्य कोड प्रक्रियेतील तीन इतर असंबंधित वैशिष्ट्ये न तोडता त्या बग्स शोधणे, वेगळे करणे आणि निराकरण करणे खूप सोपे करते.
मिथ
प्रकल्प यशस्वी झाल्यावर आपण नंतर फक्त 'कोड साफ करू शकता'.
वास्तव
प्रत्यक्षात, एकदा प्रकल्प यशस्वी झाला की, वैशिष्ट्ये पाठविण्याचा दबाव सहसा वाढतो. एखाद्या संघाला खोलवर रुजलेल्या आर्किटेक्चरल गोंधळाचे निराकरण करण्यासाठी पुरेसा 'पॉज' मिळणे फारच दुर्मिळ आहे.
वारंवार विचारले जाणारे प्रश्न
वेग आणि देखभाल दरम्यान 'सुवर्ण गुणोत्तर' काय आहे?
कोणतीही निश्चित टक्केवारी नाही, परंतु एक सामान्य उद्योग मानक म्हणजे 80/20 नियम. कोडबेस निरोगी ठेवण्यासाठी आपल्या प्रयत्नांपैकी ८० टक्के वैशिष्ट्य वितरणावर आणि २० टक्के 'रीफॅक्टरिंग' किंवा तांत्रिक कर्ज भरण्यावर खर्च करा.
गैर-तांत्रिक भागधारकांना देखभाल करण्याची आवश्यकता मी कशी स्पष्ट करू?
'कार मेंटेनन्स' सादृश्य वापरा. वेळ वाचविण्यासाठी आपण कधीही तेल न बदलता 100 मैल प्रति तास वेगाने कार चालवू शकता, परंतु अखेरीस, इंजिन जप्त होईल आणि आपले प्रतिस्पर्धी आपल्याजवळून जात असताना आपण रस्त्याच्या कडेला अडकून पडाल.
स्वयंचलित साधने देखभाल करण्यास मदत करू शकतात?
होय, लिंटर्स, स्टॅटिक अॅनालिसिस आणि सोनारक्यूब सारखी साधने स्वयंचलितपणे गोंधळलेला कोड किंवा उच्च जटिलता ध्वजांकित करू शकतात. तथापि, ही साधने मूलभूतपणे तुटलेल्या आर्किटेक्चरचे निराकरण करू शकत नाहीत; त्यासाठी अजूनही मानवी रचना आणि दूरदृष्टी आवश्यक आहे.
चपळ विकास देखभालीपेक्षा वेगाला अनुकूल आहे का?
चपळ बर् याचदा 'वेगवान हलवा आणि गोष्टी तोडा' असा चुकीचा अर्थ लावला जातो, परंतु चपळ जाहीरनामा प्रत्यक्षात 'तांत्रिक उत्कृष्टता' यावर जोर देतो. ट्रू चपळ देखभाल आवश्यक आहे जेणेकरून कार्यसंघ प्रत्येक स्प्रिंटमध्ये बदलांना प्रतिसाद देणे सुरू ठेवू शकेल.
देखभालीकडे पूर्णपणे दुर्लक्ष करणे कधी ठीक आहे?
हे 'थ्रोअवे प्रोटोटाइप' साठी स्वीकार्य आहे - व्हिज्युअल संकल्पना किंवा एकल लॉजिक फ्लोची चाचणी घेण्यासाठी विशेषतः लिहिलेला कोड जो आपण 100 टक्के हटविण्याचा आणि एकदा संकल्पना सिद्ध झाल्यावर सुरवातीपासून पुन्हा लिहिण्याचा विचार करीत आहात.
या तुलनेत 'डॉक्युमेंटेशन' कसे बसते?
दस्तऐवजीकरण हा देखभालीचा आधारस्तंभ आहे. त्याशिवाय, जेव्हा मूळ लेखक निघून जातो तेव्हा कोडचा हेतू गमावला जातो, प्रभावीपणे 'स्पीडी' कोडला ब्लॅक बॉक्समध्ये बदलतो ज्याला कोणीही स्पर्श करण्याचे धाडस करत नाही.
वेग माझ्या प्रकल्पाला मारत आहे याची पहिली चिन्हे कोणती आहेत?
'रिग्रेशन बग्स' (एका गोष्टीचे निराकरण केल्याने दुसरी गोष्ट तुटते) आणि 'वेग ड्रॉप' शोधा. जर आपला कार्यसंघ कठोर परिश्रम करीत असेल परंतु दरमहा कमी कामे पूर्ण करत असेल तर तांत्रिक कर्ज कदाचित आपल्या विकास पाइपलाइनमध्ये अडथळा आणत असेल.
'ओव्हर-इंजिनिअरिंग' देखभालीचा धोका आहे का?
नक्कीच. विकसक अशा उत्पादनासाठी 'उत्तम प्रकारे स्केलेबल' सिस्टम तयार करण्यात आठवडे घालवू शकतात ज्यात दहापेक्षा जास्त वापरकर्ते नसतात. ध्येय 'जस्ट-इन-टाइम' देखभाल आहे - पुढील 6-12 महिन्यांत आपण अपेक्षित असलेल्या प्रमाणात तयार करणे.
निकाल
सुरुवातीच्या टप्प्यातील प्रोटोटाइप, कडक अंतिम मुदतीसाठी किंवा नवीन बाजारपेठेतील गृहीतक सत्यापित करताना विकासाची गती निवडा. मुख्य व्यवसाय उत्पादने, आर्थिक प्रणाली किंवा सहा महिन्यांपेक्षा जास्त काळ जगण्याच्या आणि वाढण्याच्या उद्देशाने कोणत्याही अनुप्रयोगासाठी कोड मेंटेनबिलिटीमध्ये गुंतवणूक करा.