Dalam kehidupan hampir semua tim pengembang, ada saatnya ketika penciptaan kerangka kerja kita sendiri bergerak dari status "Apa yang harus kita buang waktu?" ke status "Ide keren!". Kami memiliki momen seperti itu sekitar dua bulan lalu, ketika kami mulai mengacaukan aplikasi klien PSB Mobile dari PSB Mobile, fungsi kontrol suara transfer menggunakan Siri. Kami menganalisis pengalaman kami dan atas dasar itu kami akan memberi tahu Anda bagaimana memahami bahwa waktu untuk kerangka kerja telah tiba.
"Kerangka kerja apa, apa yang kamu bicarakan?"
Sebelumnya, klien iOS bank untuk individu dikembangkan outsourcing. Kemudian diputuskan untuk menulis ulang semuanya sendiri dari awal. Kami membangun proses SCRUM dengan sprint dua minggu, pekerjaan mulai mendidih - kami secara aktif mencari dan menambahkan fitur baru, chip. Pada tahap pencarian aktif ini, sulit untuk memprediksi apa yang akan berakar, apa yang tidak. Merencanakan semuanya 40 langkah di depan tidak masuk akal. Tidak ada yang memikirkan embel-embel seperti universalitas - buat kerangka kerja Anda sendiri, alokasikan bagian kode ke pustaka terpisah untuk digunakan kembali. Kemungkinan ini tidak masuk akal terlalu tinggi.
WWDC menghubungkan kami
Mengapa SCRUM baik - kami sering menghubungi bisnis sebagai pelanggan. Pada saat yang sama, perubahan penting mulai terjadi. Kami mulai lebih memahami produk, tugas bisnis, proses bisnis bank tempat aplikasi terlibat. Dan yang paling penting, bisnis, untuk bagiannya, mulai mempertimbangkan pengembangan aplikasi sebagai proses, mulai lebih memahami bagaimana kami bekerja, mulai setuju dengan kami bahwa ada tugas penting, solusi yang tidak menghasilkan efek sesaat yang nyata.
Itu membantu kami bergaul dengan bisnis ... konferensi WWDC. Pelanggan bisnis kami entah bagaimana menyaksikan pengumuman peluang apel baru dan naik ke Pengembang Apple dengan rasa ingin tahu. Anehnya, semuanya ternyata jauh lebih jelas di sana daripada yang diharapkan. Sejak itu, tidak hanya kita terlibat dalam tugas-tugas bisnis, tetapi bisnis tidak lagi takut pada teknologi: mereka mencoba membaca spesifikasi sendiri, mendapatkan wawasan tentang masalah, membantu dengan analitik, dan masuk ke masalah pembangunan. Mereka mulai menyadari bahwa tidak ada gunanya menunggu peningkatan yang jelas dalam produk setiap dua minggu - setelah semua, ada sprint layanan, dari mana tidak ada pertumbuhan konkret. Saling pengertian mencapai titik bahwa kami setuju untuk memberikan refactoring 20% dari waktu sprint.
Evolusi sepeda
Dengan pertumbuhan departemen pengembangan, pengisian aplikasi dengan fitur-fitur baru, penampilan beberapa tim yang bekerja secara bersamaan pada tugas yang berbeda, nuansa baru mulai muncul. Beberapa subtugas untuk tim bisa serupa, dan segera ada keinginan untuk tidak menemukan kembali roda, tetapi pertama-tama untuk memperjelas apakah ada yang punya kode yang sudah jadi.
Biasanya tidak ada keluhan tentang kode dari pengembang kami, sehingga dapat digunakan berulang kali - dan tidak hanya dalam kerangka metodologi penggunaan kembali kode yang biasa. Mungkin, sudah pada tahap ini di kepala kita muncul ide untuk memisahkan beberapa hal menjadi perpustakaan yang terpisah untuk kebaikan bersama. Tetapi dalam kerangka tugas yang ada, tidak mungkin menemukan waktu untuk proses ini. Perlu beberapa alasan, dan segera bisnis itu melemparkannya kepada kami.
Ekstensi pemicu
Ada tugas untuk membuat dukungan untuk antarmuka suara - sehingga Anda dapat melakukan pembayaran ke pelanggan lain dari bank melalui Siri melalui nomor telepon. Dia berkata: "Transfer begitu banyak uang ke orang seperti itu." Dan jika orang ini adalah klien Promsvyazbank, maka kartu orang tersebut muncul di layar, jumlah transfer, pertanyaan "kirim uang?" dan kirim tombol. Fungsi serupa sudah ada di beberapa aplikasi perbankan, tetapi kami ingin membuatnya sehingga, di satu sisi, itu aman, dan di sisi lain, klien tidak perlu masuk ke aplikasi bank.
Bekerja dengan Siri melibatkan penulisan ekstensi terpisah, dan ketika kami mulai merencanakannya, kami menyadari bahwa sudah waktunya untuk mengembangkan kerangka kerja kami sendiri. Dalam proyek aplikasi kami, lapisan jaringan diimplementasikan, dan pilihan muncul (sebenarnya tidak): tulis lapisan ini lagi atau letakkan di wadah yang terpisah, tersedia baik di aplikasi utama dan dalam ekstensi terpisah.
Dalam prosesnya, subtugas arsitektur muncul untuk mengambil bagian dari kode dalam kerangka kerja terpisah. Total ada empat:
- Lapisan jaringan (tengah) - ini semua pekerjaan dengan jaringan, kelas model, layanan API. Lapisan ini sepenuhnya dihasilkan secara otomatis.
- Login
- Utilitas - Utilitas dan Pembantu
- Penyimpanan - Penyimpanan Aman
Jelas bahwa ini bukan keahlian kami. Jadi sudah lazim dilakukan dalam situasi seperti ini, ini adalah praktik terbaik dari semua pengembang yang menghargai diri sendiri. Tetapi penting bagaimana kita sampai pada hal ini. Pada saat inilah
tiga tanda kunci datang bersama untuk menciptakan kerangka kerja:
- Kami telah mengembangkan basis kode yang memadai
- Bisnis mulai memahami kebutuhan arsitektur (yakni,) kami.
- Tugas yang sesuai telah muncul
Cakrawala baru
Setelah menyadari semuanya ternyata sederhana. Pada pertemuan pengembang berikutnya, kami membahas detailnya, memilih
korban dari orang yang bertanggung jawab yang akan terlibat dalam refactoring utama, mengalokasikannya waktu - waktu penuh untuk tugas ini. Sisa pengembang itu hampir tidak mempengaruhi. Tetapi ketika kami mulai meletakkan lapisan jaringan dalam kerangka kerja, muncul ide-ide yang mana bagian kode yang sering digunakan lainnya harus dimasukkan ke dalam perpustakaan. Kemungkinan arsitektur kami tiba-tiba berkembang. Kami memulai hidup dengan tingkat kebebasan tambahan.
Tapi kami menggunakannya tanpa fanatisme. Untuk memutuskan apakah akan membuat kode kode dalam modul yang terpisah atau tidak, kami melihat backlog dan menentukan apakah modul ini akan digunakan kembali di beberapa tempat. Jika tidak, maka jangan repot-repot.
Apakah kita melihat manfaat menggunakan kerangka kerja kita? Jelas ya. Sekarang kita melihat bagian mana dari kode yang diperlukan sebagai bagian dari tugas baru yang sudah ada di repositori. Pengembangan layanan baru lebih cepat, kesalahan pemrograman lebih sedikit, kualitas layanan akhir lebih tinggi.
Jika Anda memerlukan ekstensi baru untuk iOS, kami sudah memiliki kerangka kerja yang diperlukan, Anda dapat segera bereksperimen. Adapun layanan yang sudah diterapkan dengan Siri, telah tersedia untuk pengguna bank selama lebih dari sebulan - sekarang kami sedang mengumpulkan ulasan, termasuk untuk memahami bagaimana dan untuk apa lagi menggunakan antarmuka suara.
Sedikit futurologi
Kisah dengan Siri membuat kami berpikir tidak hanya tentang kerangka kerja, tetapi tentang antarmuka secara umum. Manusia belum belajar mengukur konsentrasi perhatian, hanya entah bagaimana secara tidak langsung. Misalnya, semakin buruk UX dan UI, semakin besar pemborosan perhatian, semakin banyak corong konversi yang menyempit pada setiap langkah. Transfer uang reguler melalui aplikasi bank memerlukan banyak tindakan dari pengguna: buka aplikasi, masuk, cari dalam satu daftar, di kedua, masukkan penerima. Dengan Siri, ini adalah membuka kunci ditambah perintah suara. Otorisasi terjadi di latar depan melalui ID Wajah. Dan dalam beberapa skenario, Anda bahkan tidak perlu membawa telepon kepada Anda. Misalnya, ketika Anda mengemudi, dan ponsel dipasang di dekatnya, kamera dapat dengan mudah mengenali Anda.
Lihatlah ke sekeliling: asisten suara mulai secara aktif menaklukkan ruang di sekitarnya. Hype di sekitar speaker pintar Yandex, mesin cuci yang berbicara dan memahami perintah, remote TV yang mengenali suara. Semakin banyak pengguna akan dikelilingi oleh antarmuka suara, semakin mereka akan siap untuk berkomunikasi dengan aplikasi perbankan.
Antarmuka grafis dalam situasi ini akan kehilangan monopoli mereka, dari alat komunikasi utama mereka hanya akan berubah menjadi konfirmasi visual tindakan, menjadi cara untuk memberi sinyal bahwa komputer memahami Anda dengan benar.
Bagi pengembang, perubahan semacam itu, pada prinsipnya, tidak menakutkan. Dengan arsitektur yang tepat, aplikasi dapat memiliki sejumlah antarmuka: visual, suara, neuro. Hal utama adalah menggunakan pendekatan yang sesuai dengan tingkat kematangan tim saat ini.