Get best of the week

Apa yang saya pelajari saat mengerjakan proyek skala besar pertama saya

Delapan bulan yang lalu, saya mulai menulis aplikasi di Electron. Untuk menguasai tugas ini, saya harus mengembangkan tiga sub-aplikasi terpisah yang berjalan di lingkungan yang berbeda. Di bawah ini saya akan berbicara tentang apa yang saya buat untuk diri saya sendiri di sepanjang jalan.



Binder dalam bentuk aslinya

Konteks


Sebelum mempelajari rinciannya, saya akan mulai dengan memberikan beberapa informasi umum yang diperlukan untuk memahami situasi. Pada awal 2019, saya mulai mencari magang, seperti yang diminta oleh program koperasi untuk gelar saya. Pada bulan April, saya mengirimkan lusinan resume, yang masing-masing dirancang untuk perusahaan tertentu, dan secara total menerima nol jawaban. Anda dapat membayangkan bagaimana saya bereaksi terhadap ini - tangan saya jatuh, sepertinya saya tidak cocok untuk apa pun dan tidak layak bekerja sama sekali. Tetapi alih-alih membiarkan perasaan ini menang, saya memutuskan untuk membuktikan kepada diri sendiri bahwa saya masih tahu sesuatu dan saya dapat melamar untuk beberapa posting. Pada akhirnya, saya menemukan bahwa sebenarnya saya tahu kurang dari yang saya harapkan.

Saya mulai merevisi proyek-proyek saya untuk mencari proyek yang dapat diubah menjadi sesuatu yang berskala besar dan kompleks, yang dapat memacu saya. Akhirnya, saya memilih untuk Binder - pada waktu itu aplikasi web sederhana yang memungkinkan Anda untuk mengelola file dari Onedrive, Google Drive dan Dropbox pada saat yang bersamaan. Tujuannya adalah untuk mengembangkan layanan cadangan yang sebanding dengan fungsionalitas pada trinitas ini, dikurangi kemampuan untuk mentransfer file ke pengguna lain.

Awal jalan


Mungkin, saya tidak akan menyelesaikan proyek sama sekali jika saya tidak menetapkan sendiri beberapa tujuan delusi sejak awal. Tonggak pertama yang saya tentukan untuk diri saya sendiri adalah penciptaan versi alpha yang berfungsi untuk ulang tahun saya, yang saya rayakan pada pertengahan Juli. Saya mulai bekerja segera. Pada awal Mei, saya membuat klon Binder dan mulai membongkar menjadi beberapa bagian, membuang banyak fungsi yang tidak lagi saya butuhkan. Secara umum, saya mengambil aplikasi yang benar-benar layak dan mengubahnya menjadi sepotong kode di suatu tempat di tingkat tutorial.

Saya memutuskan bahwa saya akan menulis empat aplikasi terpisah. Yang pertama adalah klien yang secara alami akan bekerja di komputer pengguna. Yang kedua adalah API dengan backend, itu akan memfasilitasi pengiriman permintaan yang aman. Ketiga, layanan cloud, yang bertanggung jawab atas integritas semua data yang disimpan di dalamnya. Dan akhirnya, halaman web "pemasaran", karena suatu produk tidak dapat melakukannya tanpa situs web yang berkilauan.

Dan sekarang kesenangan dimulai


Yah, well, well, saya akui: semua yang saya katakan sejauh ini tidak ada hubungannya dengan Electron, apalagi pengembangan aplikasi skala besar. Tetapi saya perlu mengklarifikasi konteksnya sehingga Anda mengerti dari mana saya memperoleh pengetahuan saya. Berikut adalah lima pelajaran utama yang saya pelajari untuk diri saya sendiri:

# 1 Pastikan untuk menggunakan struktur tradisional untuk frontend dan backend, karena komunikasi antarproses adalah hal yang bodoh

Lebih sering daripada yang saya inginkan, saya panik karena bagaimana komunikasi antar proses primitif diimplementasikan dalam Electron (dan sekarang lagi ke psiko). Ya, komunikasi antarproses sama sekali tidak dirancang untuk melakukan abstraksi data dalam semangat Javascript, dengan representasi fungsi sebagai objek dan sebagainya. Tapi betapa mudahnya itu! Jadi, alih-alih membuat aplikasi klien minimalis, sementara array kode utama akan ditempatkan dalam proses utama, saya terpaksa memisahkan dengan jelas apa yang akan berinteraksi dengan pengguna dan apa yang tidak. Kriteria yang dengannya saya menentukan apa yang akan masuk ke proses utama dan apa ke dalam proses render dirumuskan sebagai pertanyaan sederhana: apakah kode ini melayani sesuatu? Ukuran fragmen tidak masalah. Jika dia menyajikan potongan kode lainnya,kemudian pergi ke proses utama. Satu-satunya pengecualian adalah titik akhir dari sistem pembayaran Stripe - untuk alasan keamanan, saya ingin lokasinya sedekat mungkin dengan pengguna.

2 Membuat integritas data sangat, sangat sulit,

sampai saya mulai bekerja pada Binder, saya tidak mengerti betapa sulitnya mendapatkan semua data yang berasal dari jumlah pengguna yang sewenang-wenang dan mengesankan untuk selalu tetap benar dan dapat diakses. Dan hanya untuk menyediakan penyimpanan yang aman bagi mereka bukanlah tugas yang mudah, tetapi sekarang Anda masih ingin saya memvalidasi semua ini dan memastikan bahwa tidak ada kontradiksi dengan data lain, tanpa tahu apa data itu ?!

Tentu saja, saya sedikit melebih-lebihkan di sini, tetapi esensi masalahnya tidak menyimpang. Validasi harus dilakukan sedini mungkin pada tahap paling awal dan kemudian diulangi (pada skala yang lebih sederhana) ketika aliran data meningkat. Mempertahankan konsistensi menjadi lebih mudah jika Anda menggunakan model transaksional setiap kali Anda mengubah data. Sejujurnya, bersama dengan data aktual ada juga banyak metadata, yang tidak mudah dikelola. Tampaknya selalu merupakan ide bagus untuk menulis fungsi yang membaca data pengguna dan kemudian melakukan pemeriksaan integritas. Tetapi setelah berpikir panjang, saya sampai pada kesimpulan bahwa pintu masuk rahasia tidak berbeda dari pintu depan - perbedaan keseluruhan adalah siapa yang menggunakannya.

No. 3 Antarmuka - seperti sepatu yang dijahit sesuai pesanan



Cara yang bagus untuk membuat antarmuka yang indah dan berfungsi dengan baik adalah melihatnya sebagai sepasang sepatu khusus (atau setelan yang disesuaikan dengan bentuknya, itu tidak masalah). Pertanyaan pertama yang saya tanyakan pada diri sendiri ketika saya mulai mendesain untuk Binder: siapa yang akan melihat antarmuka aplikasi? Catatan: Saya tidak berbicara tentang siapa yang akan menggunakan antarmuka. Ini harus menjadi pertanyaan kedua, karena semuanya terkait dengan penampilan. Di masa lalu, saya melakukan banyak proyek dan saya dapat memberi tahu Anda dengan penuh keyakinan: orang-orang ingin meludahi aplikasi Anda jika tidak terlihat seperti seharusnya.



Saya mulai dengan membuat sketsa kecil di buku catatan (dengan bolpoin, karena saya memiliki kebiasaan meragukan ide-ide saya). Dalam draft pertama, penekanannya adalah pada struktur umum antarmuka, dan hanya kemudian, menggambar lebih jauh, saya merinci secara rinci bagaimana masing-masing "halaman" seharusnya terlihat. Menurut pendapat saya, informasi yang disajikan tidak begitu penting seperti keterbacaannya.

No. 4 Tidak ada banyak toleransi kesalahan

Saya tidak tahu tentang Anda, tetapi saya dari pemikiran bahwa API akan macet setelah saya menerima pembayaran, keringat dingin menerobos. Mulai bekerja pada sistem pembayaran, saya berkata pada diri sendiri: "Sekarang Anda tidak dapat melewatkan satu kesalahan pun." Saya memastikan untuk menerapkan mekanisme keamanan selama proses: dari saat API menerima permintaan untuk membeli paket layanan, dan sampai Stripe mengirimkan informasi pembayaran ke sistem pemberitahuan acara dan paket diaktifkan. Paranoia semacam ini, tentu saja, memperlambat proses pengembangan, tetapi saya tidak menyesali apa pun. Tetapi saya selalu memiliki informasi lengkap tentang kapan pembayaran tiba, apa tujuannya dan apa status tindakan yang harus mengikutinya.

No. 5 Tidak sempurna? Tidak menakutkan

Saya seorang perfeksionis, dan upaya saya untuk membuat sesuatu yang menakjubkan sering keluar dari tangan dan mengubah nitpicking tanpa akhir ke setiap baris kode dan meragukan apakah mereka memiliki hak untuk hidup. Saya harus terus bertengkar dengan diri saya sendiri tentang apa yang masih lebih penting - efisiensi atau keterbacaan. Dalam beberapa bulan pertama, saya belum menerima penglihatan saya dan tidak mengerti bahwa banyak dari apa yang saya buang energi saya tidak memiliki manfaat praktis - intinya adalah membuat produk yang dapat digunakan dengan pikiran tenang, dan tidak sakit untuk beberapa penghargaan bergengsi. Sangat lucu bahwa pelajaran kelima saya sebagian bertentangan dengan yang keempat, tetapi bahkan bagus. Pelajaran keempat mengingatkan saya akan kehati-hatian dan perhatian pada harapan pengguna, dan yang kelima menetapkan batas-batas sehingga saya tidak terjebak,meningkatkan satu fungsi tanpa henti.

Sebelum kita mengucapkan selamat tinggal


Anda membaca artikel saya sampai akhir dan Anda mungkin telah memperhatikan (baik, atau tidak) bahwa Binder belum sepenuhnya beroperasi. Pada saat penulisan, saya baru saja merilis versi publik pertama (beta 4). Saya tidak terlalu cenderung mengubah Binder menjadi produk yang lengkap, tetapi tetap mengembangkannya sehingga berfungsi sebagai aplikasi normal - semua ambisi yang tiba-tiba akan mengambil alih dari saya. Halaman web berwarna-warni dapat dikagumi di sini .

Semua yang saya pikir aman untuk akses terbuka diposting di halaman proyek di GitHub. Di sana saya akan memposting pembaruan (dan di sana Anda dapat mengunduh klien sehingga pembaruan itu sendiri). Ah, well, ini adalah statistik yang saya kompilasi pada empat sub-aplikasi untuk menyanjung kesombongan saya:

binder-local (klien pada Electron)



binder-web (halaman web cantik)



Di dua sisanya, saya tidak mulai menghitung baris kode secara otomatis untuk alasan keamanan.

pengikat api

  • JavaScript: 21 file, 4117 baris
  • File lain: ~ 150 baris

binder-mongo (layanan untuk memeriksa integritas)

  • JavaScript: 16 file, 2374 baris
  • File lain: ~ 140 baris

Total jumlah baris kode: 30.015

More articles:


All Articles