WTF per Jam

Jiwa sang penyair tidak dapat menanggung ketidakjelasan, dan ia dengan murah hati membagikan gagasan-gagasan mulianya. (c) anonim

Beberapa waktu yang lalu saya menulis tiga artikel "Solusi arsitektur untuk sebuah game mobile" yang didedikasikan untuk arsitektur impian saya:
• Bagian 1: Model
• Bagian 2: Perintah dan antriannya
• Bagian 3: Melihat pada propulsi jet

Saya bahkan berpikir untuk membuat produk ini dengan aset, tetapi selama pemungutan suara ternyata ide dan diskusi jauh lebih penting bagi orang daripada kode yang sudah jadi. Sejak itu saya bekerja di dua kantor permainan, satu terlibat dan satu masih terlibat dalam permainan desktop, tetapi gagasan mengatur Antarmuka Pengguna melalui reaktivitas dalam kedua kasus itu sangat berguna, beberapa kali mempercepat beberapa pekerjaan pada antarmuka yang kompleks, dan memungkinkan untuk mengimplementasikan antarmuka itu sebelumnya tampak terlalu rumit. Semua ini menunjukkan bahwa bahkan tahap uji beta tertutup pertama tidak terlambat untuk membuat proyek lebih baik.

Saya melihat berbagai laporan pemrograman youtube, dan saya melihat kesamaan di antara mereka: Ide, bahkan yang sepenuhnya benar, masuk ke otak orang-orang yang paling membutuhkannya dan kadang-kadang disalahpahami karena ada sedikit kode dalam cerita. Programer yang keluar dari laporan seperti itu dapat duduk dan mulai menulis hanya jika apa yang sudah diberitahukan kepadanya hampir dapat dimengerti olehnya, dia hanya tidak punya waktu untuk menebak sendiri. Di ujung lain tutorial, oleh hello world. Kesedihan, secara umum.

Ada konsep seperti "Zona pengembangan terdekat": Itu ditentukan oleh isi tugas-tugas yang belum dapat diselesaikan seseorang sendiri, tetapi mampu menyelesaikan dalam aktivitas bersama dengan seseorang yang telah mengambil penghalang ini. Apa yang pada awalnya dapat diakses oleh seseorang dengan partisipasi orang lain kemudian menjadi miliknya sendiri (keterampilan, kemampuan). Oleh karena itu, tentu saja sangat berguna untuk bekerja sama dengan pemimpin yang kuat dalam proyek yang menarik. Tetapi di mana saya dapat menemukan semua proyek, dan bahkan lebih lagi.

Secara umum, memikirkan semua ini, saya ingin mencoba berbagi dengan orang-orang dalam format yang berbeda: Saya akan mengatur aliran yang didedikasikan untuk Peninjauan Kode, saya akan menunjukkan kode saya yang didedikasikan untuk reaktivitas dan menjelaskan ide-ide yang diletakkan di dalamnya dan mengapa itu ditulis seperti itu dan tidak jika tidak. Aliran akan berlangsung tepat satu jam. Di sini, di artikel saya akan menjelaskan secara singkat apa yang ingin saya bicarakan, dan kemudian setelah fakta saya akan menambahkan waktu dan masalah apa yang berhasil saya bahas dan dari menit berapa.

Dalam prosesnya, Anda dapat dan harus mengajukan pertanyaan, karena mereka mengatakan kualitas kode diukur dengan jumlah WTF per unit waktu tinjauan. Setiap pertanyaan yang lebih terperinci dapat ditanyakan di sini di komentar, dan saya akan mencoba menjawabnya selama streaming jika sepotong kode yang cocok untuk jawabannya muncul.

Dalam prosesnya, Anda dapat dan harus memperbaiki saya dan menunjukkan kesalahan. Karena pasti akan ada seseorang yang lebih pintar pada khususnya atau secara umum, dan juga karena ketika seseorang melihat kode sendiri, ia tampaknya tidak melihat bagian dari itu, otak sudah memiliki pendapat yang tertulis dalam "titik buta" dan tidak baca kembali. Banyak, seperti yang saya tahu perasaan ini, ketika Anda memanggil dua mata lagi untuk kode Anda, dan tiba-tiba orang luar melihat kesalahan yang jelas di tempat yang paling terlihat yang belum Anda lihat. Untuk orang yang berbeda, "blind spot" jatuh dalam cara yang berbeda, pada kode yang sama.

Streaming akan dimulai pada hari Rabu pukul 22:30 (sayangnya ini adalah waktu luang saya :) dan akan tersedia di sini:

Sekarang tentang konten aliran.

Secara umum, implementasi reaktivitas yang bagus ada di perpustakaan UniRX, yang saya sangat sarankan untuk berkenalan. Mungkin Anda benar-benar akan mengambilnya sendiri, atau mungkin hanya menghapus ide dari sana. Tapi saya akan menunjukkan sepeda saya sendiri, ditulis dari awal. Ini bukan hanya karena saya suka sepeda. Di UniRX, mengimplementasikan antarmuka sistem standar. IObserver <dalam T> dan System.IObservable <out T>. Dan di banyak tempat, ThreadSafe melakukan ini (tidak selalu benar) dan internal. Artinya, perpustakaan memiliki banyak kode tambahan, dan tidak nyaman untuk mengembangkannya. Pada kenyataannya, saya perlu memperluas dan beradaptasi dengan kondisi lokal dalam tiga kasus dari tiga.

Selain itu, seperti yang dikatakan direktur teknis Assetstore kami, itu akan meningkatkan waktu, tetapi itu tidak akan meningkatkan otak. Jika Anda mengambil sesuatu dari sana yang tidak dapat Anda tulis sendiri, maka cepat atau lambat Anda akan menyesap kode ini.
Benar, saya tidak akan menampilkan kode aplikasi yang benar-benar berfungsi di dalam game, tetapi versi rumah saya. Pertama, itu tidak mungkin, dan kedua, yang lebih penting, saya memiliki versi yang lebih fungsional di rumah.

Multithreading, di tempat ini benar-benar berlebihan jika kita menggunakan reaktivitas untuk antarmuka. Yang kami ingin lakukan adalah akhirnya berada di UnityThred untuk memindahkan komponen layar. Kedua, saya menulis utas untuk hal yang sama, dan dalam kasus yang lebih sulit, di tempat kerja, dan itu membutuhkan waktu lima kali lebih banyak, meskipun di beberapa tempat saya cerdik menggunakan fitur mesin server kami yang sangat tidak sinkron. Untuk membuat kode menerapkan seluruh kontrak tanpa mengumbar akan membutuhkan lebih banyak lagi.

Selain itu, IObserver sendiri adalah masalah. Pertama, untuk selera saya metode OnError (Exception e) yang benar-benar berlebihan. Ketika Anda memiliki multithreading, ini memiliki makna yang dalam, terdiri dari membuang tindakan ini di UnityThread dan tidak akan luput dari perhatian. Dan awalnya, antarmuka ini diciptakan untuk bekerja dengan file yang sering jatuh karena kesalahan. Tetapi dalam mode single-threaded dan ketika Anda bekerja dengan model aplikasi ini adalah pendarahan ekstra tiba-tiba, saya lebih suka kode untuk meningkatkan alarm tepat di tempat di mana ia mati.

Masalah kedua dengan IObserver adalah saya ingin perubahan transaksional. Bayangkan saja Daftar datang kepada Anda dari satu sumber, dan dari aliran lain kami mendapatkan indeks elemen, yang harus kami hapus dari lembaran dan meneruskan. Dan di sini indeks menunjuk ke elemen terakhir, dan di sini satu elemen dihapus, dan indeks berkurang sebesar 1. Pada akhirnya, semuanya akan baik-baik saja dan hasil operasi tidak akan berubah, tetapi jika kami menerima pesan tentang perubahan Daftar dan hanya kemudian pesan tentang perubahan indeks, kami kode akan menangkap IndexOutOfRangeException. Faktanya, masalah yang sama dengan urutan penerapan perubahan dapat memanifestasikan dirinya dalam lusinan cara lain, ini hanyalah yang paling jelas.

Oleh karena itu, saya ingin antarmuka saya, di satu sisi tanpa menyeret OnError, tetapi di sisi lain berisi .OnTransaction (ITransaction t)

Sesuatu yang saya rasakan terlalu dalam. Membicarakannya selama aliran dengan kode di layar akan jelas lebih cepat, dan jauh lebih dimengerti. Lebih jauh tentang puncak:

• Antarmuka saya IActive dan IReactive. Bagaimana mereka lebih cantik daripada acara apa pun dan seperti apa hasil akhir dari penggunaannya.
• ActiveProperty <T>. Apa perbedaan dari Active.Proxy <T>, bagaimana nilai awal suatu variabel ditransmisikan dan bagaimana itu diproses.
• Bagaimana cara memeriksa semua ini dengan tes dan mengapa ini sangat nyaman. Bahkan, tidak mungkin menulis hal seperti itu tanpa tes sama sekali.
• Strategi Housekeeping IDisposible. Mekanisme ganda yang mendukung OnComplete dan ICollection <IDisposible>
• Cara mudah membuat ekstensi alat streaming dan membaca contoh paling berguna.
• Alat debugging untuk semua kekacauan ini. Pertama-tama. Log (), dan kami akan menuju ke CalculateTree di lain waktu.
• Hati-hati membaca kode Active.Proxy <T>, mengapa tidak ada peristiwa apa pun di bawah tenda, tetapi daftar yang ditautkan dua kali lipat.
• IActiveList dan IActiveDictionary, pertama ide yang paling umum.
• Cara membagi menjadi ViewModel, Controller dan View. Bagaimana tidak untuk memutarkan aliran Anda.
• Proses menjatuhkan variabel dari reaktivitas ke model.
• ActiveList dan ActiveDictionary dengan delta minimal. Berbeda dengan implementasi frontal DeltaDictionary pada umumnya dan di UniRX pada khususnya.
• Strategi umum untuk memperbaiki kesalahan dalam kode, karena tidak ada subjek seperti itu di universitas, tetapi seharusnya.

Bahkan, sudah ada beberapa jam cerita dan pertunjukan kode, jadi mari kita mulai dari jam pertama, dan kemudian bagaimana menginjak-injak.

PS Ini akan menjadi streaming pertama saya, jadi jangan menilai dengan ketat jika ada masalah teknis.