जब दूसरे व्यक्ति ने एक जटिल समाधान का निर्माण किया तो आप एक कोड समीक्षा में क्या कहते हैं? [बन्द है]


37

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

इस स्थिति में मैं पूछता हूं "ऐसा क्यों किया गया?"

जवाब यह है कि दूसरे व्यक्ति ने ऐसा करने का मन किया।

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

जवाब न है।

तो फिर मेरा सुझाव है कि वह सभी अनावश्यक जटिलता को हटा दें। आमतौर पर मुझे जो उत्तर मिलता है वह "अच्छी तरह से यह पहले से ही किया गया है" है।

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

एक समतुल्य परिदृश्य यह है:
सहकर्मी हाथ से 8 घंटे का रिफैक्टिंग कोड खर्च करता है जो कि 10 सेकंड में अपने आप ही Resharper में हो सकता था। स्वाभाविक रूप से मैं हाथ से रिफ्लेक्टिंग पर भरोसा नहीं करता क्योंकि यह संदिग्ध गुणवत्ता का है और पूरी तरह से परीक्षण नहीं किया गया है।
फिर से मुझे जो प्रतिक्रिया मिल रही है वह "अच्छी तरह से यह पहले से ही किया गया है।"

इस दृष्टिकोण के लिए एक उपयुक्त प्रतिक्रिया क्या है?


22
केवल एक

47
"आपने एक अत्यधिक जटिल समाधान बनाया"
दांते

2
कौन सा मुद्दा इस सवाल का फोकस है: प्रोग्रामर मानसिकता / दृष्टिकोण, परियोजना प्रबंधन (विशेष रूप से समय प्रबंधन), या कौशल स्तर?
रॉन्ग

6
यह शायद कार्यस्थल पर है - यह एक प्रोग्रामिंग सवाल नहीं है।
ग्रैंडमास्टरबी

जवाबों:


25

मानसिकता / रवैया

  • मिसाल पेश करके
  • निजी (एक-से-एक, कोड समीक्षा के बाहर)
  • टीम के सदस्यों के बीच एक सहज-सरल मानसिकता को प्रोत्साहित करें

टीम प्रबंधन

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

कौशल स्तर

  • डेवलपर टूल (रिफैक्टिंग, कोड-रिव्यू) का सर्वोत्तम उपयोग करने के लिए जोड़ी-प्रोग्रामिंग सत्र या एक-से-एक प्रशिक्षण सत्र के लिए कुछ समय आवंटित करें

परियोजना (जोखिम) प्रबंधन

  • आचार संहिता की समीक्षा अधिक बार, अतुल्यकालिक (नोट)
    • "असिंक्रोनसली" के बारे में ध्यान दें
      • कोड समीक्षक को प्रतिबद्ध होने के साथ ही परिवर्तनों की समीक्षा करने के लिए सूचना / निमंत्रण मिलना चाहिए
      • कोड समीक्षक के पास डेवलपर के साथ किसी भी बैठक से पहले कोड की समीक्षा करने का मौका होना चाहिए।
      • यदि डेवलपर से स्पष्टीकरण की आवश्यकता है, तो इसे बिना किसी नकारात्मक राय के आईएम / ईमेल पर अनौपचारिक रूप से करें

69

जब दूसरे व्यक्ति ने एक जटिल समाधान का निर्माण किया तो आप एक कोड समीक्षा में क्या कहते हैं?

आप कहते हैं: "आपने एक अत्यधिक जटिल समाधान बनाया है।"

तो फिर मेरा सुझाव है कि वह सभी अनावश्यक जटिलता को हटा दें। इसका जवाब मुझे आमतौर पर मिलता है "अच्छी तरह से यह पहले से ही किया गया है।"

यदि कुछ भी बदलने में बहुत देर हो गई है, तो आप कोड समीक्षा क्यों कर रहे हैं?


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

3
कभी-कभी आपको उन चीजों को करना पड़ता है जिन्हें आप पसंद नहीं करते हैं, जैसे कि किसी ऐसे व्यक्ति को बताना जो पूरी तरह से दिन का काम जटिल कोड लिखने में करता है कि "यह अच्छा नहीं है, इसे वापस रोल करें और शुरू करें" या उन पंक्तियों के साथ कुछ। यह बेकार है लेकिन आप कृतज्ञ होंगे।
joshin4colours

3
एक सरल जवाब जो स्थिति को बिल्कुल सटीक बैठता है। "यह पहले से ही किया गया है" आपकी अन्य प्रतिक्रिया है कि यह समझाने के लिए कि एक अति-जटिल समाधान को मुख्यता में समय गंवाना पड़ेगा, और यह लंबे समय में समय की बचत करेगा।
डीजेकेवरवर्थ

30
"+" अगर किसी भी तरह से कुछ भी बदलने में बहुत देर हो गई है तो आप एक कोड समीक्षा क्यों कर रहे हैं? "
mskfisher

16

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

उसे इस कार्य को फिर से सौंपने और अपने समाधान का अनुकूलन करने के लिए कहें। यदि वह ऐसा नहीं करता है, तो उसे एक जोड़ी प्रोग्रामर नियुक्त करें और आशा करें कि वह सहकर्मी से कुछ सीखेगा।


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

+1 साधारण तथ्य के लिए कोड में (स्पष्ट) बग होते हैं और इस प्रकार इसका परीक्षण नहीं किया गया है।
रामहाउंड

8

तो फिर मेरा सुझाव है कि वह सभी अनावश्यक जटिलता को हटा दें। आमतौर पर मुझे जो उत्तर मिलता है वह "अच्छी तरह से यह पहले से ही किया गया है" है।

यह स्वीकार्य उत्तर नहीं है:

  • यदि वास्तव में बदलने में बहुत देर हो चुकी है, तो कोड की समीक्षा काफी हद तक बेकार हो जाती है, और प्रबंधन को यह जानने की जरूरत है।

  • यदि वास्तव में यह कहने का एक तरीका है कि "मैं बदलना नहीं चाहता", तो आपको यह स्थिति लेने की आवश्यकता है कि अतिरिक्त जटिलता समस्याओं के कोडबेस BECAUSE के लिए BAD है / लागत जो बाद में खराब होने वाली है। और भविष्य की समस्याओं के संभावित कारण को कम करते हुए आप पहली बार में कोड की समीक्षा कर रहे हैं।

तथा ...

... समाधान पूरी तरह कार्यात्मक नहीं था ...

यह अनावश्यक जटिलता का प्रत्यक्ष परिणाम है। प्रोग्रामर ने इसे इतना जटिल बना दिया है कि वह अब इसे पूरी तरह से नहीं समझता है और / या उसने फ़ंक्शन बिंदुओं के बजाय अपनी जटिलता को लागू करने में अपना समय बर्बाद किया है। यह प्रोग्रामर को इंगित करने के लायक होगा कि जटिलता को काटने से वास्तव में उसे तेजी से काम करने का कार्यक्रम मिल सकता है।

अब, ऐसा लगता है कि आपके पास इस पर "जोर से धक्का देने" के लिए शक्ति (या शायद विश्वास) नहीं है। लेकिन फिर भी, यह इस बारे में थोड़ा सा शोर करने के लायक है (इसे निजीकृत किए बिना) इस उम्मीद में कि अपमानजनक कोडर बेहतर काम करेगा ... अगली बार।

इस दृष्टिकोण के लिए एक उपयुक्त प्रतिक्रिया क्या है?

अंततः, इसे प्रबंधन के ध्यान में लाएं ... जब तक कि आपके पास इसे स्वयं ठीक करने की शक्ति न हो। (बेशक, यह आपको लोकप्रिय नहीं बनाएगा।)


7

आप सही थे, वे गलत थे:

  • टूट YAGNI सिद्धांत
  • टूटी हुई KISS सिद्धांत
  • कोड पूरी तरह से परीक्षण किया गया है? यदि नहीं, तो यह नहीं किया जाता है

इस दृष्टिकोण के लिए एक उपयुक्त प्रतिक्रिया क्या है?

उचित कोड समीक्षा करें। यदि वे बिना किसी कारण के सुझाए गए परिवर्तनों को लागू करने से इनकार करते हैं, तो अपना समय एक कोड समीक्षा बर्बाद करना बंद करें। आप समस्या को उनके बॉस तक भी पहुंचा सकते हैं


5

एक कार्रवाई जो हमारी टीम ने की, जिसने नाटकीय रूप से ऐसे मामलों में स्थिति में सुधार किया, यह बहुत छोटे बदलावों के लिए कदम था ।

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

लाभ यह है, कि समस्याओं का पता लगाया जा सकता है और जल्दी हल किया जा सकता है, इससे पहले कि गलत तरीके से बड़ी मात्रा में काम किया जाए।


मैं कहूंगा कि एक ही दिन में 10 बार थोड़ा बहुत है। यदि आप वास्तव में इसे आगे बढ़ाना चाहते हैं, तो 3 या 4 चेकइन ठीक हो जाएंगे, इसका मतलब है कि हर 2 घंटे में एक चेकइन औसतन 8 घंटे का दिन देता है। लेकिन 10 चेकइन ऐसा लगता है कि वास्तव में समीक्षा के आधार पर किसी भी चीज़ की समीक्षा करने, वापस रिपोर्ट करने या परिवर्तनों को लागू करने का समय नहीं है।
रामहाउंड

@ रामहाउंड हां, 10 चेकइन एक चरम मामला है, 3 से 4 गुना अधिक विशिष्ट है। और इसे इस्तेमाल करने के लिए कुछ समय चाहिए ...
स्टीफन.ज जूल 18'12

2

आपको समस्या के मूल कारण पर ध्यान देना चाहिए:

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

(कोड समीक्षा में इसे बदलने में पहले से ही बहुत देर हो चुकी है)


2

मुझे कुछ नहीं पता है कि कोड लिखे जाने के बाद काम करता है।

कोड लिखे जाने से पहले, लोग इसे करने के वैकल्पिक तरीकों पर चर्चा कर सकते हैं। कुंजी एक दूसरे के लिए विचारों का योगदान दे रही है, इसलिए उम्मीद है कि एक उचित एक को चुना जाएगा।

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


1

आप दुनिया को ठीक नहीं कर सकते।

आप अपनी परियोजना के सभी कोड भी ठीक नहीं कर सकते। आप शायद अपनी परियोजना पर विकास प्रथाओं को ठीक नहीं कर सकते हैं, कम से कम इस महीने नहीं।

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

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

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


0

इस परियोजना में एक मानक नीति होनी चाहिए जो प्रयोग करने योग्य गुणवत्ता की जाँच प्रक्रियाओं और साधनों को नियंत्रित करती है।

लोगों को पता होना चाहिए कि उन्हें क्या करना चाहिए और इस परियोजना में उपयोग के लिए कौन से उपकरण स्वीकार किए जाते हैं।

यदि आपने अभी तक ऐसा नहीं किया है, तो अपने विचारों को व्यवस्थित करें और इसे करें।

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


0

आपकी दुकान को कुछ डिजाइन विधियों को लागू करने की आवश्यकता है।

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

0

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

अन्यथा मुझे लगता है कि कोड की समीक्षा कम औपचारिक लेकिन अधिक बार की जाती है। और बड़े मॉड्यूल लिखने से पहले शायद आपको जल्दी से चर्चा करनी चाहिए कि क्या दृष्टिकोण लेना है।

"यह बहुत जटिल है" कहना आपको कहीं नहीं मिलता है।


0

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

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


0

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

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

यदि आप कोई समस्या देखते हैं (अति जटिल) तो कुछ और ठोस कहें:

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

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


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

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

0

कभी-कभी यह "एजाइल" सिद्धांतों में से कुछ पर ध्यान केंद्रित करने के लिए एक समूह के रूप में इसके लायक है - वे एक समूह या व्यक्ति की मदद कर सकते हैं जो थोड़ा दूर का कोर्स लगता है।

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

  • सबसे सरल काम करें जो संभवतः काम कर सकता है?
  • आपको इसकी आवश्यकता नहीं है (क्या आप उन समस्याओं को हल कर रहे हैं जो कल्पना में नहीं थे)
  • कोडिंग से पहले परीक्षण लिखें (आपको अपना कोड केंद्रित करने में मदद करता है)
  • अपने आप को दोहराएं नहीं

इसके अलावा कभी-कभी (साप्ताहिक) क्या काम करता है, क्या नहीं और क्या अभी भी आवश्यक है की समीक्षा वास्तव में मददगार हो सकती है ... यदि कुछ और नहीं, तो टीम के मूल्यों और प्रथाओं पर चर्चा करने के लिए सप्ताह में एक घंटे के लिए प्रतिबद्ध क्यों नहीं?


0

वृद्धि, यदि आपके पास तकनीकी रूप से दिमाग वाला प्रबंधक है। यह एक आदत की तरह लगता है जिसे तोड़ने की जरूरत है।

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

किसी भी डेवलपर के लिए यह एक बुरी आदत है। यदि वह / वह एक डिजाइन कल्पना के लिए काम कर रहा था तो बिना अच्छे कारण के मिलान नहीं करना एक नहीं है।


0

एक शब्द: चुस्त

यह निश्चित रूप से सब कुछ हल नहीं करता है। लेकिन अपने पुनरावृत्तियों (उदाहरण के लिए 1-2 सप्ताह) में शासन करके, प्रगति में काम को सीमित करना और स्प्रिंट योजना / समीक्षा का लाभ उठाना, आपको इन झरने जैसी गलतियों से बचना चाहिए। आपको वास्तव में जो किया जा रहा है उसमें बेहतर दृश्यता की आवश्यकता है - जबकि यह किया जा रहा है।

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

आपकी स्थिति शायद ही अनोखी हो। और यहां तक ​​कि छोटी टीमों के साथ, प्रक्रिया उस स्थिति से बचने में मदद करने के लिए एक लंबा रास्ता तय कर सकती है जिसमें आप अभी हैं। उचित दृश्यता और एक उचित रूप से तैयार बैकलॉग के साथ, जैसे प्रश्न स्प्रिंट प्लानिंग निर्णय बन जाते हैं - आपको तकनीकी ऋण के प्रबंधन से बचाते हैं ।


-1

मैंने अतीत में जो कहा है, "यह कोड जटिल है और मुझे विश्वास नहीं है कि यह क्या करने की कोशिश कर रहा है, क्या इसे सरल बनाना संभव है या इसे अधिक स्पष्ट रूप से लिखना है?"


-2

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

“मेरी अगली समीक्षा 20 मिनट में है।

"अच्छा दिन।"

किसी भी तर्क को स्वीकार न करें!

हो गया, IMHO

क्रिस


मुझे खुशी है कि मेरे बॉस उस तरह से काम नहीं कर रहे हैं।

@ जॉन: जब लोग "अच्छी तरह से यह पहले से ही किया जाता है" के रूप में अव्यवसायिक रूप से प्रतिक्रिया करते हैं, जैसे मेरे छह साल के बच्चे कहेंगे, तो आपको उन्हें बच्चों की तरह व्यवहार करना होगा।
cneeds

2
कह नहीं सकता मैं सहमत हूँ। आप अपने लोगों से क्या परिणाम प्राप्त करने की उम्मीद करते हैं, यदि आप "उन्हें बच्चों की तरह व्यवहार करते हैं"? अन्य दृष्टिकोण हैं जो, IMHO, अधिक रचनात्मक हैं।

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

सौभाग्य से मेरी टीम में "बच्चे" नहीं हैं, इसलिए उन्हें किसी भी चीज़ के रूप में व्यवहार करना अनावश्यक है लेकिन वे जो पेशेवर हैं। वे कार्यक्षमता (मेरे समय और धन को बर्बाद करते हुए) के लिए बिना जोड़ नहीं देते हैं, वे बहुत ठोस कोड लिखते हैं और, जब उनसे अनुरोध किया जाता है कि वे कुछ संशोधित करें या संशोधित करें, तो वे ऐसा करते हैं, और वे अनुभव से सीखते हैं।
cneeds
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.