Pikiran tentang C ++ dan pengembangan game modern

Tahun baru bagi pengembang game dimulai dengan gelombang kritik yang jatuh pada komite standardisasi C ++ setelah publikasi Pengaduan Aras Prankevichus tentang Modern C ++ . Sebuah pertanyaan serius muncul: apakah komite standar benar-benar kehilangan kontak dengan kenyataan, atau sebaliknya, dan apakah para pengembang game telah memisahkan diri dari komunitas C ++ lainnya?

Kami menawarkan kepada Anda terjemahan dari pos populer Ben Dean, seorang veteran industri game , yang bekerja lama di Blizzard, Electronic Arts, dan Bullfrog sebagai pengembang dan pemimpin tim C ++, di mana ia menanggapi kritik dari sudut pandang pengalamannya sendiri.

TL; DR: Komite Standardisasi C ++ tidak memiliki tujuan tersembunyi untuk mengabaikan kebutuhan pengembang game, dan C ++ "modern" tidak akan menjadi bahasa yang "tidak jelas".

Sepanjang minggu lalu , telah ada diskusi aktif di Twitter , di mana banyak programmer - terutama mereka yang bekerja di bidang pengembangan game - berbicara bahwa vektor pengembangan saat ini "C ++ modern" tidak memenuhi kebutuhan mereka . Secara khusus, dari sudut pandang pengembang game biasa, semuanya tampak seolah-olah kinerja debug dalam bahasa diabaikan, dan optimasi kode menjadi diharapkan dan diperlukan.

Karena fakta bahwa saya berhasil bekerja di industri game selama lebih dari 23 tahun pada tahun 2019, saya memiliki pendapat sendiri berdasarkan pengamatan pada topik ini sehubungan dengan pengembangan game, yang ingin saya bagikan. Apakah debugging penting untuk pengembang game, dan mengapa? Apa masalah yang terkait dengannya?

Sebagai permulaan - sedikit penyimpangan ke dalam sejarah.

Banyak pengembang game C ++ bekerja di Microsoft Visual C ++. Secara historis, pasar besar untuk game telah terbentuk di sekitar platform Microsoft, dan ini telah memengaruhi pengalaman khas seorang programmer game biasa. Pada tahun 90-an dan 2000-an, sebagian besar game ditulis dengan keadaan ini dalam pikiran. Bahkan dengan munculnya konsol dari produsen lain dan semakin populernya game mobile, properti banyak studio AAA dan banyak programmer game saat ini adalah alat yang dibuat oleh Microsoft.

Visual Studio bisa dibilang adalah debugger terbaik untuk C ++ di dunia. Selain itu, Visual Studio benar-benar menonjol dalam hal debugging program - lebih dari dengan front-end, back-end, implementasi STL, atau yang lainnya. Dalam lima tahun terakhir, Microsoft telah membuat langkah signifikan dalam mengembangkan alat pengembangan C ++, tetapi bahkan sebelum itu, debugger di Visual Studio selalu sangat keren. Jadi, ketika Anda mengembangkan pada PC Windows, Anda selalu memiliki debugger kelas dunia.

Mengingat hal di atas, mari kita lihat proses mendapatkan kode di mana tidak akan ada bug; peluang yang kami miliki dari sudut pandang seorang programmer yang tidak berurusan dengan game; serta keterbatasan yang dihadapi oleh pengembang game. Jika Anda mengulangi argumen utama yang mendukung "vektor pengembangan C ++ modern", maka itu akan dikurangi menjadi jenis, alat, dan tes. Mengikuti pemikiran ini, debugger harus menjadi garis pertahanan terakhir . Sebelum kita mencapainya, kita memiliki opsi berikut.

Peluang No. 1: Jenis

Kita dapat menggunakan pengetikan sekuat yang diperlukan untuk menghilangkan seluruh kelas bug pada waktu kompilasi. Pengetikan yang kuat adalah, tanpa keraguan, peluang yang diberikan evolusi C ++ baru-baru ini kepada kami; misalnya, dimulai dengan C ++ 11, kami berhasil mendapatkan:

• perluasan signifikan dari type traits - type traits ;
• inovasi seperti nullptr dan scoped enum untuk memerangi warisan C - pengetikan yang lemah;
• GSL dan alat bantu;
• konsep dalam C ++ 20.

Beberapa dari Anda mungkin tidak menyukai metaprogramming template; yang lain mungkin tidak menyukai gaya pengkodean yang menggunakan auto hampir secara universal. Terlepas dari preferensi ini, motif utama untuk menggunakan gaya yang tercantum dalam C ++ jelas ditelusuri di sini - ini adalah keinginan untuk membantu kompiler sehingga, pada gilirannya, dapat membantu kami, menggunakan pada saat yang sama apa yang paling dikenal: sistem tipe.

Jika kita berbicara tentang pemrograman game, pengetikan yang kuat di sini adalah bidang yang luas untuk penelitian, dan itu secara aktif digunakan oleh programmer game yang akrab dengan saya, yang tertarik untuk meningkatkan keterampilan aplikasi C ++ mereka dalam praktik. Dua hal penting yang menjadi perhatian di sini: efek pada waktu kompilasi, dan efek pada keterbacaan kode.

Terus terang, Anda dapat dengan mudah mengabaikan waktu kompilasi - tetapi hanya dengan syarat bahwa Anda adalah seorang programmer di perusahaan yang sangat besar yang tidak bermain game dan memiliki infrastruktur internal yang mapan dan daya komputasi yang tak terbatas untuk menyusun kode apa pun yang dapat Anda tulis . Perusahaan-perusahaan besar seperti itu khawatir tentang biaya kompilasi - oleh karena itu mereka menggunakan modul - tetapi, sebagai suatu peraturan, ini tidak menimbulkan kesulitan bagi pengembang individu. Pada saat yang sama, bagi sebagian besar programmer game, ini bukan masalahnya. Pengembang indie tidak memiliki peternakan untuk dibangun; Pengembang game AAA sering menggunakan sesuatu seperti Incredibuild , tetapi mengingat fakta bahwa mereka dapat dengan mudah bekerja dengan basis kode yang berumur 10 tahun atau lebih, proses pembuatannya masih bisa memakan waktu 15-20 menit.

Kita dapat berdebat tentang biaya relatif untuk menambahkan perangkat keras versus biaya waktu programmer, dan saya setuju dengan pandangan bahwa perangkat keras lebih murah, namun:

• Perangkat keras adalah biaya satu kali nyata yang akan dialokasikan ke anggaran kuartal saat ini, sebagai lawan dari pengeluaran yang tidak begitu nyata dalam waktu / perekrutan / dan sejenisnya, yang akan didistribusikan dalam periode waktu yang lebih lama. Orang tidak dapat mengatasi dengan baik keputusan yang mendukung kompromi semacam itu, dan perusahaan secara khusus dibangun sedemikian rupa untuk mengoptimalkan laba jangka pendek.
• Infrastruktur membutuhkan dukungan, dan hampir tidak ada yang masuk ke industri game untuk menjadi seorang insinyur rilis. Dibandingkan dengan area lain di mana C ++ digunakan, gaji pengembang game tidak begitu tinggi - dan insinyur non-game dibayar lebih rendah di sini.

Orang juga dapat berspekulasi pada fakta bahwa waktu kompilasi seharusnya tidak pernah mencapai keadaan seperti itu; dan sekali lagi saya setuju dengan Anda. Harga ini adalah kewaspadaan konstan - sekali lagi, datang dari seorang insinyur rilis - dan, idealnya, beberapa alat otomatis yang memungkinkan Anda untuk melacak perubahan pada waktu yang dibutuhkan untuk membangun build. Untungnya, dengan munculnya sistem CI, tujuan ini dapat dicapai jauh lebih mudah hari ini.

Peluang No. 2: Alat

Kita harus menggunakan alat yang maksimum yang tersedia untuk kita - peringatan, analisis statis, pembersih, alat analisis dinamis, profiler dan lainnya.

Pengalaman saya adalah bahwa pengembang game menggunakan alat ini sedapat mungkin, tetapi di sini industri secara keseluruhan memiliki beberapa masalah:

• Alat-alat ini cenderung bekerja lebih baik pada platform non-Microsoft - dan, seperti yang disebutkan sebelumnya, ini bukan skenario pengembangan game yang khas.
• Sebagian besar alat ini ditujukan untuk bekerja dengan "standar" C ++. Mereka di luar kotak mendukung std::vector , tetapi bukan CStaticVector saya tulis CStaticVector dari mesin hipotetis. Tentu saja, menyalahkan alat tidak ada gunanya, tetapi ini masih menjadi salah satu hambatan dalam penggunaannya yang harus diatasi oleh pengembang.
• Membuat dan memelihara rantai CI yang akan menjalankan semua alat ini membutuhkan kehadiran insinyur rilis - dan, seperti yang disebutkan sebelumnya, merekrut orang untuk pekerjaan teknik yang tidak terkait langsung dengan game adalah masalah sistemik untuk industri game.

Jadi, karena alat ini bekerja sangat baik dengan standar C ++, mengapa para pengembang game tidak menggunakan STL?

Di mana harus memulai jawaban untuk pertanyaan ini? Mungkin, dari perjalanan selanjutnya ke sejarah pengembangan game:

• Sampai awal 90-an, kami tidak percaya pada kompiler C, jadi kami menulis game dalam assembler.
• Dari awal hingga pertengahan 90-an, kami mulai memercayai kompiler C, tapi kami masih tidak percaya pada kompiler C ++. Kode kami adalah C, yang menggunakan komentar gaya C ++, dan kami tidak perlu lagi menulis typedef untuk struktur kami sepanjang waktu.
• Sekitar tahun 2000, revolusi C ++ terjadi di dunia pengembangan game. Itu adalah era pola desain dan hierarki kelas besar . Pada saat itu, dukungan STL pada konsol meninggalkan banyak yang harus diinginkan, dan konsol memerintah dunia saat itu. Di PS2, kita selamanya terjebak dengan GCC 2.95.
• Sekitar 2010, dua revolusi lagi diluncurkan. Rasa sakit menggunakan hierarki kelas besar merangsang pengembangan pendekatan komponen untuk kode. Perubahan ini melanjutkan evolusinya hari ini dalam bentuk arsitektur Entity-Component-System. Bersamaan dengan ini adalah revolusi kedua - upaya untuk mengambil keuntungan dari arsitektur multiprosesor.

Selama perubahan paradigma ini, platform pengembangan game sendiri terus berubah, dan mereka berubah dengan serius. Memori tersegmentasi telah memberikan ruang alamat datar. Platform telah menjadi multiprosesor, simetris dan tidak terlalu. Pengembang game, yang terbiasa bekerja dengan arsitektur Intel, harus membiasakan diri dengan MIPS (Playstation), kemudian ke perangkat keras khusus dengan CPU heterogen (PS2), kemudian ke PowerPC (XBox 360), lalu ke heterogenitas yang lebih besar (PS3) ... Masing-masing Platform baru ini hadir dengan fitur kinerja baru untuk prosesor, memori, dan drive. Jika Anda ingin mencapai kinerja optimal, maka Anda terpaksa menulis ulang kode lama Anda, dan banyak dan sering. Saya bahkan tidak akan menyebutkan seberapa besar game dipengaruhi oleh kemunculan dan pertumbuhan popularitas Internet, serta pembatasan yang dipaksakan oleh pemegang platform pada pengembang.

Secara historis, implementasi STL pada platform game tidak memuaskan. Bukan rahasia bahwa wadah STL tidak cocok untuk permainan. Jika Anda mendorong pengembang game ke dinding, maka mungkin dia mengakui bahwa std::string cukup OK, dan std::vector adalah opsi default yang masuk akal. Tetapi semua kontainer yang terkandung dalam STL memiliki masalah kontrol alokasi dan inisialisasi. Dalam banyak permainan, Anda harus khawatir tentang keterbatasan memori untuk berbagai tugas - dan untuk objek-objek yang kemungkinan besar harus Anda alokasikan memori secara dinamis selama permainan, pengalokasi slab atau arena sering digunakan. Waktu konstan diamortisasi bukan hasil yang baik, karena alokasi berpotensi salah satu hal paling mahal yang dapat terjadi selama pelaksanaan program, dan saya tidak ingin melewatkan bingkai hanya karena terjadi ketika saya tidak mengharapkannya . Sebagai pengembang game, saya harus mengelola persyaratan memori saya terlebih dahulu.

Kisah serupa diperoleh untuk dependensi lain secara umum. Pengembang game ingin tahu apa yang dibutuhkan setiap siklus prosesor, di mana dan kapan dan untuk apa setiap byte memori bertanggung jawab, dan juga di mana dan kapan setiap thread eksekusi dikontrol. Sampai baru-baru ini, kompiler Microsoft mengubah ABI dengan setiap pembaruan - jadi jika Anda memiliki banyak dependensi, membangun kembali semuanya bisa menjadi proses yang menyakitkan. Pengembang game biasanya lebih suka dependensi kecil yang mudah diintegrasikan, melakukan satu hal dan melakukannya dengan baik - lebih disukai dengan API gaya-C - dan digunakan oleh banyak perusahaan, tersedia untuk umum atau memiliki lisensi gratis yang tidak membutuhkan indikasi dari penulis. SQLite dan zlib adalah contoh yang baik dari apa yang lebih suka digunakan pengembang game.

Selain itu, industri game C ++ memiliki sejarah pasien yang kaya dengan sindrom “Not invented here”. Ini harus diharapkan dari industri, yang dimulai dengan penggemar tunggal yang membuat barang-barang mereka sendiri dengan peralatan yang sama sekali baru dan tidak memiliki pilihan lain. Industri game, antara lain, adalah satu-satunya di mana programmer ditunjukkan dalam kredit tanpa urutan tertentu. Menulis berbagai hal itu menyenangkan, dan itu membantu karier Anda! Jauh lebih baik untuk membangun sesuatu milik Anda daripada membeli yang sudah jadi! Dan karena kami sangat khawatir dengan kinerja, kami dapat mengadaptasi solusi kami sedemikian rupa sehingga sangat cocok untuk proyek kami - alih-alih mengambil solusi umum yang tanpa daya memboroskan sumber daya yang tersedia. Permusuhan terhadap Boost adalah contoh utama bagaimana pemikiran seperti itu memanifestasikan dirinya dalam pengembangan game. Saya mengerjakan proyek yang berjalan seperti berikut:

• Untuk memulainya, untuk menyelesaikan masalah tertentu, kami menghubungkan perpustakaan dari Boost ke proyek.
• Semuanya bekerja dengan sangat baik. Ketika Anda perlu memperbarui, sedikit rasa sakit terjadi, tetapi tidak lebih dari ketika memperbarui ketergantungan lainnya.
• Gim lain ingin menggunakan kode kami, tetapi halangannya adalah kami menggunakan Boost - meskipun pengalaman kami dengan Boost sudah cukup baik.
• Kami menghapus kode menggunakan Boost, tetapi sekarang kami dihadapkan dengan masalah baru: kita harus menyelesaikan masalah yang dipecahkan oleh perpustakaan dari Boost alih-alih dari yang sebelumnya.
• Kami pada dasarnya menyalin bagian dari kode Peningkatan yang kami butuhkan ke dalam ruang nama kami sendiri.
• Kemudian, kami mau tak mau dan dari waktu ke waktu menemukan fakta bahwa kami membutuhkan fungsionalitas tambahan yang sudah ada dalam kode asli jika kami tidak membuangnya. Tetapi sekarang kita adalah pemilik kode ini, jadi kita harus terus mendukungnya.

Kami tidak menyukai sesuatu yang besar yang mencoba melakukan terlalu banyak hal pada saat yang sama atau yang dapat memengaruhi waktu kompilasi - dan ini cukup masuk akal. Apa yang orang membuat kesalahan berulang-ulang adalah bahwa mereka menentang untuk menerima rasa sakit yang seharusnya hari ini - sementara karena keputusan ini mereka akan menghadapi rasa sakit yang sangat nyata dan jauh lebih besar dengan dukungan dari sesuatu dengan mengorbankan seseorang- anggaran yang harus mereka alami selama tiga tahun ke depan. Sayangnya, hadirnya bukti dalam bentuk game yang berhasil menggunakan piringan dari STL dan Boost, sama sekali tidak bisa memengaruhi psikologi manusia dan meyakinkan pengembang game.

Untuk semua alasan ini, banyak perusahaan game telah menciptakan perpustakaan mereka sendiri yang mencakup apa yang dilakukan STL - dan bahkan lebih banyak lagi - sambil mendukung kasus penggunaan khusus game. Beberapa perusahaan game besar bahkan dapat menguasai pengembangan pengganti STL mereka sendiri yang lengkap dan hampir sepenuhnya kompatibel dengan API, yang selanjutnya memerlukan biaya besar untuk mendukung proyek ini.

Adalah bijaksana untuk menemukan alternatif yang ditingkatkan untuk std::map , atau menerapkan optimasi buffer kecil di std::vector . Adalah jauh lebih tidak dapat diterima untuk ditakdirkan untuk mendukung implementasi algorithms atau type traits Anda sendiri, yang akan sedikit bermanfaat. Bagi saya, sangat disesalkan bahwa bagi kebanyakan pengembang, STL hanyalah wadah. Karena ketika mempelajari STL di awal, mereka diajarkan hal itu, berbicara tentang STL, paling menyiratkan std::vector - walaupun sebenarnya mereka harus memikirkan std::find_if .

Peluang No. 3: Tes

Dikatakan bahwa pengujian ekstensif harus dilakukan, TDD dan / atau BDD harus mencakup semua kode yang dapat dicakup, dan bug harus diatasi dengan menulis tes baru.

Karena itu, mari kita bahas topik pengujian.

Menilai dari pengalaman saya, pengujian otomatis praktis tidak digunakan di industri game. Mengapa

1. Karena kebenaran tidak begitu penting, tetapi tidak ada spesifikasi nyata

Sebagai seorang programmer muda di industri game, saya dengan cepat menyingkirkan ide bahwa saya harus berusaha untuk mensimulasikan sesuatu secara realistis. Game adalah asap dan cermin dan mencari jalur pendek. Tidak ada yang peduli seberapa realistis simulasi Anda; yang utama adalah menyenangkan. Ketika Anda tidak memiliki spesifikasi selain "permainan seharusnya terasa benar", subjek pengujian tidak ada. Berkat bug, gameplaynya bahkan bisa lebih baik. Cukup sering, bug masuk ke rilis, dan bahkan memenangkan cinta pengguna ( ingat Gandhi yang sama dari Peradaban ). Game berbeda dari area lain yang menggunakan C ++; di sini kurangnya kebenaran tidak mengarah pada fakta bahwa seseorang pada akhirnya kehilangan tabungannya.

2. Karena sulit

Tentu saja, Anda ingin membuat tes otomatis di mana pun Anda bisa. Ini dapat dilakukan untuk beberapa subsistem yang hasil akhirnya dinyatakan dengan jelas. Pengujian unit dalam industri game, tentu saja, ada, tetapi sebagai aturan itu terbatas pada kode tingkat rendah - analog STL yang disebutkan sebelumnya, prosedur konversi string, metode mesin fisik, dll. Kasus-kasus di mana bagian yang dapat dieksekusi dari kode memiliki hasil yang dapat diprediksi biasanya diuji oleh unit test, meskipun TDD tidak digunakan di sini - karena pemrogram game lebih memilih untuk menyederhanakan hidup mereka, dan bukan sebaliknya. Tetapi bagaimana Anda menguji kode gameplay (lihat poin satu)? Segera setelah Anda melampaui pengujian unit, Anda segera menemukan alasan lain mengapa pengujian game sangat sulit.

3. Karena kontennya terlibat

Pengujian sistem non-sepele mungkin akan mencakup penyediaan konten yang akan diimplementasikan. Sebagian besar insinyur tidak pandai memproduksi konten ini sendiri, jadi untuk mendapatkan tes yang bermakna, Anda harus menarik seseorang dengan keterampilan yang tepat untuk membuat konten. Setelah itu Anda akan menghadapi masalah mengukur apa yang Anda dapatkan pada output - setelah semua, ini bukan lagi garis atau angka, tetapi gambar di layar atau suara yang berubah seiring waktu.

4. Karena kita tidak mempraktikkannya

Unit testing adalah fungsi yang saya tahu kemungkinan input dan output. Namun, gameplaynya adalah perilaku yang tidak dapat diprediksi, berkembang secara dinamis, dan saya tidak tahu bagaimana fenomena seperti itu dapat diuji dengan benar. Apa yang bisa saya uji - jika, tentu saja, saya mendapat izin dari manajer saya untuk mencurahkan cukup waktu untuk ini - ini, misalnya, kinerja, atau kemampuan tingkat tinggi seperti perjodohan, yang dapat saya analisis. Pekerjaan infrastruktur semacam itu mungkin menarik untuk beberapa programmer game, tetapi bagi sebagian besar itu sama sekali tidak menarik, dan di samping itu memerlukan persetujuan dan dukungan dari pemilik dompet. Sebagai seorang programmer game, saya tidak pernah memiliki kesempatan untuk berlatih menulis tes tingkat tinggi.

5. Karena [perusahaan] tidak melihat perlunya pengujian otomatis

Tujuan utama kami adalah merilis game. Kita hidup di era industri yang bergerak maju dengan hit yang membuat sebagian besar uang mereka di bulan pertama penjualan, ketika biaya pemasaran hit ini dimaksimalkan. Siklus hidup konsol mengajarkan kepada kita bahwa kode dalam kasus apa pun tidak akan hidup selama ini. Jika kami mengerjakan game online, kemungkinan besar kami akan mendapatkan waktu tambahan untuk menguji perjodohan atau memuat server. Karena untuk perilisan game, kami membutuhkan kinerjanya, kami setidaknya harus melakukan pengujian kinerja, tetapi kami tidak boleh mengotomatiskan proses ini. Untuk manajemen di industri game, pengujian otomatis tidak lebih dari buang-buang waktu dan uang. Untuk implementasinya, perlu untuk merekrut insinyur berpengalaman yang akan melakukan pekerjaan, yang hasilnya akan hampir tak terlihat. Waktu yang sama dapat dihabiskan untuk pengembangan fitur baru. Dalam jangka pendek, jauh lebih menguntungkan menggunakan staf QA untuk menguji permainan, yang membawa kita ke poin berikutnya.

6. Karena secara umum, pengujian dalam game diklasifikasikan sebagai aktivitas kelas dua

Saya suka profesional QA yang baik. Bagi saya mereka layak emas. Mereka tahu bagaimana membuat game Anda lebih baik dengan memecahkannya dengan cara yang tidak akan pernah terlintas di benak Anda. Mereka adalah pakar khusus dalam gameplay Anda di mana Anda tidak mengerti, dan hampir tidak pernah mengerti. Mereka lebih baik daripada tim kompiler berkemampuan super untuk membantu Anda melakukan segalanya dengan benar. Saya senang bahwa saya memiliki kesempatan untuk bekerja dengan beberapa spesialis QA selama bertahun-tahun pekerjaan saya.

Saya hampir selalu harus berjuang untuk memastikan bahwa mereka tetap berada di tim saya.

Dalam perusahaan AAA besar, organisasi QA biasanya merupakan departemen yang sepenuhnya terpisah dari tim pengembangan mana pun, dengan manajemen dan struktur organisasinya sendiri. Ini diduga dilakukan agar mereka bisa objektif selama ujian. Dalam praktiknya, semuanya jauh dari cantik.

Mereka diperlakukan seperti roda gigi dalam mekanisme besar, yang sering dilemparkan antara proyek tanpa peringatan dan umumnya diperlakukan seolah-olah ada yang bisa menangani pekerjaan mereka. Ketika proyek "bergerak" dari tanggal tenggat waktu, para insinyur dapat merasakan kegentingan pada kulit mereka sendiri, tetapi QA menjadi lebih kuat, karena mereka harus bekerja pada shift malam dan pada akhir pekan, ditambah mereka juga mendapatkan kenyataan bahwa mereka membawa berita suram tentang arus keadaan kualitas proyek.

Mereka dibayar sangat rendah. Penguji paling berpengalaman dengan keahlian bertahun-tahun di bidang subjek menerima kurang dari setengah dari apa yang mereka bayar untuk pengembang tingkat menengah. Saya harus bekerja dengan para insinyur QA paling cerdas yang membuat jalur pipa untuk pengujian kinerja dengan pelacakan dan peringatan, menciptakan kerangka kerja untuk pengujian API dan untuk pengujian tegangan, dan melakukan banyak tugas lain yang dianggap tidak layak saat "insinyur nyata". Saya yakin orang-orang terpintar ini akan mendapat lebih banyak jika mereka bekerja di perusahaan teknologi besar lainnya.

Mereka tidak dipercaya. Tidak jarang penguji tetap terpisah dari pengembang lain, dan lencana mereka memungkinkan mereka mengakses hanya lantai gedung tempat mereka bekerja sendiri - atau bahkan menggunakan pintu masuk yang terpisah.

Mereka dipaksa untuk taat. Penguji sering disuruh untuk tidak mengganggu insinyur lain. Ketika mereka perlu melaporkan bug secara langsung, mereka diminta untuk menghubungi para insinyur dengan hormat, seperti "Mrs. H." atau "Tuan Y.". Kadang-kadang saya mendapat telepon dari bos-bos departemen QA yang kesal - dalam kasus-kasus tersebut ketika saya menghubungi mereka yang menemukan bug untuk penyelidikan bersama.

Semua ini terdengar seperti kisah yang mengerikan, dan jangan semua orang harus berurusan dengan hal-hal seperti itu, sayangnya ini sering terjadi; begitu sering sehingga para insinyur mulai berpikir - mungkin di bawah tekanan yang terus-menerus, tetapi itu tidak memaafkan mereka - bahwa pekerjaan QA adalah mencari bug mereka sendiri, atau, lebih buruk lagi, mulai menyalahkan QA untuk bug.

Di tim terbaik yang harus saya tangani, kami bersikeras bahwa tim kami memiliki insinyur QA mereka sendiri yang akan bekerja bersama kami. Namun, mereka tidak kehilangan objektivitas atau keinginan mereka untuk mencapai hasil yang lebih baik. Mereka senang menerima bantuan dari programmer dalam menulis tes otomatis. Yang pasti saya tidak ragu adalah bahwa akan bermanfaat bagi industri game untuk melakukan otomasi lebih sering.

Kinerja Debug

Mengingat semua hal di atas - kebiasaan debugging, platform untuk API dan alat yang masih berkembang, dan kompleksitas (dikombinasikan dengan kurangnya budaya) pengujian otomatis - menjadi jelas mengapa pengembang game bersikeras pada kemampuan debugging.

Tetapi pada saat yang sama, masih ada masalah dengan debugging itu sendiri, dan masalah dengan bagaimana pengembang game mengatasi vektor pengembangan C ++ saat ini.

Masalah utama dengan debugging adalah bahwa itu tidak skala. Di antara pengembang game pengembang yang membaca posting ini, ada yang memutuskan bahwa fenomena yang saya jelaskan tidak sesuai dengan apa yang mereka amati dalam praktik mereka. Sangat mungkin, ini disebabkan oleh fakta bahwa cepat atau lambat mereka sendiri harus berurusan dengan masalah skalabilitas debugging, dan mereka menemukan jalan keluar.

Dengan kata lain, kami ingin memiliki debugging yang produktif, karena untuk menangkap bug, kami sering harus dapat menjalankan aplikasi dengan set data yang cukup besar dan representatif. Tetapi pada kenyataannya, ketika kita mencapai titik ini, debugger biasanya menjadi alat yang terlalu kasar untuk digunakan - terlepas dari apakah itu produktif atau tidak. Tentu saja, pengaturan breakpoints pada data ( data breakpoints) mungkin berguna untuk menangkap masalah berukuran sedang, tetapi bagaimana jika kita menemukan bug nyata - bug yang tersisa setelah kita memperbaiki semuanya? Dengan yang muncul di bawah beban jaringan, atau dalam kasus kekurangan memori, atau bekerja pada batas kemampuan multithreading, atau terjadi hanya untuk subset kecil yang tidak dikenal dengan latar belakang jutaan pemain lain, atau muncul hanya pada versi disk permainan, atau hanya dalam perakitan di Jerman, atau setelah tiga jam dihabiskan untuk pengujian stabilitas ( rendam pengujian )?

Ciri kedua, kita bisa mengandalkan debugger saja. Dalam hal ini, kami melakukan apa yang selalu kami lakukan. Kami mencoba untuk mengisolasi masalah, mewujudkannya lebih sering; kami menambahkan logging dan menyaring program kami melaluinya; kami menyesuaikan timer dan pengaturan aliran; kami menggunakan pencarian biner; kami mempelajari dump inti dan log kerusakan; kami mencoba mereproduksi masalah dengan memotong konten seminimal mungkin; kami merenungkan apa yang mungkin menjadi penyebab masalah dan mendiskusikannya.

Seringkali, sampai kita sampai pada penyebab sebenarnya dari kecelakaan itu, kita akan punya waktu untuk memperbaiki beberapa hal lainnya. Dengan kata lain, kami memecahkan masalah, dan pada akhirnya, menggunakan debugger hanya sebagian kecil dari proses ini. Jadi ya, kecepatan debug adalah tambahan yang bagus, tetapi kekurangannya tidak menghalangi kita untuk terus menjadi insinyur. Kami masih membutuhkan keterampilan kami yang lain, seperti kemampuan untuk mengurai dump inti dan membaca assembler yang dioptimalkan.

Saat menggunakan "C ++ modern", saya menggunakan debugger dengan cara yang sama seperti biasa. Saya membaca kode yang baru ditulis; Saya memberikan breakpoint pada data yang menarik minat saya; Saya menggunakan debugger untuk menjelajahi kode yang tidak dikenal. Dengan munculnya "C ++ modern", tidak ada yang berubah - dan ya, meskipun STL menggunakan _ Ugly _ Identifiers, ini tidak membuat STL ajaib. Terkadang berguna untuk melihat apa yang dilakukan STL "di bawah tenda", atau melangkahinya; atau, seperti yang sekarang dapat Anda lakukan, gunakan debugger untuk menyembunyikan kode perpustakaan dari saya .

Ketika saya mengalami masalah kinerja debugging, biasanya bukan "C ++ modern" memperlambat saya - faktanya adalah pada saat ini saya sudah mencoba melakukan terlalu banyak. Menggunakan debugger tidak menskala - tidak seperti jenis, alat, dan tes.

Saya sendiri prihatin dengan masalah bahwa kode C ++ memerlukan lebih banyak dan lebih banyak optimasi, dan saya tertarik pada pendapat pengembang kompiler tentang hal ini. Faktanya adalah tidak ada jawaban tunggal. Kami sudah berada di kontinum, dan kami memiliki kesempatan untuk bergerak lebih jauh ke arah ini tanpa merusak kemampuan untuk men-debug kode. Hari ini, kompiler kami melakukan copy elision untuk objek sementara., bahkan jika kami tidak meminta mereka untuk melakukan optimasi ini. Ini tidak memengaruhi kemampuan kami untuk men-debug aplikasi. Saya ragu bahwa kami akan mengeluh bahwa debugging build mulai menyertakan NRVO atau setengah lusin optimisasi lain yang dapat dibuat sedemikian rupa sehingga kami tidak akan melihatnya saat debugging. Tersangka yang C ++ bergerak tepatnya di ini arah.

Epilog: Cara Modern C ++

Jika Anda bekerja sebagai programmer di bidang pengembangan game dan Anda tidak suka kemana C ++ menuju, maka pada dasarnya Anda memiliki dua opsi untuk tindakan selanjutnya.

1. Jangan melakukan apa pun

Dengan asumsi bahwa Anda masih akan menulis kode C ++, Anda dapat terus menggunakan bahasa dengan cara yang sama seperti yang Anda lakukan sebelumnya. Tidak perlu mulai menggunakan fitur baru jika Anda tidak ingin melakukan ini. Hampir semua yang Anda gunakan sekarang akan terus didukung - dan dengan melakukannya, di tahun-tahun mendatang Anda akan terus memetik manfaat dari meningkatkan kompiler.

Ini adalah strategi perilaku yang benar-benar tepat untuk mereka yang bekerja untuk diri mereka sendiri atau dengan tim orang-orang yang berpikiran sama. C ++ 98, bersama dengan beberapa fitur yang lebih baru, masih cocok untuk menulis gim di dalamnya.

Namun, jika Anda bekerja di perusahaan besar, cepat atau lambat Anda harus menghadapi perubahan dalam bahasa, karena Anda harus meningkatkan tim dan mempekerjakan orang baru. Pada gilirannya, ketika Anda menyewa pengembang C ++, itu berarti merekrut pengembang dengan C + + "modern". Perubahan generasi akan terjadi - seperti yang telah terjadi pada assembler, C dan C ++ 98. Anda dapat mengelola proses jika Anda menetapkan batasan pada apa yang diizinkan dalam basis kode Anda dan apa yang tidak, tetapi solusi ini tidak akan menyelamatkan Anda dalam jangka panjang. Dan apa yang harus Anda lakukan dalam kasus ini?

2. Ambil bagian

Daripada hanya menggunakan satu GDC setahun sekali, mulailah mengunjungi CppCon , di mana Anda akan mendapatkan manfaat lebih banyak dari uang yang dihabiskan perusahaan Anda untuk membeli tiket. Berpartisipasi dalam diskusi standar; bergabung dengan grup dan berlangganan buletin; baca draf standar dan berikan umpan balik kepada penulis. Jika Anda juga dapat menghadiri pertemuan komite, itu akan baik-baik saja, tetapi meskipun tidak, Anda masih dapat melakukan banyak hal untuk menyampaikan sudut pandang Anda kepada orang lain.

Keanggotaan dalam Komite C ++ terbuka untuk semua. Semua informasi yang diperlukan bagi mereka yang ingin berpartisipasi dalam pekerjaan SG14, atau SG7, atau SG15 - atau kelompok kerja lain yang berkaitan dengan bidang minat Anda -dapat ditemukan di isocpp.org . Komite tidak memiliki rencana rahasia - pada kenyataannya, apakah Anda benar-benar berpikir bahwa lebih dari 200 programmer dapat menyetujui agenda bersama? Di sini, bahkan "bos" komite sering gagal "mendorong" ide-ide mereka.

Jika Anda ingin pendapat Anda didengar, maka Anda harus mulai berbicara di mana pendapat Anda dapat didengar, dan bukan di Twitter atau Reddit. Silakan ikuti saran ini - Saya menantikan diskusi kami.