Arsitektur bersih untuk ujung depan



Web modern itu rumit. Jumlah kerangka kerja dan laju pengembangannya membuat pengembang berpacu. Seseorang menggunakan yang baru, seseorang membaca buku mode. Tapi kadang-kadang membaca dan menghabiskan energi memperdalam arsitektur, OOP, TDD, DDD, dll. jangan memenuhi harapan. Dan terkadang buku-buku itu membingungkan! Dan bahkan, hal terburuk, mereka sangat meningkatkan FAC!

Saya akan berusaha untuk menjabarkan ide utama Arsitektur Murni dalam hubungannya dengan frontend. Saya berharap ini akan bermanfaat bagi orang-orang yang ingin membaca buku ini, dan bagi mereka yang sudah membaca, tetapi tidak menggunakan pengetahuan yang diperoleh dalam kehidupan nyata. Dan bagi mereka yang tertarik pada bagaimana saya menyeret ujung depan di sini.

Motivasi


Pertama kali saya membaca FAQ adalah sekitar satu setengah tahun sebelum menulis artikel atas saran dari salah satu pengembang senior. Sebelum itu, saya sangat terkesan dengan kutipan singkat dari Pure Code yang diadaptasi untuk JavaScript ( https://github.com/ryanmcdermott/clean-code-javascript ). Saya membiarkan tab ini terbuka selama enam bulan untuk menerapkan praktik terbaik dalam pekerjaan saya. Selain itu, upaya pertama saya untuk membaca Kode Bersih asli gagal. Mungkin karena terlalu melekat pada fitur-fitur proyek front-end, atau karena membaca harus diperkuat oleh praktik jangka panjang. Meskipun demikian, Cheka adalah panduan praktis yang dapat Anda ambil dan langsung diterapkan ke fungsi tertulis (saya sangat menyarankan Anda membacanya terlebih dahulu jika Anda tidak terbiasa).

Tetapi dengan TA, ini semakin rumit - berikut adalah serangkaian prinsip, hukum, dan kiat untuk membangun program secara keseluruhan. Tidak ada spesifik yang dapat Anda ambil dan zayuzat dalam komponen. Buku ini dirancang untuk mengubah cara Anda menulis perangkat lunak, dan memberi Anda alat mental dan metrik. Adalah suatu kesalahan untuk mempertimbangkan bahwa ChA hanya berguna untuk arsitek, dan saya akan mencoba menyampaikan ini menggunakan contoh yang disesuaikan dengan front-end.

Logika dan frontend bisnis




Ketika datang ke ChA, banyak orang menggambar lingkaran dalam imajinasi mereka (lihat gambar di bawah judul), proyek-proyek berukuran raksasa, logika bisnis yang sangat kompleks, dan banyak pertanyaan - ayah seperti apa yang menempatkan YuzKeysy? Gagasan penerapan prinsip-prinsip dari ChA untuk penciptaan komponen akordeon membingungkan. Namun masalah yang muncul saat mengembangkan antarmuka modern membutuhkan sikap serius. Antarmuka modern sangat kompleks dan seringkali menyakitkan. Pertama-tama, mari kita cari tahu apa yang paling penting di front-end.

Semua orang sudah lama tahu bahwa Anda perlu memisahkan logika bisnis dari presentasi, dan mematuhi prinsip-prinsip SOLID. Paman Bob di CHA akan memberi tahu Anda tentang ini dengan sangat rinci. Tetapi apa itu logika bisnis? R. Martin menawarkan beberapa definisi dan subkategori, salah satunya terdengar kurang lebih Begitu:
Logika bisnis (aturan bisnis) adalah aturan yang membawa uang ke organisasi bahkan tanpa otomatisasi.
Secara umum, logika bisnis adalah sesuatu yang sangat penting. (Saya mendengar para backender terkikik ketika mereka mendengar tentang logika bisnis dari depan). Tetapi saya menyarankan agar pelari depan sedikit bersantai dan ingat apa yang bisa sangat penting di depan kita? Dan betapapun anehnya kedengarannya, hal terpenting di depan adalah antarmuka pengguna. Langkah pertama untuk memahami AA bagi saya adalah kesadaran bahwa logika antarmuka harus berada di tengah di lingkaran depan! (gbr. di bawah judul).

Saya mengerti bahwa ini adalah pernyataan yang tidak berdasar, dan orang dapat membantahnya dengan kuat. Tetapi mari kita ingat bahwa apa yang berubah di depan sering dan menyakitkan? Saya tidak tahu tentang Anda, tetapi saya paling sering diminta untuk mengubah perilaku elemen interaktif - akordeon, cetakan, tombol. Perlu dicatat bahwa tata letak (desain) berubah jauh lebih jarang daripada perilaku antarmuka. Perubahan dan aktor ( penggagas perubahan ) secara khusus dibahas dalam PA , catatan.

Cetakan jahat


Jangan terlalu repot untuk terminologi. Kami memberikan contoh dan menjelaskan sedikit apa yang saya sebut logika antarmuka.

Ada beberapa input dengan validasi dan pemetaan bersyarat. Anda dapat mengisi hanya satu bidang, dan formulir itu valid, tetapi input opsional akan muncul. (Perhatikan, kami tidak peduli data apa yang ada di sana. Yang utama adalah interaktivitas)





Saya harap logikanya jelas. Dan pada awalnya, implementasinya tidak menimbulkan pertanyaan. Anda mendorong benda ini ke dalam komponen kerangka kerja Anda dan dengan berani menggunakannya kembali dalam bentuk lain sebagai bagian integral dan independen. Di suatu tempat Anda harus melewati flag untuk sedikit mengubah validasi, di suatu tempat tata letak kecil, di suatu tempat fitur menghubungkan ke formulir induk. Secara umum, kode pada es tipis. Dan sekali, Anda mendapatkan tugas dalam bentuk ini (dan menggunakannya) dan membeku selama beberapa hari, meskipun tampaknya 15 menit. Sial manajer, cetakan dan tugas-tugas membosankan membosankan.

Dimana kesalahannya? Tampaknya Anda telah bekerja lebih dari satu hari, memikirkan komposisi komponen dengan sangat baik, mencoba hockeys yang berbeda, mentransmisikan templat melalui alat peraga, disulap dengan kerangka kerja untuk bentuk bangunan, bahkan mencoba mengikuti SOLID ketika menulis komponen ini.

Catatan: komponen dalam ChA! == komponen dalam reaksi / sudut dan ko.

Tetapi kenyataannya adalah bahwa Anda lupa untuk menyoroti logika. Tenang sedikit, kembali ke tugas dan mainkan simulasi.

Tugas yang terlalu sederhana


NA menekankan bahwa arsitektur sangat penting untuk proyek-proyek besar. Tapi ini tidak meniadakan kegunaan pendekatan CHA untuk tugas-tugas kecil. Tampaknya bagi kita bahwa tugasnya terlalu sederhana untuk berbicara tentang arsitektur dari beberapa bentuk. Dan bagaimana cara menentukan cara untuk melakukan perubahan, jika tidak melalui arsitektur? Jika Anda tidak menentukan batasan dan komponen antarmuka interaktif, akan lebih mudah untuk bingung. Ingat dengan pemikiran apa Anda mengambil tugas mengubah formulir di tempat kerja Anda.

Tapi mari kita mulai bisnis. Formulir apa ini Kami mencoba membuat model, mengekspresikan pikiran dengan kode semu.

ContactFormGroup
  +getValue()
  +isValid()

Menurut pendapat saya, seluruh tugas kita untuk dunia luar adalah membuat objek dengan dua metode. Kedengarannya mudah - apa adanya. Kami terus menggambarkan apa yang kami lihat dan minat kami.

ContactFormGroup
  emailFormGroup
  phoneFormGroup
  getValue()
    => [emailFormGroup.getValue(), phoneFormGroup.getValue()]
  isValid()
    => emailFormGroup.isValid() || phoneFormGroup.isValid()

Mungkin, ada baiknya secara eksplisit menunjukkan tampilan input minor. Ketika seorang manajer meminta Anda untuk dengan cepat melakukan edit ke-10 ke formulir, maka semuanya tampak sederhana di kepalanya - sama seperti kode semu ini.

EmailFormGroup
  getValue()
  isValid()
  isSecondaryEmailVisible()
    => isValid() && !!getValue()

Bisakah kita melihat tempat untuk tuntutan aneh ...

PhoneFormGroup
  getValue()
  isValid()
  isSecondaryPhoneVisible()
    => isValid() && today !== โ€˜sundayโ€™

Salah satu implementasi formulir kami pada Angular mungkin terlihat seperti ini.

Implementasi ContactFormGroup (Sudut)
export class ContactFormGroup {
    emailFormGroup = new EmailFormGroup();
    phoneFormGroup = new PhoneFormGroup();

    changes: Observable<unknown> = merge(this.emailFormGroup.changes, this.phoneFormGroup.changes);

    constructor() {}

    isValid(): boolean {
        return this.emailFormGroup.isValid() || this.phoneFormGroup.isValid();
    }

    getValue() {
        return {
            emails: this.emailFormGroup.getValue(),
            phones: this.phoneFormGroup.getValue(),
        };
    }
}

export class EmailFormGroup {
    emailControl = new FormControl();
    secondaryEmailControl = new FormControl();

    changes: Observable<unknown> = merge(
        this.emailControl.valueChanges,
        this.secondaryEmailControl.valueChanges,
    );

    isValid(): boolean {
        return this.emailControl.valid && !!this.emailControl.value;
    }

    getValue() {
        return {
            primary: this.emailControl.value,
            secondary: this.secondaryEmailControl.value,
        };
    }

    isSecondaryEmailVisible(): boolean {
        return this.isValid();
    }
}


Jadi, kita mendapatkan tiga antarmuka (atau kelas, tidak penting). Anda harus meletakkan kelas-kelas ini dalam file terpisah di tempat yang menonjol sehingga Anda dapat memahami bagian-bagian yang bergerak dari antarmuka hanya dengan melihat ke dalamnya. Kami telah mengidentifikasi, menarik, dan menekankan logika yang bermasalah, dan sekarang kami mengendalikan perilaku formulir, menggabungkan implementasi bagian individu dari ContactFormGroup. Dan persyaratan untuk berbagai kasus penggunaan dapat dengan mudah direpresentasikan sebagai objek yang terpisah.

Ini tampaknya menjadi implementasi standar dari pola MVC, dan tidak lebih. Tetapi saya tidak akan mengabaikan hal-hal mendasar yang dalam praktiknya tidak dihormati sama sekali. Intinya bukan kita menarik sepotong kode dari tampilan. Intinya adalah bahwa kita telah menyoroti bagian penting yang dapat berubah dan menggambarkan perilakunya sehingga menjadi sederhana.

Total


ChA memberi tahu kita tentang hukum perangkat lunak penulisan. Ini memberikan metrik yang dengannya kita dapat membedakan bagian-bagian penting dari yang kecil dan secara langsung mengarahkan dependensi antara bagian-bagian ini. Menjelaskan manfaat OOP dan pendekatan untuk memecahkan masalah melalui pemodelan.

Jika Anda ingin meningkatkan kualitas program Anda, menjadikannya fleksibel, gunakan OOP dalam pekerjaan Anda, pelajari cara mengelola dependensi dalam proyek Anda, bicaralah dalam kode tentang solusi untuk masalah, dan bukan tentang detail perpustakaan Anda, maka saya sangat merekomendasikan membaca Arsitektur Bersih. Kiat dan prinsip dari buku ini relevan untuk tumpukan dan paradigma apa pun. Jangan takut dengan eksperimen pada tugas Anda. Semoga berhasil

PS Tentang manajemen negara


Hambatan yang sangat besar untuk memahami NA dapat menjadi komitmen untuk perpustakaan manajemen negara. Bahkan, pustaka seperti redux / mobx secara bersamaan menyelesaikan tugas memberitahukan komponen tentang perubahan. Dan untuk beberapa pengembang, sebuah front tanpa manajer negara adalah sesuatu yang tidak terpikirkan. Saya percaya bahwa prinsip-prinsip ChA dapat diterapkan dengan dan tanpa menggunakan manajer negara. Tetapi dengan berfokus pada perpustakaan manajemen negara bagian, Anda pasti akan kehilangan beberapa fleksibilitas. Jika Anda berpikir dalam hal ChA dan OOP, maka konsep manajemen negara umumnya menghilang. Implementasi paling sederhana tanpa manajemen negara ada di sini habr.com/en/post/491684

PPS


Jujur, saya menunjukkan solusi untuk tugas antarmuka yang sama dengan teman saya - dia tidak menghargainya, dan menulis ulang semuanya untuk kait reaksi. Tampaknya bagi saya bahwa penolakan yang lebih besar disebabkan oleh kenyataan bahwa OOP secara praktis tidak digunakan dalam proyek nyata, dan sebagian besar pengembang front-end muda tidak memiliki pengalaman sedikit pun dengan solusi OOP. Saat wawancara, mereka terkadang bertanya tentang SOLID, tetapi seringkali hanya untuk menyingkirkan kandidat. Selain itu, semangat untuk pengembangan di bidang PLO di beberapa tim dapat ditekan oleh review. Dan seringkali lebih mudah bagi orang untuk memilah perpustakaan baru daripada membaca buku yang membosankan atau mempertahankan hak mereka untuk mengeluarkan logika dari suatu komponen. Tolong dukung aktivis OOP :)

All Articles