Berkelahi (dipersepsikan) overengineering vs berjalan dengan aliran [ditutup]

Saya bergabung dengan tim yang memiliki pendekatan berbeda untuk merancang dari saya. Saya percaya pada pendekatan YAGNI untuk desain. Misalnya, jika suatu metode (antarmuka, kelas) tidak digunakan, itu harus dihapus. Itu dia.

Orang-orang di tim saya sedang membangun aplikasi modular, dan salah satu modul dianggap sebagai "kerangka kerja". Aplikasi ini adalah satu-satunya pengguna kerangka ini, dan saat ini tidak ada rencana untuk memiliki lebih banyak klien. Namun, bagian dari kode dalam kerangka ini ditulis dan dipelihara seolah-olah dapat digunakan nanti , dan konsistensi dan kelengkapan menang atas YAGNI. Ada abstraksi di tempat-tempat yang mungkin tidak pernah membutuhkan abstraksi, dll.

Saya mencoba untuk memperdebatkan beberapa hal, tetapi setiap poin membutuhkan banyak waktu untuk membujuk, jika sama sekali, dan saya takut bahwa terlalu banyak "mendorong" akan mengakibatkan tim pecah ke sisi yang berlawanan.

Saya dapat "mengikuti arus" dan menulis kode tambahan tanpa masalah pribadi. Ini akan membawa saya lebih banyak waktu sekarang untuk kode, dan kemungkinan besar, lebih banyak waktu kemudian untuk mempertahankan, namun , setiap diskusi untuk tidak melakukan sesuatu yang ekstra juga membutuhkan waktu dan menambah tekanan.

Pertanyaannya adalah, dalam kasus pendapat yang berbeda, apa yang akan melakukan tindakan merugikan yang lebih besar, tidak dibutuhkan tetapi kode "tepat", atau argumen konstan dan dinamika tim yang rusak?

Mempertahankan kerangka imajiner adalah keputusan yang signifikan secara arsitektur, jadi pertanyaannya bermuara pada "bagaimana kita muncul dan mengembangkan arsitektur" dalam tim. Anda harus mulai dengan aturan pengambilan keputusan yang jelas dan dianut oleh semua orang di tim karena tidak ada permainan tanpa aturan .

Saat bergabung dengan perusahaan, salah satu pertanyaan paling penting yang mungkin Anda tanyakan adalah -

Bagaimana cara kerja proses pengambilan keputusan dalam tim dan bagaimana prosesnya berkembang seiring waktu?

Tidak ada proses pengambilan keputusan yang lebih buruk daripada proses pengambilan keputusan yang buruk . jika tidak ada proses, seseorang perlu mendefinisikannya. Jika tidak, jumlah omong kosong tumbuh bersama dengan jumlah ketidaksepakatan dengan tim.

Saya pikir dengan ini kita menutup loop - baik Anda memiliki wewenang dan kekuatan untuk menentukan proses pengambilan keputusan ketika itu hilang ATAU Anda setuju dengan proses saat ini / dan bagaimana itu berkembang. Pilih satu.

Argumen yang konstan dan dinamika tim yang rusak tidak akan pernah membuat Anda jauh.

Saya akan mencoba untuk mendapatkan pemahaman tentang mengapa ada kerangka kerja di tempat pertama.

Kemungkinan besar alasannya adalah bahwa itu diharapkan akan digunakan dalam sistem lain nanti. Jika itu masalahnya maka masuk akal untuk melakukan lebih dari yang dibutuhkan saat ini.

Alasan untuk itu adalah jika satu aplikasi dalam produksi aplikasi baru sedang berlangsung yang membutuhkan pembaruan untuk kerangka kerja maka setiap kali ada perubahan dalam kerangka kerja, mungkin abstraksi yang tidak diperlukan sebelumnya ditambahkan, maka aplikasi asli harus diperbarui dan diuji juga.

Itu banyak sekali refactoring dan pengujian ulang untuk sesuatu dalam produksi.

Jika Anda memilih untuk tidak menyertakan kerangka kerja yang diperbarui dalam aplikasi lama, maka Anda memiliki 2 kerangka kerja untuk mempertahankan salah satunya yang sudah usang.

Mempertahankan kode usang juga tidak baik untuk moral.

Jika Anda baru mengenal suatu tim, berusaha untuk tidak menjadi gangguan dalam pasukan harus menjadi perhatian pertama Anda .

Saya berasumsi Anda tidak berada dalam posisi memimpin / arsitek, dan keputusannya tidak terserah Anda.

The kedua perhatian adalah Pelajari . Belajar banyak. Pelajari mengapa mereka mengambil keputusan yang diambil, mengapa kerangka dibuat, apa rasional di balik itu. Ketika Anda memiliki semua informasi, maka Anda dapat mengambil keputusan yang terinformasi tentang bagaimana cara mendekati kemungkinan masalah, seperti overengineering dan komunikasi yang buruk.

Ajukan pertanyaan, dengan cara yang sopan . Tempatkan diri Anda pada posisi siswa, dan bukan master. Ini akan memudahkan orang untuk "mengajari" Anda mengapa mereka melakukan hal-hal seperti itu.

Sekarang kamu orang buangan. Anda bergabung dengan tim asing, dan Anda harus mempelajari kebiasaan mereka dan menyesuaikan diri.

Jika Anda melakukan pekerjaan Anda dengan cara yang benar, dengan pendekatan yang sopan kepada orang-orang, orang secara alami akan mendengarkan Anda dari waktu ke waktu. Dan kemudian, jika Anda benar bahwa pendekatan Anda adalah yang terbaik secara keseluruhan, Anda dapat memengaruhi orang untuk berubah.

Saya jarang mengenal orang yang suka bekerja dengan orang yang sering mengkritik, tetapi tidak menghasilkan nilai. Jadilah referensi ke tim Anda, seseorang yang mereka banggakan bekerja dengan.

Juga, bacaan yang disarankan: https://www.amazon.com/How-Win-Friends-Influence-People/dp/0671027034

Ada 2 hal mendasar yang saya pikir sedang terjadi. Yang pertama adalah budaya. Anda baru di tim dan belum tahu cara bekerja dengan tim ini. Mereka mungkin memiliki kebijakan dan praktik berbeda yang mungkin benar-benar bekerja untuk mereka. Juga satu atau lebih dari mereka mungkin telah melamar posisi Anda sehingga mereka mungkin secara aktif menyabot upaya Anda atau tidak memberi tahu Anda apa yang perlu Anda ketahui.

Yang kedua adalah bahwa Anda mungkin salah membaca desain. Bagian yang menurut Anda adalah kode mati mungkin sebenarnya merupakan generalisasi dari bagian lain dari desain atau mungkin berfungsi untuk mendukung sesuatu yang pada akhirnya ingin didukung oleh bisnis. Ini mungkin sebenarnya kode mati. Berhentilah terobsesi dengannya dan pahami mengapa itu ada. Mungkin butuh waktu berbulan-bulan untuk mencari tahu.

Dalam industri yang menolak risiko (yaitu, perbankan, medial ...) di mana ada sedikit kemungkinan bahwa sepotong kode dapat digunakan, potongan kode itu akan bertahan selama beberapa dekade.

Untuk menyoroti ini, salah satu struktur database orang asing yang saya lihat terpusat di sekitar 6 tabel. 3 dari mereka memetakan tabel yang menghubungkan tiga lainnya. Tidak masuk akal karena kode menunjukkan bahwa hanya satu yang digunakan sebagai hubungan banyak-ke-banyak dan 2 lainnya menerapkan satu-ke-banyak. Perancang asli ini telah pergi dan tidak ada yang bisa menjelaskan dengan tepat bagaimana atau mengapa itu bekerja. Akhirnya, saya menemukan dokumen bisnis yang menjelaskan desain - jadi dugaan saya adalah bahwa bisnis telah memintanya dan beberapa DBA baru saja dilaksanakan dengan cara yang dapat dipahami oleh bisnis - meskipun ada keterbatasan yang jelas. 30 tahun kemudian masih ada, menghasilkan uang perusahaan - tetapi dari sudut pandang pengembangan sulit untuk dipahami, dipertahankan dan dikembangkan bersama.

Saya melihat beberapa poin bagus tentang memiliki bagian dari aplikasi meskipun tidak ada orang lain yang menggunakannya.

Ini dapat menegakkan pengembangan fungsionalitas teknis dalam kerangka kerja dengan tes yang tepat di luar konteks fungsional aplikasi (dan pada peta jalannya sendiri).

Lebih jauh lagi, mungkin saja Anda tidak menginginkan setiap sentuhan pengembang kerangka itu tetapi hanya yang paling senior, jadi sekali lagi mendapatkannya di luar aplikasi adalah nilai tambah.

Untuk lapisan abstraksi yang tidak diperlukan, baik jika sudah ada, jangan mengubah sesuatu yang sudah berfungsi.

Namun Anda mungkin ingat kepada tim Anda untuk masa depan bahwa tujuan dari kerangka kerja ini adalah untuk meringankan pekerjaan Anda, tidak perlu membobotnya.

Membaca yang tersirat, saya condong ke arah anggota tim Anda. Membuat sesuatu yang "lebih rumit dari yang dibutuhkan" tidak hanya membuka jalan bagi kemungkinan fungsionalitas masa depan yang mungkin tidak pernah dibutuhkan, itu juga melayani pemahaman pengembang tentang aplikasi, itu memasukkan model dalam perangkat lunak, itu mendokumentasikan sebuah ide.

Dan hal itu membatasi cara perkembangan masa depan. Itu membuat pengembang yang tidak sepenuhnya memahami desain / maksud dari menyimpang.

Seorang pengembang baru mungkin pada awalnya terganggu oleh desain yang "tidak perlu rumit", tetapi itu juga membimbingnya ke arah yang benar, itu membuatnya jatuh ke dalam lubang kesuksesan dan membuatnya lebih sulit baginya untuk "melakukan sesuatu dengan caranya", yang hanya akan menjadi cara lain yang benar-benar menyulitkan hal-hal karena itu akan mengarah pada pendekatan yang berbeda dalam aplikasi yang sama, yang membuat semakin sulit bagi orang berikutnya untuk mengatasinya.

YAGNI tidak (atau tidak seharusnya) berarti "Anda dapat melewati desain" atau "melakukannya dengan cepat dan kotor". Jika tim Anda memiliki kemewahan untuk memikirkan semuanya, saya akan mengatakan bahwa itu adalah sesuatu untuk dihargai daripada berjuang.