🚤 🗾 🈸 25 kesalahan seorang programmer pemula 👺 💪 🗡️

Belajarlah mengidentifikasi mereka. Kembangkan kebiasaan untuk menghindarinya.

Tujuan artikel ini bukan untuk menghasut pendatang baru untuk kesalahan khas, tetapi untuk mengajar mereka untuk mengidentifikasi dan menghindari mereka. Urutan daftar adalah acak.

Dari penerjemah

Kadang-kadang bisa sulit untuk menjelaskan hal-hal sederhana dengan kata-kata sederhana: mengapa menggunakan git, apa trik enkapsulasi, mengapa menulis tes, bagaimana merencanakan kode Anda, refactor orang lain, dll. Tampaknya bagi saya bahwa artikel ini dengan kompak menyusun aspek-aspek penting “kemanusiaan” dari pemrograman. Sesuatu seperti kode etik, pedoman dan motivator dalam membuat keputusan terkait penulisan kode.

Tidak peduli betapa lucu kedengarannya, saya telah mengerjakan teks ini sejak pertengahan Maret, mencoba menemukan bahasa yang tepat dan membuatnya lebih mudah untuk dipahami. Dia berkelahi beberapa hari dengan editor Habr. Karena itu, jika Anda menemukan kekurangan, tolong jangan salahkan saya karena kelalaian, tetapi beri tahu saya, saya akan segera memperbaikinya. Saya berpikir untuk menghias artikel dengan gambar, tetapi memutuskan bahwa ini hanya akan meningkatkannya ke dimensi yang benar-benar tidak senonoh. Selamat membaca.

1) Pemrograman tanpa perencanaan
2) Perencanaan yang berlebihan
3) Meremehkan pentingnya kualitas kode
4) Pegang keputusan pertama
5) Jangan mundur
6) Jangan google
7) Jangan gunakan enkapsulasi
8) Merencanakan yang tidak diketahui
9) Menggunakan struktur data yang tidak tepat
10) Memburuk kode
11) Mengomentari hal-hal yang jelas
12) Jangan menulis tes
13) Untuk berpikir, jika sesuatu bekerja, maka itu dilakukan dengan benar
14) Jangan mempertanyakan kode yang ada
15) Obsesi dengan praktik terbaik
16) Obsesi Kinerja
17) Jangan fokus pada pengguna akhir
18) Jangan memilih alat yang tepat
19) Kesalahpahaman bahwa masalah kode menyebabkan masalah data
20) Penemuan roda
21) Sikap yang tidak benar terhadap inspeksi kode
22) Tidak menggunakan sistem kontrol versi
23) Penyalahgunaan negara bersama
24) Sikap yang salah terhadap kesalahan
25) Jangan istirahat

1) Pemrograman tanpa perencanaan

Konten berkualitas tidak dibuat "pada lutut", tetapi membutuhkan kerja menyeluruh. Kode program tidak terkecuali.

Kode yang baik harus melalui langkah-langkah berikut:

Idenya. Penelitian Perencanaan Ejaan Verifikasi Ubah

Masing-masing poin ini perlu diberikan usaha yang cukup.

Pemula cenderung kode tanpa berpikir terlebih dahulu. Ini mungkin bekerja pada aplikasi mandiri kecil. Tapi pada umumnya bisa berubah menjadi tragedi.

Sebelum Anda mengatakan sesuatu, Anda memikirkan kata-katanya sehingga Anda tidak malu nantinya. Demikian pula, hindari kode yang salah dipahami yang suatu hari nanti akan memalukan. Dan kata-kata dan kode adalah refleksi dari pikiran Anda.

“Jika Anda marah, hitung sampai 10 sebelum Anda berbicara. Jika sangat marah, maka sampai 100. " (Thomas Jefferson)

Untuk kasus kami, ini dapat diulangi sebagai berikut:

“Saat memeriksa kode, hitung sampai 10 sebelum menulis ulang 1 baris. Jika tidak ada tes untuk kode ini, maka hingga 100 ".

Pemrograman adalah studi 90% dari kode yang ada dan modifikasinya melalui bagian-bagian kecil yang mudah diuji yang sesuai dengan keseluruhan sistem. Menulis kode itu sendiri hanya 10% dari pekerjaan programmer.

Pemrograman tidak hanya menulis baris kode, tetapi kreativitas berdasarkan logika yang perlu dikembangkan sendiri.

2) Perencanaan yang berlebihan

Merencanakan sebelum menyelam ke dalam pengkodean adalah hal yang baik. Tetapi bahkan hal-hal baik dapat menyakiti Anda jika Anda bertindak terlalu jauh dengannya. Bahkan air dapat diracuni jika Anda minum terlalu banyak.

Jangan mencari rencana yang sempurna. Ini tidak ada di dunia pemrograman. Carilah rencana yang cukup baik untuk memulai. Setiap rencana akan berubah, tetapi itu akan memaksa Anda untuk mematuhi struktur dalam kode yang akan memudahkan pekerjaan Anda di masa depan.

Perencanaan linear seluruh program “dari A ke Z” (dengan metode waterfall) tidak cocok untuk sebagian besar produk perangkat lunak. Pengembangan melibatkan umpan balik dan Anda akan terus-menerus menghapus dan menambahkan fungsionalitas, yang tidak dapat diperhitungkan dalam “perencanaan air terjun”. Beberapa item berikut harus direncanakan. Dan setiap yang baru harus dimasukkan dalam rencana hanya setelah adaptasi yang fleksibel dengan kenyataan (Agile).

Perencanaan harus didekati dengan sangat bertanggung jawab, karena kekurangan dan kelebihannya dapat merusak kualitas kode. Dan jangan sampai Anda mempertaruhkan kualitas kode.

3) Meremehkan pentingnya kualitas kode

Jika Anda dapat fokus hanya pada satu hal ketika menulis kode, maka itu harus mudah dibaca. Kode tidak terbaca yang tidak bisa dipahami bukan hanya sampah, tetapi sampah yang tidak dapat didaur ulang.

Lihatlah program sebagai komponen yang berkomunikasi melalui kode. Kode yang buruk adalah komunikasi yang buruk.

"Tulis kode Anda seolah-olah itu akan disertai oleh seorang psikopat agresif yang tahu di mana Anda tinggal." (John Woods)

Bahkan "hal-hal kecil" itu penting. Jika Anda tidak sistematis menggunakan huruf kapital dan indentasi, maka Anda perlu mengambil lisensi programmer.

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)

. . -, . , , , . .

25 kesalahan seorang programmer pemula