हर प्रोग्रामर को क्या पता होना चाहिए?

Question

प्रोग्रामिंग भाषा (ओं) या ऑपरेटिंग सिस्टम (ओं) की परवाह किए बिना या उनके द्वारा विकसित पर्यावरण के लिए, जो हर प्रोग्रामर को पता होना चाहिए?

कुछ पृष्ठभूमि:

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

मैं इस जानकारी से दूसरों के हित और लाभ की अपेक्षा करता हूं।

Answer 1

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

Comments

यह कुछ ऐसा है जो हर इंसान को अपनी नौकरी की परवाह किए बिना करना चाहिए ... (सेक्स, धर्म, संस्कृति, सामाजिक स्थिति ...), क्या आपको नहीं लगता? ;)

अरे हाँ। लेकिन हम प्रोग्रामर (कम से कम मैं करते हैं) में अधिक से अधिक अभिमान होने की प्रवृत्ति होती है :-)

काश मैं तुम्हें दो बार वोट कर सकता।

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

— विनम्र

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

Answer 2

कैसे एक उपयोगकर्ता की तरह सोचने के लिए, और एक तकनीकी geek प्रोग्रामर की तरह नहीं।

Comments

मुझे हमेशा यह विडंबना लगती है कि जिस चीज की हमें कमी है, वह उद्योग में सबसे महत्वपूर्ण कौशल में से एक है: संचार कौशल।

इससे अधिक सहमत नहीं हो सकते। यह # 1 होना चाहिए।

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

आप ऐसा करने के लिए अन्य लोगों को नियुक्त कर सकते हैं, लेकिन यदि आपकी विकास टीम यह समझ सकती है कि कोई उपयोगकर्ता कैसे सोचता है, तो आपके पास चीजों के सही होने से पहले बहुत कम तर्क और पुनरावृत्तियां होंगी। इसके अलावा, अगर कोई डेवलपर किसी उपयोगकर्ता की तरह सोच सकता है, जो जानता है कि वे कौन सी नई सुविधाएँ लेकर आएंगे

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

— Reuben

Answer 3

कब मदद मांगनी है, और कब मदद नहीं मांगनी है।

Comments

सच है। हाल ही में, जवाब मेरे सिर में आ गया है क्योंकि मैं किसी से पूछ रहा था। :(

— केविन्दूब

तो, क्या जवाब है?)

पहले अपने रबर डकी से पूछें। वह आपकी मदद नहीं कर सकते, तो किसी और से पूछना ...

— डीन बल्कि

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

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

Answer 4

अन्य लोगों का कोड कैसे पढ़ें।

Comments

परिशिष्ट: कोड लिखने के लिए अन्य लोग कैसे पढ़ सकते हैं

परिशिष्ट # 2: 6 महीने बाद अपना स्वयं का कोड कैसे पढ़ें

@ नथन कोप: यह बेहतर होना चाहिए "कोड कैसे लिखें ताकि आप इसे 6 महीने बाद खुद पढ़ सकें"।

— डॉक्टर ब्राउन

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

— MPelletier

परिशिष्ट # 3: अपने कोड को 6 मिनट बाद कैसे पढ़ें।

— एमपीएन

Answer 5

संस्करण नियंत्रण प्रणालियों के साथ परिचित। यह हर एक के लिए नहीं है, लेकिन उन सभी पर लागू की जा सकने वाली मूल अवधारणाओं को जाना जाना चाहिए।

Comments

और यह संशोधन नियंत्रण सॉफ्टवेयर नहीं है

— jrhicks 19

मुझे लगता है कि केंद्रीयकृत SCMs (जैसे तोड़फोड़, CVS) और वितरित SCMs (जैसे गिट, व्यापारिक, बाजार) के बीच एक महत्वपूर्ण अंतर है कि यह प्रत्येक में से एक को सीखना महत्वपूर्ण है।

— intuited

Answer 6

यहाँ मेरे 10 बिट्स हैं:

• विनम्र कैसे बनें। हम सब यहां सीखने के लिए हैं। आप दूसरों की तुलना में होशियार हो सकते हैं, लेकिन आपके मुकाबले बहुत अधिक लोग होशियार हैं।
• जानकारी का अध्ययन / उपभोग कैसे करें। मैं आपके बारे में नहीं जानता, लेकिन मैं हमेशा अध्ययन कर रहा हूँ! किताबें, इंटरनेट, जो भी हो!
• एक शब्दकोश क्या है और एक का उपयोग कैसे करें, और कैसे जल्दी से परिवर्णी शब्द पता लगाने के लिए।
• व्यापार के मूल उपकरण क्या हैं और वे क्या करते हैं (IDE, CVS et al)।
• सामान्य शब्दावली जानिए और उनका क्या मतलब है: डिजाइन पैटर्न, प्रयोज्य, परीक्षण (हा!), स्टैक, आदि।
• OOP की समझ हो।
• कम से कम एक भाषा में "सक्षम" बनें, अद्भुत कुछ भी नहीं, बस चर और तरीकों की पहचान करना जानते हैं, आदि यहाँ से आप FAST सीख सकते हैं।
• यह समझें कि लोग अंततः सॉफ्टवेयर का उपयोग करते हैं और उन लोगों को खुश करना चाहते हैं।

Comments

यह एक अष्टकोणीय पद होना चाहिए।

— यहां तक ​​कि Mien

पहले बिट के बारे में .... "इतना विनम्र मत बनो, कि तुम महान नहीं हो"।

— मैग्नस

@ TheOtherScott, अच्छा कैच लोल, लेकिन मैं वास्तव में कह रहा था 2 बिट्स: डी;)

अंक 3 के बारे में: www.acronymfinder.com

— जैस्पर बेकर्स

@ jasper / अंतर्निर्मित: Google में केवल संक्षिप्त नाम लिखें और यह एक या दूसरे को खींच लेगा ... उत्तर आमतौर पर पहले 10 परिणामों में से एक है। अधिक जानकारी क्लिक करके प्राप्त की जा सकती है!

— एमपीएन

Answer 7

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

Comments

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

— इयान रॉबिन्सन

मुझे अपने उत्तर के लिंक को अपने पूर्व टीम के होमपेज के रूप में रखना चाहिए। तुम बिलकुल सही हो।

मुझे लगता है कि आपने कहा "बहुत सारे प्रोग्रामर (और सामान्य लोग)" :-)

Answer 8

कैसे आराम करें। यह उत्पादकता का रहस्य है।

आखिरकार, इच्छाशक्ति और कैफीन पर्याप्त नहीं हैं। यह निरंतर संकुचन जो हम करते हैं वह बहुत हानिकारक है।

यह बड़ा सौदा है।

Comments

संकुचन से आपका क्या मतलब है?

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

— ब्रायन मैकके

@ फिर, उसका अर्थ है अप्रयुक्त मांसपेशियों का संकुचन।

कॉफी और संकुचन की बात करते हुए, क्या आप जानते हैं कि कॉफी मस्तिष्क को रक्त पहुंचाने वाली धमनी को सिकोड़ती है। जिसके कारण मस्तिष्क जागता है। कॉफी इतनी अच्छी बात नहीं है। tl; ड्रिंक पानी पीना

— Reno

Answer 9

बुनियादी डेटा प्रकार और एल्गोरिथ्म सिद्धांत। बिग ओ संकेतन, सरणियाँ, कतारें, आदि जैसी चीजें।

Comments

यदि आप सब करते हैं तो वेब सामग्री प्रबंधन प्रणालियों के लिए खाका तैयार नहीं करता है।

खैर, आजकल मानक एल्गोरिदम पुस्तकालयों / रूपरेखाओं में लागू होते हैं, लेकिन मैं मानता हूं कि कुछ कठिन-एल्गोरिथ्म जैसी सोच उपयोगी है, लेकिन बहुत बार नहीं

सिर्फ इसलिए कि वे पहले से ही लागू हैं इसका मतलब यह नहीं है कि आपको यह समझने की ज़रूरत नहीं है कि कब, क्या उपयोग करना है, जटिलता की गारंटी देता है, आदि एल्गोरिदम के पीछे यह महत्वपूर्ण सामान है।

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

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

Answer 10

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

Comments

+1 ताकि यह 42 :) पर न रहे

— चार्ल्सब

Answer 11

खैर, यहाँ मेरे $ .02 है:

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

Comments

क्या यह आपके .02 डॉलर या .02 सेंट है? जबरदस्त हंसी! :

"अपना कोड लिखें जैसे कि वह व्यक्ति जो इसे बनाए रखने जा रहा है वह एक मनोवैज्ञानिक सीरियल किलर है जो जानता है कि आप कहां रहते हैं।" +1

— बेन

Answer 12

आप किसी उत्पाद में गुणवत्ता का परीक्षण नहीं कर सकते।

Comments

इस प्रकार "गुणवत्ता आश्वासन" पेशेवरों का गलत नाम है।

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

— टॉल जेफ़

हाल ही में सामना किया गया - और अटक गया: "परीक्षण का परिणाम गुणवत्ता नहीं है, लेकिन ज्ञान है"।

— पीटरचेन

richdiet: SQA विशेषज्ञ जेम्स बाख का मानना ​​है कि SQA / QA में "A" को "सहायता" के लिए खड़ा होना चाहिए। मैं उनकी राय और आपके कथन से दृढ़ता से सहमत हूं।

Answer 13

प्रत्येक प्रोग्रामर को डिज़ाइन पैटर्न को समझना चाहिए ।

Comments

मुझे लगता है कि वे भी एक समझ की जरूरत है कि सब कुछ नहीं दिया जा सकता है एक डिजाइन पैटर्न में सींग।

— दोपहर

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

— अली

डिजाइन पैटर्न "प्रोग्रामर" नहीं, desingers के लिए हैं - एक प्रोग्रामर को यह जानना होगा कि जब वह "डिजाइनर" बन जाता है

दो तरह के लोग होते हैं .. जो लोग कोडिंग का आनंद लेते हैं और वे लोग जो कोडिंग के बारे में बात करना पसंद करते हैं। डिजाइन पैटर्न दूसरे समूह के लिए बहुत जरूरी है ..

— ब्योर्न रिपेन सेप

इस तरह के पैटर्न भाषाओं की सीमाओं को दूर करने का एक तरीका है। एक प्रोग्रामर को उन्हें केवल इसलिए समझना चाहिए क्योंकि उन्हें समझना चाहिए और अपनी भाषाओं की कमजोरियों को दूर करने में सक्षम होना चाहिए।

Answer 14

मुझे इस पर थोड़ी देर हो गई है, लेकिन मैं एद्सर्ज दिक्स्ट्रा द्वारा निर्धारित ज्ञान के साथ जाऊंगा:

एक गणितीय झुकाव के अलावा, किसी की मूल जीभ की असाधारण अच्छी महारत एक सक्षम प्रोग्रामर की सबसे महत्वपूर्ण संपत्ति है।

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

Comments

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

@cheduardo, ऐसा इसलिए है क्योंकि एक बार जब आप किसी प्रोग्राम को संकलित करते हैं या चलाते हैं, तो ज्यादातर भाषाओं में, आपको किसी भी वर्तनी, व्याकरण या विराम चिह्नों के बारे में बताया जाएगा, जिसे तब आसानी से ठीक किया जा सकता है। तार्किक त्रुटियों के लिए ऐसा नहीं है।

— इंशाल्लाह

@Inshallah: जब तक आप कुछ काम नहीं करते हैं if (BlowUpTheSystem = 1)। दी गई, उचित इकाई परीक्षण, आपको केवल समय बचाने की संभावना है। लेकिन तब समय बहुत महत्वपूर्ण है।

— intuited

सहमत .. हम्म ... "देशी जीभ" का हिस्सा, हममें से कुछ [दुर्भाग्य से?] हमारे गैर-देशी जीभ में बेहतर / स्पष्ट संवाद करते हैं।

Answer 15

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

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

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

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

Answer 16

सी। में कैसे प्रोग्राम करें

Comments

Haha। जब आपको उसकी आवश्यकता हो तो जेफ कहां है? ;)

— केविन फेयरचाइल्ड

विधानसभा भाषा का उल्लेख नहीं।

— फेरुशियो

एक्स।

— अली

इसे पेंच ... बाइनरी

जेफ !!!! लोग आपकी साइट पर बात कर रहे हैं: P

— आंद्रेई रिनिया

Answer 17

जिस दिन आप सीखना बंद कर देते हैं वह दिन ऐसा होना चाहिए जिस दिन आप प्रोग्रामर नहीं रह जाते हैं।

Comments

अगर मेरी एक इच्छा होती, तो यह होगा कि सांता मेरे पिता थे।

क्योंकि संता ...?

जिस दिन आप सीखना बंद कर देते हैं वह दिन आपको मरना चाहिए। :) +1 वैसे भी

— ShdNx

इसलिए हमेशा जीने के लिए आपको हमेशा सीखते रहना चाहिए? अब एक विचार है कि मैं समर्थन कर सकता हूं!

— कनाडा की

Answer 18

यूनिट परीक्षण और डिबगिंग।

Comments

पहला दूसरे की आवश्यकता को हटा देता है। ;-)

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

— ज़ैन लिंक्स

इस पर जोर नहीं दे सकते।

— fastcodejava

Answer 19

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

यह पहले उल्लेख किया गया था, लेकिन मुझे लगता है कि यह इसके जवाब का हकदार है।

Comments

मैं अधिक से अधिक इसके लिए उपयोग करता हूं, और मैं यहां और वहां टुकड़े उठाता हूं, लेकिन मैं अभी भी शौकिया नहीं हूं।

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

— किब्बी

कुछ लोग, जब एक समस्या का सामना करते हैं, तो सोचते हैं "मुझे पता है, मैं नियमित अभिव्यक्ति का उपयोग करूंगा।" अब उन्हें दो समस्याएं हैं। - "जेमी ज़्विन्स्की ": jwz.livejournal.com , comp.lang.emacs में

— ब्योर्न रेपेने

मूल रूप से उनके चारों ओर निर्मित एक संपादक का उपयोग करना बुरा नटखट किरकिरा सीखने का एक अच्छा तरीका है। मेरा अनुभव vim -which के साथ है, जो वास्तव में मानक PCREs के बराबर-तुलनीय है, लेकिन मुझे लगता है कि समान नियम emacs की दुनिया में लागू होते हैं।

— intuited

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

— डोनाल्ड फेलो

Answer 20

कोई नहीं सॉफ्टवेयर का उपयोग करना चाहता है। वे समस्याओं का हल चाहते हैं।

Comments

ठीक ठीक। जब मैंने सुना कि डेवलपर्स एक अंतिम उपयोगकर्ता को डेटाबेस के बारे में समझाने का प्रयास कर रहे हैं, तो उनके सवाल के जवाब के रूप में कि कुछ क्यों नहीं किया जा सकता है, मैं क्रिंग करता हूं। उन्हें यह जानने की जरूरत नहीं है कि हम कैसे सामान बनाते हैं। वे चाहते हैं कि यह काम करे। और यही तरीका होना चाहिए।

— केविन फेयरचाइल्ड

मुझे यह विश्वास करना पसंद है कि कोई ऐसा सॉफ्टवेयर लिख सकता है जिसका उपयोग करने में लोगों को खुशी मिले।

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

— ब्लूब

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

Answer 21

कॉफी और IntelliSense कभी भी आपके सबसे अच्छे दोस्त हैं।

Comments

काश मैं इसे 1 से अधिक उत्थान दे पाता!

— दीना

मैं और अधिक कॉफी की उम्मीद है !!!! n_n

मुझे लगता है कि मैं इससे अधिक सहमत हूं तो एसओ पर कोई अन्य बात।

— Unwwntech

मैं व्यावहारिक रूप से कभी भी कॉफी नहीं पीता, जब तक कि मुझे एक्स घंटे में एक परियोजना खत्म करने की आवश्यकता न हो, जब: इस्तेमाल किए गए घंटों की संख्या + एक्स> 8 एक दिन के लिए।

— ब्लूब

कॉफी आपको कोई ऊर्जा नहीं देती है। यह सिर्फ आपके आंतरिक भंडार से कुछ निचोड़ता है। यह बुरा / अस्वास्थ्यकर है।

— आंद्रेई रिनिया

Answer 22

किसी बड़ी जटिल वस्तु का अवलोकन कैसे करें और इसे छोटी सरल वस्तुओं में विघटित करें जो फिर से एक साथ रखने पर समान कार्य को पूरा करती हैं।

Answer 23

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

इसे भविष्य के प्रमाण और विस्तार योग्य बनाएं - आपको कभी नहीं पता होगा कि आप इसे कुछ वर्षों में विस्तारित करना चाहते हैं और यह महसूस करते हैं कि बुरी तरह से बनाए गए कोड को फिर से कोड करने में कितना प्रयास लगेगा।

Comments

यह भी सामान्यीकृत है। कुछ व्यावहारिकता भी अच्छी है।

— mafu

Answer 24

यह कि प्रोग्रामर को सब कुछ पता नहीं है और उसे हमेशा नई भाषाओं / तकनीकों आदि को सीखने की कोशिश करनी चाहिए।

Answer 25

अच्छा यूआई डिजाइन और संचार (उर्फ ग्राफिक) डिजाइन की मूल बातें ।

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

एक अनुशंसित पुस्तक रॉबिन विलियम्स द्वारा गैर-डिज़ाइनर की डिज़ाइन बुक है

यहाँ जोएल स्पोलस्की इसके बारे में क्या कहते हैं :

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

Comments

मैं दूसरी बार 'अतिरिक्त रोजमर्रा की चीजों के डिजाइन' के साथ आता हूँ। amazon.com/Design-Everyday-Things-Donald-Norman/dp/038526774646

— Stimul8d

Answer 26

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

Comments

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

Answer 27

संस्करण नियंत्रण। और मेरी गर्ल फ्रेंड को उद्धृत करने के लिए: "मैं केवल व्यंजन नहीं करना चाहता, मैं चाहता हूं कि आप इसे पसंद करें !"

Answer 28

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

इससे प्रभावित होने वाले विषयों से संबंधित यहाँ कई प्रश्न हैं ।

Answer 29

मेरे सर के ऊपर से चला गया:

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

2. किसी भी समय आप अपने बारे में अनुमान लगाते हैं कि कुछ कैसे काम करना चाहिए, आप इसे गलत कर रहे हैं। टेलीपैथिक होना आपका काम नहीं है।

3. आपको कल्पना देने वाला व्यक्ति शायद ही कभी सब कुछ जानता है जो वह चाहता है जब तक आप इसे बाहर नहीं निकालते।

4. एक महान प्रोग्रामर होने के आधे से अधिक इंसानों के साथ व्यवहार करने से आता है। अपनी टीम के साथ बातचीत करना, अपने प्रबंधक का प्रबंधन करना, और अंतिम उपयोगकर्ता की चालाकी करना काम का आधा हिस्सा है।

5. अच्छा कोड लोगों द्वारा पढ़ा जाना लिखा है जितना कि आपके कंपाइलर द्वारा पढ़ा जाना है।

6. सबसे अच्छा अभ्यास और व्यावहारिक वास्तविकता प्रोग्रामर के विचार से अधिक संघर्ष में होगा, लेकिन प्रबंधक की तुलना में कम है। जब वे संघर्ष में दिखाई देते हैं, तो यह आपके ऊपर निर्भर होता है कि वे संघर्ष को समझें और व्यावहारिक को दें। सूक्ष्म और चतुर समाधान केवल बदसूरत से बेहतर है, अगर यह लंबे समय में अधिक लागत प्रभावी है, तो एक क्रूर।

7. महान उपकरण महान प्रोग्रामर नहीं बना सकते हैं, लेकिन खराब उपकरण हमें समान रूप से भयानक बनाते हैं।

8. कभी भी एक तकनीक पर ध्यान न दें, लेकिन हमेशा सर्वश्रेष्ठ विकल्प की तलाश करें।

9. जितनी अधिक भाषाएं आप जानते हैं, आप उतने ही बेहतर होंगे, जितना आप उपयोग कर रहे हैं।

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

Comments

नंबर 10 ने मुझे हंसाया। तो कई बार मैं काम पर एक समस्या पर काम कर रहा हूँ, लेकिन यह केवल 10:00 बजे बिस्तर पर है कि मैं अंततः जवाब के साथ आता हूं!

Answer 30

अन्य लोगों के कोड को पढ़ने से आपका दिमाग खराब नहीं होगा, बल्कि यह पता लगाना चाहिए कि आपने ऐसा क्यों नहीं किया है (यदि बेहतर है या नहीं तो यह एक और सवाल है)।

यह आपको प्रोग्रामिंग gedankenexperiment देता है , और कभी-कभी आप किसी को किसी तरह बेहतर तरीके से लागू करते हुए पाते हैं! बेहतर तरीके से पसंद है।

यह उत्तर स्वाभाविक रूप से आपके स्वयं के कोड को पढ़ने के लिए फैलता है, इस प्रकार यह संस्करण नियंत्रण और डीआईएफएफ का उपयोग करने के लिए फैलता है, और इस प्रकार 42 तक।