Pembicaraan selanjutnya dengan Pixonic DevGAMM Talks, yang telah kami uraikan, sedikit filosofis - ini adalah pidato oleh Konstantin Gladyshev. Dia adalah Lead Game Programmer di 1C Game Studios dan berbicara tentang prinsip mengelola kompleksitas pengembangan dalam konteks seluruh produk, bukan fitur individual. Dan dengan contoh, ia menunjukkan mengapa hal utama dalam pembangunan adalah menentukan apa yang tidak boleh dilakukan. Untuk laporan lain, baca tautan di akhir artikel.
Saya ingin berbicara tentang utara, tetapi memutuskan untuk membuat laporan filosofis tentang apa yang harus dilakukan dengan lebih mudah. Saya bekerja di Pos III, Indestructible, War Robots dan saya sedang melakukan Calibre, seorang penembak sesi online dari 1C dan Wargaming.
Mengapa kami memutuskan untuk berbicara tentang KISS (Sederhana saja, bodoh)? Karena bahkan manula dengan pengalaman 20 tahun atau CTO sering terus memahat dan menciptakan sesuatu. Tetapi Anda perlu melakukannya dengan lebih mudah. Sebenarnya, ada lebih banyak tentang YAGNI (Anda tidak akan membutuhkannya) dan sedikit filosofi.
Saya harus segera mengatakan bahwa kita tidak membicarakan solusi yang benar-benar bodoh, seperti "find x", kita berbicara tentang solusi yang kurang lebih sederhana.
Mengapa terkadang terlalu sulit? Semuanya dimulai dengan niat baik, dan mereka, seperti yang Anda tahu, mengarah ke neraka. Berikut ini adalah komik tentang ini.
Alasannya kira-kira sama, tetapi saya menyebutnya berbeda:
- Solusi universal . Ada beberapa jenis fitur dan kami segera membuat perpustakaan darinya, sejuta kasus tambahan. Lalu tiba-tiba penembak kita akan berubah menjadi peternakan? Atau "lain kali aku akan melakukan penembak lain yang persis sama." Kecil kemungkinan bahwa itu akan berubah untuk Anda.
- Bukti masa depan . Hal yang hampir sama - ini adalah masalah yang tidak ada. "Dan jika saya memiliki sejuta pengguna segera, apakah saya perlu menahan 22 server perantara?" dll. Untuk mulai menghasilkan, satu server sudah cukup untuk Anda.
- Menggunakan alat yang salah . Ketika Anda menggunakan alat yang tidak sesuai dan bertahan dalam khayalan Anda.
- Dan semua orang tahu optimasi prematur .
Kami punya contoh ketika mereka membuat Calibre. Orang-orang yang membantu kami kemudian memutuskan untuk segera membuat superserializer di C ++ terbaru.
Akibatnya, itu tidak berfungsi seperti yang diinginkan, tidak nyaman untuk mengirim keadaan parsial, karena templat tidak benar-benar mengerti di mana perlu, di mana tidak, atau jika Anda membuat beberapa bendera. Bug yang ada dalam kode boilerplate ini, bahkan penulis tidak mengerti dari waktu ke waktu.
Kemudian salah satu programmer hanya dalam dua jam menulis ulang semua hal ini pada satu halaman kode C, yang melakukan apa yang kami butuhkan saat itu. Dan itu bekerja dengan sangat baik.
Contoh lain. Kami memiliki Pos III dan dibuat di mesin Sumber. Ada dunia yang begitu terbuka, Anda bisa berjalan di antara peta, kamera orang ketiga, banyak rumah bergaya Amerika berlantai satu dengan jendela, bot dapat berlarian dan dengan panik membuka pintu. Akibatnya, seluruh BSP tidak berfungsi. Itu dipertimbangkan untuk waktu yang sangat lama, karena dari jendela ternyata satu juta sektor dan masih tidak melakukan apa-apa. Butuh banyak memori dan dimuat untuk waktu yang lama.
Half-Life, di mana mesin itu dibuat, adalah penembak orang pertama, dan dari yang ketiga itu merepotkan untuk melakukan beberapa hal. Segala sesuatu yang berguna dari Half-Life sama sekali tidak cocok untuk kita. Juga, sejumlah besar animasi seharusnya dilakukan, karena dari orang ketiga Anda perlu memanjat, dll. Itu perlu untuk mengganti mesin, tetapi kemudian tidak ada pilihan.
Apa yang harus dilakukan ketika semuanya buruk, sulit, tetapi mereka mendorong kita? Pertama, melakukan fitur dalam urutan yang benar, karena mengoptimalkan sebelumnya adalah salah satu masalah. Beberapa mulai menempel strassiks sebelum mereka menjahit gaun, dan kemudian mereka tidak bisa menjahit, karena para strazik mengganggu.
Pertama, buat chip yang paling sederhana sehingga hanya berfungsi, lalu stabilkan, lalu optimalkan. Dalam urutan inilah segala sesuatu yang salah.
Dengan visualisasi, kami memahami bahwa itu beroperasi secara minimal, mis. MVP (produk minimum yang layak).
Kemudian Anda mengevaluasi potensinya. Katakanlah para desainer game datang dengan fitur-fitur, resor pemrogram dan berkata, "Saya akan melakukannya dengan baik, saya tidak akan melakukan yang buruk, jadi segera buat desain game yang funky." Tapi bagaimana dia tahu? Dia tidak bermain, tidak tahu apakah itu baik atau buruk. Karena itu, idealnya, Anda membuat fitur, bermain, jika normal, maka lakukan lebih jauh. Tidak normal - dibuang, tidak sayang.
Seribu tahun yang lalu, Sun Tzu mengatakan bahwa memenangkan 100 pertempuran bukanlah puncaknya, puncaknya adalah menang tanpa pertempuran. Yaitu jangan lakukan apa yang tidak bisa kamu lakukan.
Stabilisasi. Anda telah membuat fitur dan selanjutnya menstabilkannya tanpa tambahan yang tidak perlu. Apakah Anda memerlukan roda di pohon, di tali? Itu tergantung. Tidak lebih.
Dengan demikian, jika tiba-tiba ditemukan (tanpa bukti di masa depan) bahwa fitur tersebut harus berubah - mulai lagi. Hanya membuat prototipe, menstabilkan, dan jangan mencoba menebak ke depan. Anda masih tidak akan menebak.
Nah, optimasi prematur. Ini selalu buruk. Anda harus mengoptimalkan di bagian paling akhir, ketika Anda tahu pasti bahwa fitur ini penting, itu harus dioptimalkan dan itu tidak akan berubah secara mendasar dalam waktu dekat.
Karena optimasi adalah seperangkat kasus khusus. Keterbacaan kode semakin buruk, abstraksi rusak dan mudah dibawa, sebagai suatu peraturan, juga semakin memburuk.
Ini slide yang provokatif, karena kruk benar-benar buruk. Tapi di sini situasinya diperlihatkan ketika ada banyak fitur dan prototipe yang membosankan, semuanya buruk, dan tampaknya semuanya akan runtuh. Tapi ini tidak benar. Lihat - ini adalah bekisting, beton dituangkan ke dalamnya, dan "tongkat" disangga saat mengering. Yaitu situasinya benar-benar normal, "kruk" kemudian akan dihapus, tetapi tidak segera, tanpa panik.
Secara singkat tentang filsafat. Tidak ada solusi yang berlaku secara universal. Jangan mencoba membuat kerangka kerja untuk 100 tahun sebelumnya atau untuk semua kesempatan.
Lebih baik membuat banyak potongan kecil yang melakukan pekerjaannya dengan baik. Buang yang tidak perlu sesegera mungkin, jangan coba-coba mendukungnya. Dan ketika menulis kode, buat itu eksplisit. Terkadang lebih baik menulis kode eksplisit yang Anda serialkan dengan tangan Anda, daripada refleksi atau sesuatu yang lain. Menggunakan tindakan ketergantungan saat Anda tidak membutuhkannya juga merupakan ide yang buruk. Sangat sulit dibaca, separuh kesalahan dalam runtime. Eksplisit lebih baik daripada implisit. Dan buat sesederhana mungkin untuk menghindari kesalahan ketika seseorang tidak memahami sesuatu atau bahkan sepenuhnya lupa.
Seperti yang dikatakan Bruce Lee, kesederhanaan adalah tingkat seni tertinggi. Suatu ketika seorang aktor yang dia ajar Jeet Kune-Do bertanya kepadanya: "Apa esensi seni bela diri Anda, Jeet Kune-Do?" Pada saat itu, Bruce Lee menjatuhkan dompetnya, aktor itu mengambilnya dan Bruce Lee berkata: "Anda tahu, Anda hanya membungkuk dan mengambil dompet itu, dan jika Anda berdiri dalam posisi seorang penunggang, membuat kata, Anda tidak akan pernah mengangkatnya."
Pertanyaan dari audiens
"Kamu bilang optimasi prematur itu jahat." Apakah layak menulis tes prematur ketika sebuah proyek baru dimulai?- Dalam pemahaman saya, segala sesuatu yang prematur berbahaya. Dalam tes, saya tidak terlalu kuat, karena dalam pengembangan game (dalam banyak kasus), tes lebih dekat ke akhir pengembangan. Pada awalnya, semuanya berubah begitu cepat sehingga saat Anda menulis tes, perancang permainan sudah akan mengubah segalanya. Saya percaya bahwa menghabiskan energi untuk menguji apa yang akan berubah dalam dua jam adalah hal yang buruk. Ini harus dilakukan pada tahap stabilisasi. Tetapi tidak pada tahap prototipe. Tetapi jika tim dapat menulis tes dengan cepat, ini mungkin bagus. Jika tidak, maka tidak.
- Anda menyebutkan bahwa kruk akan dihapus, tetapi ada tesis yang bagus - tidak ada yang lebih permanen daripada sementara. Kita semua bekerja di game dev, kami memiliki tenggat waktu, produser, kemudian fitur baru dan sebagainya. Seberapa sering Anda melihat situasi di mana Anda membersihkan kruk? Dan apakah mereka membawa mereka ke nol?- Mungkin tidak nol. Jika proyek ini aktif, Anda akan selalu memiliki beberapa tongkat penyangga. Semuanya berfungsi jika dibersihkan secara sistematis. Yaitu Anda membuat fitur - segera direkam.
- Yaitu Haruskah proses tertentu dibangun di perusahaan? Jenis fase pembersihan kruk resmi?- Ya, saya percaya ini harus dimasukkan dalam tugas. Yaitu jika Anda perlu refactor dalam proses tugas - Anda refactor. Secara kasar, bahkan kata refactoring tidak - itu di dalam tugas.
- Apakah Anda berhasil melakukan ini dalam praktik? Anda datang ke produser dan mengatakan pada perencanaan iterasi baru bahwa kita perlu dua minggu untuk membersihkan, refactor, dll. Dan dia mengatakan bahwa nilai bisnis adalah nol, sekarang kami memiliki fitur x, dan kemudian Anda akan membersihkannya nanti malam setelah bekerja. Bagaimana bisa berada dalam situasi ini?- Kami berhasil. Produser menyadari bahwa ada beberapa hutang yang Anda koreksi, tetapi tepat waktu. Bukannya Anda memiliki rilis baru, ini tidak memiliki fitur baru, tetapi di sini ada semacam refactoring. Pilih saja produsen yang tepat.
"Dengan pengalaman, pengertian datang, semakin sederhana semakin baik." Tetapi programmer pemula mencoba untuk menciptakan sistem yang kompleks, menakutkan, besar dan raksasa. Pertanyaan: bagaimana menjaga mereka dari ini, kecuali untuk "tidak" yang sulit?- Saya pikir ini adalah masalah pembelajaran. Penting untuk menunjukkan sedini mungkin solusi mana yang berfungsi, mana yang tidak, dan mengapa. Ketika Anda memiliki pengalaman dan Anda dapat menjelaskan mengapa Anda tidak perlu melakukan ini, Anda bisa memberikan banyak contoh dan itu sudah bekerja dengan baik. Untuk menunjukkan dan terus memantau dengan contoh Anda sendiri sehingga semuanya sederhana. Pakai prototipe sehingga mereka menulis ulang lebih sering - ketika Anda sering menulis ulang, Anda tidak merasa ingin banyak menulis dan mereka menulis lebih banyak dan lebih sederhana.
- Jika sudah ada sesuatu yang sangat rumit yang digunakan pada beberapa proyek, dan kompleksitas ini tidak membantu lagi, tetapi malah mengganggu - seberapa mudahnya beralih ke solusi sederhana?- Pendapat saya, mulai lakukan lagi. Idealnya, tim yang terpisah, langsung dari awal. Kemungkinan besar Anda akan memulihkan 80% fungsionalitas dengan sangat cepat. Di perpustakaan baru dan bersih. Dan kemudian Anda akan menyusul.
- Misalnya, ada beberapa serializer dan editor logika game yang kuat, sekarang sudah cukup usang ...- Ini adalah alat yang tidak nyaman sama. Nyaman. Persatuan, misalnya.
- Katakan padaku, apa rencanamu dalam kode, seberapa detailnya? Apakah programmer utama menyelesaikan semua masalah kecil, semua tugas?- Kami memiliki anarki seperti itu, struktur yang cukup datar, tidak banyak orang. Kami mempercayai semua orang dan hanya mendistribusikan siapa yang akan mengambil prototipe dan siapa yang tidak. Itu bisa berupa sembarang orang.
Lebih banyak pembicaraan dengan Pixonic DevGAMM Talks