Mengapa tim pengembangan bersikeras bahwa menggunakan solusi tunggal untuk beberapa proyek di Visual Studio "meningkatkan kompleksitas saling ketergantungan"?


26

Saya membantu mengelola tim eksternal yang mulai mengembangkan versi baru dari beberapa produk yang ada. Secara historis, tim ini selalu menggunakan model proyek tunggal dalam solusi tunggal untuk sekitar 30 modul di Visual Studio yang bekerja sama untuk menghasilkan bangunan yang dapat digunakan.

Ini berdampak buruk pada keandalan dan kualitas build, karena mereka tidak selalu mengirimi kami kode sumber yang terbaru. Kami mencoba menekan mereka untuk menyatukan semua kode yang direferensikan ke dalam satu solusi, tetapi kami mendapatkan beberapa penolakan - khususnya mereka terus berbicara tentang saling ketergantungan antar modul (baca "proyek" di Visual Studio) ditingkatkan jika semuanya ditempatkan di file solusi tunggal. Tidak ada kode dalam solusi terpisah yang digunakan di tempat lain.

Saya bersikeras ini omong kosong dan pola perkembangan yang baik akan menghindari masalah seperti itu.

Tim tersebut juga melakukan perbaikan bug dan pengembangan fitur baru pada produk yang sudah ada, yang pengalamannya paling sedikit dan mengalami masalah yang sama seperti pemecahan beberapa solusi. Kami telah ditolak akses ke kontrol sumber ( TFS ) mereka, dan pendekatan yang kami ambil untuk menyatukan basis kode adalah dengan mencoba dan setidaknya mengurangi jumlah pembaruan yang hilang dan lebih dari sesekali regresi (ya, bug yang diperbaiki mendapatkan kembali -diintroduksikan ke dalam produk) dengan mengatakan "kirim kami ZIP dari seluruh folder solusi sehingga kami dapat unzip, buka di Visual Studio, dan tekanF5 untuk pengujian ". Dalam hal struktur dan kualitas umum, kodenya cukup buruk dan sulit untuk didukung. Pengalaman ini adalah alasan saya bermaksud mendapatkan proses kerja yang tepat di awal siklus pengembangan sebanyak mungkin.

Apakah ada sesuatu yang saya lewatkan? Adakah alasan yang bagus untuk memisahkan semua kode itu? Untuk uang saya itu harus menjadi alasan yang meyakinkan bahwa itu akan menjadi pengetahuan umum, tapi saya lebih dari bersedia untuk mengakui bahwa saya tidak tahu segalanya.


5
Jika tim bersifat eksternal, akan sulit untuk mencoba mengubah apa pun. Alih-alih berfokus pada masalah Anda mencoba untuk mendorong ide Anda. Masalahnya adalah "mereka tidak selalu mengirimi kami kode terbaru", sudahkah mereka menyelesaikan masalah ini, seperti yang mereka inginkan. Tidak bisakah mereka memberi Anda akses ke sistem kontrol versi?
RMalke

9
Kedengarannya seperti omong kosong. Proyek-proyek tersebut akan saling bergantung satu sama lain baik dalam satu atau tiga puluh solusi. Alasan untuk menjaga kode dalam solusi yang terpisah adalah karena pustaka yang dihasilkan digunakan oleh beberapa, build yang dapat digunakan secara terpisah. Ini kedengarannya tidak cocok untuk Anda.
David Arno

3
Sepertinya Anda memiliki banyak masalah non-teknis yang paling baik diselesaikan dengan perubahan pada kontrak dan laporan kerja Anda.
Ross Patterson

9
Menciptakan solusi tunggal tidak selalu berarti mereka harus melepaskan solusi individual, karena sebuah proyek dapat ada di lebih dari satu solusi.
Erik Eidt

6
Saya tidak yakin mengapa Anda bertanya-tanya tentang solusi teknis untuk sesuatu yang pada dasarnya masalah orang. Memecat orang-orang ini, dan mempekerjakan orang-orang yang berada di atas tingkat kompetensi yang biasa-biasa saja. Itu berarti Anda akan membayar lebih, tetapi itu pasti layak untuk TI dalam hal mengurangi total biaya kepemilikan. Semakin lama Anda bertahan semakin Anda akan menderita.
Brad Thomas

Jawaban:


54

Anda tidak perlu memberi tahu mereka cara menyusun proyek mereka. Sebagai gantinya, buat persyaratan sulit bahwa Anda dapat membangun sistem dari sumber dengan menjalankan satu skrip tunggal, tanpa mendapatkan kesalahan apa pun. Jika skrip itu menjalankan Visual Studio atau Msbuild atau beberapa alat lain, dan jika itu dipanggil sekali, 50 atau 100 kali seharusnya tidak menjadi masalah.

Dengan begitu, Anda mendapatkan "tes kelengkapan" kode yang sama dengan yang Anda dapatkan dengan memasukkan semuanya ke dalam satu solusi. Tentu saja, skrip itu tidak memberi tahu Anda jika tim benar-benar memeriksa versi terbaru dari kontrol sumber mereka, tetapi memiliki seluruh kode dalam satu solusi tidak akan memeriksanya juga.

Sebagai balasan untuk "saling ketergantungan antara modul yang meningkat jika semuanya ditempatkan dalam satu file solusi" - ini adalah omong kosong yang terbukti , karena menambahkan proyek ke solusi tidak mengubah salah satu dari dependensi antara proyek, dependensi adalah hasil dari satu proyek referensi file yang lain, yang sepenuhnya independen dari solusi referensi file proyek mana. Tidak ada yang menghentikan tim itu untuk memiliki keduanya - solusi tunggal yang mereferensikan semua proyek, dan juga solusi individual masing-masing referensi hanya satu proyek.

Namun demikian saya akan menyarankan untuk menambahkan skrip build. Ini memiliki manfaat bahkan ketika hanya ada satu file solusi. Misalnya, ini memungkinkan seseorang untuk menjalankan VS build dengan konfigurasi yang disukai, memungkinkan Anda menyalin file akhir untuk penyebaran (dan tidak lebih) ke folder "deploy", dan dapat menjalankan beberapa alat dan langkah lain untuk membuat build selesai. Lihat juga F5 bukan proses membangun! , dan The Joel Test .


Ya saya setuju bahwa F5 bukan proses pembuatan, tetapi kami ingin menguji kode mereka dalam tim pengembang sebelum meneruskan ke proses QA kami untuk pengujian ujung ke ujung, karena regresi dan kegagalan pembaruan. Seperti yang telah saya katakan, kami tidak memiliki akses ke TFS mereka sehingga kami harus mengimpor perubahan mereka ke basis kode kami sendiri, dan kemudian memeriksanya ke TFS. Saat ini proses ini sangat buruk sehingga menjalankan autobuild di checkin adalah buang-buang waktu! Kami memiliki autobuild di seluruh sisa produk kami dan itu bekerja dengan sangat baik bagi kami.
DrMistry

Hanya ingin menambahkan, bahwa "Tes Joel" sangat bagus dan saya akan merekomendasikan memiliki tampilan yang bagus. Terima kasih banyak!
DrMistry

3

Itu akan tergantung pada seberapa banyak majelis yang dikompilasi digunakan kembali. Jika tidak ada penggunaan kembali rakitan, maka tidak ada alasan nyata untuk memisahkan "modul". Sebenarnya dalam pengalaman saya ini lebih merupakan penghalang.

Dalam tim pengembangan, saya adalah bagian dari kami memiliki perpustakaan independen yang telah kami tulis yang digunakan dalam banyak produk sebagai solusi terpisah, yang dalam hal ini masuk akal jika tidak kami harus mengkompilasi Aplikasi A agar Aplikasi B tetap mutakhir, yang mungkin diperlukan untuk menjaga agar Aplikasi C tetap mutakhir.

Setiap produk disimpan dalam solusinya sendiri, bahkan jika ada beberapa proyek yang membentuk produk. Dengan cara ini, kita hanya perlu membangun solusi Library untuk menjaga kode yang dibagikan tetap terbaru di semua produk yang dikembangkan.


Tidak ada proyek pemisahan yang digunakan di tempat lain sama sekali, itu hal yang membuat frustrasi. Mereka semua digunakan dalam satu produk ini dan tidak di tempat lain!
DrMistry

1

Setiap perusahaan perangkat lunak yang pernah saya bekerja memiliki tim pengembangan inti yang menyediakan cabang utama yang mencakup kasus penggunaan mendasar dari produk perusahaan.

Pengembang cabang yang menggunakan repositori inti bertanggung jawab untuk menemukan peningkatan dan mengirimkan permintaan tarikan ke cabang utama untuk ditinjau. Ini biasanya bagaimana seseorang menjadi pengembang inti, dengan menunjukkan seseorang dapat memberikan kontribusi yang lebih baik daripada hanya mengipasi api konflik arsitektur.

Kemungkinan perusahaan Anda tidak memiliki sumber daya untuk segera "menyatukan semua kode yang dirujuk satu solusi". Menyarankan mereka melakukannya tanpa memahami kendala anggaran mereka (paling tidak) kemungkinan akan mencegah seseorang menjadi insinyur inti.

Jadi, rumuskan visi agung Anda menjadi beberapa permintaan tarikan yang menghancurkan sampai ke intinya, dan bersiaplah untuk mempertahankan diri Anda dalam ulasan!


0

Ada kernel kebenaran dalam pernyataan "Menggunakan satu solusi untuk beberapa proyek meningkatkan kompleksitas saling ketergantungan".

Sebuah solusi tunggal membuat referensi proyek dari proyek lain (yaitu menggunakan kembali kode proyek alias "memperkenalkan kompleksitas interdependensi") lebih mudah:

  • alih-alih menjelajahi seluruh sistem file / cache rakitan global untuk rakitan yang direferensikan, Anda dapat memilih proyek dari sekumpulan proyek terkait yang terbatas dalam solusi; dan,
  • ketika membaca kode sumber, jauh lebih mudah untuk beralih ke proyek yang direferensikan dalam solusi daripada ke majelis (biner) yang sewenang-wenang.

Jadi di tangan tim yang tidak disiplin menggunakan beberapa proyek dalam satu solusi dapat menyebabkan banyak ketergantungan yang diperkenalkan secara sembarangan. Namun, sebuah tim dapat lebih baik mencoba mempelajari disiplin yang diperlukan untuk mengelola dependensi dengan hati-hati dan kemudian menggunakan kemudahan penggunaan kembali yang menggunakan penawaran solusi.

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.