Apakah pernah boleh untuk melakukan kode yang tidak berfungsi?


40

Apakah ide yang baik untuk mengharuskan hanya melakukan kode kerja?

Komit ini tidak perlu meninggalkan repositori dalam kondisi kerja sebagai:

  • ... kita sedang dalam tahap desain awal, kodenya belum stabil.
  • ... Anda adalah satu-satunya pengembang di proyek ini. Anda tahu mengapa semuanya tidak berfungsi. Selain itu, Anda tidak menghentikan pekerjaan siapa pun dengan melakukan kode yang rusak.
  • ... kode saat ini tidak berfungsi. Kami akan membuat perubahan besar untuk itu. Mari kita berkomitmen, agar ada titik untuk kembali ke jika semuanya menjadi jelek.
  • ... rantai panjang, tidak ada masalah jika kode yang rusak ada di cabang lokal. Yaitu

    1. file lokal
    2. area pementasan
    3. berkomitmen di cabang lokal
    4. melakukan di cabang fitur pribadi jarak jauh
    5. bergabung dengan developcabang jarak jauh
    6. bergabung dengan mastercabang jarak jauh
    7. bergabung dengan releasecabang jarak jauh
  • ... Berkomitmen awal, komit sering.

Jadi, dalam pertanyaan yang ditautkan di atas, sebagian besar jawaban mengatakan bahwa melakukan kode yang tidak dapat dikompilasi bukanlah masalah di cabang lokal dan fitur. Mengapa? Apa nilai komit yang rusak?


Ditambahkan: Ada beberapa komentar dengan suara sangat tinggi, yang mengatakan bahwa pada local brach seseorang dapat melakukan apapun yang diinginkan. Namun, saya tidak tertarik pada sisi teknis dari pertanyaan itu. Sebaliknya, saya ingin mempelajari praktik-praktik terbaik - kebiasaan, bahwa orang-orang yang telah bekerja bertahun-tahun di industri ini, telah menjadi yang paling produktif.


Saya kagum dengan banyaknya jawaban hebat! Mereka menuntun saya pada kesimpulan bahwa saya tidak cukup mahir menggunakan cabang untuk mengatur kode saya.


28
Di cabang lokal semuanya berjalan. Lakukan apa pun yang Anda inginkan. Bersihkan sebelum Anda mendorong.
Joachim Sauer

@ Joachim Sauer, saya bertanya tentang praktik terbaik dan alasan di baliknya, untuk membangun kebiasaan yang baik . Saat ini saya sering melakukan kode yang rusak. Dan kembali adalah mimpi buruk, melalui puluhan komitmen selama beberapa hari terakhir.
Vorac

9
jika Anda mengembangkan setiap fitur di cabangnya sendiri, maka keputusan itu sepele: buang cabangnya, lanjutkan dari cabang baru yang dibuat pada master saat ini
Joachim Sauer

1
kecuali Anda mendefinisikan apa yang membuat komit "rusak", tidak mungkin untuk menjawab pertanyaan ini secara otoritatif. Lihat juga: Haruskah seorang programmer memperbaiki bangunan gagal orang lain?
Agak

1
"Kenapa? Apa nilai komit yang rusak?" Kemampuan untuk mengidentifikasi masalah dan menguji beberapa resolusi berbeda di atasnya dan untuk dapat kembali ke masalah yang Anda tahu Anda miliki secara andal, daripada keadaan di mana Anda mendapatkan itu dan mungkin beberapa yang baru, juga .
Joshua Taylor

Jawaban:


20

Salah satu filosofi percabangan (bagian Mengembangkan Strategi Pencabangan dan Kebijakan Codeline dalam Strategi Pencabangan SCM Tingkat Lanjut - juga membaca praktik - praktik Perforce Best , yang merupakan pdf tetapi masuk ke beberapa perincian lainnya) adalah bahwa Anda bercabang pada kebijakan incompatabile.

Kebijakan codeline menentukan penggunaan wajar dan check-in yang diizinkan untuk codeline, dan merupakan panduan pengguna yang penting untuk codeline SCM. Misalnya, kebijakan codeline pengembangan harus menyatakan bahwa itu bukan untuk dirilis; demikian juga, kebijakan codeline rilis harus membatasi perubahan pada perbaikan bug yang disetujui. Kebijakan ini juga dapat menjelaskan cara mendokumentasikan perubahan yang diperiksa, pemeriksaan apa yang diperlukan, pengujian apa yang diperlukan, dan ekspektasi stabilitas kodeline setelah check-in. Kebijakan adalah komponen penting untuk proses pengembangan perangkat lunak yang terdokumentasi dan dapat ditegakkan, dan kodeline tanpa kebijakan, dari sudut pandang SCM, berada di luar kendali.

(dari Praktik Terbaik Perforce)

Katakanlah Anda memiliki 'rilis' cabang (atau 'master') dari mana rilis dibuat dan 'trunk' (atau 'dev') tempat pengembang memeriksa kode kerja. Ini adalah kebijakan cabang. Memperhatikan 'kode kerja' adalah bagian dari kebijakan cabang 'dev', seseorang tidak boleh melakukan kode rusak ke cabang dev. Seringkali ada hal-hal seperti server CI terhubung ke cabang-cabang ini dan memeriksa kode yang rusak ke dev dapat mengacaukan cabang semua orang dan merusak build.

Namun, ada saat-saat yang tepat untuk memeriksa kode parsial yang tidak berfungsi. Dalam hal ini, seseorang harus bercabang - kebijakan yang tidak kompatibel dengan trunk. Di cabang baru ini, seseorang dapat memutuskan kebijakan ('kode rusak ok') dan kemudian komit kode untuk itu.

Ada satu aturan sederhana untuk menentukan apakah codeline harus bercabang: itu harus bercabang ketika penggunanya membutuhkan kebijakan check-in yang berbeda. Misalnya, grup pelepasan produk mungkin memerlukan kebijakan check-in yang memberlakukan pengujian yang ketat, sedangkan tim pengembangan mungkin memerlukan kebijakan yang memungkinkan check-in yang sering terhadap perubahan yang diuji sebagian. Divergensi kebijakan ini memerlukan cabang codeline. Ketika satu kelompok pengembangan tidak ingin melihat yang lain

(dari Praktik Terbaik Perforce)

Sadarilah bahwa ini berasal dari server pusat berbasis SCM dengan pola pikir perusahaan yang kuat. Gagasan intinya masih bagus. Ini sering dianggap secara implisit - Anda tidak memeriksa kode dev yang belum diuji ke cabang rilis. Itu sebuah kebijakan.

Jadi cabang, katakan bahwa cabang ini dapat memiliki kode yang rusak dan komit.


40

Salah satu filosofi yang disarankan oleh Linus Torvalds adalah bahwa pemrograman kreatif harus seperti serangkaian eksperimen. Anda punya ide, dan ikuti. Tidak selalu berhasil, tetapi setidaknya Anda mencobanya. Anda ingin mendorong pengembang untuk mencoba ide-ide kreatif, dan untuk melakukan itu, harus murah untuk mencoba eksperimen itu, dan murah untuk pulih. Ini adalah kekuatan sebenarnya dari git yang berkomitmen sangat murah (cepat dan mudah). Ini membuka paradigma kreatif yang memberdayakan pengembang untuk mencoba hal yang mungkin tidak mereka miliki. Ini adalah pembebasan git.


2
Sungguh suatu hal yang indah. Saya tidak berpikir masyarakat telah benar-benar belajar menghargai git dan DVCS secara umum.
ChaosPandion

5
Selama orang tidak membingungkan filosofi ini dengan program trial and error, yang harus dihindari.
Pieter B

10

Ya, selama itu bukan cabang rilis.

Di cabang pribadi, semuanya berjalan dan kemudian dapat dibuang jika percobaan tidak berhasil. Itulah salah satu manfaat utama DVCS: kebebasan

Nilai komit kode yang rusak ?: kolaborasi dan eksperimen


Tweak kecil: Ya, selama itu tidak akan berjalan dalam produksi. Kode yang disembunyikan oleh fitur toggle, misalnya.
Rob Crawford

5

Ya tidak apa-apa dan itu adalah sesuatu yang saya lakukan banyak.

Inti dari melakukan kode yang tidak dapat dikompilasi (setidaknya di cabang) adalah bahwa kadang-kadang kode Anda sedang dalam proses, tetapi pekerjaan yang dilakukan sejauh ini layak disimpan dan / atau dibagikan dengan orang lain

Praktik saya adalah:

  • tulis tes terlebih dahulu
  • komitmen wip (work-in-progress) baik
  • sering melakukan (beberapa kali dalam sehari) dan awal (menyimpan langkah 'bekerja')
  • dorong setelah setiap komit (seandainya hard drive Anda macet / bus menabrak Anda).
  • selalu bekerja di cabang dulu
  • bila memungkinkan hanya menggabungkan kode kerja menjadi master
  • rebase interaktif di git untuk squash wip sebelum master merge

Masalah utama dan mungkin yang Anda sentuh adalah ketika Anda memiliki fitur yang pada dasarnya berfungsi dan sangat dibutuhkan oleh bisnis (dan karenanya perlu di 'master') tetapi memiliki beberapa tes gagal. Salah satu opsi di sini mungkin melakukan tes tertunda yang memungkinkan Anda bergerak maju untuk saat ini. Namun ini penuh dengan bahaya karena tes mungkin tidak pernah diperbaiki dan mungkin menetapkan pola di daerah lain dari hanya tes yang tertunda keluar daripada memperbaiki mereka.

Pilihan lain adalah menggunakan sementara dan menyebarkan cabang. Ini dapat membantu dalam situasi tertentu tetapi umumnya tidak direkomendasikan dan tidak berkelanjutan.

Mungkin pilihan terbaik pada dasarnya adalah mengambil pendekatan yang lebih profesional untuk pengembangan perangkat lunak dan benar-benar memerlukan tes kerja untuk setiap kode yang berkomitmen. Ini sering merupakan bagian 'sulit' dari pengembangan perangkat lunak, bukan pengkodean yang dibayangkan banyak orang. Pendekatan yang lebih baik kemungkinan akan membutuhkan estimasi awal yang lebih baik, alokasi sumber daya, penetapan prioritas, dll. Ditambah, selama pengembangan Agile, memberikan waktu yang cukup dan menggunakan disiplin yang cukup untuk memperbaiki masalah apa pun baik pada saat itu terjadi maupun selama sesi penunjukan perawatan.

Berfokuslah pada apa yang dimaksud dengan 'selesai' - artinya kode DAN tes ditulis, telah di refactored dan berfungsi. Jika Anda mendengar komentar seperti "sebagian besar dilakukan, hanya perlu menulis / memperbaiki / menguji tes, maka TIDAK dilakukan. Mengatakan fitur dilakukan tanpa secara teknis lengkap adalah salah satu kesalahan paling umum dari programmer junior.


3

Nilai dari setiap komit, rusak atau tidak, adalah bahwa kode tersebut dikomit ke server. Dalam lingkungan profesional, server itu aman, berlebihan dan menjalankan cadangan. Jika saya bekerja sepanjang hari, komit adalah bentuk memastikan kode saya bertahan apa pun yang terjadi pada mesin lokal saya. Hard disk mati. Laptop hilang atau dicuri. Cadangan dari server repositori akan tersedia bahkan jika gedung terbakar.


8
Ini tidak selalu benar untuk DVCSes. Misalnya, jika repositori pribadi lokal Anda atau cabang fitur lokal, itu mungkin atau mungkin tidak didukung (dan ini terutama berlaku jika Anda bekerja offline dari jaringan perusahaan tanpa akses ke sumber daya perusahaan). Cabang master dan release harus di suatu tempat yang didukung, tetapi itu tidak selalu berlaku untuk cabang lokal.
Thomas Owens

Bahkan pada DVCSes, commit bernilai sesuatu, karena kode di dalamnya "lebih permanen" daripada yang ada di file. Setidaknya untuk git.
Joachim Sauer

3
@ThomasOwens, dengan segala hormat, jika admin DVCS Anda mengatur sistem Anda sehingga repositori atau cabang lokal tidak didukung, admin DVCS Anda adalah idiot dan perlu mencari pekerjaan baru yang lebih sesuai dengan bakatnya ("Apakah Anda ingin kentang goreng dengan itu? "). Jika admin DVCS Anda melakukannya dengan cara itu karena orang-orang IT Anda menyuruhnya, itu juga berlaku untuk organisasi TI Anda. Jika ada, ini bisa dibilang merupakan dakwaan dari seluruh konsep DVCS: komit kode ke VCS harus BY DEFINISI berarti komit ke backup otomatis.
John R. Strohm

6
@ JohnR.Strohm Saat bepergian, saya sering memiliki akses jaringan terbatas, jadi saya tidak memiliki akses ke sumber daya cadangan atau drive jaringan apa pun. Saya mengembangkan tanpa cadangan hingga saya memiliki akses ke jaringan. Ini adalah titik dari DVCS - Anda tidak perlu jaringan. Haruskah repo Anda dicadangkan? Mungkin, tapi itu hanya persyaratan untuk rilis atau master repo. Anda benar-benar tidak boleh pergi berhari-hari antara mendorong ke repo yang didukung, tetapi dorongan itu tidak boleh kode rusak.
Thomas Owens

1
@ThomasOwens maksud saya adalah bahwa meskipun akses Anda ke server cadangan itu hanya sporadis, berkomitmen untuk itu harus menjadi prioritas daripada membuat kode Anda berfungsi. Anda selalu dapat membuat kode Anda berfungsi di komputer lain, bahkan orang lain di tim Anda dapat membuat kode berfungsi di mesin mereka. Jika hanya duduk di mesin Anda, pelanggan kemungkinan besar tidak akan peduli jika itu berhasil. Pelanggan peduli untuk rilis baru dari server build yang pada gilirannya menarik dari repositori server.
nvoigt

3

Pikirkan seperti ini. Sebagai pengembang, salah satu hal paling mengganggu yang Anda lakukan adalah menghentikan pengembang lain di tim Anda dari mengerjakan tugas mereka.

Filosofi dari hanya melakukan kode kerja berasal dari tim pengembangan yang mengerjakan batang tunggal yang sama dalam repositori. Ini mungkin terlihat gila sekarang, tetapi 10 tahun yang lalu, ini adalah cara kerja normal. Cabang akan muncul ketika Anda ingin membuat rilis yang stabil, tetapi pemikiran seorang pengembang yang bekerja di cabang untuk mengimplementasikan fitur baru hampir tidak pernah terdengar.

Jika lingkungan Anda berarti bahwa komitmen Anda tidak langsung memengaruhi pengembang lain, maka sering-seringlah komit. itu memberi Anda lebih banyak keamanan dalam kode Anda, membuatnya lebih mudah untuk memutar kembali kesalahan kode dan banyak sistem kontrol sumber memberi Anda beberapa perlindungan kode untuk kode yang dilakukan (meskipun tidak semua).

Sekarang, pastikan penggabungan Anda dengan cabang yang dibagikan dengan pengembang lain berfungsi, dan bahwa kode apa pun yang Anda promosikan untuk kompilasi tingkat ini, lulus semua pengujian unit dan pemeriksaan kewarasan berbasis tim lainnya ... itu sangat penting jika Anda tidak ingin tetap membeli bir di pub ...


3

Sebelum Anda mulai dogmatis tentang cara bekerja dengan kontrol versi Anda, ada baiknya memikirkan mengapa Anda bekerja dengan kontrol versi.

Berkomitmen pada kontrol versi membekukan status kode Anda untuk referensi di masa mendatang - segala sesuatu yang lain tidak cocok untuk ini. Melihat perbedaan dan membuat tambalan hanya melihat bagaimana kode berubah di antara snapshot. Cabang dan tag hanyalah cara mengatur snapshot. Berbagi kode dengan pengembang lain hanya membiarkan mereka melihat snapshot tertentu.

Kapan Anda harus berkomitmen? Ketika ada kesempatan yang masuk akal, Anda akan melihat status kode Anda (atau pesan komit yang menjelaskan perubahan) di masa mendatang.

Git memberi Anda banyak fleksibilitas tentang bagaimana mengatur foto Anda. Tidak ada repositori pusat sehingga Anda dapat membagikan kode Anda dengan pengembang lain tanpa mendorong status Anda ke repositori 'utama'. Anda dapat dengan mudah membuat, menggabungkan & menghapus cabang untuk mengisolasi detail dari set negara dari narasi kode utama. Anda dapat berkomitmen secara lokal, untuk membantu Anda membatalkan mengikuti perkembangan Anda saat ini, dan kemudian mengelompokkan semuanya menjadi satu komitmen sebelum mendorongnya untuk dilihat orang lain. Anda dapat menandai revisi tertentu agar mudah ditemukan nanti.

CIUMAN . Apa yang bekerja paling baik untuk satu pengembang pada tahap awal pengembangan sebuah proyek kecil akan sangat berbeda dari apa yang perlu Anda lakukan ketika Anda memiliki seratus pengembang yang bekerja pada sistem misi kritis berusia satu dekade. Dalam proses pengembangan perangkat lunak apa pun, Anda harus menghindari membuat artefak yang tidak perlu hanya karena orang lain menyuruh Anda melakukannya.


Jawaban Anda menginspirasi, tetapi tidak jelas bagi saya. Masalah saya saat ini adalah saya membuat (saya pikir) terlalu banyak komitmen, dan ketika saya perlu kembali, saya tidak tahu ke mana, karena banyak dari mereka tidak bekerja. Konteksnya adalah pengembangan solo tim kecil <5. Saya pikir saya mengambil "terlalu sering melakukan" hal yang terlalu jauh dan mungkin perlu dipulihkan. Bagaimana cara saya melakukan, yang akan memiliki pesan komit yang bermakna?
Vorac

1
Jika Anda harus berkomitmen setiap kali mengkompilasi / menguji, mungkin Anda perlu menemukan editor yang lebih baik yang memberi Anda lebih banyak undo histori. Jika Anda tidak dapat menulis pesan komit yang secara bermakna mengekspresikan perubahan Anda, jangan komit.
Sean McSomething

Jika Anda kesulitan mengingat apa yang harus Anda lakukan, Anda tidak cukup sering menggabungkan perubahan Anda. Simpan cabang "stabil", cabang "pengembangan" dan cabang "eksperimental". Ketika kode berfungsi, gabungkan perubahan Anda dari "eksperimental" menjadi "dev" (squash komit Anda terlebih dahulu), lalu bebaskan untuk memecahkan "eksperimental" dengan mengetahui Anda bisa menghapusnya dan membuat cabang baru dari "dev". Setelah seluruh fitur selesai, gabungkan dev menjadi stabil.
RubberDuck

2

Bangun / Keluarkan Cabang

Anda seharusnya tidak pernah dengan sengaja melakukan kode rusak ke cabang build. Cabang apa pun yang berada di bawah integrasi terus-menerus atau yang darinya rilis atau build harian dibuat harus selalu dalam kondisi yang berpotensi untuk dirilis.

Cabang Lain: Sering Menyimpan Negara

Untuk cabang pribadi atau fitur, tujuannya seringkali berbeda. Check-in kode yang sering (apakah berfungsi atau tidak) mungkin diinginkan. Secara umum, Anda akan ingin melakukan kapan saja Anda mungkin perlu mundur ke keadaan saat ini.

Pertimbangkan contoh-contoh ini di mana kondisi tersimpan memberikan manfaat yang signifikan:

  • Anda dapat melakukan komit tepat sebelum menjalankan pencarian dan penggantian global sehingga Anda dapat mengembalikan pohon Anda dalam satu operasi jika terjadi kesalahan.
  • Anda mungkin melakukan serangkaian komitmen sementara sambil refactoring sepotong kode yang kompleks sehingga Anda dapat membagi dua atau mundur jika Anda akhirnya melanggar sesuatu dalam proses.
  • Anda dapat melakukan komit, memulai cabang baru, atau membuat tag ketika Anda ingin mencoba sesuatu yang eksperimental sambil dapat kembali ke keadaan pohon kerja saat ini setiap saat.

0

Melakukan beberapa basis kode yang rusak tidak masalah selama masih bersifat lokal.

Mengapa?

  • Sangat penting untuk menggunakan komitmen sebagai titik penyimpanan dalam pengembangan Anda
  • Ini menunjukkan kepada Anda pola pemikiran yang digunakan saat mengembangkan produk.
  • Itu tidak merusak kolaborasi .

Namun, ketika ada tim programmer, filosofi rumah pemrograman adalah yang terpenting dan menggantikan perilaku komitmen individu. Beberapa program pemrograman memutuskan untuk mencatat semua kemajuan sementara yang lain memutuskan untuk hanya melakukan kode yang memecahkan fitur. Dalam hal ini, nilai ( biaya , dari sudut pandang manajemen perangkat lunak) dari komit yang rusak sangat mengerikan:

  1. waktu yang digunakan untuk fitur lebih lanjut sekarang dihabiskan untuk memperbaiki kesalahan ...
  2. pemotongan pengembangan tidak terpenuhi ...
  3. produk tidak dikirim tepat waktu

Poin-poin lain dapat ditambahkan ke tiga cascading efek mereka secara eksponensial ke dalam krisis perusahaan ... tentu saja, ini harus menjadi efek dari kebiasaan kronis melakukan kode buruk.


0

Saya rasa tidak apa-apa untuk melakukan kode yang rusak.

Apa yang terjadi jika

  • Diperlukan perbaikan terbaru yang mendesak. Basis kode dalam keadaan rusak. Anda dipaksa untuk memutar kembali, memperbaiki, dan menggunakan.

  • Orang lain mulai bekerja di cabang yang sama tanpa mengetahui bahwa Anda telah melakukan kode yang rusak. Mereka mungkin mengejar 'herring merah' berpikir bahwa perubahan mereka telah merusak sesuatu.

  • Anda memutuskan untuk meninggalkan perusahaan, pergi berlibur atau tidak bisa datang kerja karena alasan apa pun. Kolega Anda harus menggali lebih dalam untuk menemukan apa yang rusak dan mengapa itu dilakukan dalam keadaan rusak.

  • Seseorang menyebarkan 'kode rusak' Anda? Ini bisa menjadi 'game over' jika Anda bekerja dengan data pribadi atau penyedia pembayaran.

Balas ke @ WarrenT

Saya setuju dengan Anda bahwa di dunia yang ideal di mana semua orang bekerja di cabang fitur, melakukan kode yang tidak berfungsi mungkin berhasil. Saya telah bekerja pada proyek-proyek besar dan bahkan kemudian ada kasus di mana banyak orang harus bekerja dalam satu cabang fitur. Saya juga melihat orang-orang melakukan kode 'tidak berfungsi' ke cabang utama karena rilis beberapa minggu lagi dan mereka berencana memperbaikinya hari berikutnya. Semua hal ini adalah kandidat untuk bencana dan saya sangat percaya bahwa mereka harus dihindari dengan cara apa pun.


Turunkan suara. Tidak satu pun dari skenario ini yang mungkin terjadi jika Anda menggunakan alur kerja DVCS standar.
user16764

1
Dengan alur kerja git (atau DVCS lainnya), pengembang bekerja pada cabang, cabang lokal, BUKAN batang utama. Pertanyaan selanjutnya adalah apakah pengembang pernah mendorong kode yang rusak ke repositori lain. Ini adalah masalah tim yang memiliki pemahaman tentang apa cabang untuk apa, dan menggunakan komentar yang baik pada komitmen Anda. Perbaikan panas hanya akan dilakukan pada cabang rilis. Tentu saja tidak ada yang harus menggabungkan kode yang rusak di sana. Tim memang perlu memiliki aturan tentang alur kerja, tetapi apa yang dilakukan di repositori lokal adalah masalah yang sama sekali berbeda.
WarrenT

Saya pikir ada perbedaan antara "kode tidak berfungsi" (apa yang diminta OP) dan "kode rusak" yang Anda rujuk.
Simon

@ WarrenT Silakan lihat balasannya.
CodeART

-1

Beberapa pertanyaan untuk membantu Anda menentukan apakah boleh melakukan kode yang tidak berfungsi:

  1. Apakah Anda terlalu banyak bekerja?
  2. Apakah rekan tim Anda terus-menerus merusak bangunan?
  3. Apakah basis kode Anda berantakan dan sepertinya tidak bisa lebih buruk?

Jika Anda menjawab ya untuk salah satu di atas, maka ya tidak apa-apa untuk melakukan kode yang tidak berfungsi.

Ingatlah untuk memperbaikinya sesegera mungkin, tutup dengan unit test yang berlaku, dan minta maaf karena melanggar build.

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.