Haruskah pengembang diharapkan untuk menyusun perpustakaan internal sebelum program yang sebenarnya?

Baru-baru ini seorang pengembang senior yang bekerja dengan saya membuat kasus untuk mengharuskan pengembang mendapatkan versi terbaru dan mengkompilasi sebagai bagian dari proyek mereka perpustakaan internal utama. Ini bertentangan dengan argumen konter bahwa tim proyek harus mengerjakan versi stabil yang mereka dapatkan dari repositori Maven internal yang mana pengembang berpendapat bahwa memiliki kode sumber yang tersedia di mesin pengembang menghemat waktu karena mereka dapat membaca sumber perpustakaan kode untuk menentukan apakah fungsionalitas yang diperlukan tersedia.

Apakah pengembang senior memiliki argumen yang valid? Atau apakah mengharuskan pengembang untuk membaca kode sumber perpustakaan berjalan berlawanan dengan filosofi dasar enkapsulasi dan bahkan memiliki perpustakaan di tempat pertama?

Argumen pengembang senior ini tidak masuk akal bagi saya.

Mereka ingin menambahkan overhead untuk mengambil & mengkompilasi pustaka internal agar devs sesekali dapat membaca kode sumber? Itu akan membuang lebih banyak waktu daripada memiliki devs melihat kode sumber hanya ketika mereka perlu memeriksa apakah suatu fitur tersedia.

Ini adalah ide yang sangat buruk jika perpustakaan dan klien sedang dikembangkan oleh berbagai kelompok pengembangan dan perpustakaan sedang dikembangkan secara aktif. Pengembang klien tidak akan memiliki isolasi dari ketidakstabilan di perpustakaan.

Saya tidak melihat mengapa kode sumber tidak dapat dibuat tersedia untuk pengembang tanpa memaksa mereka untuk membuatnya menjadi bagian dari build normal mereka.

Sarannya adalah

Kami dapat menghemat waktu oleh pengembang sisi klien membaca kode sumber perpustakaan untuk menentukan apakah fungsionalitas yang diperlukan tersedia

Anda dapat membuat saran alternatif

Kami dapat menghemat waktu dengan seseorang yang mendokumentasikan perpustakaan untuk menunjukkan fungsionalitas apa yang tersedia.

Saya tidak akan membeli argumen bahwa memiliki kemampuan untuk meneliti sumber secara lokal adalah keuntungan, tetapi jika perpustakaan sedang dalam pengembangan aktif (mungkin untuk menambah dukungan untuk kebutuhan proyek Anda) maka saya tidak berpikir itu tidak masuk akal untuk meminta pengembang untuk unduh pembaruan secara berkala (mungkin beberapa kali sehari). Saya pikir masuk akal bisnis yang lebih baik untuk membuat biner dikompilasi (dan unit-diuji) tersedia daripada mengharuskan pengembang untuk mengkompilasi dari sumber.

Apakah Anda memiliki kemampuan dalam proyek Anda untuk mengatur semacam repositori bersama di mana versi kompilasi terbaru akan tersedia? Idealnya Anda menginginkan server CI yang melakukan penjadwalan, tetapi meskipun itu hanya sumber daya jaringan yang salah satu pimpinan tim bertanggung jawab untuk memperbarui secara berkala, itu mungkin membantu. Tentu saja, ini harus di piring tim perpustakaan, tapi jelas mereka tidak tertarik, jadi Anda harus mengambil kendur mereka.

Saya dulu bekerja untuk perusahaan perangkat lunak besar yang terus-menerus "dogfooding" perangkat lunak mereka sendiri dengan sistem bisnis internal.

Mereka melihat ini sebagai tingkat pengujian yang lain.

Saya setuju dengan, untuk sebuah perusahaan, adalah hal yang baik.

Saya pikir memaksa Anda untuk mengunduh, dan mengkompilasi versi terbaru adalah langkah terlalu jauh, kecuali langkah kompilasi adalah bagian penting dari perusahaan Anda yang menawarkan penjualan, atau bahkan outsourcing, perpustakaan.

Walaupun memiliki kode sumber yang tersedia dapat bermanfaat, jika Anda memiliki agen pembangun CI yang memantau repositori, WAY lebih masuk akal untuk membuat agen tersebut mengkompilasi pustaka ini dan menyalinnya ke proyek dependen sebagai eksternal, daripada mengharuskan pengembang untuk jalankan dua langkah kompilasi yang berbeda saat membangun salinannya.

Saat ini saya sedang mengerjakan proyek yang tidak terhubung ke agen pembangun, yang membutuhkan pembuatan sub-aplikasi sebelum membangun aplikasi utama. Ini adalah rasa sakit yang serius di posterior saya; untuk melakukan perubahan pada sub-aplikasi, pertama-tama saya harus membangun seluruh proyek, kemudian pergi ke folder sub-build, mengeluarkan produk yang dikompilasi dari itu dan menyalinnya ke sub-folder yang berbeda, sebelum membangun seluruh proyek LAGI untuk memastikan versi sub-aplikasi terbaru termasuk dalam pembuatan aplikasi utama. Ini BUKAN bagaimana hal itu seharusnya dilakukan; setidaknya harus ada skrip MSBuild yang akan mengotomatiskan proses ini, dan saya lebih suka bahwa agen build memperbarui eksternal setiap kali kode baru berkomitmen untuk trunk.

Karena begitu banyak orang menjawab bahwa tidak masuk akal untuk meminta semua orang membangun perpustakaan internal, saya akan menyajikan sudut pandang yang berlawanan yang dapat membenarkan alasannya:

1. Anda sering menggunakan perpustakaan dan tidak ada dokumentasi. Jadi setiap orang harus memiliki sumber untuk referensi. Jika ini adalah perpustakaan yang sangat sering digunakan, memiliki referensi berguna bisa berguna

   • Tentu, orang akan mengatakan bahwa mereka harus bekerja pada dokumentasi dan kemungkinan besar pengembang senior Anda mengetahui fakta ini. Tapi mari kita hadapi kenyataan, banyak kali tim pengembangan berakhir dengan satu ton kode tidak berdokumen, jadi ketika Anda perlu tahu cara kerjanya, Anda pergi ke sumbernya. Anda tidak harus melakukannya, tetapi dalam jangka pendek, ini adalah alternatif terbaik.
   • Biasanya orang-orang terbaik untuk menempatkan dokumentasi di tempat adalah mereka yang tahu perpustakaan yang terbaik. Sayangnya, mereka adalah orang yang sama yang biasanya paling sibuk, jadi seringkali tidak mudah bagi mereka untuk meninggalkan semuanya dan mulai mendokumentasikan.

2. Ketika orang mulai menulis kode mereka sendiri yang tergantung pada perpustakaan dan sesuatu di perpustakaan tidak berfungsi, alih-alih melemparkan tangan mereka ke udara, jika perpustakaan dibangun secara lokal, menjadi sangat mudah untuk melangkah tepat di dalam kode perpustakaan

   • Ini bisa terjadi karena banyak perpustakaan masih jauh dari sempurna dan sementara kita semua ingin bekerja dengan rilis "stabil", masih ada masalah.
   • Mungkin Anda mendapatkan hasil yang buruk karena kesalahpahaman bagaimana API harus digunakan. Bahkan dengan dokumentasi, orang sering membuat asumsi yang salah
   • Orang senior Anda mungkin bosan dengan orang baru (dan kadang-kadang ada lebih banyak orang baru daripada mereka yang mengetahui proyek dalam dan luar) melemparkan tangan mereka ke udara setiap kali terjadi kecelakaan / kesalahan lain yang tampaknya berasal dari kode perpustakaan. Jadi alih-alih harus datang ke mesin Anda dan kemudian ke orang yang duduk di sebelah Anda, mereka menginginkan pilihan untuk menjawab dengan pertanyaan-pertanyaan ini: 1) di mana tepatnya kecelakaan itu? modul / file / baris apa? 2) sudahkah Anda mendebugnya? apa yang telah ANDA temukan?
   • Orang-orang senior Anda bekerja dengan basis kode ini (aplikasi dan perpustakaan utama Anda) cukup lama dan berpotensi dia mungkin telah memperhatikan bahwa ketika kode sudah ada di mesin dan siap untuk di-debug dan dilangkahi, itu membuat hidupnya lebih mudah dan membuat orang-orang untuk mempelajari basis kode lebih cepat. Jadi untuk alasan itu dia memaksa Anda untuk mengambil biaya dimuka untuk membangun perpustakaan di mesin Anda.

Saya tidak mengatakan keputusannya dibenarkan, hanya menunjukkan bahwa a) pertanyaan yang disajikan di satu sisi cerita dan b) mungkin ada motif yang masuk akal.

Pengujian semacam ini sebaiknya dilakukan memang. Masalahnya, itu harus dilakukan oleh penguji, bukan oleh pengembang . Dalam hal itu, itu bukan pekerjaan Anda atau pengembang perpustakaan.

_{Dari apa yang Anda gambarkan sepertinya tidak ada penguji dalam proyek - jika ini masalahnya, itu adalah masalah manajemen, dan cukup serius.}

... menghemat waktu karena mereka dapat membaca kode sumber perpustakaan untuk menentukan apakah fungsionalitas yang diperlukan tersedia

Alasannya cukup lemah. Ketika sebagian besar pustaka versi terbaru gagal dikompilasi dengan proyek versi terbaru, mungkin ada berbagai alasan untuk itu - hanya mengebor kode sumber lib bisa membuang-buang waktu.

• Bagaimana jika pustaka OK dan kegagalan build disebabkan oleh bug dalam kode proyek? Atau, bagaimana jika kegagalan pembangunan disebabkan oleh perubahan sementara yang tidak kompatibel yang seharusnya diperbaiki satu atau dua hari kemudian? Bagaimana jika kegagalan pembangunan menunjukkan masalah integrasi yang rumit yang akan memerlukan waktu seminggu atau sebulan untuk ditangani? Untuk masalah integrasi, apakah menggunakan pustaka versi sebelumnya dapat mengatasinya atau tidak?
   
  Apa pun alasannya, melakukan analisis awal tentang kegagalan akan berarti membuang waktu pengembang untuk pekerjaan yang seharusnya dilakukan oleh penguji.

Hal lain di atas alasan meleset adalah kehilangan produktivitas yang tak terhindarkan (dan cukup menyakitkan dalam pengalaman saya) yang terjadi ketika seseorang harus memutus arus dengan beralih antara pengembangan dan aktivitas QA.

Ketika ada penguji dalam tim, hal-hal seperti itu sangat sederhana dan dapat ditangani dengan lebih mudah. Apa yang diberikan oleh pengembang "senior" Anda pada dasarnya adalah persyaratan pengujian konsep.

Setelah setiap perubahan yang dilakukan pada proyek atau perpustakaan, pastikan pembangunan berhasil.

Langkah-langkah untuk melanjutkan dari sana adalah aktivitas QA yang khas: memperjelas perincian persyaratan, merancang skenario uji yang diformalkan, bernegosiasi tentang cara menangani kegagalan uji.

• Dari perspektif SQA , ini cukup tugas rutin untuk merancang, mengatur dan memelihara prosedur pengujian regresi yang cukup sederhana yang bisa sangat otomatis - mungkin sampai pada titik bahwa hanya aktivitas manual yang akan menciptakan dan memelihara tiket dalam pelacak masalah dan verifikasi perbaikan.

Apa yang disarankan oleh Dev Dev kurang masuk akal bagiku. Sangat menyenangkan bisa menelusuri sumber, tetapi ada cara yang lebih baik untuk melakukannya.

Repositori Artifact apa yang Anda gunakan? Anda harus dapat menggunakan tabung sumber untuk setiap versi untuk hidup di sebelah perpustakaan yang dikompilasi. Sebagian besar IDE akan memungkinkan Anda untuk melampirkan ini ke pustaka yang dikompilasi untuk penelusuran sumber. Eclipse dengan Plugin Maven akan melakukan ini secara otomatis.

Jika Anda membutuhkan kode terbaru, Anda bisa menggunakan snapshot versi.

Ini seharusnya terjadi di skrip build Anda:

1. periksa apakah versi baru tersedia. lewati 2 sebaliknya.
2. unduh dan kompilasi dan jalankan alat apa pun yang Anda miliki untuk membuat referensi API dari kode sumber secara lokal. tampilkan log perubahan.
3. bangun aplikasi Anda

Saya tidak mengerti mengapa atau bagaimana ini menjadi masalah. Juga ketika ada sesuatu yang hilang dalam referensi, Anda dapat menambahkannya ke sumber dan mendorong perubahan. Tentu saja mungkin tampak sedikit menakutkan bahwa perpustakaan dapat berubah tepat di bawah kaki Anda, tetapi jika pengelola perpustakaan melakukan pekerjaan mereka dengan benar, ini adalah hal yang baik.