25 गलतियों एक नौसिखिया प्रोग्रामर

उन्हें पहचानना सीखें। इनसे बचने के लिए आदतें विकसित करें।

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

अनुवादक से

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

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

1) बिना योजना के प्रोग्रामिंग
2) अत्यधिक योजना
3) कोड गुणवत्ता के महत्व को कम आंकना
4) पहले फैसले को समझें
5) पीछे न हटें
6) गूगल मत करो
7) एनकैप्सुलेशन का उपयोग न करें
8) अज्ञात की योजना बनाना
9) अनुचित डेटा संरचनाओं का उपयोग करना
10) कोड बिगड़ना
११) स्पष्ट बातों पर टिप्पणी करना
१२) टेस्ट न लिखें
13) सोचने के लिए, अगर कुछ काम करता है, तो यह सही तरीके से किया गया है
14) मौजूदा कोड पर सवाल न करें
१५) सर्वोत्तम प्रथाओं के साथ जुनून
16) प्रदर्शन जुनून
17) अंतिम उपयोगकर्ता पर ध्यान केंद्रित न करें
18) सही उपकरण न चुनें
19) यह गलतफहमी कि कोड समस्याएं डेटा समस्याएँ पैदा करती हैं
20) पहिये का आविष्कार
21) कोड निरीक्षण के लिए अनुचित रवैया
22) संस्करण नियंत्रण प्रणालियों का उपयोग नहीं करना
23) साझा राज्य का दुरुपयोग
24) त्रुटियों के लिए गलत रवैया
25) आराम मत करो

1) बिना योजना के प्रोग्रामिंग

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

अच्छा कोड निम्नलिखित चरणों से गुजरना चाहिए:

विचार। अध्ययन। योजना। लेखन। की जाँच करें। बदलें।

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

शुरुआती लोग बिना सोचे-समझे कोड करने लगते हैं। यह छोटे स्टैंडअलोन अनुप्रयोगों पर काम कर सकता है। लेकिन बड़े पैमाने पर एक त्रासदी में बदल सकता है।

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

“यदि आप नाराज हैं, तो बोलने से पहले 10 तक गिनें। यदि आप बहुत क्रोधित हैं, तो यह 100 तक है ”। (थॉमस जेफरसन)

हमारे मामले के लिए, यह निम्नानुसार किया जा सकता है:

“कोड की जाँच करते समय, 1 पंक्ति को फिर से लिखने से पहले 10 तक गिनें। अगर इस कोड के लिए कोई परीक्षण नहीं हैं, तो 100 तक ”।

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

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

2) अत्यधिक योजना

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

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

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

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

3) कोड गुणवत्ता के महत्व को कम आंकना

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

प्रोग्राम को उन घटकों के रूप में देखें जो कोड के माध्यम से संवाद करते हैं। खराब कोड खराब संचार है।

"अपना कोड इस तरह लिखें जैसे वह एक आक्रामक मनोरोगी के साथ होगा जो जानता है कि आप कहाँ रहते हैं।" (जॉन वुड्स)

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

tHIS is
  WAY MORE important
than
         you think

. 80 . (ESLint, Prettier js).

. , . 10 – .

. . .

, , . , , , .

“ : ”. ( )

. - 12, :

const monthsInYear = 12; 

. , .

. . , . . – , .

“ , , ”. ( )

. , , . , . .

4)

, , , . , , , . , , .

, , . , , .

“ : 1) , , , ; 2) , ”. ( )

5)

– . , . “ ” , . . – . , . Git , .

, . .

6)

, , - . , .

. , , . , , .

– . , .

, :

“, , – ”.

7)

, . .

, . , . , . , .

. , , , .

. – . , – .

, , . , “ ”. .

, (High Cohesion and Low Coupling). , , – .

8)

, : “ …” , . .

, . , - .

, . , , .

“ — ”. ( )

9)

. – . .

, , .

: “ !”. .

?

– .

:

[{id: 1, title: "entry1"}, {id: 2, title:"entry2"}, .... ]

:

{ 1: {id: 1, title: "entry1"}, 2: {id: 2, title:"entry2"}, ....}

, , . , . , push, pop, shift, unshift, , .

, , . , , .

?

, . , 2 .

. , .

10)

, . - . . . . — , -. , , , , . , .

, :

, , . , , . , .

, :


, , : “ ?” “”.

if , , . – : ?

if:

function isOdd(number) {
 if (number % 2 === 1) {
   return true;
 } else {
   return false;
 }
}

if:

function isOdd(number) {
 return (number % 2 === 1);
};

11)

. , .

, :

// This function sums only odd numbers in an array
const sum = (val) => {
  return val.reduce((a, b) => {
    if (b % 2 === 1) { // If the current number is odd
      a+=b;            // Add current number to accumulator
    }
    return a;          // The accumulator
  }, 0);
};

:

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (isOdd(currentNumber)) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  }, 0);
};

. : “ ”, “ ”. , :

// create a variable and initialize it to 0
let sum = 0;
// Loop over array
array.forEach(
  // For each number in the array
  (number) => {
    // Add the current number to the sum variable
    sum += number;
  }
);

, . — .

12)

, , – .

, . -, - . , . , , . , - , , .

, , - . .

, . (test-driven development, TDD) . , , .

TDD , , , .

13) , - ,

, . ?

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (currentNumber % 2 === 1) { 
      return accumulator + currentNumber;
    }
    return accumulator;
  });
};
 
 
console.assert(
  sumOddValues([1, 2, 3, 4, 5]) === 9
);

. . ?
, . .

1

. , ? .

TypeError: Cannot read property 'reduce' of undefined.

:
.
.

, . , :

TypeError: Cannot execute function for empty list.

, 0? , - , .

2

. , ? :

sumOddValues(42);
TypeError: array.reduce is not a function

, array.reduce — . array (), ( 42), . , 42.reduce — . :

: 42 -   , . 

1 2 , . , . , , ?

sumOddValues([1, 2, 3, 4, 5, -13]) // => still 9

-13 ? ? ? “ ”? . , , , , , , .

“ . ” — , .

3

. . .

sumOddValues([2, 1, 3, 4, 5]) // => 11

2 , . , reduce initialValue, . . , .

14)

- , , . , , .

, , , .

, . .

: , — , . . . git blame, .

, , . , . .

15)

“ ” , , « ».

“ ” . .

, “ ” . , . “ ”, , .

-, - , - , - “ ”. , , , .

16)

“ – ( )”. , 1974

, .

“ ”, . , , .

, , . , Node.js .

.

17)

, ? , . ? . ?

. , , . , . , .

18)

. - , . . , , 5.0.

, – .

, “” . .

, . .

. , . , .

19) ,

— . – , .

. , . , . , .

, , , .

? : , , (). , .

.

NOT NULL , . , .

UNIQUE . .

CHECK , , 0 100.

PRIMARY KEY . .

FOREIGN KEY , .

– . , , , , .

20)

. . .

, , , , . , , , . .

- . . . “ ” . (open source), , , .

, , . - . shuffle lodash, , lodash.

21) (code review)

, . , .

. . . . .

, – , – .

-. , , , . , .

22) (Git)

/, Git.

, . — . . , , .

, . . , , .

, . , . .

– . , . , , , , .

, , , . bisect, , .

, , :

• (staging changes)
• (patching selectively)
• (resetting)
• (stashing)
• (amending)
• (applying)
• (diffing)
• (reversing)

, , . Git , .

23) (shared state)

.

. . , , . , , . , . .

, ( ). (Race conditions). , . . . .

24)

– . , . , – .

– . , , , .

– . .

25)

. . -, . , , , . .