अब इसे सरल रखें, या भविष्य को ध्यान में रखते हुए प्रोग्राम करें?


21

मैं वर्तमान में अपनी कंपनी के लिए एक नया एप्लिकेशन कोड कर रहा हूं जो इसमें शामिल है। समय सीमा को पूरा करने के लिए, कार्यक्षमता को थोड़ा नीचे रखा गया है ताकि हम लॉन्च के लिए जाने के लिए कुछ तैयार कर सकें।

मुझे महीने के अंत तक संस्करण 1 प्राप्त करने और चलाने का काम दिया गया है। मैं विकास के बारे में आधे रास्ते में हूं और मैं अब इस बिंदु पर आया हूं कि दृष्टि में अंत है।

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

मुझे नहीं पता कि मैं v2 कर रहा हूँ या नहीं। यह मैं हो सकता है या यह एक सहकर्मी, या एक प्रशिक्षु भी हो सकता है।

यदि आप मेरे जूते में थे, तो क्या आप भविष्य में इसे आसान बनाने के लिए अभी समय व्यतीत करेंगे, या क्या आप अपना समाधान छोड़ देंगे और समय आने पर इससे निपटेंगे?



निम्नलिखित लिंक मेरे लिए उपयोगी थी: सुरुचिपूर्णcode.com/2012/01/16/marines-vs-boy-scouts
क्वानहड

जवाबों:


18

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

यदि समय सीमा में पर्याप्त लचीलापन है (1 दिन, इसकी ध्वनि से, इसलिए 2.5 दिनों के विस्तार के लिए लक्ष्य रखें) तो निश्चित रूप से, ज्ञात भविष्य के लिए आगे और कोड करें!


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

2
मैंने वास्तव में दस्तावेज़ पढ़ने के बाद आज सुबह v2 प्रत्याशा के लिए विधि स्टब्स लिखना शुरू कर दिया। मुझे लगता है कि मैं इसे उस पर छोड़ दूंगा और कुछ टिप्पणियां कहूंगा कि ये भविष्य में कैसे खेलेंगे। धन्यवाद :)
त्यान्ना

1
गेंद पर अपनी नजर बनाए रखें .... मेरा अनुभव यह है कि वी 2 के साथ कुछ भी करने के लिए खुद के साथ चिंता करना एक बुरी बात है जब आपके पास आंखों के बीच हिट करने के लिए वी 1 की समय सीमा होती है यदि यह लचीला है तो इसकी समय सीमा नहीं है। अगर किसी विकास की समय सीमा समाप्त हो जाती है, तो यह डेवलपर्स की गलती है।
मटनज़

13

दूसरे सिस्टम इफेक्ट के शिकार (जल्दी) होने से बचें । यहाँ कुछ अच्छी तकनीकों को लागू किया गया है:

  1. निश्चित रूप से डी-रेलिंग संस्करण 1 से बचें क्योंकि आप संस्करण 2 में आते हुए देखते हैं। आगे की योजना बनाना ठीक है, लेकिन v2 चश्मा के निर्माता को v2 की विफलता के लिए जिम्मेदार होना चाहिए, v1 नहीं।
  2. (यदि संभव हो) देखें कि क्या आप निर्माता के संस्करण 2 के लिए आवश्यकताओं को फिर से काम कर सकते हैं जिन्हें अब बड़े बदलावों की आवश्यकता नहीं होगी - और फिर बाद में उनके लिए योजना बनाएं, शायद v3 के लिए।
  3. रखें YAGNI मन में हैं, लेकिन ध्यान तानाना के लिए कोड की कोशिश करते हैं - से बचने के जादू नंबर, हार्ड-कोडेड मूल्यों, अच्छा लिखने इकाई परीक्षण या कोड अनुबंध, आदि जल्दी पर अच्छा तकनीक लागू पुनर्रचना और कोड रास्ते में कम दर्दनाक बदलता है कर देगा।

अधिकांश सॉफ्टवेयर प्रोजेक्ट जो शहरों की तरह बढ़ते हैं , लंबे समय में सफल होते हैं। केवल भविष्य में विकासवादी नियोजन आपके सॉफ़्टवेयर को समय पर रिलीज़ करने की अनुमति देता है और रिलीज़ में आवश्यक कार्यक्षमता के साथ - और नहीं। कार्ल सागन का यह अंश देखें:

व्यवस्था [एक शहर की] और अधिक कुशल हो सकती है यदि सभी नागरिक प्रणालियों का निर्माण समानांतर और समय-समय पर किया गया (जो कि विनाशकारी आग है - लंदन और शिकागो के महान संघर्ष, उदाहरण के लिए-कभी-कभी शहर की योजना में एक सहायता होती है)। लेकिन नए कार्यों की धीमी गति से शहर को सदियों से कम या ज्यादा लगातार काम करने की अनुमति मिलती है।


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

2
+1: भविष्य की भविष्यवाणी करने की कोशिश से बचें। जब यह आयेगा तो आश्चर्य होगा।
एस.लॉट

7

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


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

@JoelEtherton: भले ही आपको व्यवसायिक ज्ञान हो, लेकिन परिवर्तनों का अनुमान लगाना बहुत कठिन है, इस बात के लिए कि यह अक्सर कोशिश करने लायक नहीं है ... बस मेरा अनुभव है।
सालेके

@ स्लेस्क: कभी-कभी संभवतः, लेकिन मेरा अनुभव दोनों दिशाओं में रहा है। मेरी वर्तमान नौकरी में, अच्छी योजना और दूरदर्शिता ने मुझे एक टन अतिरिक्त सिरदर्द से बचाया है।
जोएल एथरटन

6

जैसा है वैसा ही रहने दो।

डेवलपर्स वास्तव में एक विरासत परियोजना को लागू करते हैं जो वह करता है जो इसे करना चाहिए और अधिक नहीं।

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


"नहीं आधा-कार्यान्वित कार्यक्षमता" के लिए +1। काश मैं और बढ़ जाता।
सालेके

1

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

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


बदलावों को अलग रखने के बारे में अच्छा विचार है। एक अंतर के बजाय, एक शाखा शायद एक बेहतर विचार है (दृश्यमान, विलय करने में आसान)। आप इसे बाद में कभी भी हटा सकते हैं।
सालेके

1

निर्भर करता है। एक अच्छा पुराने जमाने का नियम है: अन्य लोगों के साथ वैसा ही व्यवहार करें, जैसा आप स्वयं उपचार करना चाहते हैं। यदि यह आपकी अपनी परियोजना थी और आप सभी प्राथमिकताओं को जानते हैं तो आप क्या करेंगे?

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

यदि v2 की आवश्यकता के बारे में कोई संदेह है तो YAGNI के साथ रहें। इसके अलावा अगर आप स्पेक्ट्रम के दूसरी तरफ हैं और उन ग्राहकों में से एक हैं, जो लगातार बनने से पहले आपको अपने विचारों से अनचाहा भेजते हैं, तो रोजाना केवल 2 या 3 बार अपने ईमेल की जांच करें और कार्रवाई में जल्दबाजी न करें, आपको आश्चर्य होगा। इससे पहले कि आप उन्हें पढ़ें, कितनी "समस्याएं" और अनुरोध अप्रासंगिक हो जाते हैं।

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