2009-09-18 7 views
8

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

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

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

मेरा प्रश्न है:

एक प्रोग्रामर जो एक भाषा में लिखते हैं प्रभावी रूप से किसी अन्य भाषा वे का ज्ञान नहीं है की एक सहायक/रचनात्मक कोड की समीक्षा प्रदर्शन कर सकते हैं?

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

+2

यह स्पष्ट नहीं है कि आपका मालिक समीक्षाकर्ता या नफरत करता है या नहीं उसका कोड समीक्षा कर रहा है। यदि यह पूर्व है, तो संभावना अधिक है कि आपको उससे उचित समीक्षा नहीं मिलेगी, इससे कोई फर्क नहीं पड़ता कि वह भाषा में कितना कुशल है। – Constantin

उत्तर

17

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

वह आपको सॉफ्टवेयर इंजीनियरिंग पर अच्छी सामान्य सलाह देने में सक्षम हो सकता है, लेकिन मुझे नहीं लगता कि वास्तव में कोड समीक्षा है।

+0

बॉस कोड समीक्षा पर जोर देने का एक कारण हो सकता है ... –

+0

व्यावहारिक रूप से किसी भी व्यवहार के लिए एक कारण हो सकता है। ब्योरे के बिना यह कहना असंभव है कि क्या कारण कोई समझ में आता है। "कोड गंध" के लिए –

0

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

2

क्या एक प्रोग्रामर जो एक भाषा में लिखता है प्रभावी ढंग से एक अन्य भाषा की सहायक/रचनात्मक कोड समीक्षा कर सकता है जिसके बारे में उन्हें कोई जानकारी नहीं है?

मुझे ऐसा लगता है, लेकिन अनुमान है कि यह प्रोग्रामर पर निर्भर करता है।

  • क्या कार्यक्षमता आप को लागू किया है:

    वह कर सकते हैं जैसे सवाल पूछता है?

  • इस सॉफ्टवेयर के कौन से हिस्से कार्यक्षमता के कुछ हिस्सों को लागू करते हैं?
  • आपने इसका परीक्षण कैसे किया है?

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

हालांकि, अगर "वह हमेशा कोड समीक्षा से नफरत करता है", तो यह एक लक्षण है कि वह/आप इसे सही नहीं कर रहे हैं: और हो सकता है कि उसे कोड समीक्षा को और अधिक सफल बनाने के बारे में और जानें।

13

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

+0

+1 (फाउलर द्वारा रिफैक्टरिंग देखें) और स्कैला। यदि कार्य 1000 लाइनों के लिए चला जाता है, तो भाषा के बावजूद यह एक खराब कोड है। –

0

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

2

मैं इसे कोड के रूप में चर्चा करूंगा कोड निरीक्षण के समानार्थी होने की समीक्षा करें: कोड पर बैठे कमरे में बैठे डेवलपर और समीक्षक। उन बिट्स को अनदेखा करें जो आपकी स्थिति से प्रासंगिक नहीं हैं।

कोड कोड की आलोचना के रूप में कोड कोड को नहीं सोचने का प्रयास करें। अगर ऐसा हो जाता है, तो वे इसे गलत कर रहे हैं।

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

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

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

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

0

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

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

1

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

4

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

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

ये सभी "सामान्य अभ्यास" चीजें हैं, लेकिन लंबे समय तक भाषा विशिष्ट वाक्यविन्यास सामग्री से शायद अधिक महत्वपूर्ण हैं।

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

0

के रूप में मैं देखें कि यह कैसे काम कर सकता के लिए विभिन्न विकल्पों के एक जोड़े मैं हाँ कहेंगे:

  1. मालिक अपने दम पर कोड पढ़ता है और कुछ देखने के लिए कैसे चीजें आम तौर पर काम के आसपास खेल रहे हैं और करता है फिर आप विभिन्न हिस्सों के माध्यम से चलने के लिए वापस आते हैं जिन्हें आवेदन के कुछ हिस्सों में सुधार के लिए बदला जा सकता है।

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

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

0

शायद आप कोड समीक्षा से एक डिज़ाइन समीक्षा अलग कर सकते हैं।

एक अनुभवी डेवलपर प्रभावी ढंग से भाग लेने और किसी भी आवेदन की डिज़ाइन समीक्षा में मूल्य जोड़ने में सक्षम होना चाहिए।

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

0

क्या एक प्रोग्रामर जो एक भाषा में लिखता है प्रभावी ढंग से एक अन्य भाषा की सहायक/रचनात्मक कोड समीक्षा कर सकता है जिसके बारे में उन्हें कोई जानकारी नहीं है?

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

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

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

टिप्पणियों की समीक्षा करें -

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

1

"लेकिन यह एक आवश्यक बुराई" पहले से ही एक टिपऑफ है कि आप और आपके मालिक और संगठन के कुछ मुद्दे हैं।

मुझे संदेह है कि आपको कोड समीक्षाओं से लाभ होगा - क्योंकि कोड समीक्षा खराब नहीं है या क्योंकि लोग भाषा के साथ कुशल नहीं हैं, कोड की समीक्षा कर रहे हैं, लेकिन क्योंकि आपकी संस्कृति बस ऐसा नहीं होने देगी।

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

बहुत कम प्रभाव, अनौपचारिक समीक्षाओं से शुरू करें।

शुभकामनाएं

1

एह, क्या आपके पास कोई विकल्प है? मैंने सोचा कि वह आपका बॉस था?

(दूसरी दुनिया में, उसे लिप्त - आप अंततः वैसे भी :) जाएगा)

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

0

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

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

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

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

और हाँ एक अनुभवी कोडर आमतौर पर कोड समीक्षा में इंगित करने के लिए चीजें ढूंढ सकता है भले ही यह उसकी सामान्य भाषा न हो।

0

वास्तव में यह कैसे तैयार किया जाता है इस पर निर्भर करता है। इसे फ्रेम करने के बहुत सारे बुरे तरीके, जैसे कि आप दुर्व्यवहार कर रहे हैं।

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

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

दूसरों की तरह कहता है, ऐसा लगता है कि आपके पास बहुत पसंद नहीं है, और यह वास्तव में उपयोगी हो सकता है।

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

सभी समय को एक अलग नज़रिए के साथ सब कुछ ले यह मेरे लिए होता है:

  • मैं समीक्षक जो स्पष्ट रूप से कम से कम सीखने की परवाह नहीं है करने के लिए सभी बुनियादी बातों की व्याख्या करने के लिए है न्यूनतम
  • समीक्षक केवल तर्क के कुछ भागों grasps जब तक कि यह एक बहुत ही सरल फ़ाइल
  • मैं trivialities के बारे में चर्चा करने के लिए
  • मैं मिलता है है है कुछ उपयोगी एक समय में एक बार टिप्पणी की तरह आप इसे एक निरंतर यहाँ

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

    एक गाइड है जो वास्तव में कोड लिखने नहीं है
  • एक आदमी है कि में एक नियमित आधार पर कार्यक्रम नहीं है
  • :

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

  • एक प्रबंधक या कोई गैर तकनीकी व्यक्ति जो मानता है कि वह तकनीक जानता है, सिर्फ इसलिए कि वह लेख पढ़ता है।
  • एक औरत, जो उसे याद कर सकती है :-)। हां, मुझे पता है कि कुछ क्या कहने जा रहे हैं लेकिन stil ... :-) स्पष्ट कारणों से प्रोग्रामिंग करने वाली कई महिलाएं नहीं हैं :-)
संबंधित मुद्दे