भविष्य प्रमाण कोड


33

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


5
मुझे लगता है कि एकमात्र भविष्यप्रूफ कोड है ... अच्छी तरह से व्हाट्सएप। :)
एडम एरोल्ड

6
"बस समय में, न कि केवल मामले में"।
रीन हेनरिच

4
@edem मैं असहमत हूं, वह भाषा भविष्य-
प्रमाण के

जवाबों:


62

वैसे सबसे पहले, कुछ चीजें हैं जिन्हें स्पष्टीकरण की आवश्यकता है:

  • फ्यूचर प्रूफिंग सामान नहीं जोड़ रहा है।
  • भविष्य के प्रमाण यह सुनिश्चित कर रहे हैं कि आप मौजूदा कार्यक्षमता को तोड़े बिना आसानी से कोड / सुविधाएँ जोड़ सकते हैं

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

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

मेरा 2 सी


यह और @ Thorbjørn रावन एंडरसन संयुक्त परीक्षणों के संबंध में सही जवाब होगा।
एंडी लोरी

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

भविष्य के अशुद्धि जाँच सुविधाओं को नहीं जोड़ सकते हैं, लेकिन निश्चित रूप से आप कोड जोड़ सकते हैं। एक तकनीक सुरक्षा जांचों को जोड़ना और किसी भी अपरिभाषित व्यवहार को स्पष्ट रूप से खारिज करना है।
eda-qa mort-ora-y

18

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

सुशोभित वसूली या असफल-तेज़ की अनुमति देने वाली अप्रत्याशित समस्या स्थितियों के खिलाफ कोड को मजबूत बनाएं, लेकिन भविष्य के संभावित उपयोगों के लिए कोड न लिखें।

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


+1: भविष्य की भविष्यवाणी करना इतना कठिन है। बस अच्छे डिजाइन का उपयोग करना - और इसे "अच्छा डिजाइन" कहना - भविष्य की भविष्यवाणी करने के बहाने से बेहतर है।
एस.लॉट

17

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

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

  • उपरोक्त के समान, SOAP या REST API के माध्यम से आपके एप्लिकेशन के एक हिस्से को उजागर करने से एक समान चीज प्राप्त होती है। जो भी प्रौद्योगिकियां विकसित होती हैं, आपको जरूरी नहीं कि आवेदन के हर हिस्से को फिर से लिखना होगा क्योंकि नई प्रौद्योगिकियां अभी भी पुराने के साथ संवाद करने में सक्षम होंगी।

  • कोड लिखने के मामले में इसकी आवश्यकता होती है , मुझे लगता है कि यह बहुत खतरनाक है क्योंकि कोड के बहुत कम या बिना परीक्षण के होने की संभावना है।

तो, हर तरह से, कोड को भविष्य का प्रमाण बनाएं (नासा अभी भी फोरट्रान का उपयोग करके स्पेसशिप भेजते हैं), लेकिन कोड को 'बस के मामले में' न लिखें।


1
Proof भविष्य के प्रमाण ’और it's भविष्य के लिए जरूरी है’ के बीच के अंतर के लिए +1
जॉन दस्ता

2
ध्वनि डिजाइन सलाह। इससे गायब केवल एक स्पष्ट कथन है कि "भविष्य का प्रमाण" केवल एक व्यर्थ चर्चा-वाक्यांश है जिसका अर्थ है "यथोचित डिजाइन"।
एस.लॉट

11

इस बारे में सोचें कि आपने कितने समय तक उत्पादन परिवेश में लाइन के एक टुकड़े को सक्षम किया है और सोचा, "भगवान का शुक्र है कि मैंने 2 साल पहले लिखा था!"।

कोड आसानी से परिवर्तनीय / विस्तार योग्य होना चाहिए। ऐसा कोड न जोड़ें, जो तुरंत आवश्यक न हो, क्योंकि यह सुरक्षा की बहुत गलत भावना देता है और बदलती आवश्यकताओं की दुनिया में देव / परीक्षण संसाधनों को बर्बाद करता है।


3
क्या आप सुझाव दे रहे हैं "धन्यवाद भगवान मैंने लिखा है कि 2 साल पहले!" दुर्लभ है? मेरे अनुभव में ऐसा कभी नहीं हुआ, लेकिन शायद सिर्फ मैं ही हूं।
एस.लॉट

4
यह एक बहुत ही दुर्लभ घटना है - क्योंकि कोड आधार जो 2 साल के बिना ठोस बने रहते हैं / 2 साल दूर होने वाले परिवर्तनों की भविष्यवाणी करना बहुत मुश्किल है।
सुबु शंकर सुब्रमण्यन

2
खैर, मैं वास्तव में काफी कुछ था "धन्यवाद भगवान मैंने लिखा है कि एक साल पहले" क्षण। मैं जितना समझती हूं उससे ज्यादा चालाक हूं।
फाल्कन

1
@ फाल्कन केयर इन क्षणों को विस्तृत करने के लिए? यह जानना काफी दिलचस्प होगा कि आपको कौन सा सही लगा।

7

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

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

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

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

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

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


6

अच्छा, स्वच्छ, अच्छी तरह से संगठित कोड है अर्थों में भविष्य प्रूफ कि इसे सही ढंग से लागू करने के लिए परिवर्तन और परिवर्धन आसान बना देता है।


5

"फ्यूचर प्रूफ" का सबसे अच्छा अर्थ है "शिथिल-युग्मित डिज़ाइन"। 80% लोगों का अर्थ "लचीला" होता है जब वे "भविष्य के प्रमाण" कहते हैं। कभी-कभी वे इसे कोशिश करते हैं और शांत ध्वनि कहते हैं। लेकिन कम से कम वे समय पर कुछ दे रहे हैं जो काम करता है।

"फ्यूचर प्रूफ" सबसे खराब अर्थहीन है। समय का 20%, यह केवल कुछ देने के बजाय वैकल्पिक प्रौद्योगिकियों पर शोध करने के लिए समय बर्बाद करने का एक बहाना है। वे कुछ भी नहीं दे रहे हैं (या जो वे वितरित कर रहे हैं वह हाथ में समस्या के लिए बहुत जटिल है।)

दो किनारे मामले हैं।

  1. दूरदर्शिता का अभाव। एक वास्तव में भविष्य की सटीक भविष्यवाणी कर सकता है । इस मामले में, कृपया इस शक्तिशाली दूरदर्शिता को कोड को भविष्य के प्रमाण के लिए लागू करें। बेहतर है, बाजार की प्रवृत्तियों की भविष्यवाणी करने और जल्दी रिटायर होने और कोडिंग को रोकने के लिए अप्रभावी दूरदर्शिता को लागू करें।

  2. एक "भविष्य" चला रहा है। यही है, किसी के पास भविष्य में तैनात करने के लिए कुछ नई तकनीक है जो इस समय वितरित की जा रही चीज को फिर से लिखने की आवश्यकता होगी। यह अजीब है कि कोई इस शांत भविष्य की चीज़ को पहले तैनात नहीं कर रहा है।

    हमें "ए" प्रोजेक्ट देना होगा, यह जानकर कि प्रोजेक्ट "बी" "ए" के तत्काल फिर से लिखना होगा। केवल इस मामले में, हम भविष्य के प्रमाण "ए" के लिए सक्षम हो सकते हैं।


5

YAGNI = आपको इसकी आवश्यकता नहीं है

आपकी प्रवृत्ति सही है: उनका कोड बहुत ही अच्छा है, रखरखाव और परीक्षण का बोझ जोड़ता है, और उन चीजों पर समय बर्बाद करता है जिनके पास एक ठोस व्यावसायिक मूल्य नहीं है।

इन्हें भी देखें: गोल्ड प्लेटिंग


4

प्रश्न के शीर्षक को नजरअंदाज करना, और "सामान डालना" के बारे में मुख्य बिंदु को चिपकाना क्योंकि कोई व्यक्ति इसे किसी दिन चाहता हो सकता है "...

जवाब न है। कभी नहीँ। आज आपको जिस कोड की आवश्यकता नहीं है, उसे सिलाई न लिखें। यहाँ पर क्यों:

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

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

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