Dari seorang penerjemah: hari ini kami
menerbitkan sebuah artikel untuk Anda oleh penguji gamedev yang berpengalaman, Richard Taylor. Artikel ini akan berguna untuk pemula dan pengembang berpengalaman - pasti ada sesuatu untuk didiskusikan di sini.
Saya telah membuat banyak game. Biasanya tahap akhir perkembangannya sangat menyakitkan. Lagipula, pada akhirnya kita menemukan bug, dan hanya setelah itu kita benar-benar dapat membawa gloss ke produk. Situasi memburuk ketika pengembang memiliki waktu minimum untuk menyelesaikan proyek. Anda harus bekerja dengan cepat, dan bug dalam hal ini sering menjadi tamu. Bagaimana saya bisa menghadapinya? Ini sangat sederhana: untuk membuat lebih sedikit kesalahan, itu saja (ini adalah ironi penulis - catatan oleh penerjemah).
Skillbox merekomendasikan: Kursus praktis dua tahun "Saya seorang Pengembang Web PRO . "
Kami mengingatkan Anda: untuk semua pembaca "Habr" - diskon 10.000 rubel saat mendaftar untuk kursus Skillbox apa pun menggunakan kode promo "Habr".
Kurangi jumlah bug
Karena semua bug ada dalam kode, apakah mungkin cukup meminta tim pengembang untuk membuat lebih sedikit kesalahan?
Jika Anda lucu di tempat ini, saya tidak akan terkejut. Dan sungguh, karena tidak ada yang (baik, atau hampir tidak ada) yang melakukannya atas kehendak sendiri. Jadi, apa yang bisa Anda tawarkan kepada tim untuk membuat lebih sedikit kesalahan dalam kode sehingga tidak ada bug di dalamnya?
Kami memulai proyek baru. Langkah Satu - Jangan Ulangi Kesalahan Sebelumnya
Tim kami telah mengerjakan beberapa proyek AAA. Sebelum memulai salah satu dari mereka, kami memutuskan untuk bertukar pikiran tentang topik "Cara membuat jumlah kesalahan minimum." Tidak satu pun dari kami yang ingin menghabiskan beberapa bulan terakhir mengerjakan proyek mencari bug dan menghapus kode. Salah satu tugas utama adalah pembagian tanggung jawab dan tanggung jawab. Setiap jenis pekerjaan ditugaskan senior.
Langkah pertama adalah memutuskan mengapa semua ini perlu. "Mengapa" tingkat atas dijelaskan secara sederhana: kami ingin mengurangi jumlah waktu yang diperlukan untuk menghilangkan bug, mengoptimalkan biaya, dan meningkatkan kualitas keseluruhan proyek.
Ini adalah tentang meluangkan waktu untuk melakukan tugas-tugas menarik, tugas-tugas yang memungkinkan Anda untuk bangun dengan gembira di pagi hari dan segera melaksanakan tugas tersebut. Inilah yang membuat kami semua pengembang - kesempatan untuk menggunakan waktu kami untuk hal-hal yang sangat keren!
Ngomong-ngomong, bahkan jika ada tugas yang jelas untuk membuat bug lebih sedikit, itu sangat umum sehingga bisa menjadi tidak berarti. Ini adalah pernyataan niat yang perlu diklarifikasi dan dipecah menjadi serangkaian tugas yang jelas ditujukan kepada anggota tim individu.
Ketika menjawab pertanyaan tentang bagaimana melakukan ini, perlu untuk mengikuti dasar-dasar metode ilmiah: observasi, hipotesis, tes, pengulangan.
Pengamatan
KategorisasiBuka basis data bug proyek terbaru Anda dan lihatlah. Ada banyak jenis bug, jadi katakan saja: lebih sedikit kesalahan tidak berguna.
Untuk lebih memahami masalah ini, Anda perlu menentukan spesifiknya. Pertama-tama, perlu untuk mengurangi jumlah masalah tersebut, deteksi dan solusi yang membutuhkan terobosan waktu.
AnalisisSetelah menyusun daftar bug yang paling memakan waktu, langkah selanjutnya adalah upaya menemukan kesamaan dalam kesalahan ini, serta memahami alasan kemunculannya. Analisis dan interpretasikan!
Penyebab masalahPada akhirnya, kami membuat sejumlah templat untuk mencari bug tertentu, yang memungkinkan untuk memahami mengapa pencarian dan penghapusannya memakan banyak waktu. Setelah itu, kami siap untuk pergi ke kode sumber untuk menemukan akar penyebab masalah.
Bekerja dengan spesialis teknis, kami menemukan lebih banyak perubahan perbaikan. Lalu kami menyusun daftar baru sistem, file, dan baris kode yang terkait dengan bug utama. Pada akhirnya, kami membuat daftar perubahan kode yang diperlukan yang dapat didiskusikan dengan tim pengembangan.
Kami sudah bilang begitu!Kemudian kami mengadakan pertemuan dengan para programmer untuk membahas temuan kami. Ternyata, orang-orang tahu tentang sebagian besar area masalah dalam kode. Tetapi jika demikian, apa gunanya mengadakan pertemuan?
Jawaban: kami berhasil menggambar paralel antara tempat-tempat tertentu dalam kode dan kehilangan waktu yang terkait dengan masalah ini. Dan ini, pada gilirannya, memungkinkan untuk mengevaluasi secara objektif setiap proposal untuk pemeliharaan kode.
Dengan demikian, kami meninjau bagian dari kode yang bisa disebut buruk. Ketika kami mengevaluasinya dengan praktik terbaik kami, ternyata kami perlu refactoring. Pada saat yang sama, tim teknik sebelumnya meninggalkannya karena "ada terlalu banyak pekerjaan" atau "itu tidak mungkin".
Faktanya, banyak masalah yang sistemik. Banyak aspek "tak terlihat" menyebabkan serangkaian peristiwa yang menyebabkan munculnya kesalahan. Omong-omong, penyebab masalahnya begitu sistemik sehingga proyek harus dimulai dari awal.
Sebagai hasilnya, kami telah mengumpulkan hasil observasi empiris dan analisis yang cukup untuk membentuk hipotesis. Seluruh tim mengambil bagian dalam proses ini.
Hipotesis
Hipotesis 1. Pola pengkodean spesifik cenderung mengarah pada munculnya bug dalam proyek perangkat lunak besar.
Hipotesis 2. Waktu yang diperlukan untuk memperbaiki kesalahan dalam suatu proyek dapat dikurangi dengan menghindari pola perilaku yang didefinisikan dalam hipotesis pertama.
Mari kita putuskan apa proyek besar itu. Ini adalah sekitar 25 programmer, 12 bulan pengembangan. Pernyataan berikut ini berlaku untuknya:
A. Kode apa pun akan hidup cukup lama, sehingga biaya pemeliharaan pada akhirnya akan melebihi biaya pengembangan itu sendiri.
B. Kompleksitas menghubungkan sistem proyek individu lebih tinggi daripada kompleksitas sistem tertentu.
Mengapa ini sangat penting? Dalam proyek-proyek kecil, Anda dapat mengatasi hampir semua hal, di sini struktur program tidak begitu penting. Kode ini siap membantu Anda.
Jika proyek besar, maka semuanya berubah. Anda dapat bekerja dengan kode yang tujuannya tidak Anda mengerti, Anda bahkan mungkin tidak tahu bagian mana dari proyek yang dimiliki situs tertentu.
Setelah diskusi kami, kami mendapat pernyataan hasil ini: “Data menunjukkan bahwa pola pemrograman spesifik ini adalah faktor umum yang terkait dengan berbagai bug / masalah. Kami percaya bahwa dengan menghindari pola-pola ini, kami dapat mengurangi waktu yang diperlukan untuk memperbaiki kesalahan dan pada saat yang sama meningkatkan kualitas. "
Sekarang kita mulai implementasi praktis.
Pengujian
Saat membuat proyek baru, Anda harus menghindari pola bug yang diidentifikasi. Kami memilikinya:
- Kelebihan operator dan penamaan yang buruk.
- Otomatis, fitur polimorfik, dan pengabaian jenis keamanan.
- Meningkatkan kompleksitas kode dengan, misalnya, menyuntikkan dependensi dan panggilan balik.
- Menggunakan mutex, semaphores, dan sejenisnya dalam kode tingkat tinggi.
Apa selanjutnya
Dan kemudian kami mendapat kesempatan untuk memulai proyek baru, pengembangan game baru. Kami mampu membuat mesin permainan dari awal dan menyelesaikan semuanya tepat waktu, dengan tim programmer yang relatif kecil. Ada beberapa bug, tetapi kodenya ternyata bagus. Pada saat yang sama, butuh sedikit waktu untuk melayaninya.
Semua ini menjadi mungkin karena kami tidak menggunakan pola yang bermasalah, seolah-olah mereka tidak ada lagi. Kami bahkan mendapat mantra "Persulit penampilan kesalahan."
Seluruh tim senang dengan hasil seperti itu, menjadi lebih menarik untuk bekerja, karena sekali lagi menjadi mungkin untuk menghabiskan waktu pada apa yang Anda suka.
Skillbox merekomendasikan: