🎯 👛 👨🏽‍🔧 Pemrograman ke massa 🀄️ 🍌 🗺️

Memahami bahkan dasar-dasar pemrograman dapat menyederhanakan aktivitas manusia. Selain hal-hal yang jelas, seperti pengembangan pemikiran abstrak atau kemampuan untuk membagi tugas menjadi bagian-bagian yang lebih kecil, saya mengusulkan untuk melangkah lebih jauh dan menggunakan pendekatan dasar untuk pengembangan. Menggunakan contoh membuat permainan logis klasik, menggambar analogi antara pemrograman visual dan tradisional, saya ingin menunjukkan bagaimana keterampilan pengembangan dapat membantu dalam memecahkan masalah yang diterapkan. Mereka yang ingin berdebat tentang topik atau bermain "Bulls and Cows" dan memenangkan hadiah - panggilan untuk kucing.

Nama saya Zhenya dan saya adalah pengembang backend di ManyChat. Beberapa waktu yang lalu, tim HR menghampiri saya dengan permintaan untuk mengimplementasikan game "Bulls and Cows", yang akrab bagi banyak orang sejak kecil, berdasarkan produk kami. Izinkan saya menambahkan sedikit konteks. ManyChat adalah alat untuk mengotomatisasi interaksi antara bisnis dan pelanggan mereka, memungkinkan Anda untuk menjawab pertanyaan umum melalui Facebook, dan yang terbaru adalah SMS dan Email. “Bulls and Cows” adalah permainan logis, di mana, untuk beberapa upaya, perlu menebak angka yang ditebak. Banyak yang bisa mengetahuinya dari game Fallout, tempat Anda perlu meretas terminal komputer. Rincian lebih lanjut tentang aturan dapat ditemukan di akhir artikel.

Visualisasi

Apa yang kita lakukan sebelum menulis kode untuk tugas yang kompleks? Kami pergi ke papan tulis dengan spidol atau mengambil pensil dan kertas dan menggambar diagram blok atau diagram UML, karena visualisasi adalah cara paling alami bagi orang untuk menyajikan dan memahami informasi. Flow Builder adalah jantung dari sistem kami, berdasarkan berbagai objek, elemen grafis, dan aturan yang digunakannya untuk saling berinteraksi. Saya akan mengatakan bahwa ini adalah kelanjutan logis dari pemrograman berorientasi objek. Jadi saya membuang alat yang biasa dan segera mulai merancang logika komunikasi antara bot dan pemain.

Game Flow of the Bulls and Cows

Ini sangat nyaman, karena diagram UML dan Flow Builder hampir identik. Pada langkah ini, desain dan pemrograman sudah digabungkan. Untuk beberapa iterasi, saya melemparkan aliran dan menunjuk tempat-tempat interaksi dengan pengguna dan dengan API. Hasil yang diperoleh agak berbeda dari representasi asli di kepala saya - visualisasi memberikan kesempatan untuk melihat tugas dari perspektif yang berbeda. Ini bagus, karena perubahan diagram lebih mudah dan lebih murah daripada kode. Tampak bagi saya bahwa makna dari pendekatan ini berakar pada pepatah "mengukur tujuh kali, memotong satu". Insinyur harus sangat akrab dan dapat dimengerti.

Pembagian tanggung jawab

Apa yang harus diimplementasikan di sisi ManyChat, dan apa di sisi kode? Jawaban untuk pertanyaan ini pada awalnya tidak tampak jelas bagi saya. Ada dua alat untuk berinteraksi di platform kami: Blok Dinamis dan Permintaan Eksternal. Mereka hampir identik kecuali bahwa yang pertama mengeksekusi permintaan ke server jauh dan pindah ke instruksi berikutnya, dan yang kedua memungkinkan Anda untuk pertama membandingkan data respons dengan variabel bot. Di salah satu versi pertama, saya menggunakan blok Dinamis dan mengimplementasikan pengiriman kedudukan dari metode API langsung ke Facebook. Tampaknya tidak ada yang salah dengan pendekatan ini. Tetapi jika Anda melihat lebih jauh dan berasumsi bahwa pemain ingin bermain menggunakan SMS, kode harus mencari tahu tentang saluran komunikasi pemain tertentu. Sepertinya tidak perlu. Di versi berikutnya, saya beralih aliran untuk bekerja dengan Permintaan Eksternal,menambahkan catatan respons ke variabel pengguna dan menghapus penyebutan saluran dari kode. Sekarang kode gim dapat digunakan di aplikasi lain dan mengimplementasikan antarmuka interaksi yang diinginkan: dari konsol ke aplikasi seluler. Apakah itu memisahkan pandangan dari logika kontrol sesuai dengan pola MVC atau menyoroti konteks terbatas sesuai dengan pendekatan DDD - putuskan sendiri. Hal utama di sini adalah bahwa terlepas dari kurangnya persyaratan, pada tingkat bawah sadar, saya mengidentifikasi potensi kemacetan dalam sistem yang dapat menciptakan masalah di masa depan.Apakah itu memisahkan pandangan dari logika kontrol sesuai dengan pola MVC atau menyoroti konteks terbatas sesuai dengan pendekatan DDD - putuskan sendiri. Hal utama di sini adalah bahwa terlepas dari kurangnya persyaratan, pada tingkat bawah sadar, saya mengidentifikasi potensi kemacetan dalam sistem yang dapat menciptakan masalah di masa depan.Apakah itu memisahkan pandangan dari logika kontrol sesuai dengan pola MVC atau menyoroti konteks terbatas sesuai dengan pendekatan DDD - putuskan sendiri. Hal utama di sini adalah bahwa terlepas dari kurangnya persyaratan, pada tingkat bawah sadar, saya mengidentifikasi potensi kemacetan dalam sistem yang dapat menciptakan masalah di masa depan.

Penamaan variabel

Penamaan variabel adalah salah satu dari dua masalah pemrograman utama. Selain variabel, penamaan blok juga sama pentingnya. Banyak pengguna tidak mementingkan hal ini, tidak punya waktu untuk melihat-lihat karena aliran berubah menjadi satu set Copy 1, Copy 2, dan sebagainya. Ini sangat menyulitkan pemahaman. Semuanya seperti dengan kelas yang buruk - tidak mungkin untuk mengetahui apa yang dia lakukan tanpa masuk ke dalam. Secara lebih rinci pemikiran ini diungkapkan oleh rekan saya. Jika Anda tertarik, saya sarankan Anda membaca postingnya .

Steve McConnell dalam bukunya "Kode Sempurna" menulis bahwa nama harus sepenuhnya dan akurat menggambarkan entitas yang diwakili. Saya pikir sulit untuk berdebat dengan itu. Sebagai contoh, untuk variabel boolean, saya lebih suka menggunakan awalan is. Dalam hal ini, pembaca sudah bisa mengerti apa yang dia hadapi dengan dua huruf pertama. Adapun panjangnya, diinginkan bahwa tidak melebihi 20 karakter (Gorla, Benander, dan Benander, 1990). Semakin kecil cakupan variabel, semakin pendek namanya. Tetapi karena semua variabel di ManyChat memiliki cakupan global, ada baiknya menggunakan namespace. Untuk Bulls dan Sapi, saya menggunakan segmen awal dalam bentuk dua huruf kapital SM yang berasal dari Bulls dan Sapi. Diberikan di atas, saya mendapat nama variabel BC Is Victory - Cukup unik dan komprehensif, menurut saya.

KERING, CIUMAN

Gim ini bekerja dan, sepertinya, Anda bisa menghembuskan napas dengan rasa puas. Tetapi kita tahu bahwa langkah selanjutnya adalah peninjauan ulang diri dan refactoring. Dengan analisis yang lebih terperinci, Anda dapat melihat bagaimana menghentikan pemrosesan kata dan kemenangan yang mengarah ke blok yang serupa - pemain meminta beberapa tindakan. Pada saat yang sama, kehilangan, karena alasan yang tidak diketahui, menjalani hidupnya sendiri. Menggabungkan tempat-tempat ini menjadi satu tampaknya menjadi langkah logis untuk menghindari duplikasi, yang pada gilirannya menyebabkan peningkatan konsistensi perilaku dan kemudahan pemeliharaan. Sekarang, jika perubahan diperlukan, Anda perlu membuatnya dalam satu-satunya unit sistem tanpa perubahan pada yang lain, yang menunjukkan bahwa prinsip Jangan mengulangi diri Anda berhasil diterapkan.

Alur dengan KERING

Namun, jangan berhenti di situ. Solusi kompleks sulit dipertahankan. Ketika kesalahan terjadi, itu tidak akan mudah untuk melokalkannya, terutama setelah saat ketika Anda keluar dari konteks. Seseorang yang baru akan membutuhkan banyak energi untuk mencari tahu apa apa. Dan Anda harus membiasakan diri dengan setiap node, agar tidak ketinggalan sesuatu yang penting. Karena itu, ada baiknya menggunakan prinsip Keep it simple, bodoh dan sebarkan semua tindakan yang mungkin ke tempat yang terpisah. Setelah dekomposisi, saya mendapat 5 aliran yang cukup mudah dimengerti. Sebagai bonus yang menyenangkan, refactoring ini memenuhi tanggung jawab Tunggalprinsip. Setiap aliran memiliki satu tanggung jawab dan tanggung jawab ini dirangkum sepenuhnya di dalamnya. Banding adalah ala Black Box, dan berdasarkan sifat masalahnya dapat dilokalisasi lebih cepat.

Aliran KISS-compliant

YAGNI

Dalam salah satu versi otomatisasi pertama, ada prestasi dalam mengirimkan pengingat permainan yang ditinggalkan dan instruksi untuk menerima hadiah oleh para pemenang. Implementasi ide pertama diperumit oleh pembatasan pada bagian dari Facebook - baru-baru ini kondisi untuk mengirim pesan di luar jendela pada 24 jam menjadi lebih sulit. Yang kedua ternyata tidak cukup sepele untuk implementasi oleh kode. Kedua masalah diselesaikan, tetapi jumlah upaya yang dibutuhkan tidak dibenarkan oleh kebutuhan kampanye satu kali. Selain itu, tugas sprint menginjak tumit, jadi diputuskan untuk tidak mengimplementasikan fungsi ini. Dan di sini datang untuk menyelamatkan Anda tidak akan membutuhkannyasebuah prinsip yang bertujuan untuk tidak melakukan fungsi yang berlebihan. Ini adalah situasi normal ketika kondisi berubah dan mati, lebih banyak bagian yang tidak perlu muncul dalam produk. Menghapus blok yang sesuai memfasilitasi pemahaman tentang tujuan aliran dan sekali lagi mengingatkan pentingnya penolakan tepat waktu untuk menambah fungsionalitas baru, yang tidak diperlukan secara langsung.

Pengembang yang berpengalaman tahu bahwa fitur apa pun membutuhkan dukungan terus-menerus, dari refactoring kode hingga memperbarui dokumentasi dan bekerja dengan umpan balik pengguna. Oleh karena itu, penambahan fungsi baru harus selalu dianggap dengan kecurigaan, mengajukan pertanyaan, apakah itu benar-benar diperlukan? Pada akhirnya, pada tahap ini, Anda dapat menghemat banyak sumber daya.

Mari main

Tahapan peninjauan ulang diri dan refactoring dilewati, tidak ada fungsi yang tidak perlu, dan makna semua aliran transparan untuk dipahami. Ini berarti bahwa permainan sudah siap dan sekarang saatnya untuk bersaing untuk mendapatkan hadiah. Menurut ketentuan kompetisi, 10 pemain top yang mencetak poin terbanyak sebelum 22 Mei 2020 akan menerima hadiah dari tim ManyChat.

Sedikit tentang aturannya. Dalam implementasi kami, game ini dirancang untuk satu orang. Bot membuat urutan 4 digit dengan angka yang tidak berulang. Pemain berusaha menebak nomornya. Bot melaporkan sebagai tanggapan atas berapa banyak angka yang ditebak tanpa kebetulan dengan posisi mereka, yaitu, jumlah sapi, dan berapa banyak yang ditebak sampai ke posisi itu, yaitu, jumlah sapi jantan. Hasilnya, skenario permainan mungkin terlihat seperti ini:

Angka 1234 dapat ditebak.
Peserta membuat asumsi pertama: 4321
Mendapat jawaban: 0 sapi jantan dan 4 sapi.
Peserta membuat asumsi kedua: 1678
Dan menerima jawabannya: 1 sapi jantan dan 0 sapi.

Untuk mencoba, ikuti tautan dan ikuti petunjuknya. Biarkan saya mengingatkan Anda bahwa game melewati Facebook Messenger. Kami menawarkan 2 tingkat kesulitan: permainan untuk jumlah gerakan terbatas dan tidak terbatas. Menang dalam yang sulit akan memberi Anda 3 poin, dalam yang sederhana - 2. Kehilangan, terlepas dari level, akan mengambil 1 poin.

Permainan ini diimplementasikan pada tumpukan teknologi standar: Nginx 1.17, PHP 7.4, PostgreSQL 12.1. Jika mau, Anda dapat mengkloning repositori ke server Anda, instal template di halaman ManyChat Anda dan mengatur turnamen Anda sendiri.

temuan

"Semua orang di negara ini perlu belajar bagaimana memprogram pada komputer karena itu mengajarkan Anda untuk berpikir." Saya pikir relevansi pernyataan ini telah lama melampaui batas hanya satu negara. Pemrograman bukanlah karakter rahasia di terminal, sulit untuk dipahami oleh orang yang belum tahu, dan seorang programmer bukan yang dipilih. Pertama-tama, ini adalah cara berpikir dan seperangkat keterampilan untuk memecahkan masalah.

Beralih ke judul artikel dan slogan asli, saya ingin mengulanginya: “Pemrograman adalah milik rakyat. Ia harus memiliki akar terdalamnya di kedalaman massa pekerja yang luas. Itu harus dipahami oleh massa ini dan dicintai oleh mereka. "

Saya tidak akan pernah berpikir bahwa dalam satu artikel saya akan mengutip Steve Jobs dan Lenin.

Saya yakin bahwa pikiran yang disajikan di sini datang ke pikiran saya tidak hanya kepada saya. Beberapa bahkan akan menganggap mereka kapten. Tetapi saya tahu sendiri bahwa kadang-kadang Anda perlu mendengar informasi yang sama beberapa kali untuk mulai menggunakannya. Prinsip dangkal adalah menyederhanakan hal-hal sesederhana yang terlihat. Setiap programmer tahu bahwa kode proyek dengan cepat dan mudah keluar dari tangan jika tidak diperhatikan. Tetapi kadang-kadang Anda harus mengingatkan diri sendiri tentang hal ini lagi.

Sesuatu tidak menyala sama sekali. Misalnya, teknik pemrograman ekstrem seperti pemrograman pasangan, rilis kecil yang sering, dan permainan penjadwalan tidak dibahas dalam artikel ini. Meskipun metodologi yang fleksibel memiliki akar yang sama dengan sistem untuk mengatur produksi fisik offline, mereka masih sering digunakan untuk pengembangan perangkat lunak. Meskipun potensi mereka tidak terbatas pada industri.

Mungkin ada sesuatu yang tidak pernah saya pikirkan. Kita masing-masing memiliki pengalaman dan visinya sendiri. Karena itu, saya mendorong Anda untuk membagikan pemikiran Anda tentang hal ini dalam komentar.

Pemrograman ke massa