एक अप्राप्य अंतहीन परियोजना के साथ परछती


10

हमारे पास एक बड़ी (1200+ घंटे) वेबसाइट है जिसमें बहुत अधिक तकनीकी ऋण है। यह मुख्य रूप से निम्नलिखित (सामान्य) कारणों से होता है।

  1. कई प्रोग्रामर जो विकास के दौरान आते हैं और जाते हैं।
  2. विकास के दौरान विनिर्देशों में परिवर्तन।
  3. कई अतिरिक्त कार्य जोड़े गए (थोड़े समय में)।

ग्राहक नई कार्यक्षमताओं की एक बहुत चाहता है, और यह मूल रूप से 10+ घंटे के लिए साप्ताहिक इस परियोजना पर काम करने के लिए नीचे आता है ।

तकनीकी ऋण के कारण, हम समस्याओं को ठीक करने या जांच करने में बहुत समय बिताते हैं , जो आमतौर पर निम्नलिखित में से एक में अपना मूल पता लगाते हैं:

  1. एक बेशर्म, मूर्खतापूर्ण बग जो लोगों को रुला देता है।
  2. उपरोक्त में एक नई सुविधा का परिणाम है क्योंकि हमने उन सभी स्थानों को नहीं देखा था जहां नई सुविधा का प्रभाव होगा।
  3. कुछ अन्य समस्याएं जिनका हमें सामना करना पड़ा है (फ़ेर सर्वर माइग्रेशन, अपग्रेड)

हमारे पास दैनिक मुद्दे हैं और हमने इसे रोकने के लिए निम्नलिखित चीजों की कोशिश की है:

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

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

मुझे लगता है कि वहाँ बड़ी परियोजनाओं पर काम कर रहे प्रोग्रामर का एक बहुत हैं तो यह। यही कारण है कि मैं अपने सवाल पर आता हूं:

बड़ी परियोजनाओं पर इन समस्याओं से बचने के लिए हम क्या कर सकते हैं या आप क्या कर सकते हैं?

मामूली संपादन, अतिरिक्त जानकारी:

  1. हम संस्करण नियंत्रण (एसवीएन) का उपयोग करते हैं।
  2. हमारे पास डीटीएपी विकास प्रक्रिया है।

2
मुझे यकीन नहीं है कि यहां एक विशिष्ट पर्याप्त प्रश्न है, इसके अलावा, एक बड़े वेब एप्लिकेशन को विकसित करने और बनाए रखने का सही तरीका क्या है?
जेफओ

मैंने इसे यथासंभव विशिष्ट बनाने की कोशिश की। हम अपनी स्थिति पर लोगों की राय सुनना चाहते हैं और क्या सुधार करना चाहते हैं, या अपने स्वयं के अनुभव को साझा करना चाहते हैं और उन्होंने इस समस्या का सामना कैसे किया।
वेस्ले वैन ओपडोर्प

क्या आपके पास बिल्ड इंजन है? जो डिलिवरेबल्स बनाता है? हर बार जब कोई किसी चीज की जांच करता है?

मुझे DTAP: phparch.com/2009/07/…
Tangurena

3
बहुत बुरा काफ्का सॉफ्टवेयर सिस्टम के बारे में लिखने के लिए बहुत जल्दी था।
डेविड थॉर्नले

जवाबों:


11

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

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

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


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

1
अफसोस की बात यह है कि मैंने जो वर्णन किया है वह मूल रूप से मेरे विकास करियर की कहानी है। मैं ऑफिस पॉलिटिक्स नहीं खेल सकता, इसलिए जो लोग और लोग नहीं हैं, वे "टाइप ए" पर्सनैलिटी बिल्कुल नहीं हैं (या वे हैं, लेकिन समस्याओं को नहीं समझते हैं) इसलिए कुछ भी नहीं बदला जाता है, आमतौर पर, मुझे।
वेन मोलिना

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

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

लगता है कि मेरी निराशावादी दृष्टि किसी के साथ अच्छी तरह से नहीं बैठी है .. किसी को भी नीचे की व्याख्या करने की परवाह है?
वेन मोलिना

4

यदि आप कोई काम नहीं कर रहे हैं तो यूनिट-टेस्टिंग चीजें एक अच्छी शुरुआत है। बहुत कम से कम वे पुराने कीड़े को ठीक करते समय आपको नए कीड़े जोड़ने से बचाएंगे।

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

ग्राहक के अंत में, मैंने पाया है कि मूल्य / और (लंबी) देरी पर चर्चा करते हुए जैसे ही परिवर्तन / अतिरिक्त सुविधाओं का उचित रूप से अच्छी तरह से काम करने का अनुरोध किया जाता है, जिस समय आप उन पर चर्चा / डिजाइन करने के लिए खर्च करते हैं। अक्सर, ग्राहक तय करेंगे कि दूसरे विचार पर वे इंतजार कर सकते हैं।

(इसके विपरीत, यदि आप तुरंत उसके साथ चश्मा और कार्यान्वयन विचारों में खोदते हैं, तो वे आमतौर पर आपको "ओह" के लिए सेट करेंगे, मैंने सोचा था कि हम सहमत थे कि आप इसे वैसे भी करेंगे "या इससे भी बदतर, कई दिनों के बाद और बारीकियों पर) "लेकिन देखो, यह पहले से ही डिज़ाइन किया गया है और हमने जो चर्चा की है वह इतना कठिन नहीं लगता है!"।

पिछले नहीं बल्कि कम से कम, मैंने पाया है कि मैं प्रति दिन केवल एक बार ईमेल पढ़ता हूं (काम पर पहुंचने पर), और यह कि मुझे कुछ और जरूरी चीजों के लिए एक फोन है, एक जबरदस्त उत्पादकता में वृद्धि होती है।


3

मेरा सुझाव है कि आप कुछ सीआई-आधारित परीक्षण जोड़ते हैं, मुख्यतः उन क्षेत्रों पर। इससे आपको गुणवत्ता बढ़ाने में मदद मिलेगी क्योंकि परियोजना पर काम किया जा रहा है।

यह और भी स्पष्ट हो जाता है कि कौन से क्षेत्र / कार्यक्षमता अधिक बार टूटती है और इस प्रकार यह तय करना आसान होता है कि किन हिस्सों को रिफैक्टिंग की आवश्यकता है, या कम से कम परीक्षण में वृद्धि हुई है।

अधिक मैनुअल परीक्षण जोखिमों को जोड़ना परियोजना के $ $ $ और समय के अनुसार गलत तरीके से चलते हैं और प्रति सुविधा समय की आवश्यकता होती है।

कुछ कोड की समीक्षा अच्छी है, लेकिन शायद यह A-> B-> C-> एक परीक्षण योजना का हिस्सा है। (शायद दूसरी दिशा में कोड समीक्षा?)


1

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

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

1) वे आम तौर पर कार्यालय की राजनीति और शक्ति के संतुलन को बाधित नहीं करते हैं। 2) वे मुद्दे के केंद्र में हड़ताल के बजाय प्रबंधन द्वारा नियंत्रण का भ्रम पैदा करने में सफल होते हैं।

"प्रकाश यहां बेहतर है" प्रबंधन को लगता है कि आमतौर पर यह कहकर चला जाता है, "हर नई सुविधा के लिए एक विस्तृत तकनीकी कल्पना होनी चाहिए", या "मुद्दों पर चर्चा करने और उन्हें दूर करने के लिए प्रतिदिन एक घंटे की स्थिति की बैठक करें"।

इन बातों में से न तो वास्तव में मुद्दों के दिल में हड़ताल है और वे सिर्फ उत्पादकता में कमी कर सकते हैं, लेकिन वे निश्चित रूप से प्रबंधन द्वारा नियंत्रण के भ्रम को मान्य करते हैं।

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

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


1

मैं कुछ समय पहले उसी स्थान पर रहा हूं। मैं अब दो सरल नियमों के लिए धन्यवाद नहीं कर रहा हूँ:

  • हर हफ्ते एक या दो दिन, ऐप के अधिकांश बालों वाले हिस्सों को ठीक करने / फिर से लिखने में खर्च किए जाते हैं। कोई बग शिकार नहीं, कोई नई सुविधा नहीं।
  • नई सुविधाओं को लागू करते समय हम इसे तब भी सही करने का प्रयास करते हैं जब हम ग्राहक की अपेक्षा अधिक समय बिता रहे हों।

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


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

@WayneM इस दिन के लिए हाँ मैं हैरान हूँ कि यह वास्तव में काम करता है, कुछ लोगों के दृष्टिकोण को देखते हुए। ऐसा इसलिए होना चाहिए क्योंकि प्रबंधन विचारों से बाहर निकलता है कि "बग काउंट" को कैसे कम किया जाए और हमारे दृष्टिकोण को आजमाने का फैसला किया जाए।
जसूक प्रूइया

0

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

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

जब यह बहुत कम या बहुत अधिक उपयोग किया जाता है तो प्रक्रिया खराब होती है। मुझे लगता है कि आप पूर्व स्थिति में हैं।


0

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

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

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

चीयर्स। जस।


0

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

इससे पहले कि आप कोड लिखना शुरू करें कुछ फ्रंट डिज़ाइन का काम करें; इसके लिए संपूर्ण, या विशाल, या यूएमएल को समाहित करने की आवश्यकता नहीं है, लेकिन इसे समस्या का एक ठोस समाधान होना चाहिए, जिसे हल करने की आवश्यकता है। जहां तक ​​मैं बता सकता हूं कि कम सॉफ्टवेयर की योजना बनाई गई है, उतना ही बुरा है। इससे पहले कि आप इस पर काम करना शुरू करें, डिजाइन पर चर्चा करें।

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

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

नियमित / दैनिक कोड समीक्षा करें: यह सुनिश्चित करने के लिए कि चैरिटी के बारे में अधिक जानकारी है कि देव दूर तक नहीं गए हैं। अगले दिनों के काम की योजना बनाने के लिए इन सत्रों का उपयोग करें। ऐसे दिन हो सकते हैं जब ये 5 मिनट, या 1 घंटा लेते हैं; बिंदु एक संवाद खुला रखना है और डेवलपर्स को अन्य डेवलपर्स के साथ अपने काम पर चर्चा करने और सलाह लेने का मौका देना है। कोड के कठिन भागों पर, या प्रोटोटाइप विचारों के लिए कुछ युग्मन सत्र करें, लेकिन लोगों को काम करने का अपना समय दें।

अपना कोड बनाना और तैनात करना आसान बनाएं। बिल्ड समय को कम रखने का प्रयास करें। इसे बनाने में जितना आसान होगा, उतना ही जल्दी इसका निर्माण होगा।

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

मौलिक रूप से मुझे नहीं लगता कि आप जिस प्रक्रिया का उपयोग करते हैं, उसके बारे में बहुत कुछ है, फैशन आते हैं और जाते हैं। वास्तव में क्या मायने रखता है कि आप पेशेवर हैं कि आप सॉफ्टवेयर कैसे विकसित करते हैं और आप अपने अभ्यास में अनुशासित हैं।


1
-1: स्पष्ट कार्यात्मक विनिर्देश लिखें; पांडित्यिक रूप से - मैं दृढ़ता से असहमत हूं क्योंकि समय और ऊर्जा ने "पांडित्य, कार्यात्मक विशिष्टताओं" को लिखने में खर्च किया है (जो कि जल्दी ही अप्रचलित हो जाएगा) समय और ऊर्जा है जो आप कार्यात्मक इकाई परीक्षणों को लिखने में खर्च नहीं कर सकते हैं जो कोड को हर स्वचालित निर्माण चक्र को मान्य करते हैं।
जिम जी

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

1
आप दोनों मान्य अंक बनाते हैं। ठोस परीक्षण प्रथाओं के लिए मजबूत कार्यात्मक आवश्यकताएं आवश्यक हैं, हालांकि जब परियोजना पहले से ही कुप्रबंधित हो रही है तो इससे बहुत कम मदद मिलेगी।
maple_shaft

2
मैं आपकी बात लेता हूं, लेकिन मेरे अनुभव में यह नहीं पता कि जो विकसित हो रहा है, वह कुप्रबंधन का बीज है।

@ बी टायलर: ... मेरे अनुभव में पता नहीं क्या विकसित हो रहा है कुप्रबंधन का बीज। - 100% सहमत। हम सिर्फ उपाय पर असहमत हैं।
जिम जी

0

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

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

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

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