Apa istilah untuk komit kode sumber yang benar-benar BESAR? [Tutup]


37

Terkadang ketika kita memeriksa histori komit perangkat lunak, kita mungkin melihat bahwa ada beberapa komit yang benar-benar BESAR - mereka dapat mengubah 10 atau 20 file dengan ratusan baris kode sumber yang diubah (delta). Saya ingat bahwa ada istilah yang umum digunakan untuk komit BESAR seperti itu tetapi saya tidak dapat mengingat dengan tepat istilah itu. Ada yang bisa bantu saya? Apa istilah yang biasanya digunakan oleh pemrogram untuk merujuk pada komitmen BESAR dan raksasa seperti itu?

BTW, apakah melakukan banyak perubahan bersama-sama merupakan praktik yang baik?

UPDATE: terima kasih kepada kalian untuk diskusi yang menginspirasi! Tapi saya pikir "bom kode" adalah istilah yang saya cari.


15
"Melanggar komit". :-)
Peter K.

3
Secara pribadi saya akan memanggil komit yang ukurancluster f...
Ramhound

1
Bos saya melakukan ini sepanjang waktu. Komentar masuk: "semuanya; o)"
MetalMikester

+1 untuk pertanyaan karena saya sangat menyukai setiap jawaban sejauh ini, dan telah menderita karena telah melakukan setidaknya satu dari dosa setidaknya satu kali dalam karir saya dan ingin yang lain tidak melakukan itu =)
Patrick Hughes

Saya bisa mengatakan kode longsoran!
Brian

Jawaban:


50

(1) Ben Collins-Sussman : "..." bom kode ". Yaitu, apa yang Anda lakukan ketika seseorang muncul di proyek sumber terbuka dengan fitur baru raksasa yang membutuhkan waktu berbulan-bulan untuk ditulis? Siapa yang punya waktu untuk meninjau ribuan baris kode? ... "

(2) Dan Fabulich : "Bom Kode, atau: Pemula dengan Ide Besar ... Bom kode adalah tambalan yang begitu besar sehingga tidak ada yang bisa memeriksanya."

(3) Google Summer of Code: Pedoman : "Berkomit lebih awal, komit sering ... Tolong jangan bekerja sepanjang hari dan kemudian mendorong semuanya keluar dalam satu bom kode tunggal . Sebagai gantinya, setiap komit harus mandiri hanya untuk satu tugas saja yang harus dirangkum dalam pesan log. "

(4) Jeff Atwood : "bom kode ... Aturan # 30: Jangan menjadi gelap ... ...


tautan 2 dan 4 secara langsung menghubungkan dan mengutip tautan 1. Tidak ada yang salah dengan penyebaran konsep, tetapi itu sedikit kurang relevan. Saya suka istilah itu, tapi sepertinya tidak terlalu banyak.
haylem

1
Bagaimana jika kode yang dikomit adalah kode baru yang cukup terisolasi dari sisa proyek? Dalam hal ini saya pikir satu komit besar (hampir) kode selesai dan dibersihkan lebih baik daripada banyak komit kecil yang memaksa orang untuk meninjau (1) perbaikan bug menengah, (2) refactoring seperti penggantian nama kelas dan sebagainya, ( 3) kode awal yang pada akhirnya akan dihapus. Hanya 2 sen saya.
Giorgio

Ini adalah alasan mengapa saya menentang penulisan ulang / rebasing sejarah
dukeofgaming

@Iorgio - itulah gunanya cabang.
Brian

@ Brian: Ya, itu sebuah kemungkinan. Dalam hal ini Anda memiliki komit besar pada cabang utama saat Anda menggabungkan fungsionalitas yang telah Anda kembangkan di cabang.
Giorgio

38

Kami mungkin menyebutnya komitmen buruk . :)

Praktek yang buruk

Dan ya, itu umumnya dianggap praktik buruk , karena memiliki efek negatif:

  • membuatnya sulit untuk ditinjau ,
  • membuatnya sulit untuk dipahami dengan mudah dan cepat niat asli komit ,
  • membuatnya sulit untuk melihat bagaimana itu berdampak pada kode untuk secara eksplisit memperbaiki atau mengatasi masalah ,
  • membuatnya sulit untuk mengetahui apakah ukuran komit disebabkan oleh kebisingan dari perubahan lain yang mungkin tidak terkait atau tidak (misalnya pembersihan kecil atau tugas lainnya).

Kasur yang Dapat Diterima

Namun, Anda dapat memiliki kasus di mana komit besar dapat diterima . Contohnya:

  • saat menggabungkan seluruh cabang ,
  • saat menambahkan sumber baru dari basis kode lain yang tidak berversi,
  • ketika mengganti fitur besar di tempat (meskipun Anda lebih suka melakukannya di cabang, dengan komit yang lebih kecil menangani bagian perubahan yang berbeda, dan kemudian menggabungkan semuanya kembali, sehingga Anda dapat memiliki jendela yang lebih baik tentang pengembangan tambahan dari fitur dan masalah yang mungkin ditemui di sepanjang jalan),
  • ketika refactoring API berdampak pada banyak kelas turunan dan konsumen.

Jadi, jika memungkinkan, lebih suka "pemogokan bedah" -jenis komitmen (dan tautkan ke ID tugas di pelacak masalah Anda!). Jika Anda memiliki alasan yang valid, silakan.


Terlepas dari itu, saya sebenarnya tidak tahu dan tidak berpikir saya pernah mendengar nama khusus untuk komit besar. Monster-commit? Berkomitmen gemuk?

Pembaruan: Jawaban David Cary menghubungkan ke aktor-aktor TI terkenal yang menggunakan istilah "bom kode" (yang paling penting, Collins-Sussman, pencipta asli Subversion ). Seperti itu (meskipun sejauh ini saya tidak bisa mengatakan saya sering mendengar).


11
Komitmen Godzilla! Eeeeeeeek !!!
Péter Török

@ PéterTörök: Menyukai itu. Mari membuatnya menjadi tren. Pilihan lain: komit paus, komit raksasa, atau BigFatCommit.
haylem

1
Ya, baik "buruk" atau "terlambat". Jika tidak ada nama untuk itu di perusahaan Anda, beri nama setelah pengembang yang dimaksud. "Hei, cowok baru, jangan lakukan Jerry! Berkomitmen lebih awal dan berkomitmen sering."
chooban

Jangan lakukan Jerry, itu pendekatan yang berguna! Komit masif juga dapat berasal dari pengembang yang tertekan yang tidak percaya atau memahami penggunaan versi. Periksa pengetahuannya!
Independen

Bagaimana jika nama seseorang adalah Jerry?
Loïc Faure-Lacroix

12

BTW, apakah melakukan banyak perubahan bersama-sama merupakan praktik yang baik?

Ya, itu bukan praktik yang baik untuk menahan perubahan untuk waktu yang lama, dan mengimplementasikan berbagai fitur dan perbaikan bug, dan kemudian mengkomitnya, yang merupakan salah satu cara komit besar bisa terjadi.

Cara lain ini bisa terjadi adalah jika refactoring mengubah tanda tangan dari fungsi yang banyak digunakan, dan kemudian semua itu harus diubah. Ini tidak selalu buruk, dan saya tidak ingin pengembang menahan diri dari membersihkan kode karena takut melewati ambang batas.

Jadi, ada lebih dari itu hanya dengan melihat jumlah file yang disentuh dalam komit.


5
Ini. Yang benar-benar penting bukanlah jumlah file yang diubah, atau jumlah baris yang diubah, tetapi ruang lingkup perubahan. Jika Anda dapat dengan mudah dan akurat menggambarkan set perubahan dalam pesan komit pendek yang tidak meninggalkan apa pun, jumlah perubahan fisik relatif tidak penting. Bukan tidak penting, tetapi saya sendiri, saya lebih suka memiliki satu komit besar yang membuat kode dapat dibangun daripada seperangkat komit di mana hanya beberapa dari mereka menghasilkan pohon kode sumber yang akan membangun (cf metode perubahan tanda tangan).
CVn

8

Istilah yang saya dengar adalah "chunky check-in" . Dan saya bukan penggemar mereka. Saya suka komitmen yang lebih kecil yang memastikan tidak ada lagi yang rusak pada langkah wajar dalam suatu proyek. Komit besar umumnya penuh dengan masalah yang bergaung untuk beberapa saat ketika itu terjadi.


1 karena saya tidak ingat bahwa pada saat itu (meskipun saya tidak berpikir itu istilah umum, atau saya tidak menyadarinya), tapi saya pernah mendengar kata "chunk" yang digunakan secara khusus oleh lincah dalam kaitannya dengan ekstensi yang memungkinkan untuk mengirimkan komit besar dengan potongan data yang berbeda, tetapi selain itu saya rasa saya tidak pernah mendengar istilah itu untuk komit secara umum.
haylem

Perusahaan tempat saya berada saat pengembang menggunakan istilah itu menggunakan SourceGear Vault.
Jesse C. Slicer

3

Saya menyebutnya "commit SVN biasa" atau "besok adalah hari rilis komitmen"

Seperti halnya saya mencintai SVN, saya hanya dimatikan oleh kenyataan bahwa saya tidak dapat melakukan komitmen lokal.

Sunting: mereka biasanya memiliki kata "barang" dan "bir" dalam pesan komit.

EDIT LAGI: Melakukan banyak perubahan, meskipun tidak selalu merupakan praktik yang buruk, harus sebisa mungkin dihindari. Saya merasa lebih mudah untuk meninjau revisi / komit yang singkat dan ringkas. (dipasangkan dengan pesan komit yang ditulis dengan baik, lihat hasil edit saya sebelumnya untuk contoh yang buruk)



2
  • komitmen awal - proyek yang tidak di bawah kendali revisi dilemparkan ke SVN
  • refactoring - arsitek memiliki ide cemerlang tentang mengubah nama kelas dari / ke Konvensi Penamaan Smurf atau mengubah akar hierarki paket
  • format kode - arsitek telah memutuskan untuk mengubah indentasi kode dari 4 menjadi 3 spasi atau mengubah akhiran baris dari Unix ke Windows (atau mengembalikan)
  • Komitmen Jumat - Joe selalu melakukan pekerjaan sepanjang minggu pada hari Jumat pukul 16:30
  • uuups commit - Ted secara tidak sengaja menghapus direktori root, melakukan itu, dan sekarang dia memompa sekali lagi seluruh hierarki file ke dalam SVN

0

Biasanya banyak orang cenderung membuat komitmen besar menggunakan VCS terpusat, terutama server memberlakukan kebijakan komitmen yang baik. Itu adalah komit harus melewati semua tes dan tes membutuhkan waktu lebih lama (lebih lama dari beberapa detik). Jadi pengembang tidak ingin menunggu terlalu lama untuk melakukan beberapa kali dan memecah perubahan menjadi beberapa komit kecil.

Dan pengembang yang hijau untuk VCS mungkin lupa memecah perubahan menjadi beberapa komit kecil. Mereka hanya ingat untuk berkomitmen ketika mereka merilis program ke tim QA. Lebih buruk lagi, untuk menghindari orang lain melihat kode kereta, mereka tidak melakukan sebelum berhasil melewati pengujian QA. Terakhir, mereka tidak menyadari bahwa mereka telah melakukan binary output, file sementara dan output linker, yang benar-benar menghasilkan komit "besar".

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.