Apa yang harus saya lakukan ketika saya sudah menunggu terlalu lama di antara komitmen?

100

Saya nakal ... Terlalu banyak "koboi pengkodean," tidak cukup berkomitmen. Sekarang, saya di sini dengan komitmen besar. Ya, saya seharusnya sudah melakukan selama ini, tapi sekarang sudah terlambat.

Apa yang lebih baik

Lakukan satu komit besar yang mendaftar semua hal yang saya ubah
Cobalah memecahnya menjadi komit kecil yang kemungkinan tidak akan dikompilasi, karena file memiliki beberapa perbaikan, perubahan, nama metode tambahan, dll.
Coba lakukan pembalikan sebagian file hanya untuk komit yang sesuai, lalu kembalikan perubahan yang baru.

Catatan: sampai sekarang saya adalah satu-satunya programmer yang mengerjakan proyek ini; satu-satunya orang yang akan melihat komentar komit ini adalah saya, setidaknya sampai kita mempekerjakan lebih banyak programmer.

By the way: Saya menggunakan SVN dan Subclipse. Saya memang membuat cabang baru sebelum melakukan perubahan ini.

Informasi lebih lanjut : Saya mengajukan pertanyaan terpisah yang berkaitan dengan bagaimana saya masuk ke situasi ini di tempat pertama: Bagaimana mempersiapkan untuk menulis ulang lem aplikasi

— durron597
sumber

2

Program kontrol versi apa yang Anda gunakan? Banyak yang memiliki modul yang memungkinkan Anda untuk memecah suntingan Anda di "bakhil", yaitu kelompok garis yang dimodifikasi, yang akan memungkinkan Anda untuk mengelompokkan suntingan Anda dengan cara apa pun yang Anda suka dan mendistribusikan mod satu file ke beberapa perubahan. Misalnya, lincah memiliki ekstensi "mengesampingkan". Tentu saja Anda masih harus memeriksa apakah setiap kumpulan perubahan dikompilasi, jika itu penting untuk proses Anda. Apakah itu semua sepadan dengan masalahnya, terserah Anda dan toko Anda.

— alexis

6

Setidaknya periksa di cabang, sehingga Anda tidak kehilangan perubahan Anda.

— Rory Hunter

2

Anda dapat terus bertanya pada diri sendiri dan menunggu lebih lama, atau benar-benar berkomitmen dan menangani kekacauan apa pun yang menciptakan ... Dan kemudian ... jangan lakukan itu lagi!

— haylem

40

# 1, berdoa untuk pengampunan, dan kemudian pergi dan jangan berbuat dosa lagi :)

— Peteris

5

Pertanyaan yang lebih penting yang harus Anda tanyakan pada diri sendiri adalah: "bagaimana cara mengubah kebiasaan buruk saya untuk mencegah hal ini terjadi lagi". Seharusnya tidak ada alasan untuk melakukan tidak setidaknya sekali sehari, lebih baik lebih sering.

— Doc Brown

52

Untuk menjawab, Anda harus bertanya pada diri sendiri bagaimana Anda berharap untuk menggunakan hasil dari komitmen ini di masa depan. Alasan paling umum adalah:

Untuk melihat rilis apa bug diperkenalkan.
Untuk melihat mengapa ada baris kode tertentu.
Untuk bergabung ke cabang lain.
Untuk dapat memeriksa versi sebelumnya untuk pemecahan masalah, pelanggan atau penguji melihat dalam versi itu.
Untuk dapat memasukkan atau mengecualikan bagian-bagian tertentu dari rilis.

Dua alasan pertama dapat dilayani sama baiknya dengan satu check-in besar, dengan asumsi Anda dapat membuat pesan check-in yang berlaku sama baiknya untuk setiap baris kode yang diubah. Jika Anda satu-satunya programmer, maka komitmen yang lebih kecil tidak akan membuat penggabungan Anda lebih mudah. Jika Anda tidak berencana melakukan rilis atau pengujian dengan hanya sebagian dari perubahan yang tidak terkirim, maka dua alasan terakhir tidak berlaku.

Ada alasan lain untuk membuat komitmen kecil, tetapi itu untuk sementara Anda berada di tengah-tengah perubahan, dan waktu sudah lewat. Alasan-alasan itu membuatnya lebih mudah untuk mundur dari kesalahan atau perubahan eksperimental, dan membuatnya lebih mudah untuk tetap disinkronkan dengan kolega tanpa penggabungan yang menakutkan.

Dari pemahaman saya tentang situasi Anda saat Anda menggambarkannya, tampaknya ada sedikit manfaat atau tidak untuk memisahkan komitmen Anda pada titik ini.

— Karl Bielefeldt
sumber

Jawaban yang sangat bagus! Meskipun saya tidak merasa menyesal tidak melakukan komitmen kecil, saya merasa jauh lebih baik tentang apa yang harus saya lakukan untuk kembali pada perilaku yang baik seproduktif mungkin.

— durron597

1

Hal lain tentang 3 dan 5 adalah bahwa setiap pekerjaan yang Anda lakukan sekarang untuk memungkinkan mereka terjadi, Anda bisa menunggu sampai Anda benar-benar membutuhkannya dan kemudian melakukan pekerjaan yang sama. Mungkin akan lebih sulit di masa depan karena ingatan Anda tentang apa yang Anda lakukan hilang. Tetapi sekali lagi, Anda mungkin tidak akan pernah membutuhkannya.

— Steve Jessop

Dalam pengalaman saya, sulit dan rapuh untuk mengandalkan komentar kontrol versi untuk menceritakan kisah mengapa kode itu ada (yaitu alasan 1 dan 2). Jika Anda menggunakan SVN dengan cabang, sejarah komit hilang karena penggabungan (Anda akan lebih baik dengan hal-hal yang lebih modern seperti git). Jadi itu IMHO terbaik disajikan dengan komentar.

— Hans-Peter Störr

1

@ hstoerr - jika Anda menggunakan Subversion 1.5 atau lebih baru, Anda bisa menyimpan sejarah dengan opsi --reintegrate saat digabung.

— Dustin Kendall

1

git add -p adalah teman terbaik Anda di sini. Saya jatuh cinta dengan fitur itu. Dengan cara ini saya dapat melakukan modifikasi standar pengkodean saya di komit terpisah, dan menjaga perubahan kode yang relevan terisolasi.

— Spidey

39

Saya pikir apa pun yang Anda lakukan, cobalah untuk menghindari memeriksa kode yang Anda tahu tidak akan dikompilasi.

Jika Anda berpikir opsi ketiga Anda layak, itu mungkin cara yang baik untuk melakukannya, selama Anda dapat memastikan bahwa urutan komit Anda tidak akan membuat sistem yang tidak dapat dikompilasi. Kalau tidak, lakukan saja komitmen besar. Itu jelek, tapi sederhana, cepat, dan menyelesaikannya. Ke depan, komit lebih sering .

— FrustratedWithFormsDesigner
sumber

Opsi tiga dimungkinkan tetapi akan sangat memakan waktu. Saya pikir saya hanya akan melakukan opsi 1

— durron597

3

Apa kelemahan dari melakukan kode yang tidak dapat dikompilasi atau dibangun di cabang fitur (atau serupa) yang sangat mengerikan untuk memaksa seseorang untuk menghindari melakukan "apa pun yang mereka lakukan"? Saya membayangkan bahwa setiap komit yang benar-benar mengerikan dapat dihindari oleh yang lain, yang merupakan satu-satunya alasan mengapa saya menghindarinya (dengan asumsi, tentu saja, komit tersebut tidak dilepaskan ).

— Kenny Evitt

3

The "menghindari memeriksa kode yang tidak dapat dikompilasi" hanya berlaku untuk bersama kode-base / cabang. Pada proyek satu orang atau cabang pengembangan satu orang, saya mengklaim lebih penting untuk memasukkan perubahan Anda ke VC sehingga Anda tidak kehilangan barang.

— Stephen C

3

@StephenC misalnya karena merusak alat seperti git-membagi dua. Jika kode mengkompilasi / menjalankan semua waktu dan Anda perlu menemukan regresi jika ia mengkompilasi sepanjang waktu, Anda hanya dapat mencari biner (tidak menyebutkan bahwa jika ada regresi dalam potongan kode Anda dibiarkan dengan perubahan besar untuk membaca alih-alih menyempit bawah).

— Maciej Piechotka

@MaciejPiechotka - Ya, tentu saja jika Anda perlu menggunakan alat khusus pada cabang pribadi Anda, dan mereka membutuhkan kode yang dapat dikompilasi, maka lakukanlah. Tapi itu tidak khas untuk proyek / cabang satu orang.

— Stephen C

19

Alasan paling penting untuk membuat komitmen yang sering, kecil, dan bermakna adalah untuk membantu pemahaman tentang sejarah kode. Secara khusus, sangat sulit untuk memahami bagaimana kode telah berubah jika sulit untuk menghasilkan perbedaan yang dapat dimengerti.

Opsi 1 mengaburkan riwayat perubahan yang telah Anda buat, tetapi sebaliknya itu tidak akan menyebabkan masalah.

Opsi 2 mengaburkan riwayat perubahan yang telah Anda buat, mungkin agak kurang dari opsi 1, tetapi bisa menyebabkan masalah lain untuk Anda atau orang lain jika mereka menganggap atau menyimpulkan bahwa komitmennya berbeda, misalnya dapat digabung ke cabang lain secara mandiri. Kecuali ada alasan praktis yang kuat mengapa ini lebih disukai daripada opsi 1, ini kurang ideal daripada itu.

Opsi 3 adalah yang terbaik, semuanya sama, tetapi jika, seperti yang telah Anda jelaskan di tempat lain, melakukannya akan membutuhkan jumlah waktu "ekstrem" atau akan menimbulkan biaya signifikan lainnya, Anda harus mempertimbangkan biaya-biaya tersebut terhadap manfaat yang diharapkan dari membuat komitmen lebih bersih.

Berdasarkan info yang Anda berikan, saya akan memilih opsi 1. Mungkin Anda harus mengatur pengingat yang meminta Anda melakukan perubahan?

Prototyping dan Penulisan Ulang

Pertimbangan lain yang perlu diingat, terutama mengingat catatan Anda tentang menjadi programmer tunggal, dan kecurigaan saya bahwa Anda sedang mengerjakan basis kode yang relatif baru, adalah bahwa mungkin baik untuk mengembangkan kebiasaan yang berbeda sehubungan dengan melakukan perubahan ketika Anda sedang membuat prototipe kode baru versus mempertahankan atau memperluas kode yang ada. Mungkin tidak ada pembagian yang sangat tajam antara keduanya, tapi saya pikir itu masih merupakan perbedaan yang berguna.

Saat Anda membuat prototipe kode baru, komit kapan pun Anda ingin menyimpan perubahan Anda, hampir pasti di cabang, tapi mungkin dalam proyek terpisah. Atau mungkin bahkan hanya bekerja di luar kendali versi sama sekali. Alih-alih, Anda bisa fokus mengumpulkan bukti tentang kelayakan berbagai hipotesis atau desain yang Anda pertimbangkan. Saya sering menulis prototipe kecil menggunakan alat yang berbeda, misalnya LINQPad bukan Visual Studio untuk kode C #.

Saat Anda telah memvalidasi hipotesis atau desain tertentu, tulis ulang di proyek utama Anda, idealnya di cabang, dan buat komitmen kecil dan bermakna yang akan membantu pemahaman orang lain (termasuk Anda di masa depan) tentang sifat perubahan Anda sedang membuat.

— Kenny Evitt
sumber

1

Jawaban yang bagus; Kenny apakah Anda memiliki artikel bagus atau basis pengetahuan lain untuk dihubungkan dengan detail yang lebih spesifik tentang pembuatan prototipe? Versi saya dari prototyping adalah "sketsa di notebook atau di papan tulis"

— durron597

@ durron597, saya tidak bisa memikirkan tautan apa pun (bahkan untuk mencari) dari atas kepala saya. Saya telah bermain-main dengan bahasa pemrograman yang cukup ditafsirkan (dan dikompilasi secara dinamis) yang saya bahkan tidak berpikir bahwa ide 'prototyping' mungkin novel! Dan saya telah menulis ulang begitu banyak program C, C ++, dan Java (berulang-ulang) sehingga saya tidak berpikir bahwa itu mungkin tidak biasa juga, atau paling tidak baru bagi sebagian orang.

— Kenny Evitt

12

Meskipun satu-satunya jawaban yang masuk akal adalah tidak pernah mematahkan belalai , beberapa kali itu tidak mungkin. Sebagai contoh, svn dapat merusak komit jika Anda komit terlalu banyak (mungkin opsi, atau fitur, saya tidak yakin). Dalam kasus khusus seperti itu, cukup periksa dalam beberapa bagian. Karena Anda adalah seorang programmer tunggal itu tidak akan mengganggu siapa pun.

Karena itu, saya akan memilih opsi 1. Jika tidak memungkinkan, maka opsi 2.

Opsi 3 membutuhkan banyak usaha, dan itu tidak layak.

— BЈовић
sumber

1

atau tandai versi yang tidak dikompilasi sebagai "JANGAN SAMPAI"

— ratchet freak

2

@ scratchetfreak: Saya kira "tag" di SVN tidak akan banyak membantu, karena tag tidak berfungsi sebagai "komentar" di bagasi.

— Doc Brown

@DocBrown maksud saya menambahkannya ke pesan commit

— ratchet freak

5

@ scratchetfreak Saya akan melakukannya sebagai "BAGIAN X / N: memeriksa di ABC

— DOESNT COMPILE

Opsi 3 tidak membutuhkan banyak usaha. Jawaban lain menjelaskan cara melakukannya dengan cepat dan mudah menggunakan git add --patchdan git stash. Situasi hanya tampak sulit karena alat kontrol sumber dan pengetahuan yang sudah ketinggalan zaman.

— Ron MacNeil

7

Cobalah memecahnya menjadi komit kecil yang kemungkinan tidak akan dikompilasi, karena file memiliki beberapa perbaikan, perubahan, nama metode tambahan, dll.

Ketika saya menemukan diri saya dalam situasi yang sama saya menggunakan teknik berikut:

Tambahkan hanya kode yang relevan dengan fitur tertentu: git add --patch
Simpan semua perubahan lainnya: git stash save --keep-index
Jalankan tes / coba kompilasi
Komit berubah jika semuanya baik-baik saja, jika tidak masuk ke 1

Saya tidak terbiasa dengan SVN, jadi saya tidak tahu apakah ini berlaku untuk situasi spesifik Anda, tetapi dasarnya harus sama - mengisolasi bagian-bagian kecil kode dan mengujinya secara individual.

— Milos
sumber

Saya suka ini tetapi sayangnya salah satu dari banyak hal dalam daftar todo saya (ada banyak ketika Anda satu-satunya orang teknologi di perusahaan) adalah untuk beralih dari SVN ke git, dan saya belum sempat melakukannya .

— durron597

1

Karena saya tidak cukup untuk menggunakannya --patch, saya menggunakan Undo di berbagai panel editor, untuk mencapai kondisi kerja sebelumnya, dan mengkomitnya. Lalu saya ulangi untuk komit berikutnya. Karena godaan untuk membuat tambahan kecil pada kode ketika dalam keadaan Undone, saya selalu membuat cadangan sebelum saya memulai proses ini!

— joeytwiddle

Dengan git Anda juga dapat menambahkan secara interaktif (add -i) sebelum melakukan dan cabang setelah itu untuk memvalidasi komit Anda secara independen.

— riezebosch

3

Bagaimana dengan opsi 4: Cadangkan keadaan repo Anda saat ini di tempat sementara, kembalikan repo Anda ke keadaan semula, buat daftar semua perubahan yang Anda lakukan (Anda masih dapat melihat cadangan sementara), lalu reimplement secara manual (dan kompilasi secara manual dan uji!) mereka sebagai komitmen terpisah.

Ini seharusnya lebih mudah, karena Anda sudah menulis kode, itu hanya sedikit mencari tahu bagian mana yang akan disalin dan tempel dari cadangan sementara Anda.

Ketika Anda telah menerapkan kembali setiap perubahan dengan bersih, dan dengan demikian memastikan bahwa komit mandiri, kecil, dan kompilasi, Anda dapat menghapus cadangan sementara, dan semuanya akan hampir sama persis (kecuali untuk waktu / tanggal komitmen) itu akan jika Anda melakukannya sejak awal.

— Hebat
sumber

Ini hanya cara melakukan opsi # 3. Mungkin cara terbaik, benar, tetapi masih cukup memakan waktu.

— durron597

Ada 149 baris pesan Menambah / Menghapus / Mengirim ketika saya melakukan satu komit besar. Setidaknya setengah hari untuk melakukan ini.

— durron597

@ durron597 Saya tidak setuju, saya pikir ini berbeda dari # 3. Mengenai 149 baris, seberapa besar Anda menghargai riwayat komit bersih? Apakah layak menghabiskan setengah hari? Lagi pula, ini tidak seperti metode lain yang tidak memerlukan mencari tahu baris mana yang harus di komit, jadi Anda harus melalui 149 baris dengan cara baik. Perbedaan waktu akan kecil.

— Biasa

Heh. Saya cukup berpengalaman untuk mengetahui untuk menggunakan kontrol versi, tetapi tidak cukup berpengalaman untuk pernah menyelamatkannya :) Jadi alasan praktis untuk melakukan hal-hal masih sedikit akademis, jika Anda tahu apa yang saya maksud.

— durron597

Anda tidak perlu mencadangkan seluruh repo Anda . Anda dapat membuat komit "cadangan", lalu memutar kembali KEPALA git reset HEAD~. Komit Anda akan tetap ada git reflogjika Anda memutuskan Anda membutuhkannya nanti. Anda bahkan dapat memotong cabang (dan kemudian beralih kembali ke cabang yang berfungsi) sebelum melakukan reset, untuk memberi Anda "cadangan" komit nama. Hapus cabang nanti jika Anda tidak membutuhkannya. Sunting: Maaf tidak menyadari OP ada di svn!

— joeytwiddle

3

Anda satu-satunya programmer; lakukan saja checkin besar tunggal merinci bit penting dari apa yang Anda lakukan.

Apakah Anda cenderung untuk memutar kembali "bagian" dari apa yang Anda lakukan? Jika tidak, maka lanjutkan dengan opsi 1.

Ada beberapa alasan untuk memeriksa kode ke dalam sistem kontrol versi. Dan SEMUA dari mereka, ketika Anda satu-satunya pengembang, berputar di sekitar keselamatan - yaitu, jika Anda gagal, mesin mati atau apa pun, Anda selalu dapat kembali ke pos pemeriksaan terakhir.

Seorang programmer yang datang ke proyek nanti tidak mungkin ingin memutar kembali ke versi yang tidak dikompilasi. Jadi, IMHO, opsi 2 adalah kegilaan.

Opsi 3 terdengar seperti tenggang waktu, bahwa jika saya adalah bos Anda dan melihat Anda menghabiskan waktu berjam-jam melakukan ini, saya akan berbicara sedikit dengan Anda tentang berapa nilai waktu Anda.

Untuk mengulangi: dengan memeriksa kode Anda, Anda menutupi / menyimpan pantat Anda jika terjadi kegagalan pada mesin Anda. Yang lainnya, dalam satu tim, adalah ganti jendela.

— Bukan saya
sumber

1

Berguling kembali bukan satu-satunya alasan untuk menggunakan komit kecil. Itu bahkan bukan alasan yang sangat bagus. Alasan utamanya adalah untuk dapat melihat kapan dan mengapa perubahan diperkenalkan, dan untuk memfasilitasi pemecahan masalah saat Anda dihadapkan dengan masalah yang tidak diketahui asalnya. Programmer lain yang masuk ke proyek nanti hampir pasti akan setidaknya kadang-kadang menemukan garis kode yang membuatnya pergi "WTF" dan merujuk kembali ke komit di mana ia pertama kali ditulis atau terakhir dimodifikasi. Jika komit itu adalah satu komit raksasa yang mengubah 500 hal, mustahil untuk mendapatkan informasi yang berguna dari sejarah.

— Aaronaught

Kebetulan, inilah sebabnya tim yang menggunakan Git umumnya membenci komitmen gabungan dan meminta / meminta rebase sebagai gantinya; menggabungkan komit istirahat bisectdan teknik lain yang biasa digunakan untuk mengisolasi masalah, karena begitu banyak perubahan dimasukkan ke dalam satu komit besar.

— Aaronaught

1

Pada tingkat pribadi saya setuju bahwa Anda tidak boleh melakukan komitmen besar kecuali jika Anda secara radikal mengubah basis kode .. pada titik mana Anda seharusnya tetap melakukan percabangan. Namun kita berbicara tentang seorang programmer tunggal yang telah bekerja pada dasarnya terputus dan sekarang sedang mencoba untuk kembali melakukan hal yang benar. Dalam hal ini saya percaya satu komit besar lebih disukai.

— NotMe

1

@Aonaona saya menambahkan bahwa diri Anda 3 bulan kemudian dapat merupakan 'programmer lain'.

— Maciej Piechotka

1

Saya juga harus tidak setuju dengan percabangan sebagai strategi yang layak untuk perubahan arsitektur atau perubahan "destruktif" lainnya. Itu hanya mengarah ke mimpi buruk konflik gabungan dan bug pasca-gabungan. Dalam jangka panjang, jauh, tidak terlalu menyakitkan untuk menemukan cara untuk memecah perubahan besar menjadi perubahan yang lebih kecil, kompatibel dengan terbelakang, atau, dalam skenario terburuk, menggunakan apa yang Fowler, Humble, dan sisanya sebut Branch Dengan Abstraksi (yang sebenarnya bukan cabang sama sekali). Kedua strategi ini menyiratkan komitmen kecil dan fokus.

— Aaronaught

2

Aturan saya adalah: Tidak ada lapor masuk tanpa tinjauan kode serius. Jika saya sendiri, saya harus meninjau kode sendiri, tetapi akan ditinjau. Tampaknya Anda memiliki sejumlah perubahan kode yang tidak dapat ditinjau oleh orang lain, oleh karena itu Anda tidak dapat memeriksanya sendiri (meninjau kode Anda sendiri lebih sulit dan membutuhkan lebih banyak disiplin, karena Anda secara otomatis membuat asumsi yang salah bahwa kode Anda sendiri benar. ).

Aturan yang benar-benar tidak dapat dipecahkan oleh semua orang adalah: Jangan pernah memeriksa kode yang bahkan tidak dibuat, dan secara serius menghindari memeriksa kode yang tidak berfungsi.

Solusi: Salin kode Anda yang diubah, kembali ke titik semula. Gabungkan satu perubahan pada satu waktu ke dalam kode asli, tinjau, uji, periksa. Dengan metode pemrograman yang Anda jelaskan, Anda pasti menemukan beberapa bug serius dengan cara itu.

Ini juga cara yang baik untuk melatih diri Anda sendiri kebiasaan pemrograman yang baik.

— gnasher729
sumber

Ini secara logis sama dengan jawaban berbasis Git di atas ( git add --patchdan git stash) dan contoh yang baik dari skenario yang dapat ditangani dengan mudah oleh DVCS modern tetapi sistem yang lebih tua tidak dapat melakukannya.

— Ron MacNeil

1

Saya pikir Anda terlalu khawatir. Jika Anda adalah satu-satunya programmer dan Anda tidak memiliki lembar spesifikasi untuk dikerjakan maka itu sepenuhnya terserah Anda apa yang Anda lakukan. Saya berasumsi tidak ada yang akan menghukum Anda karena membuat komit besar sehingga satu-satunya masalah yang akan Anda hadapi adalah teknologi, seperti tidak dapat mengembalikan perubahan file individual dalam komit. Karena Anda hanya mengendalikan repo pada saat ini yang seharusnya tidak menjadi perhatian besar juga.

Ada garis yang harus ditarik antara pragmatisme dan dogmatisme. Apa yang Anda lakukan tidak akan menjadi ide yang baik di tim dan mungkin tidak boleh diulang maju, tetapi dalam situasi Anda, saya hanya akan menyerahkan komit besar.

— Roy
sumber

1

ini tampaknya tidak menambahkan sesuatu yang substansial atas apa yang sudah diposting di 12 jawaban sebelumnya

— nyamuk

-1

Masalahnya bukan pada penundaan yang lama di antara commit, tetapi pada kenyataan bahwa Anda menyimpan kode dalam waktu yang tidak dapat dikompilasi terlalu lama. Pertama-tama, apa definisi Anda tentang 'panjang'? Bagi sebagian orang 5 menit untuk keadaan transisi terlalu banyak tetapi beberapa dapat memoles kode mereka selama berhari-hari bahkan tanpa mencoba menjalankan kompiler.

Sebenarnya tidak masalah - yang penting adalah Anda kehilangan kendali atas kode Anda, kode Anda menjadi tidak terkelola. Ini normal, itu hanya berarti bahwa Anda memiliki hutang teknologi dan ini saatnya untuk berpikir tentang refactoring. Jadi kamu frustrasi? Kode Anda tidak dikompilasi, Anda bahkan tidak memiliki tes unit? Bagaimana Anda bisa berpikir tentang refactoring dalam kasus ini? Jangan khawatir. Selesaikan "koboi kode" dan mulailah membersihkannya. Idealnya cobalah menulis beberapa tes. Anda tidak punya waktu untuk itu? Ok, mulai dari perbaikan kecil.

Beberapa perubahan tidak memerlukan tes. Ubah nama variabel agar lebih cocok, pindahkan kode berulang ke fungsi terpisah, dll ... Anda akan mendapatkan gagasan kode yang lebih baik. Setelah itu Anda bisa melakukan perubahan yang lebih besar. Sekali lagi, cobalah menulis tes jika memungkinkan. Buat kode Anda dapat dikelola.

Setelah itu Anda akan melihat bahwa perubahan selanjutnya tidak akan membuat Anda "terlalu lama" (apa pun artinya).

— AlexT
sumber

2

Dia tidak mengatakan bahwa dia menjaga kode itu tidak dapat dikompilasi untuk waktu yang lama. Kode dalam repo itu tidak dimodifikasi untuk waktu yang lama - lama tetapi masih dapat dikompilasi. Kode dalam copy pekerjaannya sering diperbarui tetapi tidak dilakukan. Tidak ada dalam pertanyaan yang menunjukkan bahwa kodenya mungkin memerlukan refactoring - "koboi pengkodean" di sini merujuk pada alur kerjanya SCM, bukan pada kualitas kode aktual

— Idan Arye

@IdanArye Dari pertanyaan awal. ...Try to break it into smaller commits that likely won't compile...Jika ada sesuatu yang mencegah Anda melakukan kode Anda daripada sudah bernyanyi dengan baik, kode itu sulit dikelola. "Berkomitmen" hanyalah salah satu cara untuk bertahan dalam pekerjaan Anda. Kita dapat memikirkan kasus yang lebih ekstrem - "jika ada sesuatu yang mencegah saya menyimpan file sumber". Jadi, apa itu? Saya kira itu takut perubahan Anda sendiri. Kenapa bisa begitu? ... Saya kira Anda mengerti maksudnya

— AlexT

2

Bagi saya sepertinya apa yang mencegahnya melakukan itu hanyalah kemalasan.

— Idan Arye

@IdanArye Anda benar dalam semua hal. Itu plus tidak cukup melakukan TDD, yang merupakan masalah terpisah.

— durron597

@AlexT mempertimbangkan skenario di mana Anda memperbaiki dua bug, dan salah satunya membutuhkan metode yang baru dikembangkan. Jika Anda telah melakukan dengan benar, Anda memperbaiki satu bug, melakukan, lalu memperbaiki bug lainnya. Jika tidak, maka ketika Anda melakukan, Anda harus memasukkan kedua perubahan dalam komit yang sama, atau melakukan perbaikan bug pertama dengan perubahan untuk yang kedua, kecuali versi yang dikomit tidak memiliki pemanggilan metode baru dan oleh karena itu tidak dikompilasi.

— durron597