Bagi yang berpengalaman, saran kami mungkin tampak jelas. Namun untuk pemula, kami sangat menyarankan membaca. Luangkan waktu untuk menerjemahkan ide-ide ini ke dalam proyek Anda sehingga Anda tidak menghabiskan lebih banyak waktu untuk refactoring tanpa akhir nanti.
Ide serupa dapat diekspresikan di hampir semua area pengembangan, tetapi kami akan membicarakannya menggunakan contoh proyek di React.
Memulai proyek dari awal, Anda memikirkan cara terbaik untuk mengatur semuanya sehingga nantinya tidak akan sangat menyakitkan karena pengerjaan ulang yang tak ada habisnya. Dalam proyek hewan peliharaan pribadi, Anda dapat memagari apa pun yang Anda inginkan - lalu hidup dengannya sendiri. Namun dalam kerja tim, Anda perlu bertindak sedemikian rupa untuk memudahkan rekan kerja memahami esensi dan mendalami detailnya. Itu. Jangan menemukan kembali pendekatan pembangunan - lebih baik tetap berpegang pada praktik yang sudah mapan dan diakui industri.
Pikirkan tentang mengetik
Terlepas dari kebebasan bahasa pengembangan, pengetikan statis sangat berguna pada proyek besar jangka panjang. Jika karena alasan tertentu tidak mungkin menggunakan pengetikan statis pada proyek semacam itu, maka JSDoc pun akan sangat membantu menjaga kualitas kode.
Namun kami tidak akan menyarankan Anda untuk selalu menggunakan pengetikan. Tidak sia-sia bahwa reservasi dibuat di atas untuk proyek-proyek besar, karena mengetik adalah, pertama-tama, membantu tim. Tetapi organisasi dan pemeliharaannya (jenis yang sama berubah sesuai dengan perubahan pada backend) membutuhkan sumber daya tertentu. Dalam proyek kecil jangka pendek di mana 1-2 orang bekerja, investasi ini tidak ada gunanya. Tetapi mereka diperlukan ketika tim besar dan akan berkembang.
Jika penggunaan pengetikan dibenarkan, kami menyarankan Anda untuk membuat jenis sejak awal, jika tidak, Anda harus menghabiskan lebih banyak waktu untuk pekerjaan ini. Meskipun Anda belum memiliki API apa pun dan tidak tahu model datanya, setidaknya buatlah rintisan sehingga jenis generik tidak muncul di mana pun.
Seiring dengan berkembangnya proyek, mengetik harus ditaati, bahkan jika semua tenggat waktu telah habis untuk waktu yang lama. Maka Anda akan berterima kasih pada diri Anda sendiri atas perfeksionisme ini.
Bagilah kode menjadi beberapa blok, sorot logikanya
Kode tidak boleh disatukan. Perlu mempertimbangkan hierarki dalam struktur proyek - memecah kode menjadi modul dan blok, membagi komponen menjadi cerdas dan bodoh. Lebih mudah untuk mempertahankan dan mengembangkan struktur seperti itu daripada mencari partikel logika ini dalam satu tumpukan besar, terutama jika partikel-partikel ini saling berhubungan. Mungkin saran ini tidak hanya berlaku untuk frontend.
Manfaat dari prinsip ini terlihat sangat jelas pada proyek dengan formulir besar, yang kami tulis baru-baru ini ( https://habr.com/ru/company/maxilect/blog/511322/ ). Dalam proyek tersebut, pemeriksaan blok dan visibilitas blok tersebut pada awalnya ditautkan. Tetapi ketika kami mengumpulkan semua komunikasi bidang di satu tempat, itu menjadi lebih mudah untuk melacak perubahan dalam logika. Dan yang terpenting, kami dapat menggunakan kembali kode tersebut dalam proyek baru yang serupa.
Tidak ada standar tunggal untuk struktur proyek - di sini Anda harus mengandalkan pengetahuan Anda. Ada dua pendekatan yang mungkin berhasil untuk banyak proyek: Jenis File Pertama dan Fitur Pertama.
Untuk menemukan titik awal dalam menemukan struktur yang sesuai bagi Anda, kami menyarankan Anda untuk merujuk ke dokumentasi. Praktik terbaik biasanya dijelaskan di sana. Misalnya, React dan Redux dalam dokumentasinya menawarkan standar untuk mengatur logika dan struktur file sebuah proyek. Dengan beberapa pengalaman, Anda dapat bereksperimen dan menyimpang dari standar jika memungkinkan Anda untuk mengatasi beberapa batasan untuk proyek tertentu, tetapi dalam banyak kasus hal ini tidak perlu. Dan, tentu saja, jangan lupakan prinsip "dasar" seperti SOLID. Artikel bagus tentang bagaimana menerapkan prinsip-prinsip ini di React:https://habr.com/ru/company/ruvds/blog/428079/ . Artikel bagus tentang arsitektur bersih: https://habr.com/ru/post/499078/ .
Pada organisasi basis kode di React dan masalah terkait, ada koleksi materi yang bagus, meskipun tidak diperbarui untuk waktu yang lama: https://github.com/markerikson/react-redux-links/blob/master/project-structure.md .
Merumuskan konvensi pengkodean
Arsitek yang awalnya merencanakan proyek berdasarkan jalur pengembangan aplikasi memiliki template tertentu dalam pikirannya. Ada baiknya mengungkapkannya secara eksplisit dalam bentuk paspor proyek, melengkapinya dengan aturan penulisan kode, misalnya, apa yang boleh dan tidak boleh dimasukkan ke dalam modul terpisah (secara umum, ini pertanyaan yang agak filosofis). "Paspor" seperti itu akan membantu pengembang untuk menentukan terlebih dahulu bagaimana menulis, agar nanti tidak menulis ulang. Ini dapat mengurangi waktu peninjauan dan membantu menstandarisasi pendekatan pengkodean, yang sangat berguna saat mengerjakan proyek dengan pekerja jarak jauh atau tim terdistribusi.
Tetap berpegang pada paradigma yang dipilih
Jika pada awalnya Anda memutuskan untuk mengikuti beberapa pendekatan, misalnya, desain web atom, Anda tidak boleh meninggalkannya begitu tenggat waktu mulai habis. Dukungan yang dimulai dan ditinggalkan untuk sebuah paradigma terkadang hampir lebih buruk daripada ketiadaan sepenuhnya. Jika Anda "memberikan sedikit kebebasan untuk mengendalikan kekacauan", akan sangat sulit untuk memulihkan ketertiban - Anda harus menghabiskan waktu untuk kembali ke paradigma. Dan Anda tidak akan dapat dengan cepat "melompat" ke yang lain, karena kekacauan tak berbentuk telah terbentuk dalam proyek tersebut.
Penolakan paradigma demi timing atau faktor lain ibarat berganti kuda di sebuah persimpangan. Ini menyakitkan dan tidak dianjurkan. Tetapi jika tidak ada jalan keluar, Anda perlu menutupi sebagian besar aplikasi Anda dengan pengujian. Dan di sini kita beralih ke tip berikutnya ...
Ingat tes
Tes pada sebuah proyek tidak harus begitu saja. Mereka harus bekerja. Dan perlu untuk memasukkan mereka ke dalam proyek pada tahap pertama - segera setelah pengembangan dimulai. Jika tidak, pada titik tertentu, Anda dapat mengubah sesuatu dalam aplikasi, dan kemudian keluar dari tenggat waktu rilis, memulihkan kinerja berbagai bagian proyek, yang hanya dicakup oleh pengujian manual.
Biarkan tes menjadi kecil di awal dan jangan memeriksa apa pun. Tetapi jauh lebih baik untuk mengembangkannya seiring dengan berkembangnya fungsinya, daripada menghabiskan seminggu kemudian untuk melunasi "hutang teknis" ini. Dalam hal jumlah waktu yang dihabiskan, pendekatan pertama lebih efektif. Ngomong-ngomong, banyak yang menyadari hal ini, tetapi masih meninggalkan tes untuk nanti.
Saya juga ingin menyebutkan integrasi dan tes ujung ke ujung.
Uji integrasi harus dijalankan setiap kali Anda memperbaiki bug atau menambahkan fitur baru untuk memastikan bahwa penyesuaian tidak memengaruhi apa pun. Pada proyek kami, kami mencoba meluncurkannya secara otomatis ketika kami mengunggah hasil pekerjaan kami (kami menerapkan ini melalui pengait). Pengujian tidak berhasil - Anda tidak boleh mengupload perubahan ke proyek. Pertama, Anda perlu memperbaiki semuanya.
Tetapi tes integrasi hanya menyangkut frontend. Tes ujung ke ujung lebih lambat dan menguji interaksi aplikasi dengan semua item yang bergantung. Tes ini mensimulasikan tindakan pengguna. Di sini kami tidak mengejek apa pun, tetapi benar-benar menunggu tanggapan backend dan memeriksa interaksi dalam seluruh ekosistem proyek menggunakan Cypress (kami juga dapat merekomendasikan Puppeteer sebagai analog).
Pikirkan sebelum meningkatkan, tetapi jangan menyerah
Di dunia frontend, semuanya berubah dengan sangat cepat - versi kerangka kerja saling menggantikan, pustaka yang lebih sukses muncul. Itu layak untuk membuat mereka selalu up-to-date, tetapi tidak fanatik.
Seperti mengetik, yang kita bicarakan di atas, pembaruan apa pun membutuhkan sumber daya (yaitu, secara tidak langsung, uang). Tetapi ada beberapa hal yang membuat tidak mungkin untuk sepenuhnya menyisih dari pembaruan.
Pertama, dukungan untuk pustaka yang paling sukses pun terkadang berakhir. Dalam situasi ini, Anda harus mencari analog yang lebih menjanjikan.
Kedua, bekerja dengan tumpukan teknologi lama jarang menginspirasi pengembang. Jika Anda menyadari bahwa tim tidak dapat disimpan di Backbone yang berdebu, atau Anda melihat bahwa tumpukan yang usang sangat memengaruhi masuknya pengembang baru, Anda harus memperbarui.
Penyegaran harus diambil sebagai bagian dari tatanan alam. Tetapi sebelum mengubah perpustakaan atau memperbarui kerangka kerja, Anda harus selalu melakukan penelitian.
Apakah versi baru tepat untuk Anda? Bagaimana Anda mengatur transisi? Dan tentu saja, Anda perlu merencanakan semuanya sebelumnya.
Pembaruan sangat sulit dilakukan jika tidak ada pengujian pada proyek tersebut. Bahkan pustaka tanggal kecil dapat mencakup banyak bagian berbeda dari sebuah proyek, dan memperbaruinya mengarah pada pengujian regresi penuh. Dengan pertumbuhan proyek, tidak mungkin untuk melakukannya secara efisien, hanya memiliki tes manual di gudang senjata.
Apakah kamu baik-baik saja sekarang?
Ukuran seberapa efisien Anda mengembangkan proyek dapat berupa rasio waktu yang dihabiskan untuk mengembangkan fitur baru versus waktu yang dihabiskan untuk bug. Tergantung pada pendekatannya, indikator ini mungkin lebih atau kurang, jadi kami tidak akan berusaha untuk menetapkan level "target". Anda sendiri dapat membandingkan situasi sebelum dan sesudah transformasi apa pun.
Selain karakteristik non-numerik, seperti “kepuasan pengembang dari proyek”, ada indikator seperti waktu orang baru bergabung dengan proyek. Ini adalah karakteristik seberapa baik proyek dijelaskan dengan jelas melalui dokumentasi, tes, dan konvensi pengkodean.
Dan ingat, lebih baik meninggalkan kode yang lebih baik daripada sebelumnya. Jangan menimbulkan hutang teknis, jika tidak maka akan menghambat perkembangan proyek nantinya.
Mungkin Anda punya tip sendiri? Tinggalkan di komentar!
PS Kami mempublikasikan artikel kami di beberapa situs di Runet. Berlangganan halaman kami di saluran VK , FB , Instagram atau Telegram untuk mempelajari semua publikasi kami dan berita lainnya dari Maxilect.
PPS Gambar judul dari Playhouse Competition yang diadakan baru-baru ini.