it-swarm-id.com

Bagaimana cara memberi tahu atasan Anda bahwa gaya pemrogramannya sangat buruk?

Saya seorang mahasiswa dan di waktu senggang saya bekerja untuk perusahaan besar sebagai Java pengembang. Pekerjaannya bagus, tetapi masalahnya adalah, bos saya menulis kode yang sangat aneh. Saya tidak tidak ingin mengeluh, tetapi beberapa masalah menurut saya sangat aneh. Misalnya:

  • dia tidak tahu boolean. Semua kondisi boolean adalah Strings yang disebut "YesOrNo" dan kemudian dalam kondisi yang ia gunakan if (YesOrNo == "Yes")

  • ada banyak karakter yang sangat aneh dalam nama metode dan variabel seperti é õ ô atau è

  • semua loop adalah loop tak terbatas dengan gaya for (;;). Kemudian pada akhir loop kondisi diuji dan jika kondisi terpenuhi istirahat; disebut.

Saya tidak tahu apakah saya harus mengatakan kepadanya bahwa saya pikir ini bukan praktik yang baik, karena dia adalah bos saya dan memutuskan bagaimana dan apa yang harus dilakukan. Di sisi lain beberapa contohnya benar-benar sangat aneh.

Adakah petunjuk bagaimana cara mengatasinya? Dan apakah hanya saya yang berpikir ini gaya buruk?

63

Mintalah dia untuk menjelaskan kodenya kepada Anda

Katakan padanya Anda belum pernah melihat X diprogram seperti itu sebelumnya, dan tanyakan kepadanya mengapa ia mengkodekannya seperti itu. Tunjukkan padanya cara Anda mengkodekannya, dan beri tahu mengapa Anda melakukannya dengan cara itu (praktik terbaik, kinerja yang lebih baik, lebih sedikit kemungkinan kesalahan, lebih mudah bagi programmer lain untuk membaca/memelihara, dll).

Pastikan untuk menyiapkan semua argumen Anda sebelumnya, dan fokuskan pada mengapa metode Anda yang terbaik daripada mengapa metodenya yang terburuk. Setelah itu, lihat apakah dia masih mendukung metodenya di atas milikmu.

Jika dia terbuka untuk perbaikan, dia kemungkinan akan mengubah cara pengkodeannya. Jika ia masih lebih suka menggunakan gaya pengkodeannya untuk Anda, Anda tidak akan mengubah pendapatnya.

78
Rachel

Promosikan penggunaan analisis statis otomatis dan alat pengecekan gaya seperti linter dan pencari bug (dalam bahasa apa pun yang Anda gunakan). Jika semua orang di perusahaan mulai menggunakannya (mis., Mereka diberi mandat sebelum checkin), ia tidak dipilih.

Alasan saya menyarankan ini adalah:

1) Orang biasanya lebih suka mengecam dari alat otomatis daripada rekan kerja atau bawahan mereka.

2) Alat-alat ini mencakup banyak masalah yang dapat dianggap sebagai gaya yang buruk.

3) Anda bisa Tweak aturan di balik layar untuk gaya buruknya di luar apa yang dibangun ke dalam alat. Misalnya, menegakkan gaya variabel tertentu.

4) Beberapa orang menyadari bahwa kode mereka tidak begitu baik dan benar-benar mulai lebih memperhatikan bahkan pada hal-hal yang tidak tercakup oleh linter.

Cukup banyak perusahaan yang dihormati (seperti majikan saya sendiri) memaksakan pemeriksaan serat sebelum check-in. Pandangannya adalah bahwa gaya buruk adalah hutang teknis. Anda selalu dapat menggunakan "Ya, jika X dan Y dan Z melakukannya, itu mungkin ide yang baik".

39
Uri

Saya pikir Anda pasti tidak harus memberitahunya hal seperti itu secara langsung . Pernyataan seperti itu dapat dengan mudah menyebabkan reaksi defensif dalam dirinya, yang hampir pasti akan menutup kemungkinan baginya untuk belajar, dan bahkan dapat menyebabkan masalah bagi Anda.

Alih-alih, cari (dan bahkan coba ciptakan) peluang untuk santai mendiskusikan gaya pengkodean dan masalah idiom dan menyebut dia "praktik terbaik" yang Anda ketahui. Tentu saja, Anda harus memastikan terlebih dahulu bahwa apa yang Anda sarankan benar-benar praktik terbaik yang dikenal dan diterima secara luas.

Juga, cobalah untuk membahas masalah yang sama dengan anggota tim lainnya juga. Penting untuk memahami "konsensus" (yang diucapkan atau tidak diucapkan) di dalam tim mengenai gaya dan kualitas pengkodean . (Jika semua orang menulis kode yang bersih dan berkualitas tinggi, Anda memiliki kasus yang sangat berbeda daripada jika anggota kelompok lainnya terdiri dari Pemrogram Nyata yang dengan bangga menulis program FORTRAN dalam bahasa apa pun.) Mereka juga dapat menceritakan lebih banyak tentang latar belakang historis proyek tersebut. dan gaya penulisan atasan Anda, yang membantu Anda mengarahkan upaya Anda dengan lebih baik.

Cara lain adalah memintanya untuk memesan Java Efektif untuk Anda, karena Anda merasa Anda perlu untuk menjadi programmer yang lebih baik. (Seandainya Anda belum membacanya, Anda sebenarnya membutuhkannya.) Lalu, Anda dapat berbicara dengannya tentang solusi dan praktik luar biasa dalam buku ini.

Jika dia terbuka untuk meningkatkan dirinya sendiri, dia akan mengambil saran Anda (dan bukunya). Jika tidak, Anda bisa mundur tanpa kehilangan muka dan melelahkan hubungan Anda.

24
Péter Török

Jika bos Anda pria yang keren, tanyakan saja kepadanya: "Bung, WTF?"

21
gruszczy

Dalam semua kasus di mana Anda berpikir "milikku lebih baik" tidak pernah memberi tahu seseorang bahwa Anda berpikir demikian, tunjukkan pada mereka.

Saya ulangi, TUNJUKKAN, jangan katakan.

Ya tahu bahwa mengatakan tentang tindakan, lebih keras, kata-kata ... itu benar.

8
Jack Marchetti

Apa posisi bos Anda? Apakah dia seorang pengembang, pemimpin teknologi? Berapa banyak pengembang lain yang ada di perusahaan? Apakah perusahaan memiliki standar pengkodean dan ulasan kode?

Tidak mungkin Anda membuat bos Anda mengubah kebiasaan buruknya (IMHO), tetapi Anda mungkin bisa menggunakan peer group atau standar perusahaan untuk memengaruhinya. Jika kodenya tidak mengikuti standar dan rekan-rekan semua sama maka pilihan Anda terbatas.

6
Qwerky

Inilah rekomendasi saya:

  • Nyatakan kasus Anda dengan baik.
  • Jika manajer Anda tidak * menerima pandangan Anda, dan Anda merasa benar, cari padang rumput yang lebih hijau dan jangan membuat alasan apa pun.

Saya sarankan Anda mencari padang rumput yang lebih hijau karena tiga alasan:

  1. Dalam jangka panjang, berbahaya bagi karier programmer untuk melanggengkan praktik buruk. Kelanggengan praktik buruk melahirkan kebiasaan buruk.
  2. Toko pemrograman yang tidak menerima sudut pandang alternatif menghambat imajinasi.
  3. Ketika Anda tahu bahwa Anda sedang melanggengkan praktik buruk dan tim Anda tidak mau menerima sudut pandang alternatif, moral Anda akan tenggelam, dan ini akan membuat hidup Anda sengsara. Jadi tinggalkan ASAP.

* Perbedaan Penting: Mengharapkan seseorang menerima sudut pandang Anda tidak sama dengan mengharapkan seseorang untuk menghasilkan untuk Anda sudut pandang. Saya selalu menghargai orang-orang yang mempertimbangkan sudut pandang saya, sedangkan saya kurang menghargai orang-orang yang lunak dan menghasilkan menurut sudut pandang saya tanpa alasan atau alasan yang cukup. bukti untuk melakukannya.

6
Jim G.

Tindakan Berbicara Lebih Keras dari pada kata-kata:

Pendekatan yang berbeda:

  • Anda perlu lead dengan contoh.
  • Pastikan proyek yang Anda lakukan adalah terbaik yang dapat Anda lakukan.
  • Anda perlu Excel dalam hal kinerja, lebih sedikit bug, dll.
  • Setelah Anda dapat menunjukkan bahwa pendekatan dan gaya Anda lebih baik daripada bos Anda, kecuali dia sangat arogan maka saya berpikir bahwa secara alami orang itu akan mengikuti apa pun yang paling berhasil.
6
Darknight

Saya hanya akan memberinya Pointer dalam dosis kecil, ketika Anda melihat dia melakukan sesuatu yang "buruk"

"Hmm, lihat pendekatan ini untuk itu {Menunjuk ke layarnya}, aku suka melakukannya dengan cara ini karena bla bla bla."

Lakukan ini Tidak lebih dari sekali setiap hari. Kalau dia tidak menerima saran Anda, jangan pernah menyebutkannya lagi (selama beberapa minggu). Beberapa akan menempel. Dan dia perlahan akan menjadi lebih baik.

4
Morons

Minta atasan Anda untuk membandingkan dengan cara lain yang telah diajarkan kepada Anda. Dia mungkin memiliki alasan yang sah. Anda tidak akan tahu sampai Anda bertanya. Mungkin ada beberapa standar pengkodean lama yang dia coba pertahankan atau dia mungkin tidak peduli. Jangan memberikan indikasi bahwa Anda berpikir bos secara otomatis salah. Oh, dan lakukan itu secara pribadi. Ini untuk tujuan pendidikan Anda.

4
JeffO

Tergantung. Jika kode yang Anda tinjau adalah kode yang benar-benar baru, maka mintalah untuk memiliki ulasan kode karena akan membantu "mempercepat Anda" dan itu akan menunjukkan bahwa Anda tertarik untuk belajar. Bos mungkin menganggap ini bermanfaat karena akan menunjukkan kepadanya bahwa Anda ingin melakukan hal yang benar. Jika ini adalah kode lama yang kebetulan Anda temui dan dipaksa untuk mempertahankannya, pastikan untuk melakukan refactoring dengan lambat. Deklarasi jenis di sana-sini sambil masih menyelesaikan tugas yang sedang dihadapi. Sekarang masalahnya di sini adalah bahwa String YesOrNo dapat mengambil nilai-nilai lain seperti Maybe yang dapat menyebabkan kode rusak jika Anda tidak hati-hati.

4
Woot4Moo

Hal pertama yang akan saya lakukan adalah, untuk mengetahui bagaimana dia bereaksi terhadap kritik. Jika saya akan menjadi bos - ya saya tidak akan melakukan kesalahan, bukan? - Saya lebih suka diberi tahu tepat di wajah saya, sekaligus tetapi dengan cara yang hormat. Bergantung pada temperamen dan budaya, bos Anda mungkin berbeda.

Tetapi kebanyakan dari mereka membutuhkan rasa hormat. Cara yang baik untuk menunjukkan, bahwa Anda menghormatinya adalah, apa yang telah disarankan sebelumnya: Anda menjelaskan apa yang Anda maksudkan, tetapi serahkan keputusan kepadanya: "Ini adalah alasan saya, tetapi mungkin saya telah mengawasi sesuatu. Setelah penjelasan saya:"

if (YesOrNo == "Yes")
if (YesOrNo == "yes")
if (YesOrNo == "YES")
if (YesOrNo == "oui")
if (YesOrNo.equals ("Yes"))
if ("Yes".equals (YesOrNo)) // might be null

"Apa yang disarankan Anda?"

Dan Anda dapat mengajukan metaquestion sebelumnya: "Tn. X, jika saya menemukan sesuatu dalam kode Anda, yang umumnya dilaporkan merupakan praktik yang tidak dapat diperbaiki - bagaimana saya harus melaporkannya kepada Anda? Sekaligus, atau langkah demi langkah? Atau haruskah saya hindari menyebutkannya dengan cara apa pun? Perbaiki kode secara diam-diam? "

Itu akan tergantung pada hubungan saya yang mana kata-kata yang akan saya pilih, dan pendekatan mana.

4
user unknown

Bos Anda tidak tahu cara memprogram, dan ia seharusnya tidak melakukannya. Pengalaman saya memberi tahu saya bahwa mengasumsikan bahwa seseorang yang dipanggil bos juga lebih berpengalaman atau lebih baik daripada Anda adalah kesalahan. Dia mungkin lebih baik dalam hal-hal lain, tetapi titik manajemen dan hierarki adalah untuk mendelegasikan hal-hal kepada orang yang paling tepat. Seorang bos adalah seseorang yang memiliki peluang memulai bisnis, atau masuk ke posisi manajemen pada akhirnya karena keterampilan manajerialnya, belum tentu untuk keterampilan pemrogramannya.

Saya pernah punya bos yang berpura-pura menginstal komputer saat terhubung ke generator listrik bensin, karena dia mengklaim peretas bisa masuk melalui jaringan listrik saat mesin masih tidak terlindungi. Saya segera berhenti. Saya belajar pelajaran berharga saat itu: bos tidak selalu benar, dan kadang-kadang berhenti adalah satu-satunya respons yang berharga.

Jadi, untuk kembali ke kasus Anda, Anda mungkin memiliki kasus di mana hanya mencari pekerjaan lain (ya, krisis, yadda yadda ... saya tahu) mungkin obat terbaik. Jangan buang waktu berharga Anda.

4
Stefano Borini

Cobalah tunjukkan padanya potongan kode sampel pendek dari situs/tempat/buku terkemuka dll yang menyelesaikan hal serupa.

4
chiurox

Saya tinggal di industri di mana saya tidak dapat menemukan kesalahan bos saya. Jadi lebih baik, saya akan menghasilkan kasus-kasus di mana kesalahan muncul dalam kode dan biarkan dia melihat kesalahan, daripada saya akan menyarankan dia perubahan yang diperlukan dan tentang kemungkinan alasan [dalam kasus Anda, Anda yakin tentang alasan ..: - D] dari kesalahan. Pengembang mana pun, baik atau buruk, tidak akan menerima kesalahan sampai ia melihat bug.

3
Chris

Saya pernah punya masalah besar dengan gaya bos.

Ada dua masalah dengan itu. Pertama, kurasa aku tidak pernah mengatakannya di wajahnya, tapi kurasa dia tahu. Dia tetap profesional, saya tidak, TKI.

Kedua, ada alasan untuk apa yang dia lakukan, dan hanya perlu waktu bagi saya untuk memahami betapa terlalu rumit dan menjengkelkannya "solusi" saya yang benar ini.

Dari tiga poin dalam pertanyaan, diakritik tidak aneh untuk semua orang, dan sementara saya tidak akan menggunakannya untuk loop, saya merasa jengkel oleh keluarga C lakukan ... sementara sintaksis dan bagaimana (tidak) cocok dengan gaya indentasi saya, jadi saya mungkin bisa melihat dari mana asalnya.

Bahkan hal boolean mungkin memiliki penjelasan dalam hal kebiasaan yang dibawa dari bahasa lain (yang tentu saja bukan pembenaran).

3
Steve314

Saya kira ini mungkin berhasil -

  1. Minta manajer Anda untuk meninjau kode Anda yang tidak memiliki kesalahan apa pun yang dilakukannya.
  2. Kemudian lihat apakah manajer Anda bertanya kepada Anda mengapa tidak melakukannya dengan cara "nya"
  3. Jika dia mengajukan pertanyaan ini, Anda bisa bertanya kepadanya mengapa itu cara yang lebih baik.

Dengan cara ini Anda bisa tahu mengapa menurutnya jalannya benar.

3
k25

Saya pernah kesana sebelumnya. Saya langsung keluar dari Uni dan setelah sekitar satu tahun bekerja untuk seorang pria, saya menyadari bahwa saya tahu jauh lebih banyak darinya tentang pemrograman, tetapi itu adalah urusannya, dan dia yang mengambil keputusan - dan hanya tidak ingin menyinggung perasaannya. bagaimanapun! Saya memutuskan bahwa jalan terbaik untuk itu, adalah untuk membahas manfaat dari memiliki konvensi pengkodean yang umum di perusahaan yang harus kita semua pertahankan, dan lihat bagaimana dia bereaksi. Yang mengejutkan, dia pikir itu ide yang bagus, dan meminta saya untuk menyusun daftar standar, yang kami berdua tinjau bersama, dan selesai dll.

Yang penting di sini adalah, bahwa Anda hanya bisa salah seperti dirinya, dan bahwa hanya karena beberapa caranya aneh/salah, beberapa di antaranya akan lebih baik daripada Anda.

Namun dari pengalaman pribadi saya tidak berhasil. Meskipun menghabiskan 2 hari untuk meneliti dan menyusun dokumen standar dan konvensi pengkodean yang hebat - ia sudah menetapkan caranya, tidak benar-benar melihat manfaat dalam konvensi pengkodean, atau menulis kode yang mengurangi beban pada server, yang membuat pekerjaan kami lebih cepat dan lebih mudah, dan memangkas biaya.

Pada akhirnya saya pergi untuk mencari tempat yang membutuhkan pengembangan sedikit lebih serius. Itu tidak semuanya buruk, karena penelitian yang saya lakukan pada konvensi pengkodean sangat membantu hingga hari ini.

3
user16731