Haruskah saya menyimpan kode yang dihasilkan di kontrol sumber


106

Ini adalah debat yang saya ikuti. Saya ingin mendapatkan lebih banyak pendapat dan sudut pandang.

Kami memiliki beberapa kelas yang dihasilkan dalam waktu pembuatan untuk menangani operasi DB (dalam kasus khusus ini, dengan SubSonic, tapi saya rasa itu tidak terlalu penting untuk pertanyaan itu). Generasi ditetapkan sebagai langkah pra-bangun di Visual Studio. Jadi setiap kali developer (atau proses build resmi) menjalankan build, class ini dibuat, lalu dikompilasi ke dalam project.

Sekarang beberapa orang mengklaim, bahwa menyimpan kelas-kelas ini di kontrol sumber dapat menyebabkan kebingungan, jika kode yang Anda dapatkan, tidak cocok dengan apa yang akan dibuat di lingkungan Anda sendiri.

Saya ingin memiliki cara untuk melacak kembali sejarah kode, bahkan jika biasanya diperlakukan sebagai kotak hitam.

Adakah argumen atau argumen balasan?


PEMBARUAN: Saya menanyakan pertanyaan ini karena saya benar-benar yakin ada satu jawaban pasti. Melihat semua tanggapan, saya dapat mengatakan dengan tingkat kepastian yang tinggi, bahwa tidak ada jawaban seperti itu. Keputusan harus dibuat berdasarkan lebih dari satu parameter. Membaca jawaban di bawah ini dapat memberikan pedoman yang sangat baik untuk jenis pertanyaan yang harus Anda tanyakan pada diri Anda sendiri ketika harus memutuskan masalah ini.

Saya tidak akan memilih jawaban yang diterima pada saat ini karena alasan yang disebutkan di atas.


1
Anda mungkin tertarik dengan pertanyaan serupa: stackoverflow.com/questions/739391/…
mouviciel

Saya ingin mengatakan, dalam kasus SubSonic, mungkin menarik untuk tetap dalam kontrol sumber sebagai cara untuk juga melacak (beberapa) perubahan database dengan mudah, jika Anda tidak memiliki cara lain untuk melacak riwayat database Anda.
Earlz

1
Dalam pemikiran saya, masalah utamanya adalah pengembang yang berbeda tidak mendapatkan hasil yang sama saat membuat kelas. Konfigurasi untuk membuatnya harus diperiksa, dan memberikan build yang konsisten di semua lingkungan developer.
nawroth

1
Tidak tahu bagaimana melakukan ini, namun saya pikir pertanyaan ini harus ditutup sekarang karena terlalu terbuka untuk pendapat dan diskusi tanpa terkait erat dengan sistem kontrol sumber tertentu atau jenis file yang dihasilkan tertentu.
Chris Halcrow

Ini adalah pertanyaan yang bagus, tetapi terlalu berdasarkan opini untuk SO, seperti yang ditunjukkan oleh beberapa jawaban yang saling bertentangan, dan komentar OP sendiri untuk efek ini.
Flimzy

Jawaban:


48

Menyimpannya dalam kendali sumber lebih merepotkan daripada nilainya.

Anda harus melakukan commit setiap kali Anda melakukan build agar nilainya menjadi berapa pun.

Umumnya kami meninggalkan kode yang dihasilkan (idl, jaxb stuff, dll) di luar kendali sumber tempat saya bekerja dan itu tidak pernah menjadi masalah


43
Saya tidak setuju dengan "Anda harus melakukan komitmen setiap kali Anda membangun". Ini seharusnya tidak menyebabkan komit tambahan karena satu-satunya hal yang harus memengaruhi komit adalah perubahan pada kode yang karenanya mengubah sumber yang dihasilkan. Jadi pada dasarnya Anda harus memasukkan kode yang dihasilkan hanya ketika Anda sudah melakukan perubahan ke sumber kode yang dihasilkan.
JaredPar

5
Setuju dengan JaredPar. Juga pembuat kode Anda mungkin merupakan alat eksternal, dan jika Anda memperbaruinya, kode yang dihasilkan dapat berubah dan oleh karena itu Anda mungkin perlu melakukan perubahan. Namun dalam kasus ini saya benar-benar ingin melihat perubahan dalam kontrol sumber.
van

Alat yang berbeda dapat menghasilkan sumber yang berbeda (setidaknya mereka mungkin berbeda dalam komentar atau pemformatan kode). Misalnya Ide menambahkan komentar "dihasilkan oleh ide" sedangkan Eclipse tidak.
Petr Gladkikh

1
Pendapat itu terbagi, menandai yang satu ini sebagai jawaban akan menyampaikan pesan yang salah.
Espresso

34

Taruh di kontrol kode sumber. Keuntungan memiliki riwayat dari semua yang Anda tulis tersedia untuk pengembang di masa mendatang lebih besar daripada rasa sakit kecil karena sesekali membangun kembali setelah sinkronisasi.


18
Itu bukan keuntungan - karena kode yang membuatnya diperiksa, Anda sudah memiliki 'semua yang Anda tulis' yang tersedia untuk pengembang di masa mendatang.
Shane C. Mason

13
@Shane, saya sangat tidak setuju. Memiliki kode yang membuatnya tidak sama dengan memiliki kode. Setiap langkah ekstra yang harus disertakan untuk pembuatan adalah gangguan ekstra saat melacak bug. Jauh lebih mudah untuk menelusuri riwayat kode daripada memeriksa versi N file dan menghasilkan kembali versi N dari kode yang dihasilkan.
JaredPar

10
Terkadang bermanfaat untuk memiliki file yang dihasilkan dalam kontrol sumber. Misalnya jika Anda memutakhirkan sebuah komponen, dalam hal ini SubSonic, Anda dapat dengan mudah mendeteksi perubahan dalam sumber yang dihasilkan. Ini bisa berguna untuk melacak bug dan masalah. Saya tidak akan menambahkan semua kode yang dihasilkan ke kontrol sumber. Terkadang sangat berguna. Sebagian besar sistem kendali sumber akan membiarkan Anda melakukan perbedaan untuk melihat apakah file benar-benar berubah meskipun mungkin lebih merupakan proses manual jika Anda harus mengembalikan file secara manual meskipun satu-satunya perubahan adalah stempel waktu.
Ryan

18
Dengan logika itu, Anda juga harus memeriksa file objek yang dikompilasi, pustaka, dan file yang dapat dieksekusi.
Laurence Gonsalves

9
Jenis pembuat kode apa yang Anda gunakan jika "bahasa aslinya tidak ada artinya"? Adapun poin tentang melacak versi alat apa yang Anda gunakan untuk membangun setiap versi kode, Anda sudah perlu menyelesaikan masalah itu untuk seluruh rantai alat Anda. Lagi pula, bagaimana Anda mengharapkan untuk mem-backport bug ke versi lama produk Anda kecuali Anda tahu versi compiler dan linker yang Anda gunakan saat itu? Generator kode tidak berbeda dengan kompiler C ++ / Java / C # Anda. Fakta bahwa Anda mungkin dapat membaca keluarannya tidaklah penting: masukannya adalah sumbernya.
Laurence Gonsalves

31

Setiap kali saya ingin menampilkan perubahan pada pohon sumber di repo pribadi saya, semua 'file yang dihasilkan' akan muncul sebagai telah berubah dan perlu comitting.

Saya lebih suka memiliki daftar modifikasi yang lebih bersih yang hanya mencakup pembaruan nyata yang dilakukan, dan bukan perubahan yang dibuat secara otomatis.

Biarkan mereka keluar, dan kemudian setelah membangun, tambahkan 'abaikan' pada setiap file yang dihasilkan.


3
Selain itu, pada pembaruan, Anda bisa mendapatkan konflik aneh yang oleh VCS akan dianggap membutuhkan resolusi, tetapi sebenarnya akan menyelesaikan sendiri saat Anda membangunnya lagi. Belum lagi kekacauan di batang kayu, yang saya anggap lebih buruk daripada kekacauan di pohon lokal Anda.
rmeador

5
Di mana saya berada, mereka tidak muncul sebagai 'telah berubah' kecuali mereka benar-benar telah berubah. Jika mereka dibuat ulang tetapi masih memiliki konten yang sama sehingga satu-satunya yang berbeda adalah tanggal pembuatan / modifikasi file, sistem mengira mereka belum berubah dan semuanya baik-baik saja.
Joel Coehoorn

+1 Saya hanya ingin bertanggung jawab atas kode apa yang saya tulis, bukan beberapa kode yang dihasilkan oleh beberapa toolkit yang mungkin memiliki masalah pada saat itu yang sekarang tidak dapat diduplikasi (tetapi seseorang dapat menghabiskan banyak waktu untuk mencoba.)
dkretz

4
Saya telah melihat alat pembuat otomatis yang memperbarui stempel waktu setiap kali dijalankan. Saya mengutuk mereka.
Kieveli

25

Lihatlah dengan cara ini: apakah Anda memeriksa file objek Anda ke dalam kontrol sumber? File sumber yang dihasilkan adalah artefak build seperti file objek, pustaka, dan file yang dapat dieksekusi. Mereka harus diperlakukan sama. Sebagian besar akan berpendapat bahwa Anda tidak boleh memeriksa file objek yang dihasilkan dan file yang dapat dieksekusi ke dalam kontrol sumber. Argumen yang sama berlaku untuk sumber yang dihasilkan.

Jika Anda perlu melihat versi historis dari file yang dihasilkan, Anda dapat menyinkronkan ke versi historis dari sumbernya dan membuatnya kembali.

Memeriksa file yang dihasilkan dalam bentuk apa pun ke dalam kontrol sumber mirip dengan denormalisasi database. Ada kadang-kadang alasan untuk melakukan hal ini (biasanya untuk kinerja), tetapi ini harus dilakukan hanya dengan hati-hati karena menjadi jauh lebih sulit untuk mempertahankan kebenaran dan konsistensi sekali data denormalized.


20

Saya akan mengatakan bahwa Anda harus menghindari menambahkan kode yang dihasilkan (atau artefak lain) ke kontrol sumber. Jika kode yang dihasilkan sama untuk input yang diberikan maka Anda bisa memeriksa versi yang ingin Anda diff dan menghasilkan kode untuk perbandingan.


1
FYI, saya telah membagikan skrip untuk melakukan perbandingan itu di sini: stackoverflow.com/a/16754923/105137
kostmo

17

Saya menyebutnya prinsip KERING. Jika Anda sudah memiliki "file sumber" di repositori yang digunakan untuk menghasilkan file kode ini pada waktu pembuatan, tidak perlu ada kode yang sama yang dikomit "dua kali".

Juga, Anda dapat menghindari beberapa masalah dengan cara ini jika misalnya pembuatan kode rusak suatu hari nanti.


15

Tidak, karena tiga alasan.

  1. Kode sumber adalah segalanya yang diperlukan dan cukup untuk mereproduksi snapshot aplikasi Anda pada beberapa titik waktu saat ini atau sebelumnya - tidak lebih dan tidak kurang. Sebagian dari apa yang tersirat di sini adalah bahwa seseorang bertanggung jawab atas segala sesuatu yang masuk. Umumnya saya senang bertanggung jawab atas kode yang saya tulis, tetapi bukan kode yang dihasilkan sebagai konsekuensi dari apa yang saya tulis.

  2. Saya tidak ingin seseorang tergoda untuk mencoba membuat pintasan dari sumber utama dengan menggunakan kode perantara yang mungkin atau mungkin tidak terkini (dan yang lebih penting saya tidak ingin menerima tanggung jawab.) Dan bukankah itu juga menggoda beberapa orang untuk terjebak dalam proses yang tidak berarti tentang konflik debug dalam kode menengah berdasarkan build parsial.

  3. Setelah itu dalam kendali sumber, saya menerima tanggung jawab untuk a. itu ada di sana, b. itu sedang berlangsung, dan c. itu dapat diintegrasikan dengan andal dengan segala sesuatu di sana. Itu termasuk menghapusnya saat saya tidak lagi menggunakannya. Semakin sedikit tanggung jawab itu semakin baik.


14

Saya benar-benar tidak berpikir Anda harus memeriksanya.

Tentunya setiap perubahan dalam kode yang dihasilkan akan menjadi gangguan - perubahan antar lingkungan, atau perubahan sebagai akibat dari sesuatu yang lain - misalnya perubahan dalam DB Anda. Jika skrip pembuatan DB Anda (atau dependensi lainnya) berada dalam kontrol sumber, mengapa Anda membutuhkan skrip yang dihasilkan juga?


8

Aturan umumnya adalah tidak , tetapi jika perlu waktu untuk menghasilkan kode (karena akses DB, layanan web, dll.) Maka Anda mungkin ingin menyimpan versi yang di-cache di kontrol sumber dan menyelamatkan semua orang dari rasa sakit.

Perkakas Anda juga perlu menyadari hal ini dan menangani check-out dari kontrol sumber bila diperlukan, terlalu banyak alat memutuskan untuk check-out dari kontrol sumber tanpa alasan apa pun.
Alat yang baik akan menggunakan versi yang di-cache tanpa menyentuhnya (atau memodifikasi langkah waktu pada file).

Anda juga perlu memberi peringatan besar di dalam kode yang dihasilkan agar orang tidak mengubah file, peringatan di atas tidak cukup, Anda harus mengulanginya setiap lusin baris.


6

Kami juga tidak menyimpan kode DB yang dibuat: karena dibuat, Anda bisa mendapatkannya sesuka hati pada versi apa pun dari file sumber. Menyimpannya sama seperti menyimpan bytecode atau semacamnya.

Sekarang, Anda perlu memastikan pembuat kode yang digunakan pada versi tertentu tersedia! Versi yang lebih baru dapat menghasilkan kode yang berbeda ...


5

Biarkan saja.

Jika Anda memeriksa file yang dihasilkan, Anda melakukan sesuatu yang salah. Apa yang salah mungkin berbeda, bisa jadi proses pembuatan Anda tidak efisien, atau sesuatu yang lain, tetapi saya tidak pernah melihatnya sebagai ide yang bagus. Sejarah harus dikaitkan dengan file sumber, bukan yang dihasilkan.

Itu hanya membuat pusing bagi orang-orang yang akhirnya mencoba menyelesaikan perbedaan, menemukan file yang tidak lagi dibuat oleh build dan kemudian menghapusnya, dll.

Dunia kesakitan menanti mereka yang memeriksa file yang dibuat!


4

Ada kasus khusus di mana Anda ingin memeriksa file yang Anda buat: ketika Anda mungkin perlu membangun sistem di mana alat yang digunakan untuk menghasilkan file lain tidak tersedia. Contoh klasik dari ini, dan yang saya kerjakan, adalah kode Lex dan Yacc. Karena kami mengembangkan sistem runtime yang harus dibangun dan dijalankan pada berbagai macam platform dan arsitektur, kami hanya dapat mengandalkan sistem target untuk memiliki kompiler C dan C ++, bukan alat yang diperlukan untuk menghasilkan kode lexing / parsing untuk definisi antarmuka kami Penerjemah. Jadi, ketika kami mengubah tata bahasa kami, kami memeriksa kode yang dihasilkan untuk menguraikannya.


2
Komentar serupa berlaku untuk file yang dibuat oleh autoconf / automake; kebanyakan orang memeriksa file ./configure dan Makefile.in mereka, meskipun mereka dibuat - sebagian besar pengguna (dan banyak pengembang) tidak perlu membangunnya kembali, dan dengan memeriksa file-file itu, Anda tidak perlu menginstal autotools untuk membangun.
Stobor

1
Ya, kami menyimpan skrip konfigurasi kami dan dependensi Make yang kami buat di kontrol versi juga.
Phil Miller

4

datang agak terlambat ... pokoknya ...

Apakah Anda akan meletakkan file perantara kompiler ke dalam kontrol versi sumber? Dalam hal pembuatan kode, menurut definisi kode sumber adalah input dari generator sedangkan kode yang dihasilkan dapat dianggap sebagai file perantara antara sumber "nyata" dan aplikasi yang dibangun.

Jadi saya akan mengatakan: jangan meletakkan kode yang dihasilkan di bawah kontrol versi, tetapi generator dan inputnya.

Secara konkret, saya bekerja dengan generator kode yang saya tulis: Saya tidak pernah harus memelihara kode sumber yang dihasilkan di bawah kendali versi. Saya bahkan akan mengatakan bahwa karena generator mencapai tingkat kematangan tertentu, saya tidak perlu mengamati konten kode yang dihasilkan meskipun input (misalnya deskripsi model) berubah.


3

Dalam beberapa proyek saya menambahkan kode yang dihasilkan ke kontrol sumber, tetapi itu sangat tergantung. Pedoman dasar saya adalah jika kode yang dihasilkan merupakan bagian intrinsik dari kompilator maka saya tidak akan menambahkannya. Jika kode yang dihasilkan berasal dari alat eksternal, seperti SubSonic dalam kasus ini, maka saya akan menambahkan if ke kontrol sumber. Jika Anda mengupgrade komponen secara berkala maka saya ingin mengetahui perubahan dalam sumber yang dihasilkan jika ada bug atau masalah yang muncul.

Sejauh kode yang dihasilkan perlu diperiksa, skenario terburuk adalah membedakan file secara manual dan mengembalikan file jika perlu. Jika Anda menggunakan svn, Anda dapat menambahkan hook pra-komit di svn untuk menolak komit jika file belum benar-benar berubah.


3

Tugas manajemen konfigurasi (dimana kontrol versinya hanya satu bagian) adalah mampu melakukan hal berikut:

  • Ketahui perubahan dan perbaikan bug mana yang telah diterapkan pada setiap build yang dikirimkan.
  • Mampu mereproduksi persis semua build yang dikirim, mulai dari kode sumber aslinya. Kode yang dibuat secara otomatis tidak dihitung sebagai "kode sumber" apa pun bahasanya.

Yang pertama memastikan bahwa ketika Anda memberi tahu klien atau pengguna akhir "bug yang Anda laporkan minggu lalu telah diperbaiki dan fitur baru telah ditambahkan" mereka tidak kembali dua jam kemudian dan berkata "tidak, belum". Itu juga memastikan mereka tidak mengatakan "Mengapa melakukan X? Kami tidak pernah meminta X".

Yang kedua berarti bahwa ketika klien atau pengguna akhir melaporkan bug di beberapa versi yang Anda keluarkan setahun yang lalu, Anda dapat kembali ke versi itu, mereproduksi bug, memperbaikinya, dan membuktikan bahwa itu adalah perbaikan Anda telah menghilangkan bug daripada beberapa gangguan pada kompilator dan perbaikan lainnya.

Ini berarti kompilator, pustaka, dll. Anda juga harus menjadi bagian dari CM.

Jadi sekarang untuk menjawab pertanyaan Anda: jika Anda dapat melakukan semua hal di atas maka Anda tidak perlu merekam representasi perantara, karena Anda dijamin mendapatkan jawaban yang sama. Jika Anda tidak dapat melakukan semua hal di atas, maka semua taruhan dibatalkan karena Anda tidak dapat menjamin untuk melakukan hal yang sama dua kali dan mendapatkan jawaban yang sama. Jadi Anda sebaiknya meletakkan semua file .o Anda di bawah kontrol versi juga.


2

Itu sangat tergantung. Pada akhirnya, tujuannya adalah untuk dapat mereproduksi apa yang Anda miliki jika diperlukan. Jika Anda dapat meregenerasi binari dengan tepat, Anda tidak perlu menyimpannya. tetapi Anda perlu ingat bahwa untuk membuat ulang barang-barang Anda, Anda mungkin memerlukan konfigurasi persis seperti yang Anda lakukan di tempat pertama, dan itu tidak hanya berarti kode sumber Anda, tetapi juga lingkungan build Anda, IDE Anda, bahkan mungkin perpustakaan lain , generator atau barang, dalam konfigurasi yang tepat (versi) yang Anda gunakan.

Saya mengalami masalah dalam proyek jika kami meningkatkan lingkungan pembuatan kami ke versi yang lebih baru atau bahkan ke vendor lain, di mana kami tidak dapat membuat ulang binari persis seperti yang kami miliki sebelumnya. Ini sangat merepotkan ketika binari yang akan digunakan bergantung pada jenis hash, terutama di lingkungan yang aman, dan file yang dibuat kembali entah bagaimana berbeda karena peningkatan kompiler atau apa pun.

Jadi, apakah Anda akan menyimpan kode yang dihasilkan: Saya akan mengatakan tidak. Biner atau kiriman yang dirilis, termasuk alat yang Anda reproduksi dengan saya akan simpan. Dan kemudian, tidak perlu menyimpannya di kontrol sumber, cukup buat cadangan file tersebut dengan baik.


"itu tidak hanya berarti kode sumber Anda, tetapi juga lingkungan build Anda, IDE Anda, bahkan mungkin library, generator, atau hal lainnya" \ n Itu saja yang akan saya periksa. Jika Anda membangun compiler Anda dari sumber di setiap mesin developer sebagai bagian dari build yang sama dengan aplikasi Anda (yaitu: Anda mengetik 'make' sekali), periksa sumbernya. Jika tidak, periksa binari
KeyserSoze

2

Jawaban yang benar adalah "Tergantung". Itu tergantung pada apa kebutuhan klien. Jika Anda dapat memutar kembali kode ke rilis tertentu dan mempertahankan setiap audit eksternal tanpanya, maka Anda masih belum yakin. Sebagai pengembang, kita perlu mempertimbangkan tidak hanya 'kebisingan', rasa sakit, dan ruang disk, tetapi fakta bahwa kita ditugaskan dengan peran menghasilkan kekayaan intelektual dan mungkin ada konsekuensi hukum. Dapatkah Anda membuktikan kepada hakim bahwa Anda dapat membuat ulang situs web persis seperti yang dilihat pelanggan dua tahun lalu?

Saya tidak menyarankan Anda menyimpan atau tidak menyimpan file gen, dengan cara apa pun Anda memutuskan apakah Anda tidak melibatkan Pakar Subjek dari keputusan Anda mungkin salah.

Dua sen saya.


Anda membuat poin yang menarik, dan tidak mengambil downvote secara pribadi, hanya saja untuk tujuan praktis di lingkungan pengembang yang serba cepat, ini tidak praktis. Mengapa kode yang dibuat secara otomatis membawa data apa pun yang berhubungan dengan konten atau IP? Saya akan menyarankan bahwa klien secara umum tidak akan dapat memahami implikasi dari kode yang dihasilkan otomatis pengontrol sumber dan mungkin secara umum tidak boleh ditawarkan opsi ini. IMHO itu terlalu banyak overhead dan biaya, untuk memperhatikan situasi hukum hipotetis dan tidak mungkin.
Chris Halcrow

Dalam domain yang saya miliki saat ini, asuransi klien kami (sangat besar) menyimpan SEMUANYA selama minimal 10 tahun. Kami membangun alat canggih untuk meningkatkan layanan WCF. Klien menyimpan kode yang dihasilkan, templat, semuanya. Tapi itu klien saya. Kira Anda melewatkan poin yang saya buat bahwa "Itu tergantung pada kebutuhan klien" & "dengan cara apa pun Anda memutuskan apakah Anda tidak melibatkan Pakar Subjek dalam keputusan Anda mungkin salah." Jika entah bagaimana itu adalah jawaban yang buruk, atau itu membuat Anda merasa lebih baik memberi -1, senang telah membantu. Lihat 'womp' pada komentar di atas jawaban saya.
James Fleming

2

Ada argumen baik yang mendukung dan menentang yang disajikan di sini. Sebagai catatan, saya membangun sistem generasi T4 di Visual Studio dan opsi default out-of-the-box kami menyebabkan kode yang dihasilkan diperiksa. Anda harus bekerja sedikit lebih keras jika Anda memilih untuk tidak check-in.

Bagi saya, pertimbangan utamanya adalah membedakan output yang dihasilkan ketika input atau generator itu sendiri diperbarui.

Jika Anda tidak memiliki keluaran yang diperiksa, maka Anda harus mengambil salinan dari semua kode yang dihasilkan sebelum memutakhirkan generator atau mengubah masukan agar dapat membandingkannya dengan keluaran dari versi baru. Saya pikir ini adalah proses yang cukup membosankan, tetapi dengan keluaran yang dicentang, ini masalah sederhana untuk membedakan keluaran baru terhadap repositori.

Pada titik ini, masuk akal untuk bertanya "Mengapa Anda peduli dengan perubahan dalam kode yang dihasilkan?" (Terutama dibandingkan dengan kode objek.) Saya percaya ada beberapa alasan utama, yang turun ke keadaan seni saat ini daripada masalah yang melekat.

  1. Anda membuat kode tulisan tangan yang terhubung erat dengan kode yang dihasilkan. Itu tidak terjadi secara keseluruhan dengan file obj hari ini. Ketika kode yang dihasilkan berubah, sayangnya cukup sering terjadi beberapa kode tulisan tangan perlu diubah agar cocok. Orang sering tidak mengamati tingkat kompatibilitas mundur yang tinggi dengan poin ekstensibilitas dalam kode yang dihasilkan.

  2. Kode yang dihasilkan hanya mengubah perilakunya. Anda tidak akan mentolerir hal ini dari kompiler, tetapi sejujurnya, generator kode tingkat aplikasi menargetkan bidang masalah yang berbeda dengan solusi yang lebih luas yang dapat diterima. Penting untuk melihat apakah asumsi yang Anda buat tentang perilaku sebelumnya sekarang rusak.

  3. Anda hanya tidak 100% mempercayai output generator Anda dari rilis ke rilis. Ada banyak nilai yang bisa didapat dari alat generator bahkan jika alat itu tidak dibangun dan dipelihara dengan ketatnya vendor kompiler Anda. Rilis 1.0 mungkin sangat stabil untuk aplikasi Anda, tetapi mungkin 1.1 memiliki beberapa gangguan untuk kasus penggunaan Anda sekarang. Atau Anda mengubah nilai input dan mendapati bahwa Anda sedang menjalankan generator baru yang belum pernah Anda gunakan sebelumnya - kemungkinan besar Anda akan terkejut dengan hasilnya.

Pada dasarnya semua hal ini bermuara pada kedewasaan alat - sebagian besar pembuat kode aplikasi bisnis tidak mendekati level yang dimiliki kompiler atau bahkan alat level lex / yacc selama bertahun-tahun.


2

Kedua belah pihak memiliki argumen yang valid dan masuk akal, dan sulit untuk menyepakati sesuatu yang sama. Sistem Kontrol Versi (VCS) melacak file yang dimasukkan oleh pengembang ke dalamnya, dan memiliki asumsi bahwa file di dalam VCS dibuat dengan tangan oleh pengembang, dan pengembang tertarik dengan riwayat dan perubahan antara revisi file apa pun. Asumsi ini menyamakan dua konsep, "Saya ingin mendapatkan file ini saat saya melakukan pembayaran." dan "Saya tertarik dengan perubahan file ini."

Sekarang, argumen dari kedua sisi dapat dirumuskan ulang seperti ini:

  • "Saya ingin mendapatkan semua file yang dihasilkan ini saat saya melakukan pembayaran, karena saya tidak memiliki alat untuk membuatnya di mesin ini."
  • "Saya tidak boleh memasukkannya ke VCS, karena saya tidak tertarik dengan perubahan file ini."

Untungnya, kedua persyaratan tersebut secara fundamental tidak saling bertentangan. Dengan beberapa ekstensi dari VCS saat ini, keduanya seharusnya dapat dimiliki. Dengan kata lain, ini adalah dilema yang salah. Jika kita merenungkan beberapa saat, tidak sulit untuk menyadari bahwa masalahnya berasal dari asumsi VCS berlaku. VCS harus membedakan file, yang dibuat oleh pengembang, dari file yang tidak dibuat oleh developer, tetapi kebetulan ada di dalam VCS ini. Untuk kategori file pertama, yang biasanya kami sebut file sumber (kode), VCS telah melakukan pekerjaan dengan baik sekarang. Untuk kategori yang terakhir, setahu saya VCS belum punya konsep seperti itu.

Ringkasan

Saya akan menggunakan git sebagai salah satu contoh untuk menggambarkan apa yang saya maksud.

  • git status seharusnya tidak menampilkan file yang dihasilkan secara default.
  • git commit harus menyertakan file yang dihasilkan sebagai snapshot.
  • git diff seharusnya tidak menampilkan file yang dihasilkan secara default.

PS

Git hooks dapat digunakan sebagai solusi, tetapi akan lebih bagus jika git mendukungnya secara native. gitignoretidak memenuhi persyaratan kami, karena file yang diabaikan tidak akan masuk ke VCS.enter code here


1

Saya akan berdebat. Jika Anda menggunakan proses integrasi berkelanjutan yang memeriksa kode, mengubah nomor build, membangun perangkat lunak, lalu mengujinya, maka lebih sederhana dan lebih mudah untuk hanya memiliki kode itu sebagai bagian dari repositori Anda.

Selain itu, ini adalah bagian tak terpisahkan dari setiap "snapshot" yang Anda ambil dari repositori perangkat lunak Anda. Jika itu bagian dari perangkat lunak, maka itu harus menjadi bagian dari repositori.


5
Saya suka drive oleh -1. Jika Anda tidak setuju, jangan pilih - pilih jawaban lainnya. Simpan suara negatif untuk jawaban yang salah. Ini adalah pertanyaan subjektif.
womp

1

Saya akan mengatakan bahwa ya Anda ingin meletakkannya di bawah kendali sumber. Dari sudut pandang manajemen konfigurasi, SEGALA SESUATU yang digunakan untuk menghasilkan software build perlu dikontrol agar dapat dibuat ulang. Saya memahami bahwa kode yang dihasilkan dapat dengan mudah dibuat ulang, tetapi argumen dapat dibuat bahwa itu tidak sama karena tanggal / stempel waktu akan berbeda antara dua build. Di beberapa bidang seperti pemerintah, mereka membutuhkan banyak waktu untuk melakukan apa yang dilakukan.


2
Apakah Anda memeriksa file objek Anda (.o)?
KeyserSoze

1

Secara umum, kode yang dihasilkan tidak perlu disimpan di kontrol sumber karena riwayat revisi kode ini dapat dilacak oleh riwayat revisi kode yang menghasilkannya!

Namun, sepertinya OP menggunakan kode yang dihasilkan sebagai lapisan akses data aplikasi alih-alih menulisnya secara manual. Dalam kasus ini, saya akan mengubah proses pembuatan, dan memasukkan kode ke kontrol sumber karena ini adalah komponen penting dari kode runtime. Ini juga menghilangkan ketergantungan pada alat pembuat kode dari proses pembangunan jika pengembang perlu menggunakan versi alat yang berbeda untuk cabang yang berbeda.

Tampaknya kode hanya perlu dibuat sekali, bukan setiap build. Ketika pengembang perlu menambah / menghapus / mengubah cara objek mengakses database, kode harus dibuat lagi, seperti membuat modifikasi manual. Ini mempercepat proses pembangunan, memungkinkan pengoptimalan manual dilakukan pada lapisan akses data, dan riwayat lapisan akses data dipertahankan dengan cara yang sederhana.


Saya tidak setuju. Jika Anda membuatnya dengan proses manual, itu akan rusak, dan tidak ada yang akan memperhatikan sampai tiba waktunya untuk menjalankannya kembali. Jika dibuat setiap hari di server build Anda (dan setiap mesin developer saat melakukan build 'bersih'), Anda tidak akan terkejut.
KeyserSoze

Jika kode lapisan akses data diperiksa ke kontrol sumber, seharusnya tidak ada kejutan karena orang akan dipaksa untuk memperbarui kode. Jika seseorang kebetulan mengubah versi alat pembuat kode pada mesin build dan pengembang memiliki versi lama pada mesin pengembangan mereka (mungkin cabang kode yang berbeda), maka akan ada sakit kepala. Saya menyarankan agar dia menghapus langkah pembuatan kode dari proses pembuatan, karena mereka bukan pengelola generator kode.
benson

1

Saya (dengan menyesal) akhirnya meletakkan banyak sumber turunan di bawah kendali sumber karena saya bekerja dari jarak jauh dengan orang-orang yang tidak dapat diganggu untuk mengatur lingkungan bangunan yang tepat atau yang tidak memiliki keterampilan untuk mengaturnya sehingga sumber turunan dibuat dengan tepat. (Dan dalam hal Gnu autotools, saya sendiri adalah salah satu dari orang-orang itu! Saya tidak dapat bekerja dengan tiga sistem berbeda yang masing-masing bekerja dengan versi autotools yang berbeda — dan hanya versi itu.)

Kesulitan semacam ini mungkin lebih berlaku untuk proyek paruh waktu, sukarelawan, sumber terbuka daripada proyek berbayar di mana orang yang membayar tagihan dapat menuntut lingkungan pembuatan yang seragam.

Saat Anda melakukan ini, pada dasarnya Anda berkomitmen untuk membuat file turunan hanya di satu situs, atau hanya di situs yang dikonfigurasi dengan benar. Makefile Anda (atau apa pun) harus disiapkan untuk mengetahui di mana mereka berjalan dan harus menolak untuk mendapatkan kembali sumber kecuali mereka tahu mereka berjalan di situs build yang aman.


1

Jika itu adalah bagian dari kode sumber maka itu harus diletakkan di kendali sumber terlepas dari siapa atau apa yang membuatnya. Anda ingin kontrol sumber Anda mencerminkan status sistem Anda saat ini tanpa harus membuatnya kembali.


"tanpa harus meregenerasinya." jadi Anda memeriksa binari yang dikompilasi? Apakah Anda juga memeriksa versi platform target? Strategi itu tidak akan berkembang dengan baik. :(
dss539

1
Dan itu memberi saya suara buruk ?? Tentu saja Anda tidak memeriksa biner terkompilasi (kecuali mereka berasal dari perpustakaan pihak ketiga) karena mereka dapat dibuat ulang dari kode sumber Anda. Saya berbicara tentang harus meregenerasi kode yang dihasilkan bukan binari. Tapi, hei, jika Anda ingin salah menafsirkan apa yang saya katakan, silakan saja ...
mezoid

Jawaban ini tidak pantas untuk diremehkan! Paling tidak, tampaknya terdengar untuk memasukkan kode yang dihasilkan di SC (mungkin di tempat yang diidentifikasi dengan jelas) sehingga setidaknya Anda dapat membandingkan hash kode yang digunakan untuk menghasilkan objek terhadap kode baru yang akan Anda tuju. buat untuk bangunan baru. Menarik betapa polarisasi pertanyaan ini.
rp.

1

Benar-benar memiliki kode yang dihasilkan dalam kendali sumber, karena berbagai alasan. Saya mengulangi apa yang telah dikatakan banyak orang, tetapi beberapa alasan saya melakukannya adalah

  1. Dengan file kode di kontrol sumber, Anda berpotensi dapat mengkompilasi kode tanpa menggunakan langkah pra-build Visual Studio Anda.
  2. Saat Anda melakukan perbandingan penuh antara dua versi, alangkah baiknya mengetahui jika kode yang dihasilkan berubah di antara kedua tag tersebut, tanpa harus memeriksanya secara manual.
  3. Jika pembuat kode itu sendiri berubah, Anda harus memastikan bahwa perubahan pada kode yang dihasilkan berubah dengan tepat. yaitu Jika generator Anda berubah, tetapi outputnya tidak seharusnya berubah, maka saat Anda memasukkan kode Anda, tidak akan ada perbedaan antara apa yang sebelumnya dibuat dan apa yang ada di kode yang dibuat sekarang.

1
Dan pembuat kode Anda sendiri tidak dalam kendali sumber karena ...?
Jeffrey Hantin

@Jeffrey: Saya tidak pernah mengatakan pembuat kode tidak dalam kendali sumber.
Joe Enos

Saya tahu, saya hanya menggoda. :-) Saya telah menemukan bahwa banyak generator kode berbasis CodeDom suka menghasilkan keluaran mereka dalam urutan acak, jadi untuk pengulangan (dan dengan demikian kemampuan untuk dengan mudah mengetahui apakah kode yang dihasilkan berubah dari run ke run) I ' telah menulis rutinitas yang mengurutkan konten a CodeCompileUnitke dalam urutan kanonik.
Jeffrey Hantin

0

Aku akan meninggalkan file yang dihasilkan keluar dari pohon sumber, tetapi meletakkannya di pohon membangun terpisah.

misalnya alur kerja

  1. checkin / out / modifikasi / gabungkan sumber secara normal (tanpa file yang dihasilkan)
  2. Pada kesempatan yang tepat, periksa pohon sumber menjadi pohon bangunan yang bersih
  3. Setelah membangun, check in semua file "penting" (file sumber "asli", file yang dapat dijalankan + file sumber yang dihasilkan) yang harus ada untuk keperluan audit / pengaturan. Ini memberi Anda riwayat semua kode yang dihasilkan yang sesuai + executable + apa pun, pada penambahan waktu yang terkait dengan rilis / pengujian snapshot, dll. Dan dipisahkan dari pengembangan sehari-hari.

Mungkin ada cara yang baik di Subversion / Mercurial / Git / etc untuk mengikat sejarah file sumber sebenarnya di kedua tempat secara bersamaan.


0

Sepertinya ada pendapat yang sangat kuat dan meyakinkan di kedua sisi. Saya akan merekomendasikan membaca semua jawaban pilihan teratas, dan kemudian memutuskan argumen apa yang berlaku untuk kasus spesifik Anda.

PEMBARUAN: Saya menanyakan pertanyaan ini karena saya benar-benar yakin ada satu jawaban pasti. Melihat semua tanggapan, saya dapat mengatakan dengan tingkat kepastian yang tinggi, bahwa tidak ada jawaban seperti itu. Keputusan harus dibuat berdasarkan lebih dari satu parameter. Membaca jawaban lain dapat memberikan pedoman yang sangat baik untuk jenis pertanyaan yang harus Anda tanyakan pada diri Anda sendiri ketika harus memutuskan masalah ini.

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.