Berurusan dengan cacat desain mendasar ketika Anda baru di proyek [ditutup]


13

Saya baru saja mulai mengerjakan proyek open source dengan sekitar 30 pengembang di dalamnya. Saya sedang berusaha memperbaiki beberapa bug sebagai cara untuk masuk ke "loop" dan menjadi committer reguler ke proyek. Masalahnya adalah saya pikir saya telah menemukan cacat desain mendasar yang menyebabkan salah satu bug yang saya kerjakan. Tapi saya merasa jika saya meledakkan ini di milis saya akan dianggap sombong, dan beberapa diskusi yang saya lakukan tentang masalah ini berselisih dengan beberapa orang. Bagaimana saya harus melakukan ini?

Jawaban:


20

Bahkan jika Anda cukup yakin bahwa ini adalah "cacat desain mendasar," ingatlah bahwa Anda adalah orang luar. Mungkin ada di sana untuk alasan yang bagus. Atau, tergantung pada berapa usia proyek itu, bisa saja diletakkan di sana untuk alasan yang baik pada saat itu dan sekarang masih ada karena alasan historis.

Alih-alih "meledakkan ini di milis," coba ajukan pertanyaan. Sesuatu seperti:

"Hei, aku baru saja bertemu X, dan itu tidak masuk akal bagiku. Sepertinya cara yang tepat untuk mengimplementasikan ini adalah Y, tapi sekali lagi aku tahu aku baru di sini dan aku tidak ingin lompat ke kesimpulan apa pun. Apakah ini kesalahan dalam desain, atau ada sesuatu yang saya lewatkan? Dapatkah seseorang mengisi saya? Terima kasih. "

Teknik adalah salah satu dari sedikit tempat di dunia di mana kerendahan hati masih dianggap sebagai kebajikan sejati, dan mengajukan pertanyaan tentang "masalah yang jelas" dengan cara ini adalah cara yang sangat baik untuk mendapatkan jawaban yang baik dan mempelajari hal-hal baru.


2
Ini jelas berada di arah yang benar. Saya hanya ingin melakukannya dengan cara yang tidak akan keluar sebagai "Saya tahu Anda salah dan saya benar" dan masih mendapatkan sesuatu dari itu.
Matt Phillips

@Matt: Lalu frase itu sebagai "Saya tidak tahu saya benar," dan mencoba yang terbaik untuk menghindari membuatnya terdengar sarkastik atau menuduh.
Mason Wheeler

Saya akan menggunakan sesuatu seperti "Saya tidak mengerti mengapa ini dilakukan dengan cara ini. Bukankah akan lebih baik / lebih mudah / lebih dingin untuk melakukannya dengan cara lain? Saya pikir itu juga akan membantu dengan bug XX"
Javier

2
Saya pikir Anda mungkin ingin bermain dengan kata-kata sedikit daripada langsung mengatakan "cara yang tepat untuk mengimplementasikan ini akan menjadi Y". Mengubahnya menjadi pertanyaan murni "adakah alasan mengapa Y tidak digunakan" mendapatkan poin yang sama tanpa meletakkan kaki Anda ke bawah. Siapa pun akan memiliki ego yang agak rapuh ketika ditanyai tentang kode mereka sendiri, dan dengan memohon keahlian mereka (mengapa Anda memilih X alih-alih Y) alih-alih menantangnya (Y adalah / tampaknya / terasa lebih baik / lebih dingin / lebih mudah daripada X) dapat memperoleh respons yang lebih baik.
Steven

6

Salah satu dari 48 Hukum Kekuasaan :

Menangkan melalui Tindakan Anda, Jangan melalui Argumen

Kemenangan sesaat apa pun yang menurut Anda diperoleh melalui argumen benar-benar merupakan kemenangan Pyrrhic: Kebencian dan kesedihan yang Anda bangkitkan akan lebih kuat dan bertahan lebih lama daripada perubahan pendapat sesaat. Jauh lebih kuat untuk membuat orang lain setuju dengan Anda melalui tindakan Anda, tanpa mengucapkan sepatah kata pun. Peragakan, jangan jelaskan.

Ini adalah salah satu yang saya pelajari dengan susah payah setelah banyak argumen tidak berguna.

Dalam kasus khusus ini, saya akan menyarankan datang dengan sepotong kode yang sangat sederhana dan spesifik yang harus bekerja tetapi tidak akan karena cacat desain ini. Seperti pepatah lama, "Anda tidak dapat berdebat dengan kompiler / juru bahasa".

Hal lain adalah bahwa untuk memiliki pengaruh terhadap grup, Anda harus dianggap sebagai anggota grup . Meskipun Anda telah bergabung dengan perusahaan, orang belum menganggap Anda sebagai anggota grup. Dengan demikian, mungkin lebih baik mengikuti kelompok yang sudah ada sampai mereka belajar untuk menganggap Anda sebagai salah satu dari mereka.


5

Bisakah Anda bertanya mengapa desain tertentu digunakan? Dengan begitu Anda bisa mendapatkan lebih banyak dari cerita belakang karena mungkin ada beberapa alasan bagus mengapa sesuatu dipilih yang Anda tidak tahu. Saya akan pergi dengan gagasan bahwa Anda tidak cukup ahli yang dapat memisahkan desain tetapi bertanya mungkin merupakan cara untuk belajar lebih banyak sehingga pada akhirnya Anda bisa bertanya tentang kesalahan yang Anda temukan sehingga pesan tidak akan terlihat sebagai umpan api atau trolling.


4

Anda mungkin tidak akan suka ini ... tapi, begini ...

Saya sedang berusaha memperbaiki beberapa bug sebagai cara untuk masuk ke "loop" dan menjadi committer reguler ke proyek. Masalahnya adalah saya pikir saya telah menemukan cacat desain mendasar yang menyebabkan salah satu bug yang saya kerjakan.

Tidak, tidak kamu tidak. Jika Anda melakukannya, Anda tidak akan begitu ragu tentang hal itu. Fakta bahwa Anda sendiri tidak yakin dengan "cacat desain mendasar", berarti Anda belum menemukannya. Ketika mencoba menunjukkan kesalahan orang lain, itu tidak membeli Anda teman untuk menggunakan superlatif (seperti "mendasar").

Apa yang mungkin Anda temukan adalah desain yang sedikit lebih baik, untuk masalah yang Anda alami. Anda mungkin harus mengujinya dengan seksama - karena Anda baru di proyek ini, ada kesempatan yang lebih baik daripada Anda tidak tahu apa yang Anda bicarakan.

Tapi saya merasa jika saya meledakkannya di milis, saya akan dianggap sombong

Menyebutnya "cacat desain mendasar" pasti akan dianggap sombong. Dalam hal ini, bahkan menunjukkan bahwa itu mungkin bug bukanlah ide terbaik. Jika Anda tidak tahu pasti (dan dapat mendukungnya) bahwa itu adalah masalah, maka Anda perlu mengajukan pertanyaan dan penelitian dengan rendah hati sampai Anda benar - benar memahaminya . Lebih baik daripada siapa pun yang Anda coba meyakinkan.

... dan beberapa diskusi yang saya lakukan tentang masalah ini adalah saling bertabrakan dengan beberapa orang. Bagaimana saya harus melakukan ini?

Berhenti. Ini bukan masalah moral, dan itu tidak membunuh siapa pun (saya kira). Jika Anda berniat menjadi anggota proyek jangka panjang, Anda harus terlebih dahulu mendapatkan kepercayaan sebelum menanyai mereka. Perbaiki bug, lakukan pekerjaan yang luar biasa (dengan metrik apa pun nilai grup), desain beberapa fitur, dan dapatkan kursi di meja.

Kemudian, tanpa menunjuk jari atau memanggil sesuatu yang rusak, dengan rendah hati memunculkan saran untuk meningkatkan desain ke grup. Dan Anda lebih baik memikirkan semua konsekuensi dan solusi untuk mereka, atau Anda akan ditembak jatuh karena "naif". Bersiaplah untuk argumen tentang mengapa desain Anda lebih baik. Bersiaplah untuk kalah, dan kalah dengan anggun.

Jika ide Anda benar-benar lebih baik, akhirnya akan diterima oleh grup (meskipun mungkin tidak oleh desainer asli), grup tidak peduli, atau grup itu bodoh. Dalam salah satu kasus terakhir, mengapa Anda ingin menjadi bagian dari grup?

...

Jika Anda mampu, alternatifnya adalah hanya kode hal sialan itu begitu berdarah cemerlang bahwa mereka akan gemetar dengan takjub pada kecakapan pengkodean Anda dan tidak punya pilihan selain menerima kesederhanaan yang elegan dan kebenaran abadi desain Anda. Pengembang melakukan kompetensi hormat, tetapi Anda harus berhati-hati - hukuman untuk ketidakmampuan (atau kesombongan tidak beralasan) agak parah. Karena Anda menanyakan pertanyaan ini, saya kira rute arogansi yang brilian dan tidak malu-malu bukanlah pilihan. ;)


2
"Hai, terima kasih sudah menyambutku di rumahmu. Saat aku berjalan melewati pintu, aku ingin semua orang di keluarga tahu bahwa bayi mereka jelek dan seseorang berpakaian lucu baginya."

Bug adalah bug, dan tidak apa-apa menyebutnya begitu. Mengatakan bahwa itu disebabkan oleh "cacat desain" menunjukkan orang itu di hadapan Anda (yang paling mirip "ayah") dan mengatakan kepadanya bahwa ia idiot.

Tidak perlu dan kontraproduktif. Saya menyarankan:

"Sehubungan dengan masalah #blah, aku pikir aku bisa memperbaikinya dengan melakukan XY dan Z tapi aku tidak yakin bagaimana itu akan berdampak pada sisa proyek. Apakah ini baik-baik saja?"

Di mana XY dan Z memperbaiki masalahnya. Biarkan mereka memberi tahu Anda bahwa itu adalah cacat desain; mungkin ada solusi alternatif. Atau asumsi di balik 'cacat' dapat berjalan sangat dalam di seluruh proyek sehingga mengubahnya akan memperbaiki bug tetapi menghancurkan semua yang lain!

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.