अगर किसी ने आपको बताया कि आपका कोड गड़बड़ है तो आप कैसे प्रतिक्रिया देंगे?

Question

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

हमारी टीम 5 प्रोग्रामर से बना है, और हम में से 4 नए हैं, 1 में 3 से अधिक वर्षों का अनुभव है। हम लगभग एक साल से एक कार्यक्रम के लिए काम कर रहे हैं और कोई भी कभी भी मेरे कोड की समीक्षा नहीं करता है और मुझे काम करने के लिए एक पेज दिया गया है। हमारे पास कोड की समीक्षा कभी नहीं थी और हम सभी नए हैं इसलिए हमें नहीं पता कि एक साफ कोड कैसा दिखता है। मुझे लगता है कि प्रोग्रामर खुद से सीखते हैं?

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

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

Comments

"लेकिन ऐसा लगता है कि मैं फिल्मों की तरह प्रतिभाशाली प्रोग्रामर नहीं हूं" । आपकी गलती विश्वास है कि आप सॉफ्टवेयर डेवलपर्स, हैकर्स, और वास्तविक दुनिया की तकनीक के साथ क्या करना है, के बारे में फिल्मों में जो कुछ भी देखते हैं।

— स्टीफन सी

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

— जिमी हॉफ

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

— उठने

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

— यानि नौ

लोगों को याद रखें, सिर्फ इसलिए कि किसी ने कहा था कि कोड खराब था, यह सच नहीं है। सुनने के बाद "आपका कोड गड़बड़ है" ओपी हकदार है "और यहाँ क्यों है।" फिर, विश्लेषण शुरू हो सकता है।

— टोनी एननिस

Answer 1

सच्चाई यह है कि शायद 2 साल में जब आप अपना वर्तमान कोड देखेंगे तो आप सहमत होंगे कि यह एक गड़बड़ थी। प्रोग्रामिंग सीखना एक कभी न खत्म होने वाली प्रक्रिया है और हमेशा कोई ऐसा व्यक्ति होगा जो आपसे बेहतर है।

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

Comments

आप सही हे! मैं 2 साल पहले अपने कोड पर हंसता था। इसलिए मुझे लगता है कि मैं भी अब से दो साल बाद अपने कोड पर हंसूंगा। मैं बस इसके बारे में थोड़ा भावुक हो गया। किसी भी तरह, मैं एक बेहतर बनने की कोशिश करूंगा।

— नौसिखिया

@newbie: वहाँ तुम जाओ। जो आपको वास्तव में जानना है। मेरा मकसद "दस साल से अधिक के लिए" मैं अब से दो साल के रूप में अच्छा नहीं हूँ। और मैं अभी तक गलत नहीं हुआ हूं। मैंने यह नहीं सीखा कि मेरे करियर में आप की तुलना में बहुत अधिक झुकाव है। आपके सहयोगी ने आपका बड़ा उपकार किया है।

— पीडीआर

मुझे लगता है कि अपने कोड से नफरत करने के लिए छह महीने का समय बहुत होना चाहिए। मुझे चिंता है कि कुछ दिन मैं कोड है कि मैं छह महीने पहले लिखा है और हो सकता है कर रहा हूँ नहीं कुछ मैं इसके बारे में नफरत पाते हैं। यह एक संकेत होगा कि मैं एक प्रोग्रामर के रूप में नहीं बढ़ रहा हूं।

— zzzzBov

2 साल! मैं दोपहर में कोड पर हंस सकता हूं जो मैंने सुबह लिखा था।

— dan_waterworth

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

— Mattygabe

Answer 2

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

अगर आपको पता नहीं है कि मैं किस बारे में बात कर रहा हूं, तो http://www.perlmonks.org/?node_id=270083 पढ़ें ।

Comments

अच्छा लेख। :) तो मैं सिर्फ अपने अहंकार से निपट रहा हूं।

— नौसिखिया

@newbie बिल्कुल। जब आप अपने कोड की आलोचना प्राप्त करते हैं, तो यह केवल आपको परेशान कर सकता है यदि आपका अहंकार उस कोड की गुणवत्ता में बंधा हुआ है। कोड से अपने अहंकार को तलाक दें, और समस्या दूर हो जाती है।

— btilly

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

— ब्रायन ओकले

और आपको सीखने में गर्व करने के बारे में भी सावधान रहना चाहिए क्योंकि इससे वही समस्याएं हो सकती हैं यदि आप वास्तव में सीखने में अच्छे नहीं हैं।

— निको बर्न्स

मुझे लगा कि गर्व 7 घातक पापों में से एक था? इन दिनों इसकी अनुशंसा करने वाले सभी के साथ क्या हो रहा है? कैसे के बारे में सिर्फ महसूस सामग्री है कि आप एक अच्छा काम किया है।

Answer 3

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

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

डिस्क्लेमर: इसमें से कोई भी "खराब कोड ठीक है" नहीं पढ़ा जाना चाहिए।

Comments

"काम हो रहा है" के लिए प्रयास औसत दर्जे के लिए प्रयास कर रहा है। आप सही हैं, यह काम करता है और प्रभावी हो सकता है - बस चीनी उत्पादों को देखें। लेकिन चीजों को महान बनाने के लिए प्रयास करते हुए मित्र के 20 साल के प्रोग्रामिंग को सार्थक बनाता है। 20 साल पीछे देखें, इससे क्या पता चलता है - काम करना या गर्व के साथ काम करना?

— 1998 में किंग्डैंगो

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

— स्टीवन बर्नाप

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

— मार्क बूथ

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

— सुपरकैट

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

— crampicco

Answer 4

हर किसी का कोड एक गड़बड़ है और अच्छे प्रोग्रामर नहीं हैं।

वहां:

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

वे शायद ही, अगर कभी, एक ही व्यक्ति होने का अंत करते हैं।

और बटरहार्ट प्रोग्रामर हैं जिन्हें बड़े होने की आवश्यकता है और:

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

यह कला नहीं है, यह एक शिल्प है।
हम देते हैं कि आप चतुर हैं: आप प्रोग्रामिंग कर रहे हैं कंप्यूटर, ईश्वर।
फिर भी AMD64और x86अपने गद्य की शक्ति से मजबूर नहीं हैं। चीजों को सरल रखें।

Comments

सचमुच ज़ोर से हँसा। बहुत अच्छा। Roflcopters

— kingdango

AMD64 और x86 आपके गद्य की शक्ति से मजबूर नहीं हैं। - अत्यन्त अद्भुत।

— सैम ब्रिनक

+1 SQL

— HLGEM

Answer 5

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

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

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

क्या आपके द्वारा लिखे गए कोड के कुछ पुराने हिस्सों पर चले गए हैं? आप शायद उन चीजों को देख सकते हैं जिन्हें आप अब अलग तरह से या रिफ्लेक्टर करना चाहते हैं।

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

Answer 6

मुझे बहुत दुख और दुख हुआ। मैं वास्तव में प्रोग्रामिंग से प्यार करता हूं और उन्हें ऐसा कुछ कहना पसंद करता हूं जो वास्तव में मुझे पीड़ा देता है। मैं वास्तव में खुद को सुधारना चाहता हूं।

यह अच्छा है। यह एक है बहुत की तरह, "मेरे समीक्षक भी picky है" या बस "मेरे समीक्षक मुझे पसंद नहीं है" और उनकी उपेक्षा करते हुए "मेरे समीक्षक पता नहीं कि वह क्या बारे में बात कर रहा है" एक प्रतिक्रिया की तुलना में बेहतर है। यह रवैया एक अच्छी बात है।

लेकिन ऐसा लगता है कि मैं फिल्मों की तरह प्रतिभाशाली प्रोग्रामर नहीं हूं।

यह निश्चित नहीं है कि आप किस तरह की फिल्में देखते हैं, लेकिन फिल्मों में 90% प्रोग्रामर इतने नकली हैं कि मेरे पास अनुक्रम के अंत तक आँसू हैं।

क्या आप मुझे सलाह दे सकते हैं कि बेहतर कैसे बनें?

पढ़ें और अभ्यास करें। कोड कम्पलीट या द प्रैजमैटिक प्रोग्रामर जैसी पुस्तकों को देखें । इसी तरह की किताबों के लिए अमेज़न पर देखें।

क्या आपने कभी अपने कोड की आलोचना करते हुए कुछ अनुभव किया है और आप वास्तव में आहत महसूस करते हैं? आप उन घटनाओं पर क्या करते हैं ..

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

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

Comments

+1 करने के लिए इसे एक साथ रखने के लिए और reviews you provideदूसरों के लिए महत्वपूर्ण होने के कारण बेहतर गुणवत्ता को चालू करने के लिए अपने स्वयं के कोड के लिए महत्वपूर्ण होने में बेहतर अभ्यास हो सकता है।

— जिमी हॉफ

"फिल्मों में 90% प्रोग्रामर इतने नकली हैं कि मुझे सीक्वेंस के अंत तक आंसू आ गए।" 90%? क्या फिल्में करते आप देखते हो? : पीआई ने एक भी फिल्म नहीं देखी है जो यह दर्शाती है कि हम क्या करते हैं। और फिर "स्वोर्डफ़िश" और "स्वतंत्रता दिवस" ​​थे ...

— निक बुगालिस

अच्छी तरह से डाल दिया और इतनी आसानी से!

— 1964 में किंग्डैंगो

Answer 7

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

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

किसी भी क्षेत्र में बहुत कुछ, ऐसे लोग हैं जिन्हें विशेषज्ञ माना जाता है। यदि वे लोग मौजूद नहीं थे, तो हमारे पास सीखने के लिए कोई नहीं होगा। प्रश्न में इस व्यक्ति को सही मायने में एक विशेषज्ञ मानते हुए, मैं कहता हूँ कि वह क्या कहता है और पूछेगा कि वह आपको अपने कोड में सुधार करने के लिए क्या सुझाव देगा। हालांकि, कभी मत भूलो, कि वह केवल एक ही नहीं है जो अपनी सहायता दे सकता है; हमारा सौभाग्य है कि SE / SO जैसे संसाधनों का ढेर मौजूद है।

Comments

" हमेशा कोई ऐसा व्यक्ति होगा जो कुछ नहीं जानता है जो आप करते हैं, और हमेशा कोई ऐसा व्यक्ति होगा जो कुछ जानता है जो आप नहीं करते हैं " - भयानक; +1।

— मैक्सिमस मिनिमस

हाँ, और मैं सब कुछ सीखना चाहता हूँ

— नौसिखिया

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

— सुपरकाट

Answer 8

मेस बल्कि व्यक्तिपरक है। सबसे अच्छी बात यह है कि आप वास्तव में उस व्यक्ति (या समीक्षा रिपोर्ट) से पूछ सकते हैं: यह गड़बड़ क्यों है? (उनके दृष्टिकोण से, वह है)

वे आपको जवाब देने के लिए बाध्य हैं और आप या तो सक्षम होंगे:

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

Comments

उन्होंने टिप्पणी नहीं की :( लेकिन यहाँ मेरा कोड है -> codereview.stackexchange.com/questions/18719/…

— newbie

आपको क्यों लगता है कि यह गड़बड़ है?

— नौसिखिया

@newbie: फिर वह समीक्षक बहुत अच्छा नहीं है। एक कोडर को यह जानना चाहिए कि समस्या क्या है (यह भी एक सुराग नहीं है?) को जाने बिना कुछ सुधारना चाहिए।

— ओमेगा

ठीक है धन्यवाद ... मैं एक याचक प्रोग्रामर नहीं हूं। मैं एक जावा प्रोग्रामर हूँ ....

— नौसिखिया

उस समय केवल मेरा कोड ही उसके पास उपलब्ध है। वैसे भी, तुम सही हो, मैं इसके बारे में अधिक जानकारी के लिए पूछूँगा। धन्यवाद :)

— नौसिखिया

Answer 9

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

Our team is composed of 5 programmers, and 4 of us are new

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

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

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

"यदि पर्याप्त समीक्षक हैं, तो सभी समस्याओं को हल करना आसान है।"

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

I feel so sad and hurt. 

जब आप खुद को लागू नहीं करते हैं तो आपको कितना परेशान होना पड़ेगा, यह जानने के लिए उदासी का आवेदन करें।

आपने अपनी समस्या का उत्तर दिया ... यू डोंट टेस्ट!

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

उसमें रब झूठ बोलता है

"हमने पूरी तरह से परीक्षण के बिना कार्यक्रम के लिए अपने कार्यक्रम को तैनात किया।"

CMLbing UML निर्माता ग्रेडी बूच ...

शौकिया सॉफ्टवेयर इंजीनियर हमेशा जादू की खोज में रहता है, कुछ सनसनीखेज तरीका या उपकरण जिसका आवेदन सॉफ्टवेयर विकास तुच्छ को प्रस्तुत करने का वादा करता है। यह पेशेवर सॉफ्टवेयर इंजीनियर के लिए यह जानना है कि ऐसा कोई रामबाण इलाज मौजूद नहीं है।

एलिस्टेयर कॉकबर्न अपनी साइट पर आपके और आपकी टीम के लिए प्रदर्शन और गुणवत्ता बढ़ाने के लिए चुस्त तरीकों का उपयोग करने के बारे में जानकारी प्रदान करता है।

प्रोग्रामिंग {और जीवन} के सबसे महत्वपूर्ण पहलुओं में से एक है आपकी ताकत और कमजोरियों को जानना। यदि आप अपनी कमजोरियों पर काम नहीं करते हैं, तो आपके पास एक अच्छी तरह से गोल कौशल-सेट नहीं होगा।

आउट्रो ... आपका अच्छा काम - बस कराहना नहीं है। अपने शिल्प को विकसित करने में आगे बढ़ें और प्रोग्रामिंग के लिए अपने जुनून को जारी रखें। शुभ लाभ :-)

Answer 10

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

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

आपका कोड आप नहीं है उसे याद रखो।

Answer 11

मैं यहाँ डिक बनने जा रहा हूँ और .. के आधार पर सलाह देता हूँ। जाहिर है, आपका कोड एक गड़बड़ है या जो सवाल आप पूछ रहे हैं वह यह है कि "कोई क्यों कह रहा है कि मेरा कोड गड़बड़ है?" लेकिन आप दमन को चुनौती नहीं दे रहे हैं। आप सिर्फ चोट कर रहे हैं और काफी स्पष्ट रूप से रो रहे हैं, लेकिन प्रोग्रामिंग को औचित्य देने के लिए नीचे आने पर कोई भावना नहीं है।

लेकिन वास्तव में, आप क्यों पूछ रहे हैं? आपको पता है कि आपका कोड बेकार है या आप एक अलग सवाल पूछ रहे हैं। अगर किसी ने मुझे अपना बैक-एंड वेब कोड स्टैक बताया, तो मैं हँसूँगा और कहूँगा "ठीक है इसमें गलत क्या है?" अगर उन्होंने मुझे अपना जावास्क्रिप्ट स्टैक बताया है, तो मैं उन्हें सामाजिक प्रोग्रामर को एक मोटे होंठ के बराबर दूंगा और मैं कभी भी सलाह नहीं दूंगा कि कैसे प्रतिक्रिया दें, क्योंकि छोटी कुतिया स्पष्ट रूप से हैं! @ # $ आईएनजी गलत है।

अपने आप से आप अच्छे हैं। और मैं वास्तव में इसके लिए जिम्मेदारी लेता हूं। क्योंकि यह केवल कुछ गोधूलि के लिए एक नासमझ दूसरे-अनुमान के लिए ले जाता है। अच्छा होने की अनुमति मत पूछो। बस अपना सामान पता है। समाप्त।

Comments

तथास्तु। और अपने सामान को जानने के लिए ... अच्छी तरह से ... यह सुनिश्चित करने का प्रयास कि आपको अपना सामान पता है। लेकिन अपने कॉलर को भी पॉप करना सुनिश्चित करें, यही सभी संभ्रांत बच्चे इन दिनों कर रहे हैं। : /

— kingdango

हाँ, मुझे लगता है कि मैंने अभी और अनुभवी देवों को सलाह दी है कि वे गलत होने के लिए सबसे पहले स्वीकार करें। मैं कई व्यक्तित्वों को खतरे में डाल सकता हूं।

— एरिक रेपेने

Answer 12

इसे याद रखें: सबसे खराब कोड जो आप कभी देखेंगे वह आपका अपना है!

Codinghorror.com के जेफ एटवुड ने विषय के बारे में बहुत कुछ लिखा है, आप यहां शुरू करना चाहते हैं: http://www.codinghorror.com/blog/2009/07/nn-hates-software-more-shan-software-developers.html

यदि आप सुधार करना चाहते हैं, तो कोडिंग शैली, पैटर्न, वर्कफ़्लो के बारे में सामान पढ़ना शुरू करें, मूल रूप से सब कुछ जिस पर आप अपनी उंगलियां प्राप्त कर सकते हैं। अधिक प्रोग्रामिंग भाषाएं भी सीखें, देखें कि वे कैसे सामान करते हैं। यदि आप OOP कर रहे हैं, तो इसे पढ़ें: http://en.wikipedia.org/wiki/Design_Patterns

अन्य प्रोग्रामर्स से भी बात करें और पेयर प्रोग्रामिंग करें या दूसरों का कोड देखें।

गलतियाँ करना अपरिहार्य है, उन्हें दोहराना है।

Comments

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

— Murph

Answer 13

अधिकांश समय आपको उस व्यक्ति को "थैंक यू" कहना चाहिए जिसने आपको यह बताया है।

संभावना है कि वे अपने पेशे की परवाह करते हैं, वे अपने काम की परवाह करते हैं, वे अपनी टीम की परवाह करते हैं और वे आपकी परवाह करते हैं।

आलोचना करना कठिन हो सकता है। इसके बारे में पागल मत बनो। इस बारे में सोचें कि वे आपको क्या बताने की कोशिश कर रहे हैं और अपनी भावनाओं को आप से बेहतर न होने दें।

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

अपने कैरियर की शुरुआत में आपके द्वारा लिखे गए कोड को देखने का प्रयास करें। अब यह आपको कैसा दिखता है? क्या यह उतना अच्छा लगता है जितना आपने सोचा था कि आपने इसे लिखा था;)

Answer 14

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

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

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

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

रिफैक्टरिंग की बात करें, तो आपके पास एक यूनिट टेस्ट फ्रेमवर्क होना चाहिए, क्योंकि इसके बिना, आप रिफलेक्टर नहीं कर सकते।

अंत में, मैं रॉबर्ट सी। मार्टिन द्वारा "क्लीन कोड" पढ़ने की अत्यधिक सलाह देता हूं। यह आपको बताएगा कि आपका कोड गड़बड़ क्यों है, और आप इसे साफ करने के लिए क्या कर सकते हैं।

Answer 15

क्या आप मुझे सलाह दे सकते हैं कि बेहतर कैसे बनें?

जे का उत्तर जो पुस्तकों की सिफारिश करता है वह एक अच्छा है, हालांकि ऐसा लगता है कि आप पहले से ही काम पर एक मोड़ पर हैं।

विगत:

हमारी टीम 5 प्रोग्रामर से बना है, और हम में से 4 नए हैं, 1 में 3 से अधिक वर्षों का अनुभव है। हम लगभग एक साल से एक कार्यक्रम के लिए काम कर रहे हैं और कोई भी कभी भी मेरे कोड की समीक्षा नहीं करता है और मुझे काम करने के लिए एक पेज दिया गया है।

वर्तमान:

अब यह कड़ा है और कोड के साथ बदलाव करने से पहले हमें एक अनुमोदन और कोड समीक्षा की आवश्यकता है।

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

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

बेस लाइन पर यह एक त्वरित समीक्षा होगी जिसके परिणाम "हाँ ठीक लग रहे हैं"। थोड़े अधिक केंद्रित प्रयास से आप विचारों को एक-दूसरे से दूर कर सकते हैं, "हाँ जो काम करता है, लेकिन आप इसे इस तरह से संपर्क कर सकते हैं, जो आपके लक्ष्य को स्पष्ट कर देगा ..."। यदि कोड को ठीक समझा जाता है तो भी भविष्य के लिए नोट्स लें।

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

यह एक संस्कृति परिवर्तन है, जिसे आप स्वयं के द्वारा बाध्य नहीं कर सकते हैं, लेकिन आप चीजों को सही दिशा में लाने में मदद कर सकते हैं!

मत भूलना, इस तरह का संस्कृति परिवर्तन संगठनों के लिए बेहद फायदेमंद हो सकता है; अच्छे प्रबंधक यह पहचानेंगे कि आप पूरी टीम को बेहतर बनाने के लिए काम कर रहे हैं, जो पुरस्कृत करने लायक है।

Answer 16

क्या आप मुझे सलाह दे सकते हैं कि बेहतर कैसे बनें? क्या आपने कभी अपने कोड की आलोचना करते हुए कुछ अनुभव किया है और आप वास्तव में आहत महसूस करते हैं? आप उन घटनाओं पर क्या करते हैं।

इसका जवाब नई पीढ़ी की कंपनियों में मिल सकता है। मैं Google और फेसबुक जैसी कंपनियों में गया हूं और मैं देखता हूं कि यदि आप धार्मिक रूप से एजाइल / स्क्रैम प्रक्रिया का पालन करते हैं, तो आप बेहतर कोड लिख सकते हैं और इसे हर स्प्रिंट में सुधार कर सकते हैं।

How to be better? 

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

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

Answer 17

मैं उन्हें प्रतिक्रिया के लिए धन्यवाद दूंगा, और फिर उन्हें यह बताने के लिए कहूंगा कि इससे क्या बुरा होता है और इसे कैसे सुधारना चाहिए।

यदि आप सहमत हैं कि प्रतिक्रिया देने वाला व्यक्ति समझ में आ रहा है, तो भविष्य में बदलाव करने पर विचार करें। लेकिन याद रखें, सिर्फ इसलिए कि कोई कहता है कि इसका मतलब यह नहीं है कि यह सच है।

क्या आप इसे "गड़बड़" कहे जाने के विशिष्ट उदाहरण दे सकते हैं?

Comments

भावनाओं को कभी-कभी मुश्किल हो सकता है, लेकिन यह निश्चित रूप से मुझे उम्मीद है कि मैं कैसे प्रतिक्रिया दूंगा।

— थॉमस पडरॉन-मैक्कार्थी

Answer 18

पहले किसी ने कहा कि आपका कोड गड़बड़ है बहुत अस्पष्ट और व्यक्तिपरक है। इसका मतलब अलग-अलग लोगों के लिए अलग-अलग हो सकता है। यहाँ पर क्यों; दो अलग-अलग बातें हैं जिन पर विचार किया जाना है।

संरचना

आपके कोड की संरचना भाषा, उद्योग मानकों और कंपनी के मानकों से संचालित होती है। जाहिर है कि अन्य कारक भी हैं।

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

अंदाज

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

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

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

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

अपनी आलोचनाओं को थोड़ा कम न होने दें। आप इससे क्या ले सकते हैं और अगर यह सार्थक और मूल्यवान है तो इसे अपने ज्ञान के भंडार में शामिल करें।

Answer 19

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

केवल बहुत सारे मुद्दे हैं जिन्हें आप अपने स्वयं के कोड में पहचान सकते हैं, क्योंकि यह आपके वर्तमान प्रोग्रामिंग ज्ञान की बाधाओं में उत्पन्न हुआ था।

कोड समीक्षा आवश्यक सीखने का अवसर है क्योंकि यह संभवतया आपको नए ज्ञान के लिए उजागर करता है जो आपके पास कोड पर काम करते समय नहीं था (अन्यथा आप इसका उपयोग करेंगे और कोई गड़बड़ नहीं होगी)।

मुझे लगता है कि नकारात्मक प्रतिक्रिया को संसाधित करने के दो भाग हैं।

1. उठाए गए मुद्दे (नों) की प्रकृति का निर्धारण करें और आपको इससे क्या सीखना चाहिए

जब मैं समीक्षा करता हूं या अपने कोड की समीक्षा करता हूं, तो मैं मोटे तौर पर इस तरह की बाल्टियों में कोड के मुद्दों के बारे में जानकारी सॉर्ट करता हूं:

• कठिन तकनीकी आवश्यकताओं का उल्लंघन करता है
  • सादा गलत (आवश्यकताओं के लिए कार्य या प्रदर्शन नहीं करता है)
  • अन्य परिस्थितियों में विफल रहेगा (पर्यावरण / कॉन्फ़िगरेशन परिवर्तन)
  • पदावनत कार्यक्षमता का उपयोग करता है और भविष्य के भविष्य में टूट जाएगा
• उद्योग के सर्वोत्तम अभ्यास का उल्लंघन करता है, जैसे कि चीजों की कमी
  • विशिष्ट समस्या के लिए सिद्ध दृष्टिकोण का उपयोग करना
  • प्रदर्शन
  • पिछेड़ी संगतता
  • रखरखाव में आसानी
  • कोडिंग शैली
  • प्रलेखन
• कार्यस्थल के सर्वोत्तम अभ्यास का उल्लंघन करता है
  • उद्योग के समान, लेकिन कंपनी / सहकर्मियों के लिए अधिक विशिष्ट और विवरण में उद्योग से भिन्न हो सकते हैं
• व्यक्तिगत विशेषज्ञता के अनुरूप नहीं
  • समीक्षा करने वाले व्यक्ति की राय में किसी तरह से सुधार किया जा सकता है

ध्यान दें कि यह बहुत उद्देश्यपूर्ण चीजों से होता है ("यह हमारे उत्पादन सर्वर पर तैनात होने पर टूट जाएगा") बहुत व्यक्तिपरक चीजों के लिए ("मुझे पसंद नहीं है कि आपने चर कैसे नाम दिया")।

2. यह निर्धारित करें कि कोड में परिवर्तन (यदि कोई हो) समीक्षा के परिणाम के रूप में किया जाएगा

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

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

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

Answer 20

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

मैं इस स्थिति से गुजर चुका हूं और मैं समझ सकता हूं।

Answer 21

टी एल; डॉ

अगर किसी ने आपको बताया कि आपका कोड गड़बड़ है तो आप कैसे प्रतिक्रिया देंगे?

---

मेरा सीधा, "बहुत लंबा नहीं पढ़ा (सभी उत्तर - माफी, मुझे उम्मीद है कि बाद में समय मिलेगा और यदि आवश्यक हो तो इसे संपादित / संशोधित करें") उत्तर / टिप:

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

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

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