बिना शर्मिंदा हुए एक ओपन सोर्स प्रोजेक्ट जारी करना [बंद]


51

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

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

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

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


17
एक मंच पर कोड जारी करने और देखभाल करने वालों के लिए उपलब्ध स्रोत के साथ एक परियोजना जारी करने के बीच एक अंतर है। यहां तक ​​कि कई उपयोगकर्ताओं और संभावित डेवलपर्स के साथ बड़े ओपन सोर्स प्रोजेक्ट के लिए कोड को देखते हुए, "मुझे लगता है कि आपके कोड में एक्स और वाई की खामियां हैं" प्रकार की प्रतिक्रियाएं दुर्लभ लगती हैं।

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

3
ओपन सोर्सिंग के बारे में अच्छी बात यह है कि, अगर लोग शिकायत करते हैं, तो आप हमेशा उन्हें सिर्फ आपके लिए मुद्दों को ठीक करने के लिए कह सकते हैं।
ब्लूबेरीफील्ड्स

4
यदि आपके पास संदेह के विशिष्ट क्षेत्र हैं, तो उन्हें codereview.stackexchange.com पर उठाएं
पीडीआर

12
BTW अगर शर्मिंदगी एक मुद्दा था, तो हमारे पास कभी भी Wordpress या Joomla जैसी परियोजनाएं नहीं थीं ... आधे से अधिक ब्लॉग WP पर हैं, कोई भी कोडबेस की गुणवत्ता की परवाह नहीं करता है ...
yannis

जवाबों:


35

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

यदि यह नियमित मनुष्यों के लिए एक आवेदन है, तो वे शायद केवल परिणामों की परवाह करेंगे।


3
+1 और महत्वपूर्ण डेवलपर्स वास्तव में आपको एक पैच भेज सकते हैं! दुनिया के लिए अपने ज्ञान और प्रयासों को खोलने के लिए यह हमेशा सम्मानजनक है :)
यति सगड़े

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

+1 - धन्यवाद। परियोजना डेवलपर्स के लिए है, लेकिन आप परिणामों के बारे में एक अच्छी बात करते हैं।
आशातीत

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

25

आपके कोड में समस्याएं हैं। इसलिए मेरा करें। इस सवाल का जवाब कोई और दे रहा है? उनके कोड में भी समस्याएं हैं।

जब तक कि यह न कहे, 10 लाइनें या उससे कम, यह त्रुटिपूर्ण है। शायद दुखद है।

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

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

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


24

अंगूठे के सामान्य नियम के रूप में, खुले खट्टे कार्यक्रमों में तीन लोगों के समूह होते हैं जो स्रोत कोड को देखते हैं।

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

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

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


5

मुझे वास्तव में इस प्रश्न के पीछे मनोविज्ञान नहीं मिला है ... अपने आप से पूछने के लिए एक बेहतर सवाल "मुझे इस सॉफ़्टवेयर को छोड़ कर क्या खोना होगा"

यहां तक ​​कि अगर आपका प्रोजेक्ट कोड की गंध से भरा है, तो क्या आपको कुछ भी खोना है?

यहां तक ​​कि अगर कोड भयानक है और कोई आपके पास लौ-मेल लिखने के लिए समय लेता है, तो अनुमान लगाएं कि उसने क्या किया है, उसने संभवतः आपके सॉफ़्टवेयर का उपयोग किया है ताकि वह इसमें कुछ बदलाव कर सके और इसे बेहतर बना सके।

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

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

मैं किसी ऐसे व्यक्ति के साथ काम करूँगा जो कुछ करने के लिए तैयार है, अपनी गलतियों को स्वीकार करें, उन्हें ठीक करें और किसी ऐसे व्यक्ति की तुलना में आगे बढ़ते रहें जो कुछ भी करने को तैयार नहीं है।

यदि आप वास्तव में अपने नाम के तहत सॉफ़्टवेयर जारी करने में सहज नहीं हैं, तो इसे एक उपनाम के तहत जारी करें। अगर यह अपने खुद के रूप में दावा करने में सफल होता है, तो अपना उपनाम न बदलें :)


अंतिम वाक्य के लिए +1, संगीत उद्योग के लोग हर समय अपने "प्रायोगिक" एल्बमों के साथ करते हैं :)
मत्तीडेवी

4

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


3

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

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

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


2

मैं दृढ़ता से सहमत हूं कि अन्य पोस्टरों ने क्या कहा है: भले ही आपका कोड भद्दा हो और उच्च गुणवत्ता वाला न हो - ज्यादातर लोग बस परवाह नहीं करते हैं। हर कोई जो एक समय या किसी अन्य में OpenSource कोड में डुबकी लगाता है, उसने खुद को "WTF यहाँ हुआ" सोचा होगा।

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

तो इस बात की चिंता मत करो - लोग अपने ओपन टाइम के प्रोजेक्ट्स के कोड पर नाइटपैकिंग की तुलना में अपने खाली समय में बहुत कुछ कर सकते हैं।


2

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

मैंने यह भी देखा है कि कोई भी सक्षम इंजीनियर किसी और के कोड को फाड़ सकता है।

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


2

लिंक्डइन के सह-संस्थापक रीड हॉफमैन के कुछ बुद्धिमान शब्द:

"यदि आप अपनी पहली उत्पाद रिलीज़ से शर्मिंदा नहीं हैं, तो आपने बहुत देर कर दी है।"

"सदस्यों के साथ जुड़ाव प्राप्त करना और यह देखना कि वास्तव में क्या महत्वपूर्ण है, पूरी तरह से महत्वपूर्ण है ... इसलिए आप जितनी जल्दी हो सके न्यूनतम व्यवहार्य उत्पाद निकाल लेते हैं।"

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


1

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


2
एक भगवान प्रोग्रामर क्या है?
उम्मीद है कि

1
@Hopeful। आईआईटी बॉम्बे यूनिवर्सिटी में एक प्रोफेसर हैं। अफवाहें हैं कि यह आदमी कार्यक्रम लिखता है, इसे संकलित करता है और इसे चलाता है। वहाँ कोई मंच recompiling या डिबगिंग के रूप में जाना जाता है। यह गॉड प्रोग्रामर है।
मनोज आर

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

1

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

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

मुझे लगता है कि मेरी परियोजनाओं के लिए अधिकांश रचनात्मक आलोचना / सुझाव सार्वजनिक रूप से प्रसारित करने के बजाय निजी तौर पर भेजे जाते हैं, और तब भी आपको टिप्पणियों की बाढ़ प्राप्त होने की संभावना नहीं होगी। इसलिए, मैं सिर्फ इसके लिए जाने की सलाह देता हूं!

सौभाग्य।


1

स्वयं के अध्ययन में कुछ भी गलत नहीं है। आप अलग-थलग नहीं हो सकते और सहकर्मी कोड समीक्षा की मदद ले सकते हैं।

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

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

मुझे विश्वास नहीं है कि आप कुछ गलतियाँ किए बिना सीख सकते हैं, खासकर अगर यह ऐसा कुछ है जो वास्तविक अनुशासन और प्रयास लेता है। अगर यह आसान होता, तो हर कोई इसे कर रहा होता। बस स्थापित सर्वोत्तम प्रथाओं का उपयोग करते हुए, गलतियों को मामूली तक सीमित करने का प्रयास करें। मुझे एहसास है कि हमेशा संभव नहीं है!

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

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