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

कुछ लोग कह सकते हैं कि किसी एप्लिकेशन में कोड की कम पंक्तियां, पढ़ने में आसान है। यह केवल आंशिक रूप से सच है। यहाँ पठनीय कोड के लिए मेरे मैट्रिक्स हैं:

• कोड सुसंगत होना चाहिए
  
• कोड जानकारीपूर्ण होना चाहिए।
  
• कोड को अच्छी तरह से प्रलेखित किया जाना चाहिए।
  
• कोड को स्थिर आधुनिक कार्यों का उपयोग करना चाहिए।
  
• कोड को बहुत जटिल नहीं होना चाहिए
  
• कोड अक्षम नहीं होना चाहिए (जानबूझकर धीमा कोड न लिखें)

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

जरूरी नहीं कि भाषाएं "अच्छी" या "बुरी" हों


Php को छोड़कर, बेशक (एक मजाक)। स्रोत

मैं देखता हूं कि लोग हर समय ऐसी बातें कहते हैं:

• C, प्रदर्शन के कारण X से बेहतर है
  
• संक्षिप्तता के कारण पायथन एक्स से बेहतर है
  
• एलियंस की वजह से Haskell X से बेहतर है

यह विचार कि भाषा की तुलना एक वाक्य से कम की जा सकती है, लगभग आक्रामक है। ये भाषाएं हैं, पोकेमॉन नहीं।

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

(जाहिर है, हथौड़ा बेहतर है)

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

यहाँ मुख्य पहलू हैं, जो, मेरी राय में, भाषा की पसंद (विशिष्ट मैट्रिक्स के बिना) को प्रभावित करना चाहिए:

• उपलब्ध ऑनलाइन संसाधनों का घनत्व (स्टैकओवरफ़्लो घनत्व)
  
• विकास की गति
  
• त्रुटि पूर्वसूचना
  
• पैकेज पारिस्थितिकी तंत्र की गुणवत्ता और कवरेज (हाँ, npm, गुणवत्ता के बारे में बात कर रही है)
  
• प्रदर्शन (अधिक अंक)
  
• रोजगार के अवसर (क्षमा करें, COBOL)

आपके प्रभाव से परे कुछ महत्वपूर्ण कारक। यदि आप डेटा विज्ञान के क्षेत्र में काम करते हैं, तो आपको वास्तव में पायथन, आर या स्काला (संभवतः जावा) का उपयोग करने की आवश्यकता है। यदि यह एक शौक परियोजना है, तो आपको जो पसंद है उसका उपयोग करें। मेरा केवल एक निर्विवाद शासन है। मैं भाषाओं का उपयोग करने से इनकार करता हूं यदि इस भाषा के साथ अधिकांश संभावित समस्याएं पहले से ही StackOverflow पर हल नहीं हुई हैं। ऐसा नहीं है कि मैं उन्हें हल नहीं कर सकता, यह समय के लायक नहीं है।

किसी और का कोड पढ़ना कठिन है

किसी और का कोड पढ़ना मुश्किल है। रॉबर्ट के। मार्टिन शुद्ध संहिता में इस बारे में बात करते हैं: “वास्तव में, कोड को पढ़ने और लिखने का समय 10 से 1 से अधिक है। जब हम नया कोड लिखने की कोशिश करते हैं तो हम लगातार पुराने कोड पढ़ते हैं। ... [इसलिए] जो इसके पढ़ने को सरल करता है, वही इसके लेखन को भी सरल बनाता है। "

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

किसी और के कोड की समीक्षा से आपके कौशल में काफी सुधार होगा। पिछले दो वर्षों में, मैंने गितुब पर पूल अनुरोधों के लिए काफी समीक्षा की है। प्रत्येक नए के साथ, मैं किसी और के कोड को पढ़ने में थोड़ा अधिक आत्मविश्वास महसूस करता हूं। GitHub पूल अनुरोध निम्नलिखित कारणों से विशेष रूप से उपयोगी हैं:

• यहां आप किसी भी समय एक समीक्षा कर सकते हैं, बस एक ओपन सोर्स प्रोजेक्ट ढूंढें जिसमें आप योगदान करना चाहते हैं।
  
• एक सीमित संदर्भ (एकल फ़ंक्शन या बग) में पढ़ना।
  
• इसके लिए विस्तार पर ध्यान देने की आवश्यकता है, जो आपको प्रत्येक पंक्ति की सराहना करेगा।

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

आप कभी भी "परिपूर्ण" कोड नहीं लिखेंगे

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

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

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

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

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

एक प्रोग्रामर के काम का मतलब प्रति दिन 8 घंटे की प्रोग्रामिंग नहीं है

यह एक बहुत ही सामान्य प्रश्न है, लेकिन लोग कभी भी स्पष्ट जवाब नहीं देते हैं। औसत डेवलपर या "उत्कृष्ट" डेवलपर हर दिन कोड लिखने में कितना खर्च करता है?

दिन में चार घंटे से बहुत कम कोड

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

प्रोटोकॉल के लिए, यहां तक ​​कि कंपनी भी आपके लिए लाभदायक नहीं है कि आप दिन में 8 घंटे सक्रिय रूप से कार्यक्रम कर सकें। आपका बॉस सोच सकता है कि ऐसा है, लेकिन यह अदूरदर्शी है और वह दीर्घकालिक परिणामों की अनदेखी करता है, क्योंकि यह उत्पादकता और मानसिक स्वास्थ्य को प्रभावित करता है।

केवल स्पष्टता के लिए, मेरा सुझाव है कि आप दिन में केवल चार घंटे काम न करें। शेष चार घंटे आमतौर पर सबसे अधिक खर्च किए जाते हैं:

• अनुसंधान, कार्य से संबंधित और संबंधित नहीं
  
• सहकर्मियों के साथ आपके काम की चर्चा
  
• ऐसे सहयोगियों की मदद करें जिन्हें अपने काम से समस्या है
  
• भविष्य के काम की योजना
  
• कोड की जाँच
  
• बैठकों

मैं दिन में नियमित रूप से ब्रेक लेने और खेल (कम से कम लंबे समय तक) नहीं खेलने की जोरदार सलाह देता हूं। मानसिक थकान से निपटने के लिए व्यायाम के लाभों को अच्छी तरह से प्रलेखित किया गया है। मैंने व्यक्तिगत रूप से पाया कि यदि एकाग्रता की समस्या है तो व्यायाम विशेष रूप से सहायक है।

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