Apakah boleh menggunakan meta-programming meskipun tidak semua kolega saya memahaminya?

Saya menggunakan banyak meta-pemrograman untuk menghindari tugas berulang dan membangun abstraksi yang lebih aman digunakan.

Saya baru-baru ini pindah ke pekerjaan baru di mana saya bekerja di tim yang lebih besar dan ini membuat beberapa rekan saya khawatir, karena mereka tidak memahaminya.

Saya selalu berusaha memanfaatkan potensi penuh dari bahasa tersebut, tetapi beberapa (tidak semua) kolega saya menganggap itu sebagai risiko (beberapa menyambut pendekatan).

Saya setuju itu adalah masalah untuk menulis kode yang tidak bisa dipahami oleh orang lain di tim. Di sisi lain kita semua adalah pengembang C ++ profesional dan saya pikir kita harus bercita-cita untuk standar yang lebih tinggi daripada menulis C dengan kelas.

Pertanyaan saya adalah, siapa yang benar, apa yang harus saya lakukan?

Klarifikasi: Mencoba memanfaatkan potensi penuh dari bahasa tersebut, tidak berarti saya melempar TMP pada setiap masalah. C ++ adalah kotak alat dan bagi saya kemahiran C ++ adalah tentang dapat menggunakan semua alat dari kotak dan tentang memilih yang tepat untuk pekerjaan tertentu.

Pemrograman ulang tidak masalah. Apa yang Anda coba lakukan tidak OK.

Saya menggunakan metaprogramming setiap saat dalam pekerjaan saya. Ini adalah alat yang ampuh yang dapat digunakan untuk melakukan banyak hal dengan cara yang lebih mudah dibaca dan dikelola. Ini juga salah satu yang paling sulit untuk memahami gaya pemrograman di luar sana, sehingga benar-benar perlu untuk mempertahankannya. Saya suka kalau saya bisa mengurangi 1000 baris kode menjadi 50, tetapi saya mencoba untuk membatasi itu.

Masalahnya bukan metaprogramming, tapi ini:

Di sisi lain kita semua adalah pengembang C ++ profesional dan saya pikir kita harus bercita-cita untuk standar yang lebih tinggi daripada menulis C dengan kelas.

Di sinilah Anda mendapat masalah. Anda punya pendapat. Tidak masalah memiliki pendapat bahwa pemrograman itu baik. Tidak apa-apa memiliki pendapat bahwa kita semua ingin menjadi pengembang C ++ yang lebih baik.

Tidaklah baik untuk memaksa kolega Anda dan karyawan masa depan yang harus mempertahankan kode yang Anda tulis untuk menyetujui pendapat Anda. Itu adalah tugas bos Anda. Bos Anda adalah orang yang harus peduli untuk memastikan bahwa kode Anda dapat dipertahankan dalam jangka panjang. Mereka (semoga) memiliki lebih banyak pengalaman bisnis, karena percayalah ketika saya mengatakan itu keputusan bisnis, bukan keputusan ideologis.

Tidak apa-apa ingin metaprogram. Tidak masalah untuk ingin mengajar orang lain untuk metaprogram. Tetapi pahamilah bahwa orang lain juga boleh memilih untuk tidak belajar metaprogram, dan itu akan berlaku sampai Anda berada dalam posisi berkuasa. (dan, sebagai rahasia industri: ketika Anda akhirnya menjadi pengembang utama, dalam posisi berkuasa, Anda sama sekali tidak berada dalam posisi berkuasa. Ada seseorang yang mengendalikan pengejar yang berkuasa).

Jika Anda ingin mendorong mereka agar baik-baik saja dengan metaprogramming, mulailah dari yang kecil . Mulai dengan satu enable_ifyang membuat API lebih mudah dibaca. Kemudian beri komentar pada siang hari . Maka mungkin menemukan satu kasus di mana metafungsi templat mengubah 10 kelas berulang besar menjadi 1 kelas dengan 10 pembantu kecil. Komentari hal itu. Dapatkan umpan balik. Temukan apa yang orang pikirkan tentang itu. Baik-baik saja jika mereka mengatakan kepada Anda untuk tidak melakukannya. Temukan ceruk di mana metaprogramming mendapatkan hasil yang sangat baik sehingga kolega Anda semua (dengan enggan) setuju bahwa itu adalah alat yang tepat untuk pekerjaan itu.

Sebagai cerita pendek, saya pernah menulis perpustakaan yang indah sekali, menggunakan metaprogramming yang luas. Itu benar- benar melakukan apa yang kami butuhkan saat itu, ketika tidak ada pendekatan lain yang bisa mendekat. Ini benar-benar mengubah arah aplikasi yang saya tulis. Tapi itu metaprogramming. Hanya satu atau dua orang di seluruh perusahaan saya yang bisa membacanya.

Belakangan, kolega saya menusuk masalahnya lagi. Alih-alih memanfaatkan metaprogramming untuk secara tepat melakukan apa yang dibutuhkan, ia bekerja dengan kepemimpinan untuk mengendurkan kendala yang telah diletakkan pada masalah sehingga metaprogramming tidak diperlukan. Mungkin lebih akurat, pemrograman metapl kurang dibutuhkan. Dia mampu membatasi hal itu pada apa yang diprogramkan dengan metaprogram terbaik.

Perpustakaan yang dihasilkan sekarang dalam posisi untuk digunakan di pasar yang sangat luas, dan itu tentu tidak sedikit karena fakta bahwa kode baru dapat dikelola oleh berbagai pengembang yang jauh lebih luas. Saya bangga membuka jalan dengan metaprogramming, tapi kode rekan saya yang akan menjangkau khalayak yang lebih luas, dan ada alasan bagus untuk itu.

Pertama dan terpenting, ini adalah masalah tim, dan Anda harus menyelesaikannya dengan tim. Jika Anda memiliki cadangan dari tim untuk pemrograman menggunakan elemen dan konstruksi tertentu, lakukan; jika tidak, diskusikan dengan mereka dan jika Anda tidak dapat meyakinkan mereka dan membuat alasan kuat mengapa "pendekatan Anda" jelas lebih baik, Anda akan lebih baik untuk tidak menggunakannya.

Perhatikan bahwa menggunakan templat meta pemrograman dalam C ++ selalu merupakan trade-off: tentu, kadang-kadang dapat membantu untuk merancang bagian tertentu dari aplikasi yang lebih KERING, dan tentunya sangat membantu untuk membuat perpustakaan yang sangat efisien dan sangat dapat digunakan kembali.

Di sisi lain, manfaat-manfaat ini datang dengan biaya tertentu: kode menjadi lebih abstrak, seringkali lebih sulit dibaca, lebih sulit untuk di-debug dan lebih sulit untuk dipertahankan. Ini membuat kegunaan meta-pemrograman dalam pemrograman aplikasi sering dipertanyakan. Jadi, dengan asumsi Anda tidak akan membuat STL berikutnya, setiap kali Anda tergoda untuk menggunakan meta-programming, tanyakan pada diri Anda apakah kelemahan-kelemahan itu benar-benar layak. Dan jika Anda tidak yakin, diskusikan hal ini dengan peer reviewer Anda selama tinjauan kode.

Pendapat umum saya: jika Anda memiliki pilihan, seperti yang sering terjadi, antara tiga opsi berikut:

• Ketik banyak struktur kode nontrivial secara berulang dengan tangan;
• Gunakan metaprogramming template C ++ untuk mengotomatisasi pembuatan kode;
• Gunakan beberapa mekanisme pembuatan kode lain, seperti makro atau bahasa pemrograman lain untuk menghasilkan file sumber C ++

lalu templat metaprogramming, dilakukan dengan benar, kemungkinan akan menjadi yang paling mudah dibaca dan dikelola dari tiga opsi. Ini adalah argumen yang akan saya sampaikan kepada tim, jika saya berada di posisi Anda. Contoh dengan kode aktual akan membantu meyakinkan mereka.

Ketika Anda menggunakan Template Meta-Programming ( TMP ) untuk menghindari pengulangan, Anda harus menggunakannya untuk membangun abstraksi yang terdokumentasi dengan baik dan cermat yang melokalisasi kompleksitas dalam kode TMP, membuatnya mudah untuk menulis kode klien yang benar. Ini adalah desain pustaka standar C ++.

Saya tidak berpikir bahwa kita dapat menilai siapa yang benar atau salah tanpa melihat contoh jenis kode yang Anda coba tulis.

Pengembang perangkat lunak harus bercita-cita untuk menulis kode yang berfungsi, yang bekerja jelas, yang dapat diuji, yang dapat ditinjau, yang dapat di-debug, dan yang dapat diadaptasi ketika perubahan diperlukan. Jika menulis "C dengan kelas" mencapai ini, maka tidak apa-apa.

Dan ini adalah standar yang harus Anda ukur terhadap kode Anda. Terutama: Apakah ini bekerja dengan jelas, dapatkah itu diuji, dapatkah ditinjau kembali, dapatkah itu dibobol, dan dapatkah itu diadaptasi ketika dibutuhkan?

Argumen dari belas kasih:

Apakah pekerjaan Anda memberi waktu luang untuk belajar, atau sebagai alternatif, dapatkah Anda meyakinkan bos Anda untuk mengalokasikan beberapa jam untuk mempelajari fitur-fitur bahasa ini?

Jika tidak, menggunakan itu pada dasarnya memberi mereka pekerjaan ekstra yang tidak dibayar. Anda mungkin berpikir bahwa seorang programmer C ++ harus mengetahui seluruh bahasa, atau sesuatu seperti itu, tetapi masalah akademik tidak mengurangi beban yang akan Anda tanggung pada mereka. Kolega Anda memiliki anak, orang tua yang sakit, pasangan yang sakit - atau neraka, hanya kehidupan sosial yang wajar yang tidak melibatkan belajar C ++. Lawan yang lebih vokal dari proposal Anda mungkin malas - atau mereka mungkin mengalami masa sulit dan tidak perlu omong kosong tambahan dalam hidup mereka saat ini.

Kode harus ditulis pertama untuk dibaca oleh manusia, dan hanya secara tidak sengaja bagi kompiler untuk diuraikan.

Sekarang hal yang perlu diingat tentang TMP non-sepele adalah bahwa Anda membatasi jumlah orang yang dapat membaca kode itu, itu bisa menjadi tradeoff yang valid, tapi saya berpendapat ini jauh lebih dari tradeoff yang wajar di perpustakaan dan di mana Anda memiliki tim ahli kecil kemudian dalam aplikasi yang lebih besar.

Ketika Anda mengeluarkan semua trik dalam buku yang Anda kenakan biaya pada orang lain karena sekarang mereka perlu memahami bahasa termasuk semua kasus sudut pengacara yang telah Anda eksploitasi, Anda juga membebankan biaya untuk mempekerjakan karena Anda telah meningkatkan standar. untuk bekerja pada aplikasi dengan cara yang bermanfaat, sekarang mungkin itu sepadan, tetapi perhatikan biaya ....

Bagi saya, sedikit lebih mengetik, mungkin bahkan beberapa duplikasi kode, tetapi saya dapat meletakkannya di depan Mr "C with classes plus STL" ketika perlu modifikasi jauh lebih berguna daripada beberapa hal TMP yang sangat elegan yang hanya bisa saya pertahankan (Dan karenanya akan selamanya dipertahankan). Ingat juga bahwa C dengan cowok kelas mungkin kebetulan adalah ahli materi pelajaran, dan keahlian itu biasanya jauh lebih berharga daripada menjadi pengacara bahasa.

Saya lupa siapa yang mengatakannya tetapi "Semua orang tahu bahwa debugging lebih sulit daripada menulisnya di tempat pertama, jadi jika Anda memprogramnya sepintar yang Anda bisa, bagaimana Anda bisa men-debug itu?".

Bahkan jika saya dapat menulis C ++ yang benar-benar modern, saya biasanya memilih untuk tidak melakukannya, itu berarti saya harus melakukan lebih sedikit pemrograman pemeliharaan.

Tidak seharusnya tidak. Anda dipekerjakan untuk menghasilkan kode yang memenuhi spesifikasi. Kode ini harus dipertahankan bukan perjalanan ego. Anda bisa ditabrak bus besok, jadi seseorang harus dapat mengambil kode Anda dan melanjutkan tugas di tangan. Namun, positif untuk mencoba meyakinkan majikan Anda untuk memasukkan teknik baru ke dalam standar pemrograman mereka.

Satu-satunya cara untuk menjawab pertanyaan ini dalam konteks adalah dengan melihat masalah spesifik dan cara spesifik Anda menyelesaikannya dengan pemrograman meta. Kecuali jika Anda memposting kode di sini, kami tidak dapat mengetahui apakah Anda terlibat dalam komplikasi yang tidak perlu yang menyenangkan untuk Anda sendiri "memecahkan" masalah yang tidak ada; atau apakah Anda menggunakan kekuatan penuh bahasa untuk menulis solusi sederhana dan elegan yang tidak tersedia dengan cara lain.

Jika yang terakhir, saya akan mendorong Anda untuk terus melakukannya bersama dengan tim Anda.Setiap tim yang baik harus melakukan tinjauan kode yang bermakna yang membahas tidak hanya masalah gaya tetapi juga apakah solusi programer menggunakan pendekatan terbaik, menggunakan fitur bahasa yang sesuai, dapat dipelihara dan diuji, dll. Solusi pemrograman meta Anda harus mengisi satu sesi ulasan seperti itu, kemungkinan sebuah sepanjang sore. Programer yang menolak pendekatan Anda harus memberikan alternatif (seperti pembuatan kode dengan perl, duplikasi kode, dll.) Dan menunjukkan kinerjanya sesuai dengan kriteria yang disebutkan, dibandingkan dengan solusi Anda. Pekerjaan Anda, sebagai "lawan" ramah mereka dalam argumen, adalah menunjukkan bahwa itu adalah cara untuk menyelesaikan pekerjaan dengan cepat, pemeliharaannya mudah, pengujiannya mudah, dan kode itu sebenarnya dapat dibaca setelah Anda melewati rintangan dari mengurai tata bahasa lucu.

Sebagian besar programmer malas dan menikmati solusi kecil yang elegan. Jika milik Anda satu, kemungkinan Anda dapat meyakinkan mereka, terutama jika alternatif yang ditunjukkan gagal.

Tidak ada jawaban yang benar untuk pertanyaan ini.

Karena hal pertama yang harus Anda tanyakan pada diri sendiri adalah: dalam situasi apa Anda ditempatkan oleh pekerjaan Anda? Beberapa orang memang dipekerjakan sebagai kode monyet untuk spesifikasi kode, yang lain dipekerjakan sebagai pemain tim, yang lain dipekerjakan sebagai pekerja pengetahuan atau ahli.

Satu-satunya garis bawah yang konstan adalah bahwa Anda perlu melihatnya dari perspektif atasan Anda, karena pada dasarnya ini berarti menjadi seorang karyawan. Terkadang, demi kepentingan atasan Anda adalah yang terbaik untuk mendorong kolega Anda agar menjadi lebih baik dan menguasai teknik-teknik canggih. Namun dalam situasi yang berbeda, Anda mungkin hanya menciptakan banyak masalah dan kewajiban dan membahayakan keberhasilan proyek yang Anda ikuti.

Pertanyaannya sebenarnya bukan tentang apakah pemrograman meta itu OK atau tidak, tetapi lebih pada apakah tidak apa-apa untuk menjadi lebih baik daripada yang lain dalam tim, jadi inilah beberapa poin kontroversial tentang bagaimana saya melihatnya ...

Saya baru-baru ini pindah ke pekerjaan baru di mana saya bekerja di tim yang lebih besar dan [pemrograman-meta] ini membuat khawatir beberapa rekan saya, karena mereka tidak memahaminya.

Mereka khawatir Anda lebih baik dari mereka. Itu bagus. Anda akan menjadi ahli baru. Anda baru saja menghancurkan dunia status-quo mereka.

Saya selalu berusaha memanfaatkan potensi penuh dari bahasa tersebut, tetapi beberapa (tidak semua) kolega saya menganggap itu sebagai risiko (beberapa menyambut pendekatan).

Tentu, tidak ada yang suka menjadi kurang terampil daripada orang lain, jadi mereka mencoba menghentikan Anda dari menggunakan teknik yang terlalu rumit untuk mereka. Mereka tidak dapat memahaminya atau tidak akan pergi, karena mereka merasa aman sekarang.

Saya setuju itu adalah masalah untuk menulis kode yang tidak bisa dipahami oleh orang lain di tim.

Bukan saya. Saya pikir itu menunjukkan keahlian Anda.

Pertanyaan saya adalah, siapa yang benar, apa yang harus saya lakukan?

Anda harus menggunakan semua keahlian Anda untuk menulis kode terbaik yang dapat Anda tulis dan tidak melihat ke belakang pada mereka yang tidak memahaminya. Kalau tidak, Anda akan terjebak pada level mereka dan menjadi pembuat kode biasa. Adalah hal yang baik untuk menjadi lebih baik daripada yang lain, dan itu adalah hal yang baik untuk berusaha menjadi lebih baik dari mereka. Anda tidak akan pernah mendapatkan pengalaman baru jika Anda tidak mencoba menggunakan sesuatu yang baru atau melakukan sesuatu secara berbeda.

Saya tahu saya akan diturunkan suara, tetapi seperti ini kelihatannya. Bukan kejahatan untuk menjadi lebih baik daripada yang lain di tim, dan bukan kejahatan untuk menggunakan keterampilan Anda. Hanya saja semua orang takut mengakuinya ... karena mereka berada di pihak non-terampil dan benci kalau lelaki baru itu tiba-tiba bisa melakukan sesuatu yang tidak bisa mereka lakukan. Jika mereka pintar, mereka akan meminta bantuan dan saran Anda dan tidak mengkritik kode Anda karena tidak dapat dimengerti.

SUNTING

Tampaknya ada banyak kebingungan tentang pertanyaan ini. Seperti komentar menunjukkan banyak orang berpikir ini tentang keterbacaan kode umum. Tidak, tidak. Ini tentang apakah fitur / konstruksi bahasa tertentu harus dilarang atau dihindari karena beberapa anggota tim tidak memahaminya.

Jawaban saya adalah tidak . Mereka seharusnya tidak dilarang. Jika Anda ingin melarang sesuatu, bagaimana Anda melakukannya? Anda harus menyiapkan semacam kuesioner untuk mencari tahu apa yang dapat dan tidak bisa dilakukan oleh anggota tim Anda - atau lebih tepatnya tidak ingin belajar karena saya pikir semua fitur bahasa berguna di suatu tempat sehingga mengenal mereka dan bisa menggunakannya selalu bagus dan semakin Anda tahu kode yang lebih baik Anda bisa menulis. Anda juga perlu skala untuk menentukan fitur mana yang pemula, menengah atau lanjutan.

Untuk menunjukkan betapa konyolnya pembatasan semacam itu, mari kita ambil contoh yang sangat sederhana: Anda akan dipekerjakan sebagai insinyur perangkat lunak, tetapi bos masa depan Anda memberi tahu Anda bahwa Anda tidak akan diizinkan untuk menggunakan do/whileloop karena ada beberapa orang di tim yang belum pernah menggunakan mereka sebelumnya dan juga tidak akan pergi karena mereka selalu menggunakan forloop untuk semuanya sehingga mereka menemukan do/whileloop membingungkan.

Sekarang Anda pikir ini bodoh dan gila, bukan? Tapi begitu juga melarang fitur lainnya. Sebagian orang dapat menggunakannya dan yang lain tidak ingin mempelajarinya.

Mengapa Anda harus menghasilkan kode yang lebih buruk jika Anda tahu ada sesuatu yang memungkinkan Anda melakukan hal yang sama dengan upaya yang jauh lebih sedikit namun menghasilkan kode yang lebih mudah dibaca adalah kode yang kuat?

Dan tidak masalah apakah Anda hanya menggunakan fitur bahasa dasar atau yang canggih, Anda dapat menggunakan salah satu untuk menghasilkan kode yang sama-sama tidak dapat dipahami dan tidak dapat dipertahankan sehingga ini adalah topik yang sepenuhnya berbeda.