Praktik dan alat terbaik proyek iOS

Dengan templat proyek Xcode sumber terbuka

Ketika bekerja pada proyek iOS greenfield, saya sering harus memulai proyek baru dari awal. Sambil melakukan itu, saya dan tim saya selalu menghabiskan banyak waktu untuk pengaturan proyek dasar seperti mengintegrasikan alat, mengatur struktur proyek, menulis kelas dasar, mengintegrasikan perpustakaan eksternal dll.

Saya memutuskan bahwa waktu yang dihabiskan untuk memulai proyek dapat dihemat dan prosesnya sebagian besar otomatis. Saya menuliskan semua praktik dan alat terbaik yang biasa kami gunakan dan menyiapkan templat proyek yang dapat saya dan tim saya gunakan saat memulai proyek baru. Kerangka ini harus menghemat waktu penyiapan proyek dan juga menyediakan landasan bersama yang akan digunakan oleh setiap anggota tim sehingga Anda tidak perlu berpikir dan menjelajahi struktur dan yayasan proyek. Mereka akan selalu sama.

Masing-masing dan setiap alat atau praktik terbaik yang termasuk dalam templat layak mendapat artikelnya sendiri tetapi saya ingin mencoba dan merangkum setiap poin dan memberikan penjelasan singkat mengapa saya memasukkannya.

Cocoapods

Saya tidak berpikir ini membutuhkan pengantar. Ini adalah perpustakaan untuk mengelola dependensi eksternal untuk proyek iOS. Sudah ada sejak lama dan kuat dan pertempuran diuji dalam ribuan (jika tidak jutaan) proyek. Ada manajer dependensi alternatif di luar sana seperti Carthage tetapi saya memutuskan untuk pergi dengan Cocoapods karena ia memiliki jangkauan proyek open source terluas yang didukungnya. Menggunakan Cocoapods sangat mudah dan dilengkapi dengan indeks pencarian yang memungkinkan Anda dengan mudah menemukan paket yang mungkin Anda butuhkan.

Proyek template dilengkapi dengan Podfile sederhana yang mencakup Swiftlint dan R.swift. Template juga menyertakan Gemfile untuk mengelola versi Cocoapods yang digunakan untuk menyelesaikan dependensi. Ini adalah peningkatan yang sering diabaikan yang mencegah timbulnya masalah ketika pengembang di tim Anda menginstal dependensi menggunakan versi berbeda dari Cocoapods itu sendiri. Gemfile memberlakukan menggunakan versi Cocoapods yang sama di seluruh tim.

Swiftlint

Swiftlint adalah alat yang sangat berguna untuk menegakkan aturan dan gaya pengkodean tertentu untuk setiap programmer dalam tim. Anda dapat menganggapnya sebagai sistem peninjauan kode otomatis yang memperingatkan programmer tentang hal-hal berbahaya seperti pembongkaran paksa, gips gaya, percobaan paksa dll. Tetapi juga menerapkan gaya pengkodean umum dengan memastikan semua pemrogram mengikuti aturan terkait "gaya kode" yang sama seperti lekukan atau aturan spasi. Ini memiliki manfaat luar biasa tidak hanya menghemat waktu peninjauan kode dengan melakukan pemeriksaan dasar itu, tetapi juga membuat semua file dalam proyek terlihat akrab yang meningkatkan keterbacaan mereka dan sebagai hasilnya pemahaman mereka oleh semua pengembang. Anda dapat menemukan daftar semua aturan di sini. Di dalam templat, Swiftlint diinstal melalui Cocoapods dan dimasukkan dalam langkah Build Phases sehingga lints dan memperingatkan pengembang di setiap pembangunan proyek.

R. cepat

R.swift adalah alat untuk mendapatkan sumber daya autocomplete yang sangat diketik seperti gambar, font font dan pelokalan. Ini dilakukan dengan memindai proyek Anda dan menghasilkan kelas cepat yang diperlukan untuk mendapatkan sumber daya. Titik penjualan terbesar dari perpustakaan ini adalah bahwa saat menggunakan sumber daya, ia membuat kode Anda:

  • Sepenuhnya diketik - kurang casting dan menebak metode apa yang akan kembali
  • Waktu kompilasi dicentang - tidak ada lagi string yang salah yang membuat aplikasi Anda mogok saat runtime
  • Selesai otomatis - tidak perlu menebak nama gambar / nib / storyboard itu lagi

Pertimbangkan kode berikut menggunakan API string resmi:

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

Jika Anda salah mengeja nama gambar, Anda akan mendapat nol di sini. Jika ada anggota tim Anda yang mengubah nama sumber daya gambar, kode ini akan mengembalikan nihil atau akan macet jika Anda memaksa membuka gambar. Saat menggunakan R.swift, ini menjadi:

biarkan ikon = R.image.customIcon ()

Sekarang Anda dapat yakin bahwa ikon tersebut benar-benar ada (kompiler akan memperingatkan Anda jika tidak berkat kompilasi waktu) dan Anda yakin Anda tidak akan membuat kesalahan ketik pada nama ikon karena Anda akan menggunakan pelengkapan otomatis.

R.swift diinstal melalui Cocoapods dan terintegrasi dalam templat sebagai Build Phase dan akan menghasilkan kelas pembungkus Swift pada setiap build. Itu berarti jika Anda menambahkan file / gambar / lokalisasi / font / warna / nib dll. Itu akan tersedia untuk Anda menggunakan R.swift setelah Anda mengkompilasi proyek.

Pisahkan AppDelegate untuk pengujian

Praktik baik yang sering diabaikan adalah memiliki kelas TestAppDelegate yang terpisah saat menjalankan tes. Mengapa itu ide yang bagus? Yah, biasanya kelas AppDelegate melakukan banyak pekerjaan saat startup aplikasi. Itu bisa mengatur jendela, membangun struktur UI dasar aplikasi, mendaftar untuk pemberitahuan, mengatur database dan bahkan kadang-kadang membuat panggilan API ke beberapa layanan backend. Tes unit tidak boleh memiliki efek samping. Apakah Anda benar-benar tidak ingin membuat panggilan api acak dan mengatur semua struktur UI aplikasi Anda hanya untuk menjalankan beberapa tes unit?

TestAppDelegate juga merupakan tempat yang tepat untuk memiliki kode yang hanya ingin Anda jalankan sekali selama eksekusi suite pengujian Anda. Itu bisa berisi kode yang menghasilkan tiruan, bertopik permintaan jaringan dll.

Template berisi file main.swift yang merupakan titik masuk utama untuk aplikasi. File ini memiliki metode yang memeriksa apa lingkungan aplikasi saat ini berjalan dan jika itu lingkungan pengujian, memanggil TestAppDelegate.

Bendera profil kinerja penyusun

Swift adalah bahasa yang hebat, lebih mudah digunakan dan jauh lebih aman daripada Objective-C (IMO). Tetapi ketika pertama kali diperkenalkan itu memiliki satu kelemahan besar - waktu kompilasi. Kembali di Swift 2 hari, saya sedang mengerjakan sebuah proyek yang sebelumnya memiliki 40k baris kode Swift (proyek berukuran sedang). Kode itu sangat berat dengan generik dan inferensi tipe dan butuh hampir 5 menit untuk mengkompilasi build yang bersih. Ketika Anda membuat perubahan kecil, proyek akan mengkompilasi ulang dan memakan waktu sekitar 2 menit untuk melihat perubahan tersebut. Itu adalah salah satu pengalaman pengembang terburuk yang pernah saya miliki dan saya hampir berhenti menggunakan Swift karenanya.

Satu-satunya solusi saat itu, adalah mencoba dan membuat profil waktu kompilasi proyek dan mencoba mengubah kode Anda sedemikian rupa, yang akan membuat kompiler lebih cepat. Untuk membantu ini, Apple memperkenalkan beberapa flag kompiler tidak resmi yang akan memperingatkan Anda saat mengkompilasi sebuah metode atau menyelesaikan jenis ekspresi yang terlalu lama. Saya menambahkan bendera-bendera itu ke proyek templat sehingga Anda akan diperingatkan sejak awal tentang waktu kompilasi yang lama untuk aplikasi Anda.

Saat ini waktu pembuatan telah ditingkatkan secara dramatis dan Anda sangat jarang perlu mengubah kode Anda hanya untuk meningkatkan waktu pembuatan. Tetapi tetap lebih baik untuk mengetahui di muka daripada mencoba untuk memperbaiki masalah ketika proyek menjadi terlalu besar.

Konfigurasi Dev / Staging / Produksi

Praktik baik lainnya (atau boleh saya katakan perlunya) adalah memiliki konfigurasi dan variabel lingkungan yang terpisah untuk lingkungan pengembangan, pementasan dan produksi. Hampir setiap aplikasi saat ini harus terhubung ke beberapa jenis layanan backend dan biasanya, layanan tersebut digunakan pada berbagai lingkungan. Lingkungan pengembangan digunakan untuk penyebaran harian dan untuk pengembang untuk menguji kode mereka. Lingkungan pementasan digunakan untuk rilis yang stabil bagi penguji dan klien untuk diuji. Kita semua tahu untuk apa lingkungan produksi.

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

Konfigurasi tingkat proyek

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

Configuration.plist

Saat menjalankan proyek, Anda dapat menentukan konfigurasi mana yang harus digunakan. Anda dapat melakukan ini dalam skema bangun.

Anda kemudian perlu menambahkan satu properti tambahan di file proyek Info.plist. Nilai properti ini akan diselesaikan secara dinamis pada saat runtime dengan nama konfigurasi saat ini.

Ini semua sudah dikonfigurasikan untuk Anda dalam template.

Satu-satunya yang tersisa adalah menulis kelas yang dapat mengambil variabel-variabel tersebut pada saat runtime tergantung pada konfigurasi yang dipilih dalam skema build. Templat berisi kelas ConfigurationManager yang dapat mengambil variabel untuk lingkungan saat ini. Anda dapat memeriksa implementasi kelas itu di Github untuk melihat cara kerjanya.

Baca aku

Setiap proyek harus memiliki Readme dasar yang setidaknya memiliki instruksi cara menginstal dependensi dan menjalankan proyek. Ini juga harus berisi deskripsi arsitektur dan modul proyek. Sayangnya pengembang tidak suka menulis dokumentasi (readme adalah bagian dari itu) dan saya telah melihat proyek yang sedang dikembangkan selama berbulan-bulan dan mereka bahkan memiliki Readme dasar. Untuk menghilangkan beban penulisan readme dasar ini, template berisi readme standar yang mencakup instalasi dan struktur proyek. Ketika Anda mengatur proyek baru menggunakan templat, Anda akan memiliki Readme disertakan secara otomatis.

Gitignore

Saat ini, sebagian besar proyek menggunakan GIT sebagai sistem kontrol versinya. Saat menggunakan GIT, Anda biasanya tidak akan mengabaikan beberapa file atau folder dalam proyek seperti folder build atau folder data yang diturunkan. Untuk menyelamatkan Anda dari kesulitan mencari file gitignore yang sesuai dengan proyek iOS Anda, templat menyertakan gitignore standar yang disediakan oleh kontributor Github.

Kelas dasar untuk menangani tautan dalam dan pemberitahuan

Hampir setiap aplikasi saat ini harus menangani deeplink dan notifikasi. Untuk melakukan ini, pengembang harus menulis sejumlah kode boilerplate di kelas AppDelegate. Template memiliki yang tercakup dan juga menyediakan kelas dasar yang mempermudah pengerjaan tautan dalam dan notifikasi.

Ringkasan

Singkatnya, templat mencoba memasukkan praktik terbaik dan mengintegrasikan alat pihak ketiga yang berguna. Ini akan menghemat waktu Anda dan tim kami yang dihabiskan untuk pengaturan proyek baru dan juga memberikan fondasi yang umum dan kuat untuk sisa proyek. Semoga bermanfaat bagi Anda!

PS: Jika Anda memiliki masalah atau permintaan fitur untuk templat, tinggalkan saya masalah di Github. Saya akan mencoba menyelesaikannya di waktu luang saya.