Dengan memalukan saya memperkenalkan perpustakaan "umum", yang dinamai demikian, di lingkungan tim beberapa dekade yang lalu. Saya tidak begitu memahami dinamika saat itu tentang apa yang bisa terjadi dalam pengaturan tim yang terkoordinasi secara longgar hanya dalam hitungan bulan.
Ketika saya memperkenalkannya, saya pikir saya sudah menjelaskan dan juga mendokumentasikan bahwa itu untuk hal-hal yang kita semua setuju bahwa kita akan berguna setiap hari, bahwa itu dimaksudkan untuk menjadi perpustakaan minimalis, dan bahwa perpustakaan harus bergantung pada hal lain selain perpustakaan standar sehingga semudah mungkin digunakan dalam proyek-proyek baru. Pemikiran saya pada saat itu adalah bahwa itu adalah perluasan kecil kami sendiri ke perpustakaan standar untuk hal-hal yang, dalam domain khusus kami, kami temukan berguna setiap hari.
Dan itu dimulai dengan cukup baik. Kami mulai dengan perpustakaan matematika ( common/math*) dari rutinitas yang kami semua gunakan setiap hari, karena kami bekerja dalam grafik komputer yang sering berat pada aljabar linier. Dan karena kami sering berinteraksi dengan kode C, kami menyetujui beberapa fungsi utilitas yang bermanfaat seperti find_indexitu, tidak sepertistd::finddi C ++, akan mengembalikan indeks ke elemen yang ditemukan secara berurutan alih-alih iterator yang meniru bagaimana fungsi C kita bekerja - hal-hal semacam ini - sedikit eklektik tetapi minimalis dan cukup banyak digunakan untuk tetap akrab dan praktis untuk semua orang , dan keakraban instan adalah kriteria yang sangat penting seperti yang saya lihat dalam mencoba membuat apa pun yang "umum" atau "standar" karena jika itu benar-benar "umum", itu harus memiliki kualitas yang akrab tentang itu sebagai hasil dari luasnya adopsi dan penggunaan sehari-hari.
Namun seiring waktu niat desain perpustakaan terlepas dari jari saya ketika orang mulai menambahkan hal-hal yang mereka gunakan secara pribadi yang mereka pikir mungkin berguna bagi orang lain, hanya untuk menemukan tidak ada orang lain yang menggunakannya. Dan kemudian seseorang mulai menambahkan fungsi yang bergantung pada OpenGL untuk rutin terkait GL yang umum. Selanjutnya kami mengadopsi Qt dan orang-orang mulai menambahkan kode yang bergantung pada Qt, jadi sudah umum perpustakaan bergantung pada dua perpustakaan eksternal. Pada titik tertentu seseorang menambahkan rutinitas shader umum yang bergantung pada pustaka shader khusus aplikasi kami, dan pada saat itu Anda bahkan tidak dapat menggunakannya di proyek baru tanpa memasukkan Qt, OGL, dan pustaka shader khusus aplikasi dan penulisan kami skrip bangun non-sepele untuk proyek Anda. Jadi itu berubah menjadi kekacauan eklektik dan saling tergantung ini.
Tetapi saya juga menemukan dengan memperdebatkan apa yang harus dan tidak harus masuk ke perpustakaan ini bahwa apa yang dianggap "umum" dapat dengan mudah berubah menjadi ide yang sangat subyektif jika Anda tidak menetapkan aturan garis yang sangat keras bahwa apa yang "umum" adalah apa yang cenderung bermanfaat bagi setiap orang setiap hari. Setiap pelonggaran standar dan dengan cepat menurunkan dari hal-hal yang setiap orang merasa berguna setiap hari menjadi sesuatu yang berguna bagi pengembang tunggal yang mungkin memiliki kemungkinan bermanfaat bagi orang lain, dan pada saat itu perpustakaan terdegradasi menjadi kekacauan eklektik yang sangat cepat .
Tetapi lebih jauh lagi ketika Anda mencapai titik itu, beberapa pengembang dapat mulai menambahkan hal-hal karena alasan sederhana bahwa mereka tidak menyukai bahasa pemrograman. Mereka mungkin tidak menyukai sintaks for for loop atau function call, di mana perpustakaan mulai dipenuhi dengan hal-hal yang hanya melawan sintaks dasar bahasa, mengganti beberapa baris kode langsung yang tidak benar-benar menduplikasi logika apa pun hingga satu baris singkat kode eksotis hanya akrab bagi pengembang yang memperkenalkan steno semacam itu. Kemudian pengembang seperti itu mungkin mulai menambahkan lebih banyak fungsi ke perpustakaan umum yang diimplementasikan menggunakan steno seperti itu, pada titik mana bagian-bagian penting dari perpustakaan umum menjadi terjalin dengan steno-steno eksotis yang mungkin tampak indah dan intuitif bagi pengembang yang memperkenalkannya tetapi jelek dan asing dan sulit dimengerti untuk semua orang. Dan pada titik itu saya pikir Anda tahu bahwa setiap harapan untuk membuat sesuatu yang benar-benar "umum" hilang, karena "umum" dan "asing" adalah ide yang berlawanan.
Jadi ada semua jenis kaleng cacing di sana, setidaknya di lingkungan tim yang terkoordinasi dengan longgar, dengan perpustakaan dengan ambisi seluas dan sama umum dengan "barang yang biasa digunakan". Dan sementara masalah yang mendasari mungkin adalah koordinasi longgar di atas segalanya, setidaknya beberapa perpustakaan dimaksudkan untuk melayani tujuan yang lebih tunggal, seperti perpustakaan yang dimaksudkan untuk menyediakan rutinitas matematika dan tidak ada yang lain, mungkin tidak akan menurunkan secara signifikan dalam hal ini. desain kemurnian dan dependensi sebagai perpustakaan "umum". Jadi dalam retrospeksi saya pikir akan jauh lebih baik untuk berbuat salah di sisi perpustakaan yang memiliki niat desain yang jauh lebih jelas. Saya juga menemukan selama bertahun-tahun bahwa tujuan yang sempit dan penerapan yang sempit adalah ide yang sangat berbeda.
Juga saya diakui setidaknya sedikit tidak praktis dan peduli mungkin sedikit terlalu banyak tentang estetika, tetapi cara saya cenderung memahami ide saya tentang kualitas perpustakaan (dan mungkin bahkan "keindahan") dinilai lebih oleh tautan terlemahnya daripada ini yang terkuat, dengan cara yang sama bahwa jika Anda menyajikan saya makanan yang paling menggugah selera di dunia tetapi, di piring yang sama, menaruh sesuatu yang membusuk di sana yang baunya sangat buruk, saya cenderung ingin menolak seluruh piring. Dan jika Anda seperti saya dalam hal itu dan membuat sesuatu yang mengundang segala macam tambahan sebagai sesuatu yang disebut "umum", Anda mungkin menemukan diri Anda melihat piring analog dengan sesuatu yang membusuk di samping. Jadi saya pikir itu baik jika perpustakaan dikelola dan dinamai dan didokumentasikan sedemikian rupa sehingga tidak ' t mengundang semakin banyak penambahan dari waktu ke waktu. Dan itu bahkan dapat diterapkan pada kreasi pribadi Anda, karena saya tentu saja telah membuat beberapa barang busuk di sana-sini, dan itu "lebih sedikit" mencemari jika tidak ditambahkan ke piring terbesar. Memisahkan hal-hal menjadi perpustakaan kecil, sangat tunggal memiliki kecenderungan untuk memisahkan kode yang lebih baik juga, jika hanya karena kebajikan semata yang menjadi jauh lebih tidak nyaman untuk mulai menggabungkan semuanya.
Deduplikasi kode telah dipalu pada saya selama bertahun-tahun tetapi saya merasa saya harus mencobanya kali ini.
Apa yang mungkin saya sarankan dalam kasus Anda adalah untuk mulai memudahkan deduplikasi kode. Saya tidak mengatakan untuk menyalin dan menempelkan potongan besar kode yang tidak teruji, rawan kesalahan di sekitar atau semacam ini, atau menduplikasi kode non-sepele dalam jumlah besar yang memiliki probabilitas yang layak untuk memerlukan perubahan di masa depan.
Tetapi terutama jika Anda memiliki pola pikir untuk membuat perpustakaan "umum", yang menurut saya keinginan Anda adalah untuk menciptakan sesuatu yang dapat diterapkan secara luas, sangat dapat digunakan kembali, dan mungkin idealnya sesuatu yang Anda temukan sama bermanfaatnya hari ini seperti yang Anda lakukan satu dekade dari sekarang , maka terkadang Anda bahkan mungkin perlu atau menginginkan duplikasi untuk mencapai kualitas yang sulit dipahami ini. Karena duplikasi mungkin sebenarnya berfungsi sebagai mekanisme decoupling. Ini seperti jika Anda ingin memisahkan pemutar video dari pemutar MP3, maka Anda setidaknya harus menduplikasi beberapa hal seperti baterai dan hard drive. Mereka tidak dapat berbagi hal-hal ini atau kalau tidak, mereka tidak dapat digabungkan dan tidak dapat digunakan secara independen satu sama lain, dan pada saat itu orang mungkin tidak tertarik pada perangkat lagi jika semua yang ingin mereka lakukan adalah memutar MP3. Tetapi beberapa waktu setelah Anda memisahkan kedua perangkat ini, Anda mungkin menemukan bahwa pemutar MP3 dapat mengambil manfaat dari desain baterai yang berbeda atau hard drive yang lebih kecil dari pemutar video, di mana Anda tidak lagi menduplikasi apa pun; apa yang awalnya dimulai sebagai duplikasi untuk memungkinkan perangkat yang saling bergantung ini dipecah menjadi dua, perangkat independen yang terpisah nantinya dapat menghasilkan desain dan implementasi yang tidak lagi mubazir sama sekali.
Ada baiknya mempertimbangkan hal-hal dari perspektif yang menggunakan perpustakaan. Apakah Anda benar-benar mau menggunakannyaperpustakaan yang meminimalkan duplikasi kode? Kemungkinannya adalah Anda tidak akan melakukannya karena yang melakukannya secara alami akan bergantung pada perpustakaan lain. Dan pustaka-pustaka lain itu mungkin bergantung pada pustaka lain untuk menghindari duplikasi kodenya, dan seterusnya, sampai Anda mungkin perlu mengimpor / menautkan 50 pustaka yang berbeda hanya untuk mendapatkan beberapa fungsi dasar seperti memuat dan memainkan file audio, dan itu menjadi sangat sulit . Sementara itu jika perpustakaan audio seperti itu sengaja memilih untuk menduplikasi beberapa hal di sana-sini untuk mencapai kemandiriannya, itu akan menjadi jauh lebih mudah untuk digunakan dalam proyek-proyek baru, dan kemungkinan bahwa itu tidak perlu diperbarui hampir sesering sejak ia menang ' tidak perlu berubah sebagai akibat dari perubahan perpustakaan eksternal yang bergantung yang mungkin berusaha memenuhi tujuan yang lebih umum daripada apa yang dibutuhkan perpustakaan audio.
Jadi kadang-kadang ada baiknya secara sengaja memilih untuk menggandakan sedikit (secara sadar, tidak pernah kemalasan - sebenarnya karena ketekunan) untuk memisahkan perpustakaan dan menjadikannya independen karena, melalui kemandirian itu, ia mencapai jangkauan penerapan praktis yang lebih luas dan bahkan stabilitas (tidak ada lagi kopling aferen). Jika Anda ingin mendesain pustaka yang paling dapat digunakan kembali yang mungkin akan bertahan Anda dari satu proyek ke yang berikutnya dan selama bertahun-tahun, maka di atas mempersempit cakupannya ke minimum, saya benar-benar akan menyarankan mempertimbangkan duplikasi sedikit di sini. Dan secara alami tulis unit test dan pastikan itu benar-benar diuji dan dapat diandalkan pada apa yang dilakukannya Ini hanya untuk perpustakaan yang Anda benar-benar ingin meluangkan waktu untuk menggeneralisasi ke titik yang jauh melampaui satu proyek.