किसी एप्लिकेशन के पुनर्लेखन भागों से कैसे बचें


13

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

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

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

मैं बस सोच रहा हूँ कि अगर भविष्य में कुछ भी हो तो मैं फिर से लिख सकता हूँ। मैं समझता हूं कि मैं लचीला कोड बना रहा हूं और ऐसा करने की कोशिश कर रहा हूं, लेकिन मैं बस किसी भी प्रथा या ऐसी चीजों के बारे में जानना चाहूंगा, जो मैं इस आसान को बनाने के लिए अलग तरीके से कर सकता हूं, इसलिए, भविष्य में, मैं किसी चीज पर 3 दिन खर्च नहीं करता हूं 1 लेना चाहिए था।


2
आप किस प्रोग्रामिंग प्रतिमान का उपयोग कर रहे हैं? प्रक्रियात्मक, वस्तु-उन्मुख, कार्यात्मक, अन्य?
ट्यूलेंस कोर्डोवा

2
फिर से लिखने से बचने के लिए - अपने डेटाबेस और अपनी एप्लिकेशन परत को कम करें। यह एक साधारण अवधारणा नहीं है कि आप किस तरह से कोड लिखते हैं। यह एक जटिल अवधारणा है जो आपके कोड को सरल और अनुकूलनीय बनाती है।
स्टैकऑवरफॉउल

6
लगता है कि आवश्यकताएं स्पष्ट नहीं थीं या आपने उन्हें गलत समझा। कोई सिद्धांत या सर्वोत्तम अभ्यास आपको पूरे आवेदन को फिर से करने से नहीं बचा सकता है यदि कार्यान्वयन गलत धारणाओं पर किया गया था। एक भी एलओसी नीचे टाइपिंग से पहले यह अच्छा आवश्यकताओं के पूछने के लिए " क्या है ... " ... क्या एक नया के साथ आप आश्चर्य की बात प्रबंधक के लिए इंतजार नहीं कर क्या हैं ... । कार्यात्मक अंतराल की तलाश में कुछ समय बिताने से सर्पिस कारक भी कम हो जाएगा ।
20

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

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

जवाबों:


22

जैसा कि मैंने टिप्पणी की, मुझे इस बात का सख्त एहसास है कि पहली बार आवश्यकताओं को स्पष्ट नहीं किया गया था या शायद आपने कुछ महत्वपूर्ण विवरणों को याद किया।

हर चीज को बेहतर कोड, सर्वोत्तम प्रथाओं, डिजाइन पैटर्न या ओओपी सिद्धांतों के साथ संबोधित नहीं किया जा सकता है। यदि कार्यान्वयन गलत धारणाओं या गलत परिसरों पर आधारित है, तो उनमें से कोई भी आपको पूरे आवेदन को फिर से करने से नहीं रोकेगा।

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

जितनी बार जरूरत हो उतनी बार पूछने से न डरें। कभी-कभी पेड़ (विवरण) हमें जंगल (समग्र चित्र) देखने नहीं देते हैं। और यह जंगल है जिसे हमें पहले देखना होगा।

जब आवश्यकताएं स्पष्ट होती हैं, तो डिजाइन चरण के दौरान बेहतर निर्णय लेना आसान होता है।

अंत में, याद रखें कि समग्र चित्र एक लक्ष्य है। इस लक्ष्य का मार्ग न तो सीधा है और न ही सीधा। परिवर्तन होते रहेंगे, इसलिए चुस्त रहें।


3
इस। यह उत्तर सबसे अच्छा तरीका है जिसे इसे रखा जा सकता है। आप कुछ भी करने से पहले उन आवश्यकताओं को प्राप्त करें।
राइज जॉन्स

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

खैर, मुझे इस बात का पक्का अहसास था कि समस्या वही थी जिस पर मैंने टिप्पणी की थी क्योंकि डेवलपर के रूप में मेरे शुरुआती दिनों में ऐसा ही हुआ था। फिर मैंने तुरंत LOC या मॉड्यूल में वाक्यांशों का अनुवाद किया, और जब मुझे कुछ बदलना था तो मेरे लिए काफी नाटकीय था। प्रति दिन या सप्ताह में रिफ्लेक्टर पर रिफ्लेक्टर। यहां तक ​​कि एसओसी, एसपीआर, बहुरूपता के साथ अपना सर्वश्रेष्ठ प्रदर्शन करने के लिए नहीं ... मेरे द्वारा किए गए कई संघर्षों का कारण मेरी समग्र दृष्टि का रिसाव था।
लैव जूल

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

1
कुछ का तर्क हो सकता है कि db को कोड से अमूर्त करना बहुत जरूरी नहीं है क्योंकि "db वेंडर शायद ही कभी बदलते हैं"। मैं आपसे सहमत हूं, लेकिन मेरे उत्तर की बात यह है: आवश्यकताओं को इकट्ठा करते समय, भूल जाते हैं कि आप एक डेवलपर हैं, आवश्यकता पर ध्यान केंद्रित करें। एक प्रबंधक की तरह सोचें, एक प्रबंधक की तरह पूछें। एक डेवलपर की तरह सोच में जल्दबाजी न करें।
Laiv

4

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

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

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


अच्छा लेख जो आपने लिंक किया है
SH7890

1
अच्छा लेख वास्तव में! मुझे लगता है कि ओपी मामला नहीं है लेकिन मैं लेखक के साथ अधिक सहमत नहीं हो सका।
लाईव

1
मुझे नहीं लगा कि यह एक के लिए एक था, लेकिन यह ऐसा पढ़ा जैसे यह एक दिन हो सकता है। उम्मीद है कि इससे ओपी को मदद मिलेगी।
जॉनी

2

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

यूआई कठिन सामान है, आमतौर पर, 5 लोगों के पास 15 अलग-अलग विचार हैं। और डेटा और डेटा संरचना और डेटा विश्लेषण कारक 10 से गुणा करने के लिए बदलते हैं :)। यूआई फैशन की तरह है, कुछ संयोजन शांत हैं, कुछ भयानक या लापता सामान्य ज्ञान हैं।

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

इतना सरल उत्तर है, कि इसमें कोई पुनर्लेखन जैसी कोई बात नहीं है।


2

Iterative विकास (जो आपने मूल रूप से किया था, यद्यपि एक दिवसीय पुनरावृत्तियों) अक्सर ऐसा होता है। समाधान के शुरुआती प्रयास अक्सर निशान से दूर होते हैं, और प्रतिक्रिया एकत्र करके, सिस्टम एक समाधान में परिवर्तित हो जाता है। मैं क्रेग लर्मन के प्रशिक्षक सामग्री से चित्र 2.2 को उनके लागू करने वाले यूएमएल और डिज़ाइन पैटर्न की पुस्तक के लिए उधार लूंगा ।

यहाँ छवि विवरण दर्ज करें

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

यह कहने के लिए नहीं है कि आप प्रतिक्रिया प्राप्त करने के बाद आपको फिर से लिखना कितना कम कर सकते हैं। एक बात जो अक्सर सच होती है, वह यह है कि सॉफ्टवेयर के मानव-कंप्यूटर इंटरैक्शन को बदलने की बहुत संभावना है, क्योंकि यह पहली बार सही पाने के लिए एक कठिन हिस्सा है।

Microsoft Word के बारे में सोचें और इसका डेटा प्रारूप (.doc) वास्तव में वर्षों में कितना विकसित नहीं हुआ है। ऐसा इसलिए है क्योंकि समस्या डोमेन के रूप में एक पाठ दस्तावेज़ वास्तव में बहुत विकसित नहीं हुआ है (एक पृष्ठ अभी भी एक पृष्ठ है, एक पैराग्राफ अभी भी एक पैराग्राफ है, आदि)। हालाँकि, Word का उपयोगकर्ता इंटरफ़ेस बहुत विकसित हुआ (और अभी भी जारी है)। प्रस्तुति या इनपुट के लिए कोड संस्करणों के बीच अस्थिर हो जाता है, इसलिए सिस्टम के अन्य हिस्सों को सीधे उनके साथ युग्मित करना (उन्हें फिर से लिखना शुरू करना) नहीं करना सबसे अच्छा है।

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

यह बहुत बौद्ध लग सकता है, लेकिन आप इन पुन: लिखते हैं सौभाग्यशाली रहे हैं! इतने सारे लोग एमवीसी पैटर्न या अन्य डिज़ाइन पैटर्न के बारे में सीखते हैं बिना "बुरे" के फिर से लिखना बुरे सपने से बचने के लिए माना जाता है।


मैं इस उत्तर को स्वीकार करना पसंद करूंगा। सभी आवश्यकताओं को सामने रखने की कोशिश करने की तुलना में एक समाधान की ओर इशारा करना बेहतर है। खासकर यदि एक दिन के भीतर पूरे आवेदन को फिर से लिखा जा सकता है।
जश्न

मुझे यकीन है कि बॉस को नहीं पता था कि वे दूसरे पुनरावृत्ति में क्या चाहते हैं जब तक कि पहला पूरा न हो जाए। “पहले से अधिक आवश्यकताओं को इकट्ठा करना असंभव था।
gnasher729 11

1

मेरे पास कोई जवाब नहीं है, एक अभ्यास के रूप में इतना - एक जिसे आपको संभवतः अपने समय में करना होगा, हालांकि आपके संगठन के आधार पर, आप काम के घंटों के दौरान इसे करने की अनुमति प्राप्त करने में सक्षम हो सकते हैं।

अपने पहले समाधान को फिर से तैयार करें कि उसने क्या किया, लेकिन 2 या 2 और 3 चरणों को जोड़ना आसान बना दिया। उन चरणों को न जोड़ें, उन्हें बाहर न रखें। बस एक समाधान बनाएं जो सभी मूल आवश्यकताओं को पूरा करता है लेकिन नई सुविधा को शामिल करने के लिए आसानी से अपग्रेड किया जा सकता है। अपने दूसरे समाधान के लिए भी ऐसा ही करें।


1

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

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


-1

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.