Resep untuk review kode yang bermanfaat dari pengembang dari Yandex

Hai Nama saya Sergey, saya telah bekerja di Yandex selama lima tahun terakhir. Selama waktu ini ia berpartisipasi dalam pengembangan sebelas proyek. Dia menulis kode dalam JavaScript, Python dan C ++. Dia melakukan beberapa proyek sendirian, yang lain dia kembangkan dalam kelompok delapan orang. Tetapi di setiap tim, di semua proyek, terlepas dari bahasa pemrogramannya, saya menggunakan tinjauan kode.

Dengan bantuan tinjauan kode, saya terus-menerus mempelajari sesuatu yang baru. Terkadang, melihat kode orang lain, saya ingin berseru: "Tapi apa, apakah itu juga mungkin?". Dalam kode orang lain, saya menemukan trik menarik dan membawanya ke layanan. Saya mendapatkan banyak pengetahuan baru dari komentar pada kode saya. Bagi saya itu adalah penemuan bahwa orang-orang suka berbagi pengalaman. Bahkan ketika saya mengembangkan proyek sendiri, saya meminta orang-orang dari tim lain untuk melihat tugas pencarian saya. Ini memotivasi untuk menulis kode yang indah dan jelas.

Tapi itu tidak selalu terjadi. Suatu ulasan adalah hukuman bagi saya. Saya bisa menulis kode dengan inspirasi selama seminggu, mengerahkan semua kekuatan saya ke dalamnya. Saya mengirim pullrequest, memeriksakan resensi sebanyak tiga kali, dan sebagai imbalannya menerima "like ok" yang kering atau, lebih buruk, lusinan komentar yang tidak sesuai dengan manfaatnya.

Kelompok lima ribu baris datang ke ulasan saya. Saya menghabiskan waktu berjam-jam untuk mencoba mencari tahu kode, menggulir seratus kali dari fungsi untuk menguji dan sebaliknya. Dia menulis lusinan komentar tidak berguna tentang titik koma yang hilang. Semua ini sangat mengganggu saya. Sering saya menunda ulasan untuk nanti, dan saya mengumpulkan lusinan kolam yang tidak ditinjau.

Jika Anda merasakan ini pada diri Anda sendiri, maka artikel itu untuk Anda. Hari ini saya akan berbicara tentang teknik dan alat yang saya gunakan setiap hari selama lima tahun dari tinjauan kode harian.

"Sebelum ditinjau." Kiat untuk penulis

Bayangkan bahwa solusi untuk masalah ini adalah memasak. Anda bekerja sebagai tim, jadi Anda tidak hanya perlu memasak, tetapi juga mengajar koki lainnya. Tidak cukup untuk menunjukkan hasilnya kepada mereka, Anda harus menuliskan resepnya.

Berkomitmen

Setiap langkah dari resep adalah komitmen: mereka memecahkan dua telur - membuat mereka, menambahkan segelas susu - membuat mereka, menuangkan dua ratus gram tepung - membuat mereka lagi.

Dalam setiap komitmen, saya mengungkapkan satu pemikiran sederhana. Ini bisa merupakan implementasi dari metode model atau komponen dalam tata letak. Jadi akan lebih mudah bagi reviewer untuk mengerti saya. Saya tidak menyalahkannya pada seluruh tugas, yang tidak bisa ditelan sekaligus, tetapi ceritakan solusinya dalam beberapa bagian.

Saya melakukan refactoring dalam komit terpisah. Seringkali, refactoring bersifat murni teknis, misalnya, mengganti nama metode. Peninjau tidak perlu membaca setiap baris dari perubahan seperti itu. Dia akan menjalankan matanya "secara diagonal" dan akan dapat mencurahkan lebih banyak waktu untuk kode yang lebih penting.

Hancur, hancurkan, potong kode Anda menjadi komit kecil. Ini akan memungkinkan peninjau untuk lebih memahami kode Anda. Tidak apa-apa jika Anda berlebihan dengan dekomposisi. Dua komitmen mudah digabung menjadi satu. Jauh lebih sulit untuk membagi komit besar menjadi beberapa komit kecil. "Sayuran irisan" mudah diperoleh dengan mencampurkan "tomat cincang" dan "bawang cincang." Tetapi untuk mendapatkan semua bahan dalam porsi dari piring salad, Anda perlu menghabiskan lebih banyak waktu.

Setelah komit, saya langsung mendorong perubahan ke github. Ini membantu saya beberapa kali ketika ada "masalah kopi" dengan laptop.

Deskripsi komitmen

Ketika saya menulis email, saya mengisi tajuk dan isi surat itu. Judulnya adalah judul yang pendek dan luas, isi surat itu adalah deskripsi rinci dan terperinci dengan gambar dan tautan. Saya menerapkan pendekatan yang sama dengan deskripsi komit.

git commit -m 'fix1'. git commit, . ( ). ( ).

, " " " ". , . . ASCII- . , , .

( ASCII-)

( . vim)

( GitHub. )

, , . :

git status
git diff comments.js
git add comments.js

, . git add ., . , .

. , . JavaScript ESlint. R2-D2 " ", . , , .

WebStorm " ". , , . husky.

. . .

( )

– , – . , . git log --pretty='%h: %B' --first-parent --no-merges --reverse.

( `git log --pretty='%h: %B' --first-parent --no-merges --reverse`)

( , )

, . , . .

! , .

« ».

– , .

, . , , . , . , " ".

. . .

–

. ! . , . , , . , .

. , . .

. :

function sum(arr) {
  return arr.reduce(function (res, i) {
    return res + i;
  }, 0);
}

sum([1, 2, 3]); // 6

, :

const sum = arr => arr.reduce((res, i) => res + i);

, . , , . , . – .

Offline

, . , . .

offline-. (, : , ), .

. -, . -, : ( ). -, , — .

, . offline- .

« ».

, . . .

, . , , , . , : ? ? ? , .

. , .

( : )

. , . ? ' , .

-. . , . , , .

git rebase --interactive master. , FEATURE-1, master — . , , pick squash. .

( , )

--force. , . git push origin FEATURE-1 --force , . , .

GitHub. "Squash and merge".

( GitHub)

, . FEATURE-1. :

git checkout master
git pull origin master
git branch -D FEATURE-1

( .)

, , :

#     
git checkout -b FEATURE-1

#  
git status
git diff src/controllers/v1/comments.js
git add src/controllers/v1/comments.js

#    
git commit
git push origin FEATURE-1

#    
git log --pretty='%h: %B' --first-parent --no-merges --reverse

#    
git rebase --interactive master
git push origin FEATURE-1 --force

#  
git checkout master
git pull origin master
git branch -D FEATURE-1

#  ,      
git add comment.js

#    
git commit --amend