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