Melakukannya vs Desain Perangkat Lunak yang Solid?

Dengan waktu yang hampir tidak cukup di tangan kami untuk menyelesaikan permainan yang kami buat, bagaimana Anda bisa mencapai keseimbangan yang baik antara arsitektur perangkat lunak yang solid dan membuat kemajuan yang baik untuk menyelesaikan semuanya?

Tantangan pribadi saya: Bagaimana kalau hari ini menjadi efektif dan berpikir jangka panjang? Plus, saat Anda melakukannya Anda mungkin ingin mempelajari hal-hal baru di jalan daripada menggunakan pola berulang yang sama dengan yang Anda gunakan selama 5 tahun terakhir?

Semakin sedikit pengalaman yang Anda miliki, semakin banyak waktu yang Anda buang dengan desain di muka. Membuat desain yang baik adalah sesuatu yang akan Anda pelajari dengan melakukannya dan kemudian melihat / mengevaluasi bagaimana hasilnya. Beberapa keputusan memiliki implikasi yang luas tetapi tidak jelas. Setelah beberapa permainan, Anda mungkin akan dapat membuat desain awal yang cukup solid dan akan membayar untuk menginvestasikan lebih banyak waktu ke tahap ini.

Moto saya: menyelesaikan sesuatu di tempat pertama, tetapi gunakan akal sehat Anda untuk mendeteksi komponen apa yang lebih penting daripada yang lain dan merancang itu dengan cukup baik, dalam batas waktu Anda. Misalnya, jika AI sangat penting untuk gim Anda, pastikan Anda dapat dengan mudah memperpanjang / mengubahnya nanti. Atau, jika Anda akan menulis komponen yang akan Anda gunakan di setiap gim, rancanglah agar dapat digunakan kembali. Lacak waktu Anda dan jangan menjadi liar dalam mendesain. Tetapkan batas waktu desain dan setelah itu, mulailah meretas semuanya untuk mendapatkan batas waktu rilis Anda. Tetapi pastikan Anda mencatat poin apa yang perlu di-refactoring / mendesain ulang sesudahnya dan menghitung dalam beberapa waktu sebelum Anda memulai permainan berikutnya untuk meningkatkan hal-hal itu, sehingga mereka tidak bisa menggigit Anda kembali!

Saran yang bagus: jika Anda harus memilih di antara dua opsi, jangan berlama-lama membahas detail. Paling sering, tidak ada "baik" atau "buruk". Dalam beberapa situasi, A akan lebih baik, dalam beberapa, B akan menjadi, dan secara keseluruhan, perbedaan antara keduanya mungkin tidak selalu sepadan dengan waktu.

Ada banyak pengalaman yang bisa Anda peroleh dalam mendesain perangkat lunak atau game, jadi pastikan Anda meluangkan waktu Anda untuk penelitian (misalnya membaca buku tentang desain, membaca tentang pengalaman orang lain, berbicara dengan sesama programmer tentang desain Anda, dll ... ).

Orang-orang buruk dalam memprediksi masa depan. Ini terutama berlaku untuk gim, di mana persyaratan dapat berubah setiap hari.

Ada prinsip yang disebut YAGNI , alias "Kamu Tidak Akan Membutuhkannya", yang pada dasarnya mengatakan bahwa kamu tidak boleh menerapkan sesuatu sampai kamu tahu kamu akan membutuhkannya.

Saya telah melihat begitu banyak sistem macet dengan kekakuan arsitektur yang tidak benar-benar menggunakannya karena fitur-fitur yang orang pikir perlu tidak pernah digunakan.

Filosofi pribadi saya adalah Lakukan Hal Sederhana yang Mungkin Dapat Bekerja . Yang sedang berkata, ada perbedaan antara Getting It Done dan Hacking Shit Together. Menulis kode dengan tujuan tidak boleh menyiratkan melakukan hal-hal yang menghasilkan "bau kode" seperti membuat semuanya publik, memiliki kelas gumpalan yang melakukan segalanya, atau lusinan hal lain yang menandakan kode "buruk".

Ini mengevaluasi kebenaran dalam pola pikir saya hari ini:

• Pragmatisme atas Ideologi
• (1) Buat itu berhasil (2) kemudian buatlah dengan benar - lewati jika Anda lupa langkah 2
• Lepaskan!
• Terlalu banyak desain di muka akan membuang-buang waktu
• TDD dan Clean Code mengarah ke desain perangkat lunak yang lebih sederhana dan lebih stabil

Saya teman software prototyping cepat. Terutama selama pengembangan game. Ini bagus untuk belajar cepat, menguji dan menggunakan hal-hal. Untuk dekat dengan pemrograman perangkat keras atau algoritma yang rumit adalah metode terbaik untuk saya.

Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
 Testing();
 LotOfFixing();
 PlayingWith(); 
 bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();

Versi Rapid Prototype saya harus memiliki kerak prototipe yang tepat:

• Antarmuka input yang ramah untuk mengkonfigurasi arahan dan pengaturan variabel atau data.
• Pengecualian dan penanganan kesalahan yang stabil.
• Online suka fungsi debuger tetapi pada level apa yang Anda butuhkan.
• Antarmuka keluaran ramah max untuk menunjukkan atau menangkap hasil pada semua cara yang mungkin dan diperlukan.

Keuntungan:

• Anda dapat meningkatkan kerak RapidPrototype selama pengembangan keseluruhan.
• Anda dapat melihat dan mengatur kode Anda dengan banyak cara.
• Anda hanya bisa fokus pada teori dan masalah yang perlu Anda pecahkan.
• Anda dapat dengan cepat mengembangkan bagian-bagian baru proyek dan mencobanya dengan hal-hal akhir lainnya.
• Anda dapat memberikan hal-hal baru untuk digunakan dalam pengisian konten lebih cepat dan menyelesaikannya nanti. (Terutama dalam kotak pasir)
• Anda dapat dengan mudah menggambarkan dan menunjukkan prinsip atau solusi kepada orang lain. On line.
• Prototipe fungsional dan transparan adalah sumber informasi terbaik untuk kode akhir (siapa pun dapat melakukannya).

Jika Anda melakukannya dengan baik, Anda dapat memiliki versi debug / pelajari yang sebenarnya dari produk Anda pada akhirnya.
Kami menggunakannya dalam proyek kami dan kami senang dengan itu.

Lihat pengembangan perangkat lunak tangkas . Meskipun itu bukan peluru perak, itu bertujuan untuk melakukan keduanya (menyelesaikannya dan memiliki desain perangkat lunak yang solid).