Rekan kerja mengganti nama semua pertanyaan saya [ditutup]


63

Saya tidak tahu apakah saya harus sangat kesal atau apa. Saya seorang diri membangun lebih dari 300 pertanyaan untuk database besar, dan mengembangkan konvensi penamaan sehingga saya bisa menemukannya nanti. Tidak ada orang lain di kantor saya yang tahu cara membuat permintaan, tetapi saya datang kemarin untuk menemukan bahwa semuanya telah diganti nama. Sekarang saya mengalami kesulitan menemukan sesuatu, dan saya mencoba mencari tahu apa yang harus dilakukan.

Saya berbicara dengan orang yang bertanggung jawab, dan dia meremehkan semuanya. Dia bilang dia mengganti nama mereka sehingga dia bisa menemukannya dengan lebih mudah. Sayangnya, saya satu-satunya yang tahu bagaimana membangun, mengedit, dan memeliharanya, dan satu-satunya alasan dia perlu menemukannya adalah untuk menguji kueri. Konvensi penamaan yang baru sama sekali tidak masuk akal, dan saya merasa kami telah mengambil langkah mundur dalam proses pengembangan.

Yang saya coba cari tahu adalah:

1) Apakah saya bereaksi berlebihan?

2) Apa cara terbaik untuk menangani ini? Saya benci menyebutkan hal ini kepada bos saya, tetapi setelah berbicara dengan rekan kerja saya kemarin, saya sudah bisa mengatakan dia merasa seperti dia tidak melakukan kesalahan.


29
Meskipun kami bekerja dalam tim, ada konsep siapa yang memiliki apa, dan izin harus ditanyakan sebelum mengubah kode yang telah dibuat orang lain. Sekali saya melakukannya (saya malu mengatakannya) dan saya ditegur. Ketika itu terjadi pada saya, saya telah mengubahnya kembali dan meminta mereka untuk tidak melakukannya.
Mike Dunlavey

30
Duel saat fajar! ...

46
Anda memiliki cadangan / SVN kan? Kembalikan ke sebelum perubahannya, dan rileks.
JYelton

11
jika seseorang mengganti nama kode saya, saya akan langsung mengambil nyawa seperti Shang Tsung!
Glenn Ferrie

24
Jika dia punya anak, ganti nama mereka.
Matt

Jawaban:


81
  1. Tidak juga - itu hal yang sangat tidak sopan untuk dilakukan.

  2. Anda telah berbicara dengannya dan kami belum melakukannya, tetapi sepertinya Anda berhak memulihkan konvensi penamaan sebelumnya dari cadangan atau mengembalikannya jika berada dalam kontrol sumber. JANGAN beri tahu atasan dan rekan kerja Anda jika Anda melakukan ini, dan berikan alasan Anda (Anda tidak dapat mempertahankan pekerjaan Anda sendiri).

Hal terakhir yang ingin Anda lakukan adalah bolak-balik mengenai hal ini meskipun begitu menanganinya karena situasinya tampaknya akan berubah, tetapi setidaknya harus didokumentasikan jika itu menjadi bagian dari pola rasa tidak hormat.


81
Selain itu, jika perannya dalam proyek ini sebenarnya "tester", ia sama sekali tidak berhak mengubah kode sumber. Titik. Tetapi saya ingin menambahkan bahwa, untuk mencegah situasi seperti ini, Anda harus menyusun dokumen kecil (peluru!) Yang menyatakan konvensi penamaan, karena, di masa depan perusahaan Anda dapat mempekerjakan seseorang untuk bekerja dengan Anda, atau bahkan berkoordinasi Anda, dan itu akan menjadi haknya untuk mengubah penamaan jika tidak ada konvensi resmi .
Bruno Brant

1
Saya setuju dengan jawaban ini. Jika Anda tidak melakukan apa-apa, Anda menetapkan preseden yang dapat memperburuk ketidaksepakatan di masa depan.
JYelton

2
Jelaskan padanya bagaimana penamaan Anda bekerja
GerManson

13
Pastikan Anda mengambil hak pengeditannya ke basis data saat Anda berada di ...
Ant

1
@ Tidak: Jika contoh OP adalah keseluruhan cerita, saya pikir itu mungkin agak keras. Jika ada lebih dari itu (atau mereka seharusnya tidak memiliki hak mengedit di tempat pertama) Anda mungkin benar.
BCS

117

Mengapa Anda tidak menanganinya seperti orang dewasa: duduk, non-konfrontatif, dan buat daftar pro dan kontra untuk skema penamaan, sepakati satu dan buat itu resmi dengan menulis dokumen singkat yang menggambarkannya. Dapatkan minat tulus pada inputnya sehingga dia merasa (dan) terlibat.

Jika itu sebagian besar masalah selera dan jika dia adalah tipe orang yang benar-benar harus melakukan hal-hal seperti itu, maka hanya senang bahwa Anda adalah orang yang lebih besar dan melepaskannya. Hidup ini terlalu singkat untuk mengikuti kontes skema penamaan.

Apakah masalahnya skema penamaan atau Anda merasa tidak dihormati? Jika demikian, mungkin Anda bisa memperbaiki hubungan kerja Anda. Jika Anda merasa itu tidak layak maka mengapa Anda peduli dengan apa yang dia pikirkan? :) Pilihan lain mungkin dia benar-benar tidak merasa itu masalah besar dan jika Anda menjelaskan dengan baik bahwa Anda kesulitan menemukan barang-barang mungkin Anda dapat mengubahnya kembali.


2
Saya akan mengatakan mengubahnya kembali dan memintanya untuk tidak melakukan itu, tetapi jawaban Anda bahkan lebih baik.
Mike Dunlavey

Ini cukup tepat.
Wayne Molina

20
Dan kemudian membuatnya mengubahnya ke konvensi BARU yang disepakati :)

7
@konrad, Anda menghadapi satu masalah krusial - seorang tester tidak memiliki otoritas atau bisnis apa pun yang melakukan pengeditan seperti ini sejak awal . @anon adalah programmer yang bertanggung jawab, penamaan konvensi adalah keputusannya sendiri, dan mereka tidak siap untuk pemungutan suara komite, apalagi perubahan sepihak oleh seseorang yang tidak akan pernah harus men-debug kode sesudahnya.
Shadur

36
  1. Desain basis data mencakup izin (GRANT dan REVOKE).
  2. Pengujian mencakup izin pengujian.
  3. Relatif sedikit orang yang memiliki izin untuk mengganti nama objek database.
  4. Rekan kerja Anda bukan satu dari sedikit.

Ini adalah poin yang sangat bagus. Saya bertanya-tanya mengapa seorang tester bahkan akan memiliki akses ke ini di tempat pertama.
Justin Ohms

Karena itu Akses. Tidak ada GRANT dan REVOKE di Access. Tidak ada izin sama sekali.
Kibbee

7
Sebenarnya ada izin di Access, tapi saya belum pernah bertemu seseorang yang mengerti bagaimana mereka seharusnya digunakan (apalagi menerapkannya)
Mchl

1
Karena tidak diragukan lagi, perusahaan yang sama ini mungkin bahkan tidak memiliki sistem kontrol sumber, apalagi DBA yang memenuhi syarat yang telah mengunci Access. tapi Anda harus mencarinya tidak terlalu sulit untuk dilakukan.
Tipe Anonim

21

"Konvensi penamaan yang baru sama sekali tidak masuk akal" terdengar seperti salah satu dari ini yang mungkin terjadi:

  1. Dia menerapkan beberapa norma perusahaan kepada mereka. Ini sering digunakan untuk memastikan kode setidaknya konsisten, dan dalam kasus terbaik dapat membantu hal-hal tambahan seperti skrip khusus kecil untuk menemukan kode dengan mudah. Dalam hal ini, Anda perlu memahami norma dan mengapa hal itu "tidak masuk akal" dalam situasi Anda. Jika Anda masih berpikir lebih baik bagi semua pengembang untuk membiarkannya seperti itu, jelaskan kepada mereka mengapa metode Anda lebih unggul, dan tanyakan apakah Anda dapat mengubah norma (mungkin OK jika mereka setuju itu lebih unggul) atau melupakannya dalam kasus Anda (tidak mungkin dan berantakan dalam jangka panjang).
  2. Dia menciptakan standarnya sendiri di tempat dan menerapkannya. Ini lebih mungkin jika dia baru, dan dia harus menjelaskan alasannya. Anda mungkin belajar sesuatu, dan / atau dia mungkin belajar sesuatu jika Anda kemudian menjelaskan alasan Anda.

Poin penting adalah bahwa itu bukan kode Anda (tunggal), jika ada sesuatu yang menjadi miliknya, dan akan dimodifikasi oleh, seluruh kelompok. Tidak ada kritik tentang kode yang harus dipusatkan pada siapa yang menulisnya.


2
+1 poin bagus. semua orang yang menjawab menganggap si penanya memiliki skema penamaan yang valid. Bagaimana jika dia benar-benar perusahaan "penimbun informasi". Mungkin dengan tester yang sebenarnya membuatnya lebih mudah bagi orang lain (dan siapa pun yang baru) di perusahaan untuk menemukan pertanyaan.
Tipe Anonim

Poin bagus. Jika skema penamaan yang baik, maka kedua belah pihak akan dapat menggunakannya (setelah mereka terbiasa) tidak peduli siapa yang datang dengan itu.
BCS

2
@ bcs Bahkan dalam kasus itu, cara yang tepat untuk melakukannya adalah memberi tahu programmer terlebih dahulu dan memintanya untuk mengubah konvensi penamaan sendiri, daripada menyelinap masuk dan menunggunya datang bekerja keesokan harinya dan menemukan / seluruh strukturnya dianiaya.
Shadur

16

Saya berbicara dengan orang yang bertanggung jawab, dan dia meremehkan semuanya.


Lalu aku akan memberitahumu, tanpa malu-malu:

Kembalikan perubahan.

Lakukan perang ini. Manajer Anda harus mendukung Anda dan memperkuat otoritas Anda.


Sepakat. Periksa dulu dengan dia bahwa tidak ada alasan bagus mengapa nama-nama baru itu lebih baik. Jika tidak ubah saja kembali.
Richard

11
Kapan "Wage this war" adalah nasihat yang bagus?
Sverre Rabbelier

3
@Sverre Rabbelier: ... Ketika n00b mencoba menginstal praktik perangkat lunak yang tidak optimal. OP mencoba berdebat dengannya. Sekarang saatnya untuk memperbaiki masalah. Debat ad nauseum dengan n00b tentang sesuatu yang begitu jelas adalah gerakan yang tidak produktif dan sia-sia.
Jim G.

4
@ Jim Mungkin OP adalah newb?
Joe Phillips

3
Jika dia bukan bos Anda, ubah omong kosong itu dan jangan lihat ke belakang. Saya tidak mengatakan perang upah, tapi tentu saja jangan biarkan seseorang bertindak seperti mereka memiliki tempat itu. Manajer proyek adalah orang-orang yang seharusnya menegakkan standar pengkodean. Ini bukan tentang otoritas, tetapi tentang pengalaman, ketertiban, dan lingkungan kerja yang produktif.
Jonathan Henson

10

1) Tidak, Anda tidak bereaksi berlebihan. Seseorang mengubah pekerjaan Anda tanpa memberi tahu Anda dan menepisnya ketika Anda bertanya mengapa. Itu imho yang sangat tidak sopan dan kasar.

2) Apakah Anda DBA resmi, atau setidaknya orang yang telah menjadi penjaga DB? Jika demikian, ubah kembali nama dan tulis dokumen konvensi untuk cara Anda melakukan sesuatu. Juga, tulis dokumen gaya 'Panduan Pengguna' sehingga jika seseorang harus masuk ke DB dan menemukan sesuatu yang mereka bisa.

Saya akan mengirimkan ini ke grup, tanpa menunjukkan jari, dengan catatan bermanfaat bahwa Anda akan dengan senang hati duduk dan mengajak orang melewati beberapa nuansa struktur.

Jika tidak, maka buatlah konvensi sebagai sebuah tim dan ikuti mereka sebagai sebuah tim.

Di samping catatan, untuk seseorang yang harus menguji sesuatu untuk mengubah nama 300+ pertanyaan tampaknya cukup kekanak-kanakan. Berapa banyak waktu yang dia buang untuk melakukan ini, dan hanya supaya dia dapat menemukan barang-barang? Alih-alih hanya pergi dan meminta bantuan seseorang, dia menyia-nyiakan waktu, waktu Anda, dan waktu perusahaan. Belum lagi kode mungkin rusak ketika dia melakukan ini, sehingga membuang waktu anggota tim lain juga.

Jika saya jadi Anda, saya akan menunggu sampai Anda sedikit tenang, coba dan bicara dengannya lagi. Jika itu tidak berhasil, lakukanlah dengan bos. Mentalitas koboi semacam itu pada akhirnya akan membuat seluruh tim terikat.


8

Mengganti nama secara acak dalam database dapat dengan mudah menyebabkan lingkungan produksi turun. Jika prosedur-prosedur itu direferensikan di suatu tempat dalam kode itu dapat memiliki konsekuensi serius. Anda dapat melakukan roll back, tetapi jika tester seperti ini benar-benar tidak tahu apa yang dia lakukan, itu tidak jauh dari langkah untuk melihat tester membuat beberapa perubahan pada produksi. Itu bisa berarti kehilangan bisnis, itulah sebabnya Anda harus mencoba menerapkan peran pengguna yang terpisah untuk pengembang dan penguji. Kami melakukannya dengan penguji kami dan itu bekerja dengan baik. Penguji sering menghargainya, karena mereka tidak harus hidup dalam ketakutan mengacaukan data langsung.


5

Tampaknya tidak disentuh di tempat lain, tetapi sumber apa pun (misalnya, kueri) yang diletakkan di tempat umum harus berada di bawah sistem kontrol versi.

Kemudian jika rekan kerja mengubah skema penamaan Anda, Anda dapat dengan mudah kembali ke skema kerja Anda (dan melihat perubahannya; dan berpotensi mengembalikan kembali jika perlu). Anda juga mengikat perubahan pada pengguna tertentu, sehingga Anda dapat melihat siapa yang mengacaukan segalanya.


2

Jangan melihat kuda hadiah di mulut.

Pertama, kepemilikan kode kolektif - mereka tidak boleh menjadi milik Anda.

Kedua, jika mereka telah mengganti nama mereka maka tanyakan alasan di sekitar skema penamaan yang baru. Entah mereka menggunakan kueri - dalam hal ini semacam panggilan mereka; atau itu adalah langkah pertama di dalamnya mulai memberi Anda bantuan dalam mempertahankan ini.

Jika semua orang berpikir mereka adalah 'milikmu', kamu tidak akan pernah menyingkirkannya, dan beralih ke sesuatu yang baru


2

Saya tidak tahu apakah ini telah ditanyakan tetapi konvensi penamaan mana yang merupakan versi resmi? Jika versi Anda resmi, maka saya akan mengatakan mengatasi masalah dari perspektif. Jadi alih-alih mengatakan "Orang X mengembalikan semua perubahan saya", katakan saja "Orang X melakukan perubahan yang bertentangan dengan konvensi penamaan resmi". Jika tidak ada konvensi resmi, maka saya sarankan untuk memberi tahu dia bahwa Anda tidak menghargai perubahan yang dilakukan tanpa berkonsultasi terlebih dahulu dengan Anda.

Dalam kedua kasus itu, saya pikir mengobarkan "perang" bukanlah jawabannya. Bahkan jika Anda menang, Anda kalah.


Ini satu-satunya jawaban yang benar. Jika ada standar penamaan, maka nama harus sesuai dengan standar, dan siapa pun yang ingin mereka memiliki nama lain salah. Jika tidak ada standar penamaan, harus ada standar penamaan - tim, atau pemimpin teknologi atau siapa pun - harus menulis satu. Konvensi pengkodean seperti ini membosankan, tetapi merupakan bagian penting dari tatanan sosial yang memungkinkan tim untuk beroperasi.
Tom Anderson

1

Itu adalah perilaku yang mengerikan. Sepertinya dia tidak menyesal, jadi bawalah ke atasanmu dan buat kasus agar aksesnya dicabut sampai dia yakin tidak akan dipusingkan.

Jika bos Anda tidak teknis, jelaskan dengan istilah yang akan mereka pahami. Bayangkan mulai bekerja di ruang pos, tempat pos dipilah ke dalam lubang merpati yang siap dikirim. Anda memutuskan secara sepihak untuk menyortir lubang merpati berdasarkan lantai kemudian nama keluarga bukannya sistem departemen saat ini kemudian lantai. Ini mungkin membuat hidup Anda lebih mudah dalam jangka pendek, tetapi Anda akan dibunuh oleh staf ruang pos lainnya.

Ini tidak sopan. Saya akan sangat marah.


1

Selain mengatur izin untuk menghentikan orang acak mengubahnya, Anda juga harus menjelaskan karena itu adalah tugasnya untuk menguji fungsionalitas, Anda tidak dapat memberikan jaminan keandalan jika orang acak membuat perubahan pada kode.


1

Seperti semua orang katakan, dia seharusnya tidak melakukan ini, jika hanya karena menghormati Anda karena Anda adalah pembuat pencipta dari pertanyaan ini.

Karena itu, saya tidak melihat ada yang menyebutkan fakta bahwa jika dia benar-benar mengubah nama pertanyaan Anda, itu karena dia tidak bisa memahami konvensi penamaan Anda.
Jadi masalah ini dapat dengan mudah diselesaikan dengan mendokumentasikan konvensi penamaan Anda dan memastikan bahwa rekan kerja memiliki akses ke dokumen dan dapat menemukan apa yang mereka butuhkan.

Anda juga harus berhati-hati dan mempertimbangkan bagaimana orang lain akan menemukan dan menggunakan pertanyaan Anda: jika konvensi penamaan Anda tidak memungkinkan mereka untuk melakukan pekerjaan mereka secara efisien, maka Anda mungkin perlu mempertahankan daftar pertanyaan Anda yang lebih menyeluruh, menggunakan mungkin tag dan kata kunci yang disepakati sehingga orang lain dapat menemukan apa yang mereka cari.

Kuncinya di sini saya pikir adalah tidak ada yang bekerja dalam isolasi dan cara terbaik untuk menghindari langkah kaki masing-masing adalah berkomunikasi dan menyepakati aturan-aturan dasar bersama.


0

Saya akan menanggapi dengan cara yang sama - mengecilkan keputusan Anda untuk mengembalikan semuanya. Kembalikan perubahannya dan tulis email yang sangat singkat untuk rekan kerja Anda:

"Kembalikan ubah rXXXX untuk sekarang, karena tidak mengerti itu penamaan konvensi. Terima kasih sudah mencoba. :)"


0

Ya, Anda bereaksi berlebihan.

Ada sesuatu yang disebut kontrol versi yang antara lain digunakan untuk tidak harus mengalahkan $ #! 7 dari rekan kerja ketika mereka mengacaukan barang-barang Anda. Hanya kembalikan ke versi sebelumnya dan kunci file karena itu membiarkannya menangani kemarahan. Itu akan membuka kesempatan bagi Anda untuk menjelaskan bahwa melakukan perubahan radikal pada kode yang memiliki ketergantungan pada barang orang lain tanpa alasan yang kuat dan tanpa bertanya terlebih dahulu bukan hanya salah, sangat tidak praktis dan praktis merupakan dosa.

Tentu saja ini mengasumsikan bahwa konvensi penamaan Anda lebih baik daripada dia dan bahwa Anda benar-benar dapat membuat cadangan keputusan ini dengan argumen obyektif yang kuat, jika itu tidak terjadi, hal yang paling bijak untuk dilakukan adalah mulai mengubah kode Anda sesegera mungkin untuk menangani perubahan dan cobalah membuat konvensi penamaan yang lebih baik lain kali.

Jangan bawa ke bos Anda, cara dewasa untuk menyelesaikannya adalah langsung dengan rekan kerja Anda, Anda harus bekerja dengannya setelah itu sehingga bodoh untuk merusak hubungan untuk pertengkaran yang mudah dipecahkan.

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.