Praktik dan alat terbaik untuk mengembangkan aplikasi iOS

Ketika mengembangkan aplikasi seluler, saya harus membuat proyek dari awal lebih dari sekali. Pada saat yang sama, tim saya dan saya selalu menghabiskan banyak waktu untuk pengaturan dasar proyek, seperti mengintegrasikan alat pihak ketiga, menyiapkan struktur proyek, menulis kelas dasar, mengintegrasikan perpustakaan eksternal, dll.

Saya memutuskan bahwa waktu yang dibutuhkan untuk meluncurkan proyek dapat dikurangi, dan bagian utama dari proses dapat otomatis. Pada saat yang sama, saya mengumpulkan praktik terbaik dan alat yang kami gunakan, dan menyiapkan templat proyek yang kami gunakan saat memulai proyek baru. Template seperti itu akan menghemat waktu pengembang untuk mengonfigurasi proyek baru, serta menyediakan struktur proyek bersama, yang akan digunakan oleh setiap anggota tim, sehingga Anda tidak lagi harus berpikir dan mempelajari struktur proyek baru untuknya. Sekarang selalu sama.

Setiap alat atau pendekatan yang ditambahkan ke templat layak mendapatkan artikel terpisah, tetapi saya ingin mencoba merangkum setiap paragraf dan memberikan penjelasan singkat mengapa saya memasukkannya ke dalam artikel ini.

Cocoapods

Saya tidak berpikir Cocoapods membutuhkan pengiriman. Ini adalah perpustakaan untuk mengelola dependensi eksternal untuk proyek iOS. Sudah ada sejak lama dan dapat diandalkan dan terbukti di lapangan dalam ribuan (jika tidak jutaan) proyek. Ada juga manajer dependensi alternatif, misalnya: Carthage , tetapi saya memutuskan untuk melanjutkan dengan Cocoapods, karena ia memiliki jangkauan terluas dari proyek open source yang didukung. Menggunakan Cocoapods sangat sederhana dan dilengkapi dengan indeks pencarian yang membuatnya mudah untuk menemukan paket yang dapat berguna kapan saja.

Proyek templat disediakan dengan Podfile sederhana yang berisi Swiftlint dan R.swift. Templat ini juga menyertakan gemfile untuk mengelola versi Cocoapods yang digunakan untuk manajemen ketergantungan. Solusi ini sering diabaikan oleh pengembang, tetapi mencegah masalah yang terjadi ketika pengembang tim Anda menginstal dependensi menggunakan versi berbeda dari Cocoapods. Gemfile secara paksa menggunakan versi yang sama dari Cocoapods untuk seluruh tim.

Swiftlint

Swiftlint adalah alat yang sangat berguna untuk menegakkan aturan dan gaya penulisan tertentu untuk setiap pengembang di tim yang sama. Sistem ini dapat dianggap sebagai sistem verifikasi kode otomatis yang memperingatkan pengembang tentang saat-saat berbahaya, seperti, misalnya, gips paksa, uji coba paksa, dll., Selain itu, sistem ini menerapkan gaya umum penulisan kode, pemantauan sehingga semua pengembang mengikuti aturan yang sama dengan "gaya kode", misalnya: indentasi atau interval. Pendekatan ini memiliki keuntungan besar, tidak hanya menghemat waktu pada verifikasi kode, tetapi juga membuat file proyek dikenali, yang meningkatkan keterbacaan mereka dan, sebagai hasilnya, pemahaman mereka oleh semua anggota tim pengembangan. Tautan ini menyediakan daftar semua aturan. Dalam template Swiftlint, ia diinstal menggunakan Cocoapods dan termasuk dalam langkah “Tahap Kompilasi”, sehingga ia akan menampilkan peringatan kepada pengembang setiap kali proyek dikompilasi.

R. cepat

R.swift adalah alat untuk memperoleh sumber daya yang sangat diketik secara otomatis, seperti gambar, segmen font, dan pelokalan. Itu melakukan semua tindakan di atas dengan memindai proyek dan membuat kelas yang diperlukan untuk mendapatkan sumber daya. Keuntungan terbesar dari perpustakaan ini adalah ketika menggunakan sumber daya, itu membuat kode program:

• Diketik sepenuhnya - lebih sedikit gips dan asumsi tentang metode mana yang akan dikembalikan
• Waktu kompilasi dicentang - tidak ada lagi garis tidak valid yang menghentikan aplikasi agar tidak berjalan selama eksekusi kode
• Selesai otomatis - tidak perlu menebak nama gambar / nib / storyboard lagi

Pertimbangkan kode berikut menggunakan API string resmi:

let icon = UIImage(named: “custom-icon”) 

Jika Anda membuat kesalahan dalam nama gambar, Anda akan mendapatkan nol. Jika ada anggota tim Anda yang mengubah nama sumber daya gambar, kode ini akan mengembalikan nol atau eksekusi akan dihentikan jika Anda memaksa gambar untuk berkembang. Saat menggunakan R.swift, tampilannya seperti ini:

 let icon = R.image.customIcon() 

Sekarang Anda dapat memastikan bahwa ikon tersebut benar-benar ada (kompiler akan memperingatkan Anda jika tidak, terima kasih atas kompilasi waktu pemeriksaan), dan Anda akan yakin bahwa Anda tidak akan membuat kesalahan ketik atas nama ikon, karena Anda akan menggunakan pelengkapan otomatis.

R.swift diinstal menggunakan Cocoapods dan diintegrasikan ke dalam template di Tahap Kompilasi dan akan menghasilkan kelas-kelas shell Swift untuk setiap kompilasi. Ini berarti bahwa jika Anda menambahkan file / gambar / lokalisasi / font / warna / pena, dll., Semua ini akan tersedia melalui R.swift setelah mengkompilasi proyek.

Pisahkan file AppDelegate untuk pengujian

Sangat sering mereka lupa tentang praktik baik menggunakan kelas TestAppDelegate terpisah saat menjalankan tes. Mengapa ini ide yang bagus? Biasanya, kelas AppDelegate melakukan banyak pekerjaan ketika aplikasi dimulai. Itu dapat memiliki logika konfigurasi jendela, mengkonfigurasi tampilan dasar antarmuka pengguna aplikasi, menjalankan logika pendaftaran untuk menerima pemberitahuan, memiliki kode pengaturan koneksi database, dan bahkan kadang-kadang membuat panggilan API server. Tes unit seharusnya tidak memiliki efek samping. Anda benar-benar tidak ingin membuat panggilan API acak dan menyesuaikan seluruh struktur antarmuka pengguna aplikasi Anda hanya untuk menjalankan tes unit?

TestAppDelegate juga merupakan pilihan yang tepat untuk mendapatkan kode yang ingin Anda jalankan hanya satu kali selama pelaksanaan test suite. Ini mungkin berisi kode yang menghasilkan objek tiruan, selokan permintaan jaringan, dll.

Templat berisi file main.swift, yang merupakan titik masuk utama untuk aplikasi. Ada metode dalam file ini yang menguji lingkungan aplikasi, dan jika itu adalah lingkungan uji, mereka memanggil TestAppDelegate.

Bendera profil kinerja penyusun

Swift adalah bahasa yang hebat, lebih mudah digunakan dan lebih aman daripada Objective-C (IMO). Tetapi ketika pertama kali diperkenalkan, itu memiliki satu waktu kompilasi besar cacat. Kembali pada hari-hari ketika saya sedang mengerjakan sebuah proyek di Swift, yang memiliki sekitar 40 ribu baris kode Swift (proyek berukuran sedang). Kode itu sangat berat, dengan pengaturan dan jenis inferensi, dan menyusun rakitan yang bersih membutuhkan waktu hampir 5 menit. Jika Anda membuat perubahan kecil, proyek ini dikompilasi ulang dan dibutuhkan sekitar 2 menit untuk melihat perubahannya. Ini adalah salah satu pengalaman terburuk yang pernah saya alami, dan karena ini, saya hampir berhenti menggunakan Swift.

Maka satu-satunya solusi adalah mencoba membuat profil waktu kompilasi proyek dan mengubah kode Anda sehingga kompiler bekerja lebih cepat. Untuk membantu memecahkan masalah seperti itu, Apple memperkenalkan beberapa flag kompiler tidak resmi yang memperingatkan pengembang bahwa terlalu lama untuk mengkompilasi body metode atau menentukan jenis ekspresi. Saya menambahkan tanda-tanda ini ke proyek template untuk memperingatkan tentang waktu kompilasi aplikasi Anda yang lama.

Saat ini, waktu kompilasi telah menurun secara signifikan, dan pengembang sangat jarang harus mengoptimalkan kode mereka hanya untuk mengurangi waktu kompilasi. Tetapi tetap lebih baik untuk mengetahui semuanya terlebih dahulu daripada mencoba menyelesaikan masalah ini ketika proyek menjadi terlalu besar.

Konfigurasi Dev / Staging / Produksi

Pendekatan lain yang baik (atau, bisa dikatakan, suatu keharusan) adalah memiliki variabel konfigurasi dan lingkungan yang terpisah untuk lingkungan pengembangan, pengujian akhir, dan penerbitan aplikasi. Saat ini, hampir setiap aplikasi harus bekerja dengan server, dan biasanya server ini digunakan di beberapa lingkungan. Lingkungan pengembangan digunakan untuk penyebaran harian oleh pengembang untuk menguji kode mereka. Lingkungan pengujian akhir digunakan untuk membuat rilis stabil atau untuk pengujian oleh penguji dan pelanggan.

Salah satu cara untuk mendukung beberapa lingkungan dalam proyek iOS adalah dengan menambahkan konfigurasi di tingkat proyek.


Konfigurasi Tingkat Proyek

Setelah menetapkan konfigurasi, Anda dapat membuat file Configuration.plist yang berisi variabel untuk setiap lingkungan.


Configuration.plist

Saat memulai proyek, dimungkinkan untuk menunjukkan konfigurasi mana yang harus digunakan. Anda dapat melakukan ini dalam diagram rakitan.



Maka Anda perlu menambahkan properti lain ke file proyek Info.plist. Nilai properti ini akan secara dinamis diganti pada saat runtime atas nama konfigurasi saat ini.


Semua ini sudah dipra-konfigurasi dalam templat.

Tetap hanya untuk menulis kelas yang dapat mengekstrak variabel-variabel ini pada waktu berjalan, tergantung pada konfigurasi yang dipilih dalam skema perakitan. Templat berisi kelas ConfigurationManager , yang dapat mengambil variabel untuk lingkungan saat ini. Anda juga dapat memeriksa implementasi kelas ini di Github untuk melihat cara kerjanya.

Readme

Setiap proyek harus berisi file Readme, yang setidaknya berisi instruksi untuk menginstal dependensi dan memulai proyek. Ini juga harus berisi deskripsi arsitektur dan modul proyek. Sayangnya, pengembang tidak suka menulis dokumentasi (file readme adalah bagian dari pekerjaan ini), dan saya melihat proyek yang telah dikembangkan selama berbulan-bulan, dan bahkan memiliki file Readme. Untuk menghapus beban penulisan file readme, templat berisi file readme standar yang mencakup instalasi dan struktur proyek. Saat menyiapkan proyek baru menggunakan templat, Anda secara otomatis menyertakan file Readme.

Gitignore

Saat ini, sebagian besar proyek menggunakan GIT sebagai sistem kontrol versi. Saat menggunakan GIT, pengembang tidak ingin mengabaikan beberapa file atau folder dalam proyek, seperti folder build atau folder data yang diturunkan. Untuk menyelamatkan pengembang dari keharusan menemukan file gitignore yang cocok untuk proyek iOS-nya, templat tersebut berisi gitignore standar yang disediakan oleh anggota Github.

Kelas dasar untuk menangani tautan dan pemberitahuan eksternal

Saat ini, hampir setiap aplikasi harus menangani tautan dan pemberitahuan eksternal. Untuk melakukan ini, pengembang harus menulis beberapa kode standar di kelas AppDelegate. Template ini berisi deskripsi tentang bagaimana melakukan ini, itu juga mengandung kelas dasar yang memfasilitasi bekerja dengan tautan dan pemberitahuan eksternal.

Kesimpulan

Untuk meringkas, template yang dijelaskan berisi pendekatan terbaik dan mengintegrasikan alat pihak ketiga yang berguna. Semua ini harus menghemat waktu pengembangan tim Anda untuk menyiapkan proyek baru, serta memberikan fondasi yang umum dan solid untuk sisa proyek. Biarkan templat ini melayani Anda dan tim Anda untuk keuntungan!