Bagaimana menjelaskan mengapa pilihan desain bagus? [Tutup]

Karena saya telah menjadi pengembang yang lebih baik, saya menemukan bahwa sebagian besar keterampilan desain saya berasal lebih dari intuisi daripada analisis mekanik. Ini bagus. Ini memungkinkan saya membaca kode dan lebih cepat merasakannya. Ini memungkinkan saya menerjemahkan desain antara bahasa dan abstraksi dengan lebih mudah. Dan itu membuat saya menyelesaikan lebih cepat.

Kelemahannya adalah saya merasa lebih sulit untuk menjelaskan kepada rekan satu tim (dan lebih buruk lagi, manajemen) mengapa desain tertentu menguntungkan; terutama rekan satu tim yang ketinggalan zaman dalam praktik terbaik. "Desain ini lebih bisa diuji!" atau "Anda harus memilih komposisi daripada warisan." pergi tepat di atas kepala mereka, dan mengarah ke lubang kelinci saya mencoba untuk memberi petunjuk semua orang dalam dekade terakhir dari kemajuan rekayasa perangkat lunak.

Saya akan menjadi lebih baik dengan latihan tentu saja, tetapi sementara itu melibatkan banyak waktu yang terbuang dan / atau desain yang buruk (yang akan menyebabkan waktu terbuang memperbaikinya nanti). Bagaimana saya bisa lebih menjelaskan mengapa desain tertentu lebih unggul, ketika manfaatnya tidak sepenuhnya jelas bagi audiens?

Ini mungkin tidak langsung menjawab pertanyaan Anda, tetapi mungkin mengarahkan Anda ke arah yang menarik.

Saya pikir apa yang perlu Anda lakukan lebih terkait dengan menjualnya pada gagasan itu daripada menjelaskannya kepada mereka. Penjualan adalah tentang memahami apa masalah pelanggan dan kemudian menunjukkan kepada mereka bagaimana produk Anda (atau metode pengembangan, apa pun) akan bermanfaat bagi mereka. Setiap orang memiliki kebutuhan yang berbeda, sehingga hal-hal yang bermanfaat bagi satu orang dan membuat mereka bersemangat mungkin membuat orang lain kedinginan.

Bagi CEO Anda waktu-ke-pasar mungkin adalah kuncinya, bagi manajer Anda, itu mungkin jadwal yang lebih mudah diprediksi, bagi kolega pemrograman Anda, mungkin itu adalah pengkodean yang lebih cepat (atau pengujian / dokumentasi / debugging / apa pun yang lebih mudah), dan bagi pelanggan perusahaan Anda, itu mungkin ... ?

Penjualan tidak terjadi otomatis - Anda harus membuat upaya bersama untuk memahami orang lain sudut pandang, dan kemudian mencari cara untuk memetakan ide-ide Anda ke dalam mereka Happy Tempat ™. Begitu mereka tahu bagaimana secara pribadi mereka akan mendapat manfaat dari hal baru ini, mereka sering bertanya, "Berapa biayanya dan seberapa cepat kita bisa melakukannya?" Setelah Anda mendengar kata-kata ajaib itu, Anda tahu Anda telah melakukan pekerjaan penjualan dengan baik.

Saya tidak benar-benar memiliki solusi untuk pertanyaan Anda, tetapi beberapa waktu lalu saya menghadapi dilema yang sama persis dan ingin menjawab pertanyaan yang sama persis ini.

Saya akan menemukan diri saya di satu sisi argumen dan orang lain di sisi lain dan meskipun setiap serat tubuh saya mengatakan kepada saya desain yang tepat adalah X, saya tidak bisa mendukungnya menggunakan kata-kata.

Lebih buruk lagi adalah bahwa kadang-kadang saya akan mengakui titik dan membiarkan orang lain menerapkannya dengan cara mereka hanya untuk memiliki desain mereka meledak di wajah saya dan kemudian saya akan berpikir, "Ya, ini adalah contoh sempurna mengapa saya tidak mau untuk melakukannya dengan cara itu. Kalau saja saya bisa menunjukkan kode ini kepada mereka saat itu. "

Yah, saya tidak pernah benar-benar menemukan jawabannya tetapi beberapa hari yang lalu ketika saya membolak-balik Lean Software Development: An Agile Toolkit, Saya menemukan sesuatu yang menarik yang mungkin menyarankan bahwa jawaban itu sebenarnya tidak ada. Bagian dari buku ini berbicara tentang para pemimpin di bidang lain, terutama di unit tanggap darurat dan bagaimana para pemimpin itu membuat keputusan. Ketika ada kebakaran, atau seseorang menembaki Anda, para pemimpin itu tidak pernah duduk dan berdebat pro / kontra dengan rekan satu tim mereka. Sebaliknya, mereka menggunakan intuisi, yang dikembangkan melalui pelatihan dan pengalaman untuk membantu mereka membuat keputusan. Hal yang sama berlaku untuk profesi kami: bagaimana Anda bisa membuat keputusan yang sepenuhnya logis ketika berhadapan dengan banyak hal yang tidak diketahui dan variabilitas yang sangat umum dalam pengembangan perangkat lunak? Para penulis berpendapat bahwa alih-alih berusaha membenarkan setiap keputusan, pengembang harus didorong untuk melatih dan meningkatkan naluri mereka sehingga pada akhirnya mereka akan "hanya tahu" apa yang harus dilakukan.

Satu-satunya cara saya menemukan untuk melewati argumen ini adalah untuk membangun rekam jejak yang terbukti dari pekerjaan saya. Untuk menunjukkan kepada manajemen dan orang lain di tim saya bahwa keputusan desain yang saya buat dalam kode saya menghasilkan kode yang lebih mudah untuk dipelihara, diperluas dan lebih dapat diandalkan. Anda melakukan ini berulang kali dan orang-orang akan memperhatikan Anda. Pada saat itu, pendapat Anda, yang mungkin hanya didasarkan pada insting Anda, akan memiliki bobot yang jauh lebih tinggi daripada sekarang. Strategi ini berhasil dengan 90% + tim saya termasuk bos saya. Sayangnya, Anda mungkin menemukan satu atau dua pria yang benar-benar keras kepala dan akan menolak untuk melihat apa pun dengan cara Anda. Pada saat itu, Anda memiliki beberapa opsi:

1. Anda dapat mencoba untuk menarik peringkat (akhirnya saya pergi ke bos saya dan meminta peringkat karena saya sangat lelah dengan argumen buntu ini)
2. Anda dapat mencoba melobi sebagian besar tim untuk mendukung Anda.
3. Jika proyek mampu (yaitu tidak terlalu banyak kehilangan produktivitas), apa yang menurut Anda merupakan keputusan yang buruk, biarkan orang lain memenangkan argumen. Satu dari dua hal akan terjadi:
   • Dalam beberapa kasus (semoga porsinya sangat kecil), intuisi Anda akan salah dan Anda akhirnya akan belajar sesuatu. Bagus untukmu.
   • Dalam kebanyakan kasus (sekali lagi ... semoga), Anda DAN orang yang menganjurkan desain "buruk" akan menyadari persis mengapa itu buruk; setelah semua melihat ke belakang selalu 20/20. Mudah-mudahan, ini akan menjadi pelajaran bagi orang itu bahwa mungkin Anda tahu apa yang Anda bicarakan dan lain kali mereka akan berpikir dua kali untuk memperdebatkan kasus mereka.

Yah, jawaban ini tidak terlalu spesifik untuk pemrograman seperti yang Anda pikirkan. Anda harus membawanya kembali ke hal-hal yang mereka mengerti.

Jika itu sesuatu seperti komposisi atas warisan, Anda mungkin hanya perlu mengatakan bahwa saat ini mungkin 90% pengembang akan menganggap bahwa praktik terbaik (tebakan liar, sebagian didasarkan pada kenyataan bahwa 100% pengembang setuju pada hampir tidak ada), dan Anda setuju dan akan senang masuk ke mengapa.

Saya mencoba untuk jujur ​​seperti yang saya bisa tentang apa yang kontroversial, dan berapa persen pengembang akan setuju dengan saya.

Ini umumnya bekerja lebih baik dengan manajemen daripada pengembang, yang mungkin akan membuat Anda turun ke lubang kelinci menjelaskan apakah Anda benar-benar menganjurkan desain yang baik dan bagaimana Anda mengetahuinya. Ada sesuatu yang terpuji dalam hal ini, tetapi itu berarti Anda harus meluangkan banyak waktu. Kecuali mereka cukup memercayai Anda untuk mengambil kata-kata Anda untuk hal-hal seperti itu, setidaknya untuk sementara. Sisi baiknya, mereka mungkin meyakinkan Anda bahwa Anda salah, yang mengalahkan kenyataan dingin dan sulit meyakinkan Anda.

Untuk hal-hal seperti desain menjadi lebih dapat diuji, jika mereka tidak setuju bahwa itu lebih dapat diuji maka itu hampir sama dengan contoh pertama. Jika mereka tidak setuju bahwa diinginkan untuk lebih dapat diuji, maka Anda harus membawanya kembali ke hal-hal yang mereka pahami. Ini kemungkinan besar adalah manajemen, dan Anda dapat berbicara tentang biaya pengembangan yang lebih rendah dalam jangka panjang, lebih sedikit QA, proses yang lebih dapat diprediksi (karena panjang siklus QA berulang sulit diprediksi), dll.

Saya pikir bagian dari masalahnya adalah bahwa Anda meremehkan betapa sulitnya membuat tim untuk setuju dengan Anda tentang hal-hal yang kontroversial, bahkan jika Anda benar (dan tentu saja Anda mungkin tidak). Pemrograman sebagian merupakan latihan sosiologis dan Anda mungkin perlu menjadwalkan waktu untuk benar-benar turun beberapa lubang kelinci itu, karena desain hebat yang tidak dipahami atau dibelakang siapa pun jarang merupakan desain hebat dalam praktik. Jadi jangan menganggap waktu itu sia-sia, anggap itu sebagai bagian penting dari kesuksesan proyek Anda. Meskipun akan jauh lebih mudah jika Anda bisa melewatinya.

Menjadi satu-satunya suara perubahan bukanlah hal yang mudah. Tantangan pertama biasanya untuk membuat orang lain bergabung dengan Anda (Mudah-mudahan ada beberapa di perusahaan Anda yang lebih berpikiran terbuka daripada yang lain). Jika Anda dapat menarik perhatian beberapa pengembang / manajer senior lainnya untuk bergabung dalam kampanye Anda, suara-suara gabungan itu akan semakin sulit untuk diabaikan oleh yang lain.

Saya menemukan cara yang baik untuk menjelaskan kepada orang-orang adalah dengan memberikan contoh nyata kesalahan masa lalu yang dibuat dalam proyek-proyek yang mereka terlibat secara aktif (misalnya, "Apakah Anda pernah mencoba men-debug hal ini? Sudah seperti ini selama bertahun-tahun dan tidak ada yang tahu bagaimana caranya memperbaikinya.."). Lebih baik lagi, menerapkan ide-ide dan prinsip-prinsip desain 'baru' untuk proyek kecil / percobaan dan mampu menunjukkan seberapa sukses itu pada akhirnya.

Bergantung pada sikap orang lain di perusahaan Anda, perubahan mungkin terjadi dengan cepat, atau mungkin seperti mencoba berenang melalui pengkhianatan. Beberapa manajer benar-benar tidak dapat bergerak kecuali mereka memiliki statistik / bukti kuat di depan mereka, di mana yang lain cukup ingin mengikuti pemikiran terbaru.

Anda mungkin perlu mencoba berbagai taktik tergantung pada siapa yang Anda hadapi; Menyarankan bahwa uang / waktu / upaya dapat dihemat dan kualitas mungkin ditingkatkan adalah cara yang baik untuk menarik perhatian manajer non-teknis; dan janji pengujian otomatis yang mudah menarik bagi cukup banyak pengembang yang biasanya tidak tahan menghabiskan waktu berhari-hari menjalankan lembar uji yang sama berulang kali.

Tergantung pada audiens! Sebagai pengembang, kami mengembangkan intuisi untuk kode baik dan buruk, dan menggunakan istilah emosional yang tidak jelas seperti "bau kode", "kode jelek", "solusi indah". Ini hanya berfungsi saat berkomunikasi dengan pengembang lain dengan pola pikir yang sama. Cobalah untuk menjelaskan CEO non-teknis Anda bahwa Anda harus menginvestasikan x man-jam untuk membuat beberapa kode "lebih indah" Anda kemungkinan besar akan gagal secara spektakuler.

Anda harus bisa memastikan bahwa setiap perbaikan desain yang diberikan akan baik

• menghemat uang untuk perusahaan
• menghasilkan uang untuk perusahaan

Misalnya, apa alasannya untuk mematuhi prinsip tanggung jawab tunggal? Jika setiap kelas memiliki satu tanggung jawab, membuatnya lebih mudah untuk menemukan dan memperbaiki bug, dan membuatnya lebih mudah untuk menambahkan fitur dan peningkatan. Lebih sedikit waktu memperbaiki bug dan menambahkan fitur = uang disimpan