Bagaimana Anda mengatasi secara mental satu pekerjaan yang sangat panjang [ditutup]


8

Ini adalah pekerjaan industri game pertama saya dan tugas saya adalah mengambil satu komponen game utama dan memasukkan yang lebih baru.

Sejauh ini sudah 5 minggu, dan saya masih menatap kesalahan. Saya pikir itu bisa berbulan-bulan sebelum itu pada titik yang dapat dikompilasi. Ini benar-benar membuat saya sedih. Saya hanya mengubah segalanya, saya tidak benar-benar menulis sendiri. tidak ada habisnya. Saya memperbaiki seribu kesalahan dan sembilan ribu menggantikan mereka.

Saya yakin ini pasti hal yang biasa, jadi saya hanya ingin tahu, bagaimana Anda mengatasinya? Sepertinya saya tidak bisa memecahnya menjadi potongan-potongan kecil sama sekali.


3
Eeek. Siapa yang akan menulis kode buruk sehingga butuh waktu berbulan-bulan hanya untuk mengkompilasi !? Anda mungkin ingin memikirkan kembali bagaimana Anda akan melakukan itu ... Setelah dikompilasi, itu akan penuh dengan kesalahan logis.
MichaelHouse

7
Pertanyaan ini mungkin lebih cocok di programmers.stackexchange.com (jika ada).
George Duckett

3
@GeorgeDuckett Jawaban khusus industri permainan dapat diberikan untuk pertanyaan ini yang berhubungan dengan masalah yang hanya akan Anda temui pemrograman dalam industri ini. Dikutip kata demi kata, bagian dari FAQ yang memutuskan apakah pertanyaan kode ada di sini atau di SO juga menawarkan kebijaksanaan di sini: Apakah pengembang game profesional memberi saya jawaban yang lebih baik / berbeda / lebih spesifik untuk pertanyaan ini daripada programmer lain? Jika ya, silakan bertanya di sini.
doppelgreener

5
Saya juga memilih ini sebagai pertanyaan pemrograman umum. Dia refactoring kekacauan kode besar, yang kebetulan merupakan permainan. Dia membutuhkan saran pemrograman / refactoring umum, bukan saran pengembangan game.
Tim Holt

1
Tidak bisakah pos ini dan jawabannya dimigrasikan daripada hanya ditutup?
SirYakalot

Jawaban:


21

Selamat datang di industri game :)

Jadi, Anda melakukan refactoring besar-besaran. Refactoring besar-besaran adalah Jahat, tapi bukan itu topiknya. Anda mungkin diberi tugas ini untuk menguji saraf Anda, jadi jangan menyerah.

Jawaban saya adalah: Anda harus memecahnya menjadi potongan-potongan kecil. Ini akan menjadi rutinitas harian Anda dalam beberapa bulan, jadi Anda harus belajar cara membagi dan menaklukkan. Ini pada dasarnya tugasmu. Beberapa saran:

  • Pastikan Anda memahami apa yang seharusnya dilakukan komponen ini . Bermainlah dengan apa yang harus Anda ambil dan lihat apa fungsinya, tanyakan kepada kolega Anda apakah asumsi Anda benar.

  • Anda menulis ulang modul ini karena suatu alasan. Mungkin tidak jelas bagi Anda, tetapi jika Anda diberi tugas ini kemungkinan besar karena ada sesuatu yang sangat buruk sehingga orang merasa lebih baik memulainya dari awal. Tanyakan sekitar: cacat apa itu ?

  • Coba temukan fitur inti dari komponen yang Anda tulis ulang, substansinya, alasan keberadaannya, dan mulailah dengan membuatnya berfungsi. Itu harus sangat kecil, sekecil yang Anda bisa. Tanyakan kepada kolega Anda tentang apa yang mereka pikirkan tentang fitur ini. Jika ini sistem GFX, cukup tampilkan satu poligon. Jika ini adalah sistem animasi, cukup tempatkan satu tulang dengan benar. Jika ini adalah sistem AI, buat saja ia memainkan animasi. Dll dll. Hanya buang semua yang menghalangi dan memberi Anda semua kesalahan yang menakutkan itu. Jangan terganggu oleh detailnya, cukup buat fitur inti ini bekerja secepat mungkin. Implementasi Anda akan jelek, penuh dengan bug, retasan, dan angka ajaib dan Anda tidak akan membiarkan siapa pun melihat kode Anda, tetapi itu tidak masalah.

  • Setelah Anda memiliki fitur inti ini, Anda akan mulai merasa lebih baik. Sangat penting untuk melihat hasil pekerjaan Anda sedini mungkin 1) untuk semangat Anda 2) untuk dapat mengujinya. Jadi, uji, stres, uji, siksa . Jika crash atau menunjukkan bug yang sangat buruk, perbaiki ini. Ini adalah jantung dari modul Anda jadi ulang sedikit dan bersihkan sampai Anda merasa nyaman dengannya.

  • Lalu perlihatkan kepada kolega Anda dan tanyakan apakah itu yang dibutuhkan game. Mintalah tinjauan kode : kolega Anda mungkin akan memberi tahu Anda tentang banyak hal yang tidak Anda pikirkan. Anda harus melakukan refactor lagi untuk memastikan implementasi Anda sesuai dengan yang diinginkan oleh seluruh tim.

  • Kemudian ketika Anda merasa siap untuk itu, pilih salah satu fitur lain yang Anda buang sebelumnya, bilas, ulangi. Buat itu berfungsi secepat mungkin, ulang, minta ulasan, ulang lagi.

Saya harus memberi penekanan terakhir kali pada ini: berkomunikasi . Tanya kolega Anda, tidak hanya pemimpin Anda, tidak hanya programmer, semua orang yang akan menggunakan atau menguji atau mengevaluasi sistem ini. Jangan takut menanyakan pertanyaan bodoh: ketika ragu, selalu lebih baik untuk mendapatkan informasi sekarang daripada menunggu berminggu-minggu untuk rapat atau ulasan.

Realitas pemrograman game adalah Anda tidak akan menciptakan sistem baru yang mengilap setiap hari, ini adalah tugas untuk tetap fokus dan menyelesaikan pekerjaan dengan cepat dan efisien. Tenangkan dirimu, mulai bekerja, dan semoga berhasil!

EDIT

Ada info tambahan yang saya temukan berguna dalam komentar Leo dan jawaban dhasenan, saya tanpa malu-malu menguatkan itu dari mereka untuk menyelesaikan jawaban ini.

Saya tidak menulis tentang cara menangani saling ketergantungan . Modul yang Anda tulis ulang mungkin sangat digabungkan dengan sisa permainan, itu sebabnya Anda mendapatkan banyak kesalahan saat mengubah sesuatu. Jadi ada dua solusi:

  • Jika hanya ada beberapa dependensi, maka Anda beruntung. Modul lama dan baru dapat disimpan secara paralel untuk sementara waktu, Anda bahkan dapat memiliki sakelar untuk pengguna Anda sehingga mereka dapat memutuskan untuk mengubah antara modul lama dan modul baru kapan pun mereka mau. Cukup letakkan sakelar di suatu tempat, di file konfigurasi atau di menu debug, dan gunakan di mana saja modul Anda terhubung ke sisa gim. Ketika modul baru Anda siap untuk produksi, aktifkan sakelar secara default. Kemudian, ketika modul lama tidak digunakan lagi atau ketika produksi perlu dilanjutkan, lepaskan modul lama dan sakelar.

  • Jika ada banyakdependensi, Anda harus mencabut dan pasang kembali satu per satu. Cobalah untuk menjaga kedua modul di latar belakang, dan setiap kali Anda mendapatkan fitur baru untuk bekerja, beralihlah ke modul baru untuk fitur itu. Yaitu mencabut dan pasang kembali apa yang terkait dengan fitur ini. Ini akan memakan waktu Anda karena mungkin lebih banyak pekerjaan daripada mengubah hanya satu panggilan fungsi: beberapa struktur data mungkin berubah, aliran program mungkin berubah, dll. Tapi itu masih lebih baik daripada menulis ulang semuanya sekali dan mengambil minggu untuk membunuh binatang kompilasi. Jika itu benar-benar mustahil untuk menjaga kedua modul lama dan baru secara paralel karena modul Anda sangat penting untuk gim, Anda mungkin mempertimbangkan untuk menulis ulang. Namun berhati-hatilah bahwa ini bisa berarti bahwa jika cacat ada di antarmuka modul lama, Anda akan berakhir dengan cacat yang sama. Lagi pula, jika ini terjadi,

Jika ada sesuatu yang spesifik untuk pengembangan video game, ini dia: kita tidak melakukan ilmu roket, atau penelitian yang rumit, kita bagian dari proses kreatif. Saat melakukan sesuatu, Anda harus membuat versi pertama secepat mungkin sehingga dapat diuji, dimainkan, disukai, dan dimodifikasi. Anda tidak dapat menghabiskan berminggu-minggu melakukan "satu pekerjaan yang sangat panjang" tanpa memberikan sedikit pun.


Jawaban yang bagus, jelas berlaku tidak hanya untuk game tetapi proyek apa pun
Tim Holt

1
+1, takeaway utama bagi saya: jangan hanya menguji , tetapi kode penyiksaan :) Bagi saya, ini adalah saran yang bagus.
Stefan Hanke

5
+1, Anda HARUS membagi refactorisasi besar menjadi potongan-potongan kecil. Saya sepenuhnya setuju bahwa ini adalah satu-satunya cara untuk menyelesaikan refactorisasi besar-besaran. Idealnya, ubah potongan kode dengan potongan, pastikan setiap perubahan membuat sistem berfungsi (ini akan mengurangi jumlah bug banyak). Jika ini tidak mungkin untuk fungsionalitas penuh, setidaknya lakukan untuk beberapa fungsionalitas inti. Mengubah semuanya sekaligus adalah cara pasti untuk menciptakan banyak bug yang sulit ditemukan.
Leo

1

Anda harus membagi tugas, tetapi tidak ada yang menawarkan saran tentang cara melakukannya.

  • Apakah modul baru dan lama bekerja bersama? Yaitu, dapatkah Anda mengkompilasi proyek Anda dengan keduanya? Ini akan memungkinkan Anda setidaknya mengkompilasi dan mungkin menjalankan tes otomatis di beberapa tonggak.
  • Apakah Anda menulis modul baru? Atau kode lama yang Anda miliki? Tulis ulang di tempat (sejauh API eksternal tetap sama). Jika Anda memperbaiki satu fungsi pada satu waktu, Anda harus dapat terus menggunakan API mongrel gabungan, sampai batas tertentu.
  • Apakah ada proyek lain di perusahaan yang akan melakukan transisi serupa? Tulis pembungkus di sekitar modul-modul ini untuk membuat prosesnya lebih mudah di lain waktu Mungkin bermanfaat melakukan ini sementara itu.
  • Bisakah Anda berkomentar atau menghindari kompilasi potongan rantai ketergantungan Anda? Jika Anda memiliki setengah juta baris total kode, mungkin Anda dapat membaginya menjadi dua puluh bagian yang dikompilasi secara independen, buat satu bekerja dalam beberapa minggu, dan kemudian pindah ke yang berikutnya. Mungkin potongan tidak sepenuhnya independen sepanjang waktu, tetapi kemudian Anda dapat melakukannya dalam urutan dependensi.

Juga: minta saran manajer Anda. Saya mungkin akan mulai menjelaskan masalah: butuh waktu lama untuk membuat kompilasi dengan benar sehingga sulit untuk melacak perubahan, yang akan membuat lebih sulit untuk men-debug setelah Anda memiliki sesuatu yang dapat Anda uji. Lalu saya akan menyebutkan solusi potensial, dan bertanya: "Bagaimana Anda merekomendasikan saya menerapkan solusi ini, atau apakah ada cara yang lebih baik untuk melakukan ini sepenuhnya?"

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.