Haruskah saya mengubah nama penulis di file kelas jika saya membuat lebih dari 80% perubahan?


18

Saya refactoring set kelas tes java yang ada untuk tes UI otomatis. Kadang-kadang saya akhirnya membuat perubahan besar dalam file kelas atau benar-benar merubahnya. Ini membuat saya berpikir bahwa ketika saya menulis ulang seluruh kelas maka haruskah saya mengubah nama penulis di bagian komentar menjadi milik saya?

Apakah saya serakah? atau apakah akan bermanfaat bagi seseorang untuk melihat nama saya dan bertanya kepada saya jika ada keraguan?


17
Apakah Anda menggunakan kontrol versi? Saya menemukan log komit sebagai mekanisme pelacakan yang lebih dapat diandalkan untuk kepengarangan (jika ada kebutuhan yang sah untuk mengetahuinya ...)
rwong

5
Nama harus ada di sana jika memiliki nilai apa pun terhadap kode. Yaitu contact person. Tanggung jawab dan sebagainya. Dan jika demikian, tempel dengan tanggal akhir dan nama baru terlampir.
Independen

15
Apa tujuan memiliki nama autor di file kelas?
BЈовић

2
Jika file memiliki pengganti untuk nama penulis, kemungkinan besar file tersebut juga memiliki pengganti untuk log perubahan. Saya akan memasukkan nama saya di log perubahan bukan penulis asli. Bagaimanapun, saya tidak pernah meninggalkan sidik jari saya sendiri pada kode yang saya tulis, hanya sidik jari bos saya.
mouviciel

1
apa yang salah dengan meninggalkan nama mereka sebagai penulis dan menambahkan baris di bawahnya yang bertuliskan "tanggal nama ditulis ulang /
dire

Jawaban:


15

Itu sangat tergantung ...

Jika menurut Anda ada sedikit peluang bahwa orang lain mungkin tertarik untuk bertanya pada penulis asli, biarkan namanya tercantum dalam kode. Jika Anda berpikir seseorang mungkin tertarik untuk bertanya langsung kepada Anda, biarkan nama Anda ada di dalamnya. Dan jika Anda berpikir, keduanya mungkin, biarkan kedua nama di (atau komentar seperti "berdasarkan karya ...).

Tentu saja, ketika penggunaan kontrol sumber adalah wajib di tempat kerja Anda, dan itu adalah satu-satunya cara untuk mendapatkan akses ke sumber, maka simpan hussle dan lepaskan setiap komentar penulis dari sumbernya. Di tempat kerja saya, misalnya, kami memiliki banyak file sumber di kontrol sumber di mana kami tidak repot-repot menulis nama ke dalam sumber. Jika saya ingin tahu siapa yang bertanggung jawab atas file tersebut, atau pernah ada di masa lalu, atau untuk perubahan tertentu, TortoiseSVN akan dengan mudah membuatkan saya log untuk itu.

Di sisi lain, kami memiliki banyak makro VBA, yang ditulis oleh beberapa orang, diedarkan ke orang lain (beberapa dari mereka meninggalkan perusahaan selama bertahun-tahun) dan banyak dimodifikasi, semuanya tanpa menggunakan kontrol sumber. Untungnya, komentar dari file-file itu sering berisi nama penulis dan semacam log riwayat.


13

Saya baru saja menemukan posting lain di mana OP bertanya apakah nama penulis bahkan harus di header file dan tampaknya bahwa setidaknya 2/3 orang yang menjawab mengatakan bahwa nama itu bahkan tidak boleh dicantumkan dan bahwa Anda harus menggunakan kontrol versi untuk cukup catat siapa yang mengubah file. Tidak tahu apa yang terjadi pada pos itu, tetapi sekarang saya tidak dapat menemukannya. <- (karena itu anonim "OP")

Secara pribadi, saya menemukan penulis yang tercantum dalam header file berguna tetapi karena alasan yang sedikit berbeda (dan ini mungkin tidak berhubungan dengan orang lain di lingkungan mereka). Meskipun kami mencoba mempraktikkan kepemilikan masyarakat dan sering mengerjakan berbagai bagian proyek, kami cenderung memiliki sedikit anggota tim yang mengetahui area tertentu dari kode jauh lebih dekat daripada yang lain. Jadi ketika seseorang (terutama banyak kontraktor yang datang dan pergi) membuka file yang belum pernah mereka lihat sebelumnya, penulis menjadi orang yang tepat. Dia mungkin bukan satu-satunya kontributor, atau bahkan kontributor mayoritas, tetapi memiliki namanya di atas, dia mengakui memiliki tanggung jawab tertentu dalam mendistribusikan pengetahuan / informasi tentang kode ke seluruh tim. Kami dapat membuat daftar lebih dari satu orang di tajuk ini karena banyak orang memang berkontribusi dan merasa bertanggung jawab.

Saya merasa frustrasi ketika saya memiliki pertanyaan tentang file dan harus menggunakan kontrol versi untuk mengidentifikasi orang utama, atau yang paling berpengetahuan. Kemudian akhirnya beralih dari satu orang ke yang berikutnya karena mereka semua menyangkal benar-benar mengetahui apa yang dilakukan kode ... mereka hanya harus masuk dan memperbaiki satu atau dua bug.

Latihan ini bekerja di tim kami karena kami tidak memiliki hand-off. Kecuali jika seseorang berhenti, atau pindah ke tim yang berbeda, kode / proyek itu akan tetap bersama orang tersebut dan dengan tim kami. Jelas jika orang yang menjaga kode tidak sama dengan orang yang menulisnya, maka tidak ada yang akan peduli siapa yang terdaftar di header.

Jadi mengingat pandangan saya pada header file, saya akan mengatakan jika Anda mengubah 80% file dan Anda merasa seperti sekarang Anda adalah orang yang tepat untuk pertanyaan (dan Anda mungkin harus merasa seperti itu), ya, pergi maju dan perbarui header file agar nama Anda ada di sana. Jika Anda merasa tidak enak karena menghapus orang sebelumnya, Anda dapat meninggalkan nama mereka di sana, setidaknya untuk saat ini. Anda selalu dapat meminta penulis asli dan saya yakin mereka tidak akan keberatan sedikit pun bahwa Anda mengubah nama, karena saya berasumsi tidak ada perasaan sulit tentang Anda mengubah 80% dari file itu sendiri.

UPDATE: Menemukan posting itu . Tidak tahu bagaimana saya berhasil menarik sesuatu dari Agustus. Saya baru saja selesai membaca The Pragmatic Programmer dan pada bab terakhir penulis berbicara tentang penandatanganan pekerjaan dan akuntabilitas (posting lain menyebutkannya, itu sebabnya saya mencarinya). Buku itu masuk akal dan sekarang saya memikirkannya, mungkin kita harus memperkenalkan kebijakan tim bahwa siapa pun yang terdaftar sebagai penulis, harus dimasukkan dalam semua ulasan kode file yang bersangkutan. Tidak masalah siapa yang mengubah file terakhir atau paling banyak di SVN, penulis adalah pemilik dan penjaga.


1
Saya melihat poin Anda tetapi siapa yang "OP"?
Tarun

Mungkin ada halaman proyek, atau wiki internal tempat informasi kontak dapat disiapkan untuk dilihat semua orang. Kesulitan dengan menempatkan informasi tersebut (dokumentasi dan penghubung) ke dalam kendali sumber muncul ... selama percabangan dan penggabungan.
rwong

@Tarun: OP = "poster asli" (yaitu orang yang mengajukan pertanyaan). Itu ungkapan yang digunakan di forum diskusi online.
sleske

Setuju dengan @Tarun, tautan ke pos akan membantu menempatkan jawaban Anda dalam perspektif. Saya kira ini yang ini ?
yannis

1
@ rwong: Mengapa ada masalah selama percabangan & penggabungan? Biasanya orang yang menggabungkan perubahan harus memahaminya (jika tidak, mengapa mereka menggabungkannya?). Jadi orang di log adalah orang yang bertanya.
sleske

5

Saya tidak menemukan nama penulisnya sangat berguna. Seperti yang ditunjukkan pertanyaan ini, seringkali tidak ada penulis tunggal, jadi penamaan "penulis" tidak dimungkinkan.

Anda tentu saja dapat memasukkan daftar semua orang yang memberikan kontribusi besar, tetapi Anda sudah dapat memperolehnya dari log kontrol revisi - jadi apa gunanya?

Di proyek saya, tidak ada info penulis di sebagian besar file. Jika Anda memiliki pertanyaan, Anda cukup melihat log, dan biasanya jelas bahwa satu atau dua orang melakukan sebagian besar pekerjaan, jadi Anda bertanya kepada mereka.

Edit

Jawabannya mengasumsikan proyek menggunakan kontrol versi. Jika Anda tidak (secara konsisten) menggunakan VC, maka menempatkan penulis (daftar), dan mungkin beberapa perubahan riwayat ke file mungkin merupakan solusi yang layak. Namun, Anda mungkin harus mulai menggunakan VC secepat mungkin, dalam hal ini lihat di atas :-).


so what's the point?Proyek yang tidak di bawah vcs, proyek yang pada beberapa titik bermigrasi ke vcs yang berbeda (sayangnya, tidak semua skema migrasi memungkinkan migrasi sejarah), dan proyek yang menggunakan lebih dari satu vcs pada saat yang sama - beberapa proyek FLOSS mengadopsinya. pendekatan untuk membuatnya lebih mudah bagi orang untuk berkontribusi, tanpa membatasi mereka pada satu vcs (svn orang menemukan git sulit, git orang menemukan svn tidak dapat digunakan, dan kami hg orang menertawakan keduanya)
yannis

1
@YannisRizos: Oke, itu benar. Secara implisit saya mengasumsikan proyek perangkat lunak apa pun akan menggunakan kontrol versi. Mengedit jawaban saya.
sleske

Dan tentu saja poin saya yang lain harus dengan mudah diselesaikan dengan beberapa vcs-fu minor, terlepas dari vcs yang terlibat. Namun dalam praktiknya mereka jarang, sayangnya.
yannis

2

Jika file telah dimodifikasi secara signifikan, Anda sebaiknya menambahkan nama Anda di file tersebut sebagai seseorang yang mengetahui sesuatu tentangnya.


1

Pembuat file sumber harus / harus selalu (IMHO) disebutkan dalam file sumber. Ini, dengan komentar header yang baik, harus menunjukkan mengapa penulis mengembangkan sumber dan apa yang dia pikirkan untuk menulis kode. Adapun pengelola kode, menambahkan nama pengelola sangat penting untuk pelacakan kontrol sumber.

Penamaan penulis, IMHO lagi, harus menyertakan kode sumber versi, di luar sistem kontrol versi, tanggal pertama ketika perubahan terjadi, serta nomor permintaan perubahan. Alasannya adalah, jika keputusan untuk mengubah VCS muncul, ada riwayat versi kode, siapa penulisnya serta nomor permintaan perubahan yang dapat dirujuk pengembang (jika mereka perlu tahu mengapa pengelola melakukan apa yang dia / dia lakukan). Dia melakukanya). Dengan demikian, dalam organisasi kami, format kami adalah sebagai berikut:

/**
 * $comment
 * <p />
 * $cr_number, $date, $author, $description 
 **/

3
"jika keputusan untuk mengubah VCS muncul, ada riwayat versi kode" Saya harap tidak ada organisasi yang waras yang akan mempertimbangkan untuk memigrasi VCS tanpa memigrasikan sejarah (setidaknya sejarah terkini). Lagi pula, itulah gunanya menggunakan VCS.
sleske

1
Completey tidak setuju. Informasi semacam itu harus dilacak dengan kontrol versi. Kalau tidak, tidak ada cara untuk mengetahui siapa yang membuat perubahan pada baris apa (dengan asumsi lebih dari satu orang telah mengerjakan file). Menempatkannya dalam file hanyalah duplikat kesetiaan yang rendah dari informasi yang tersedia di tempat lain.
Bryan Oakley

1
@Bryan Oakley, saya tidak menghapus kontrol versi sama sekali, saya menyatakan bahwa mengenali kode seseorang adalah cara mengetahui siapa yang bekerja pada sumbernya, tanpa perlu melakukan pencarian yang diperlukan melalui kontrol versi. Selain itu, ada beberapa kode yang tersedia di luar sistem kontrol versi, haruskah nama penulis dikecualikan?
Buhake Sindi

1

Saya suka melihat nama penulis asli, jika hanya untuk menemukan seseorang untuk memulai pencarian saya untuk jawaban tentang kode. (Penulis umumnya tidak memiliki ingatan, tapi setidaknya suntikan!)

Saya sarankan Anda cukup menambahkan nama Anda di bawah nama penulis asli.

Tidak perlu mengganti nama orang lain, karena mereka mungkin tahu beberapa aspek dari kebutuhan bisnis asli yang tidak Anda miliki, dan orang lain mengikuti setelah Anda mungkin perlu berbicara dengan orang itu juga.


+1 untuk paragraf ketiga, karena penulis asli mungkin mengenal beberapa orang lain yang telah melakukan sesuatu dalam kode, tetapi belum mencantumkan namanya di dalamnya.
Coyote21

1

Kebijakan saya tentang komentar @author adalah:

  1. Jika ini file baru, saya menempatkan diri saya sebagai @author.
  2. Jika ini adalah file yang sudah ada, saya meninggalkan @author sendirian, terlepas dari apa yang saya lakukan pada file tersebut.

Jika Anda memiliki pertanyaan tentang sesuatu, tidak masalah siapa @ penulis file tersebut - siapa pun @autor dari bagian file yang Anda edit. Itu untuk apa [git/svn/whatever] blame.

IMO, @author harus pergi.


Di satu sisi, Anda mencantumkan diri Anda sebagai penulis dalam file baru. Di sisi lain, Anda ingin penulis pergi?
Anthony Pegram

1
Standar pengodean perusahaan mensyaratkan adanya tag @author. Kalau tidak, saya tidak akan menggunakannya sama sekali (karena saya ingin pergi :)).
Michael Moussa
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.