Bagaimana cara menyebarkan kesadaran untuk pemrograman generik di antara anggota tim?

Saya tinggal di lingkungan, tempat orang percaya:

1. Java generics adalah fitur yang khusus digunakan untuk penulisan pustaka dan bukan untuk pengkodean yang sebenarnya.
2. C ++ adalah bahasa pemrograman OO; templateadalah fitur opsional dan dapat dihindari

Padahal, orang-orang ini sangat bergantung pada perpustakaan yang ditulis menggunakan pemrograman generik (misalnya STL, wadah Java). Jika saya menulis kode menggunakan templates atau generics, peninjau kode kemungkinan besar akan menolaknya dan akan berkomentar untuk menuliskannya dengan cara yang "layak / dimengerti / anggun" .

Mentalitas seperti itu berlaku dari programmer normal ke manajer paling senior. Tidak ada jalan keluar, karena 90% dari waktu, orang-orang ini melakukan lobi.

Apa cara terbaik ( tidak terpotong-potong ) untuk menjelaskannya, pendekatan praktis penulisan kode yang merupakan OO dan pemrograman generik pada saat bersamaan?

Masih ada orang di dunia yang tidak menggunakan generik jave dalam "coding biasa." Saya bisa percaya dengan template C ++, tapi generik? Mereka bahkan tidak sulit untuk dipelajari / digunakan. Serius fitur terbaik dari Java dan C ++ masing-masing adalah generik dan templat.

Cara terbaik untuk meyakinkan orang tentang berbagai hal adalah dengan membuat argumen yang meyakinkan, tidak mengancam, dan menjadi benar.

Selama Anda tidak melakukan sesuatu seperti menggunakan templat sebagai bahasa pemrograman Anda, polimorfisme parametrik (generik / templat) hampir pasti bagus.

1. Menghindari duplikasi kode.

Ini jelas, tetapi kode polimorfik adalah kode umum. Itu sebabnya disebut obat generik.

2. Mendukung pemeriksaan statis yang lebih baik.

Tanpa polimorfisme parametrik Anda akhirnya menulis hal-hal seperti public Object clone()atau public boolean equals(object b)yang bukan hanya kekejian, mereka memiliki tipe yang tidak memberikan informasi tentang apa yang mereka lakukan, dan akhirnya melemparkan pengecualian di semua tempat. Alternatif polimorfisme parametrik dilemparkan ke mana-mana

3. Kode OOP non parametrik polimorfisme pada dasarnya tidak dapat menangani "metode biner" dengan cara yang benar.

Anda sering menggunakannya.

4. Ini adalah praktik terbaik

Di Jawa, penggunaan obat generik dianggap praktik terbaik (lihat Java Efektif oleh Josh Bloch). Pemikir utama C ++ seperti Sutter dan Alexandrescu juga mendorong penggunaan templat untuk memecahkan berbagai masalah.

5. Ini sesuai dengan paradigma OO.

Orang sering tidak memerhatikan hal ini, tetapi kombinasi sub-pengetikan dan generik menghasilkan sistem yang JAUH lebih ekspresif, dan berorientasi objek daripada sistem apa pun dengan hanya satu di antaranya.

Pertimbangkan campuran Scala. Ini adalah fitur bagus yang memungkinkan Anda menarik objek dari bagian-bagian komponen. Generik dan templat dapat mensimulasikan beberapa manfaat ini. Misalnya, katakan salah satu objek Anda menggunakan database. Desain yang bagus akan membuat Anda abstrak akses database ke dalam kelas yang terpisah. Jika dilakukan dengan benar, ini tidak hanya memungkinkan Anda mengolok-olok penyimpanan data Anda (kunci untuk testabilitas) itu juga berarti bahwa Anda dapat menambahkan implementasi alternatif seperti database no-sql yang baru. Namun di sini, Anda mungkin memiliki masalah, mengenai implementasi mana yang Anda gunakan, Anda akan mendapatkan berbagai kemampuan objek bisnis Anda.

Generik untuk menyelamatkan!

   public class Business<S extends Datastore>{
      private S store; ...
   }

Sekarang Anda dapat mulai membedakan Businessobjek secara statis berdasarkan kemampuan untuk menggunakan fitur spesifik basis data. Anda masih memerlukan beberapa pengecekan runtime dan casting, tetapi Anda dapat mulai membuat kode JAUH lebih baik.

dan

6. Kode normal tidak ada.

Hanya ada tiga hal di dunia pemrograman:

1. perpustakaan,
2. konfigurasi, dan
3. kode yang buruk.

Jika Anda tidak berpikir tentang kode Anda seperti itu adalah perpustakaan Anda dalam masalah serius ketika persyaratan untuk proyek Anda berubah. Arsitektur (bisa dibilang) adalah seni merancang API yang baik.

Saya menemukan sikap ini menakjubkan. Setelah Anda terbiasa pemrograman dengan tipe parametrized, tidak menggunakannya hanya membuat semuanya sakit. Dan, Java dan C ++ memiliki banyak bintik-bintik kasar yang mereka bantu atasi.

Ini adalah bentuk khusus dari pertanyaan yang lebih umum "bagaimana Anda meyakinkan atasan Anda untuk mulai menggunakan teknologi / cara yang lebih baru dan lebih baik dalam membuat sesuatu?"

Sayangnya, saya tidak berpikir Anda bisa, dan saya tidak yakin Anda harus melakukannya. Ini adalah definisi pilihan mereka, karena mereka membayar Anda untuk melakukan hal-hal dengan cara tertentu yang telah mereka pilih, bukan dengan cara apa pun yang Anda suka. Yang terbaik yang dapat Anda lakukan adalah menyarankan bahwa teknologi ini ada di luar sana, banyak orang menggunakannya, dan tampaknya menjadi jalan masa depan. Anda bahkan mungkin ingin menyebutkan fakta yang tentu saja harus mereka ketahui: bahwa yang terbaik bagi orang-orang untuk tidak membiarkan keahlian mereka mandek. Tapi itu saja: jika mereka tidak membelinya, tidak ada yang bisa Anda lakukan.

Mereka mungkin memiliki pertimbangan lain yang tidak Anda miliki, karena Anda tidak berpikir pada level mereka. Anda berpikir sebagai seorang insinyur, mereka mungkin berpikir lebih dalam istilah bisnis atau bahkan istilah sumber daya manusia.

• Akankah obat generik (atau apa pun) meningkatkan nilai produk mereka? Mungkin tidak.

• Akankah obat generik (atau apa pun) mempersulit orang-orang yang telah mereka sewa untuk melakukan pekerjaan mereka? Iya nih.

• Akankah obat generik meningkatkan waktu ke pasar? Jika satu-satunya insinyur adalah Anda, mungkin. Tetapi jika sejumlah insinyur perlu dididik tentang obat generik sebelum baris kode lain ditulis di rumah, Tidak.

Jadi, Anda mungkin ingin mempertimbangkan untuk berganti pekerjaan saja. Dalam pekerjaan terakhir saya, saya adalah orang pertama yang menggunakan obat generik dengan Java, dan untungnya mereka tidak punya masalah dengan itu; mereka menyatakan keprihatinan bahwa obat generik membuat kode 'lebih sulit dibaca', tetapi mereka membiarkan saya mengambil jalan saya. Temukan pekerjaan seperti itu.

Saya akan menyiarkan manfaat generik kepada peninjau kode dan kolega lain sebelum ulasan:

1) Dengan memungkinkan Anda menentukan jenis yang dijalankan oleh kelas atau metode generik, fitur generik mengalihkan beban keselamatan jenis dari Anda ke kompiler. Tidak perlu menulis kode untuk menguji tipe data yang benar karena ini diberlakukan pada waktu kompilasi. Kebutuhan untuk casting tipe dan kemungkinan kesalahan run-time berkurang.

2) Generik memberikan keamanan tipe tanpa overhead dari banyak implementasi.

Jadi, [1] dan [2] mengurangi risiko kesalahan dalam kode. Ini menghemat waktu pengembang dan karenanya uang perusahaan.

Jika keterbacaan adalah masalah maka kecanggungan menggunakan tipe generik dapat dikompromikan. Ini adalah salah satu alasan Anda mungkin ingin memperluas pedoman pengkodean. Ini dapat dilakukan dalam konteks hari kerja dan tidak hanya untuk memperluas perpustakaan (namun, ini merupakan ide untuk melakukan refactor saat Anda pergi dan menandai metode kandidat yang mungkin untuk perpustakaan dalam kode untuk pengakuan yang mudah nanti). Oleh karena itu, tidak ada alasan untuk tidak menggunakannya dalam konteks hari kerja.

Saya akan menambahkan beberapa pernyataan tentang bagaimana programmer lain tidak memiliki masalah dengan obat generik: Generik banyak digunakan di Jawa dan banyak bahasa lain seperti C #. Setiap programmer yang serius akan menemukan kehidupan yang sulit tanpa jenis blok bangunan yang aman.

Meskipun demikian, Anda mungkin ingin mempertimbangkan bahwa beberapa pengembang mungkin tidak siap. Manajemen bisa saja membuat keputusan sadar untuk melindungi proyek di masa lalu, dengan demikian menjauhkan mereka dari area berbahaya. Di sini, baik yang tidak bersalah maupun yang bersalah biasanya disalahkan karena analisis atau manajemen mikro yang memadai jarang dilakukan.

Jika Anda mengajukan kasus yang baik dan Anda tidak diberi respons beralasan maka diam-diam mulai mencari perusahaan lain yang menganggap serius pemrograman.

Kecuali jika Anda adalah arsitek / pemimpin teknologi akan sulit untuk mengamanatkan bahwa Anda harus menggunakan generik / templat. Anda benar-benar harus mengusulkan solusi generik / templat jauh sebelum ulasan kode, lebih disukai sebelum Anda mulai menerapkannya.

Apa yang dapat Anda lakukan adalah menunjukkan mengapa Anda harus menggunakan obat generik dalam beberapa kasus. Jika Anda dapat menunjukkan manfaatnya, maka rekan kerja Anda mungkin setuju. Alasan yang memungkinkan mengapa Anda harus menggunakan obat generik / templat adalah sebagai berikut:

• Seharusnya membiarkan Anda menulis lebih sedikit kode untuk tugas berulang
• Itu membuat pekerjaan programmer lebih mudah
• Ini memberlakukan pola yang ditetapkan oleh arsitek solusi
• Ini merangkum fitur-fitur umum, yang akan memaksa programmer untuk tidak menyalin-menempelkan kode (yaitu menghindari masalah pemeliharaan ganda)
• Itu cukup bukti di masa depan kode Anda (meskipun jalan ini sulit untuk alasan tentang)

Dalam proyek Java baru-baru ini saya berhasil menambahkan beberapa kelas abstrak generik karena memuaskan beberapa hal dasar: itu membuat segalanya lebih mudah bagi yang lain dalam tim, menegakkan pola yang sudah diusulkan arsitek dan memiliki beberapa kode umum yang tidak perlu diprogram oleh programmer. Salin dan tempel. Itu adalah pola sederhana yang ditulis arsitek tentang orang yang cukup kompeten masih mendapatkan kesalahan (karena kompleksitas sistem yang sebenarnya dalam permainan), tetapi tanda generik yang digunakan kelas mana.

Jelas saya tidak bisa memamerkan contoh nyata tanpa melanggar perjanjian non-pengungkapan. Tetapi sebagai contoh dari apa yang saya lakukan adalah melakukan pola strategi dan menegakkannya dengan obat generik. Jadi ini adalah pola strategi:

Dan agar pemrogram menerapkan pola ini, Anda dapat menambahkan tipe generik Contextyang seharusnya menggunakan sesuatu yang memiliki Strategytipe. Dari segi kode akan terlihat seperti ini di Jawa:

// declare the generic Context class that has a type "S" 
// that is an upper bound class of Strategy
public class Context <S extends Strategy> {
    S strategy;

    // Constructor with an initial strategy
    public Context(S initialStrategy) {
        this.strategy = initialStrategy;
    }

    public void doSomething() {
      strategy.execute(); // assumes that Strategy has an execute() method.
    }

    public void setStrategy(S strategy) {
        this.strategy = strategy;
    }
}

Anda dapat melakukan ini cukup banyak dengan pola apa pun sejauh yang saya tahu. Pastikan Anda dapat menguji desain generik / template Anda dengan unit test untuk melihat apakah itu berfungsi, untuk memiliki kepercayaan pada desain kode.

Jika kolega Anda tidak menyukai ide itu maka jangan tersinggung, mungkin itu bukan solusi mudah bagi mereka untuk menanganinya seperti yang Anda pikirkan. Itulah sebabnya Anda harus mengusulkan solusi generik / template sebelum Anda mulai mengimplementasikannya. Anda masih harus bekerja sama dengan kolega Anda untuk menyelesaikan masalah aktual dengan cara yang berbeda.

Selalu ada beberapa cara untuk melakukan hal yang sama. Jika penggunaan template Anda merupakan penyalahgunaan template maka itu harus gagal dalam tinjauan kode.

Namun, jika kode Anda gagal ditinjau, karena mereka tidak memahami templat, maka masalahnya berbeda jenis. Dalam hal ini sarankan mereka (dengan cara yang baik) untuk mempelajari templat.

Apa yang Anda hadapi di sini adalah kumpulan bias. Orang-orang lebih suka status quo, sebuah groupthink telah dikembangkan, dan argumen itu telah dilancarkan beberapa kali sehingga orang menjadi tertanam dalam keyakinan mereka.

Salah satu strategi paling efektif di sini adalah fokus pada kemenangan kecil. Saya membaca contoh berikut dalam sebuah buku : penulisnya adalah pengguna non-Apple yang setia. Dia tidak menyukai mereka, dan dia tidak ingin ada hubungannya dengan mereka. Dia melakukan banyak diskusi dengan orang-orang dengan sikap pro-Apple, dan masing-masing hanya mendorong tumitnya lebih dalam ke tanah. Kemudian seseorang membelikannya iPod shuffle dan seperti itu, biasnya menghilang. Itu tidak membuatnya hanya ingin membeli produk Apple, tetapi sikap anti-Apple yang keras dan mengakar telah digantikan dengan sudut pandang yang lebih seimbang. Ada ruang untuk kompromi, dan dia perlahan-lahan beralih ke Apple sepenuhnya.

Jadi jangan mencoba meyakinkan semua orang sekaligus: itu akan memiliki efek sebaliknya. Fokus pada satu hal kecil, dan sisanya akan terjadi dengan sendirinya. Cukup singkirkan sifat dua sisi dari argumen sehingga orang dapat menyeberang sedikit demi sedikit, bukannya sekaligus.

Titik khusus untuk fokus tergantung pada situasi Anda, tetapi inilah satu ide: Pembagian yang Anda buat sketsa antara perpustakaan dan 'kode nyata' tampaknya sangat tidak wajar. Dalam pandangan saya, seorang programmer membuat aplikasi harus menghabiskan 80% waktunya di perpustakaan untuk jenis aplikasi yang dia buat dan 20% menggunakan perpustakaan itu untuk membangun aplikasi. Semua kode yang layak disimpan harus dianggap sebagai perpustakaan. Saya akan menyarankan kepada atasan Anda bahwa Anda menggeneralisasi beberapa kode Anda ke dalam perpustakaan internal (jika Anda belum melakukannya). Dengan logika mereka sendiri, mereka harus menggunakan obat generik untuk ini, dan dengan perkiraan di atas, 80% dari kode Anda dapat berakhir di dalam perpustakaan. Setelah Anda membuat semua orang menggunakan obat generik dari sisi lain, mereka harus terbiasa dengannya, dan biasnya akan memudar.

Catatan "dapat dimengerti". Jika peninjau kode tidak melihat manfaat dari obat generik, maka semua <<<>>>-stuff hanyalah suara yang tidak dapat dipahami yang tidak perlu.

Saya akan menyarankan untuk melihat berapa banyak sebenarnya, bug saat ini (terbuka atau baru saja diperbaiki) yang berisi database bug Anda yang bisa dihindari dengan menggunakan obat generik. Cari ClassCastExceptions.

Perhatikan juga bahwa jika Anda tidak memiliki bug yang dapat dihindari dengan menggunakan obat generik, maka rekan Anda memiliki titik di mana Anda tidak membutuhkannya.

Saya akan mudah dalam hal ini. Saya pindah dari Jawa 1.4 ke 1.6 beberapa tahun yang lalu, dan obat generik menjadi kejutan. Ini sederhana dan sangat membantu jika Anda mencoba menyulap beberapa Koleksi, Peta, dan struktur lainnya. Namun, menulis kelas yang mengambil data umum sebagai parameter, memanipulasi mereka, dan meneruskannya ke kelas lain dengan cepat menjadi membingungkan secara monumental. Saya mendapatkan kepuasan yang luar biasa dari membuat semuanya bekerja, tetapi bertanya-tanya apakah waktu dan upaya tambahan yang dihabiskan tidak sia-sia. Saya juga takut sejumlah programmer Java mungkin tidak pernah benar-benar memahami itu.

Beberapa pemikiran acak dari perjalanan generik saya sejauh ini:

• ClassCastExceptions muncul pada saat run time, tetapi biasanya muncul pada beberapa kali run pertama dan mudah diperbaiki.
• Setiap artikel yang saya baca tentang obat generik menyatakan bahwa kadang-kadang itu tidak berfungsi dan Anda perlu menggunakannya @SuppressWarnings(value="unchecked")sesekali. Bagaimana Anda tahu jika Anda berada di luar batas obat generik, atau jika Anda hanya bodoh dan perlu berpikir lebih keras?
• Mungkin sulit untuk diterapkan @SuppressWarnings(value="unchecked")hanya pada satu baris.
• Saya menambahkan beberapa generik mewah ke salah satu kelas saya. Saya sudah mengenal beberapa programmer yang bisa meningkatkan kelas sebelum saya membuatnya, yang tidak pernah bisa menyentuhnya dan mendapatkan kompilasi bersih setelahnya.

Generik telah membersihkan kode saya dan memperingatkan saya tentang masalah terlalu banyak bagi saya untuk menolaknya, tetapi saya juga melihat peningkatan waktu pengembangan, waktu ekstra yang dihabiskan untuk pelatihan, dan programmer Java terpaksa bekerja di C #, C, dan Visual Basic. ..atau Java 1.4. Saya akan fokus pada penulisan kode yang bisa dipahami rekan kerja Anda. Jika Anda dapat memasukkan beberapa obat generik yang dapat dimengerti, bagus. Saya melihat generik Java sebagai peluang / masalah yang belum ditemukan.