Kata pengantar
Seperti yang sudah Anda pahami dari namanya, di sini saya akan berbicara tentang arsitektur paling "tinggi" - Murni. Dan dorongan untuk pengembangan seluruh cerita ini adalah buku Robert Martin "Arsitektur murni". Jika saya belum membacanya, saya berani merekomendasikannya! Penulis mengungkapkan banyak topik penting, secara aktif berbagi pengalaman hidupnya yang kaya (dari bidang profesional, tentu saja) dan kesimpulan yang dibuat atas dasar, kadang-kadang menjalin ke dalam bab-bab cerita betapa mahirnya kepala kita (dan tidak hanya, tentu saja) ayah dan kakek kita kembali pada 60-an, 70-an, 80-an dan bahkan 90-an gagah, seperti butiran gandum, prinsip favorit semua orang SOLID dan analog mereka di dunia komponen dikumpulkan, dan apa yang mereka pelajari selama setengah abad terakhir. Dalam proses membaca buku, garis pengembangan industri pengembangan perangkat lunak terlacak dengan baik, masalah-masalah khas yang harus dihadapi anak laki-laki,dan metode untuk menyelesaikannya.Jangan berpikir, menceritakan kembali ringkasan buku bukan tujuan dari posting ini.Selanjutnya, kita akan berbicara tentang ide-ide yang mendorong saya untuk mengembangkan satu alat (saya akan menentukan tingkat kegunaannya untuk Anda, dan saya akan menunggu umpan balik, saran, dan kritik membangun dengan penuh minat).Menurut saya artikel itu akan bermanfaat bagi semua orang. Mereka yang sudah terbiasa dengan buku ini akan dapat menyegarkan kembali momen-momennya dalam ingatan mereka, atau hanya melewatkan bagian pertama dan segera mulai membiasakan diri dengan alat tersebut. Mereka yang belum membaca buku sebelumnya mungkin dapat menemukan sesuatu yang baru untuk diri mereka sendiri di bagian pertama.Untuk kenyamanan, artikel ini dibagi menjadi 2 bagian.Pada awalnya saya akan berbicara tentang ide-ide kunci yang dihasilkan di kepala saya keinginan untuk mengotomatisasi semua ini, apakah kita programmer atau yang pada akhirnya? Di sini saya akan mengutip banyak dari penulis, serta secara aktif memasukkan ekstrak dan ilustrasi dari berbagai bab buku ini.Bagian kedua, hampir seluruhnya, akan dikhususkan untuk menggambarkan alat yang telah muncul, mengungkapkan kemampuannya dan panduan langkah demi langkah.Jika Anda menganggap diri Anda sebagai kategori orang yang terlalu dekat dengan hati Anda, saya sarankan Anda untuk mulai membaca dari Kata Penutup .Bagian 1
Apa itu arsitektur perangkat lunak?
Sayangnya, penulis buku tidak memberikan definisi tunggal. Ada banyak formulasi berbeda, dan semuanya benar dengan caranya sendiri.Namun, kita bisa pergi dari sisi lain ..Apa tujuan arsitektur?
Hanya ada satu jawaban:Tujuan arsitektur perangkat lunak adalah untuk mengurangi tenaga manusia yang dibutuhkan untuk membuat dan memelihara sistem.Sedikit pengantar ..Di mana banyak proyek dimulai?
"Kami akan dapat memulihkan pesanan nanti, kami hanya akan memasuki pasar!"Akibatnya, pesanan belum dikembalikan, karena tekanan persaingan di pasar tidak pernah berkurang.“Kebohongan terbesar yang diyakini banyak pengembang adalah bahwa kode kotor akan membantu mereka dengan cepat memasuki pasar, tetapi pada kenyataannya itu akan memperlambat pergerakan mereka dalam jangka panjang. Pengembang yang percaya pada kebohongan ini menunjukkan kesombongan Hare, percaya bahwa di masa depan mereka akan dapat beralih dari menciptakan kekacauan ke memulihkan ketertiban, tetapi mereka membuat kesalahan sederhana. Faktanya adalah bahwa penciptaan gangguan selalu lebih lambat daripada ketaatan tetap kebersihan, terlepas dari skala waktu yang dipilih. "Dua nilai produk perangkat lunak
- Perilaku (sesuatu yang mendesak tetapi tidak selalu penting)
- Arsitektur (sesuatu yang penting, tetapi tidak selalu mendesak)
Banyak yang sering tenggelam dalam yang pertama, dan sepenuhnya mengabaikan yang kedua.Ketik: "Mengapa membuang waktu dengan seksama memikirkan arsitektur, hal utama adalah ia bekerja dengan benar!" .Tetapi mereka kehilangan satu poin penting: “Jika sebuah program yang berfungsi dengan baik tidak memungkinkan kemungkinan mengubahnya, itu akan berhenti bekerja dengan benar ketika persyaratan berubah, dan mereka tidak akan dapat membuatnya bekerja dengan benar. Artinya, program tersebut akan menjadi tidak berguna.Jika program tidak bekerja dengan benar, tetapi mudah untuk diubah, mereka akan dapat membuatnya bekerja dengan benar dan mempertahankan kinerjanya saat persyaratan berubah. Artinya, program akan selalu bermanfaat. ”Saya menyukai pernyataan ini:"Jika menurut Anda arsitektur yang baik itu mahal, cobalah arsitektur yang buruk." (Brian Foote dan Joseph Yoder)Ternyata penting untuk memperhatikan kebersihan kode dan arsitektur secara umum dari baris pertama. Tetapi jika semuanya relatif jelas dengan kemurnian kode (mengendus segala macam bau busuk dalam kode, dan memperbaikinya, selain itu, alat-alat itu penuh dengan IDE cerdas, penganalisa statis, dan sampah tidak diragukan lagi penting lainnya), maka dengan arsitektur tidak begitu (setidaknya arsitektur) paling tidak saya).Bagaimana Anda bisa mengendalikan sesuatu yang sangat samar sehingga sulit bahkan untuk didefinisikan oleh satu kata-kata yang memiliki pandangan yang sangat fleksibel dan setiap detik, sial, sial melihatnya dan mencoba menafsirkannya dengan caranya sendiri, jika Anda bukan cucu Vanga, tidak memenangkan acara “Intuition "Dan bukankah poin kelima tidak terlalu sensitif? Kemudian penulis buku itu mengeluarkan beberapa pemikiran berharga untuk dipikirkan ... Mari kita selesaikan.Mengapa Anda datang dengan SOLID dan mengapa itu tidak cukup sendiri?
Kita semua mungkin tahu tentang prinsip-prinsip SOLID.Tujuan mereka adalah menciptakan struktur perangkat lunak tingkat menengah yang:- toleran terhadap perubahan;
- sederhana dan mudah dimengerti;
- membentuk dasar untuk komponen yang dapat digunakan di banyak sistem perangkat lunak.
Tetapi: "Sama seperti batu bata yang baik dapat membuat dinding tidak dapat digunakan, jadi komponen yang dirancang dengan baik dari tingkat rata-rata dapat menciptakan sistem yang tidak dapat digunakan."Oleh karena itu, di dunia komponen, ada analog prinsip SOLID, serta prinsip tingkat tinggi untuk membuat arsitektur.Saya akan menyentuh topik-topik ini dengan sangat dangkal, lebih banyak detail dapat ditemukan dalam buku ini. Ayo pergi!Konektivitas komponen dan prinsip penentu
“Komponen apa yang dimiliki kelas ini atau itu? Keputusan penting ini harus dibuat sesuai dengan prinsip pengembangan perangkat lunak yang ditetapkan. Sayangnya, keputusan semacam itu bersifat khusus dan diambil hampir secara eksklusif berdasarkan konteks. ”REP: Reuse / Release Equivalence Principle - Prinsip kesetaraan reuse dan release.Dalam hal arsitektur dan desain, prinsip ini berarti bahwa kelas dan modul yang membentuk komponen harus dimiliki oleh grup yang terhubung. Sebuah komponen tidak bisa begitu saja memasukkan campuran acak kelas dan modul; Seharusnya ada beberapa tema atau tujuan yang umum untuk semua modul.Kelas dan modul yang digabungkan menjadi satu komponen harus dilepaskan bersama.PKC: Prinsip Penutupan Umum - prinsip perubahan yang konsisten.Ini adalah prinsip SRP (tanggung jawab tunggal) diulang untuk komponen.Kelas yang berubah karena alasan yang sama dan pada saat yang sama harus dimasukkan dalam satu komponen. Komponen yang berbeda harus mencakup kelas yang berubah pada waktu yang berbeda dan karena berbagai alasan.CRP: Prinsip Penggunaan Kembali Bersama - Prinsip penggunaan kembali bersama.Prinsip ini mirip dengan ISP (pemisahan antarmuka).Jangan memaksa pengguna komponen untuk bergantung pada apa yang tidak mereka butuhkan.Prinsip tersebut menunjukkan bahwa kelas yang tidak terkait erat tidak boleh dimasukkan dalam satu komponen.“Mungkin Anda sudah memperhatikan bahwa tiga prinsip komponen yang terhubung bertentangan satu sama lain. Prinsip-prinsip kesetaraan penggunaan kembali (REP) dan perubahan konsisten (CCP) inklusif: keduanya berusaha untuk membuat komponen sebesar mungkin. Prinsip Penggunaan Kembali (CRP) luar biasa, berusaha keras untuk membuat komponen sekecil mungkin. Tugas seorang arsitek yang baik adalah untuk menyelesaikan kontradiksi ini. "
“Di masa lalu, kami melihat konektivitas lebih mudah daripada prinsip-prinsip kesetaraan penggunaan kembali (REP), perubahan konsisten (CCP), dan penggunaan kembali bersama (CRP) menyarankan. Setelah kami berpikir bahwa konektivitas hanyalah atribut, modul melakukan satu dan hanya satu fungsi. Namun, ketiga prinsip konektivitas komponen menggambarkan variasi yang jauh lebih kompleks. Saat memilih kelas untuk dimasukkan dalam komponen, Anda harus mempertimbangkan kekuatan lawan yang terkait dengan kemudahan penggunaan kembali dan pengembangan. Menemukan keseimbangan kekuatan-kekuatan ini berdasarkan kebutuhan aplikasi bukanlah tugas yang mudah. Selain itu, keseimbangan hampir selalu selalu berubah. Artinya, partisi yang dianggap berhasil hari ini mungkin tidak berhasil setelah satu tahun. Karena itu,komposisi komponen hampir pasti akan berubah seiring waktu dan fokus proyek akan bergeser dari kemudahan pengembangan ke kemudahan penggunaan kembali. "Kompatibilitas Komponen
“Tiga prinsip berikut ini mendefinisikan aturan untuk hubungan antar komponen. Dan lagi, kita dihadapkan dengan kontradiksi antara kemudahan pengembangan dan organisasi yang logis. Kekuatan yang mempengaruhi arsitektur struktur komponen bersifat teknis, politis, dan tidak stabil. ”ADP: Asiklik Dependensi Prinsip - asas asliklisitas dependensi.Loop dalam grafik ketergantungan komponen tidak diperbolehkan!
Dari komponen apa pun yang ditampilkan pada grafik, Anda mulai bergerak di sepanjang panah yang menunjukkan arah ketergantungan, Anda tidak akan dapat kembali ke titik semula. Ini adalah grafik berorientasi asiklik (DAG - Sutradara Asiklik Grafik).
Dalam gambar ini, kita memiliki ketergantungan yang mengarah pada penampilan suatu siklus. Ketergantungan siklik yang dihasilkan selalu dapat rusak.Metode untuk memutus ketergantungan siklik
1. Dengan menerapkan DIP (prinsip inversi ketergantungan)
2. Pengenalan komponen baru
“Solusi kedua melibatkan ketergantungan struktur komponen pada perubahan persyaratan. Memang, ketika aplikasi tumbuh, struktur dependensi komponen tumbuh dan berubah. Karena itu, harus selalu diperiksa siklusnya. Ketika siklus terbentuk, mereka harus dipecah dengan satu atau lain cara. Kadang-kadang untuk ini perlu untuk membuat komponen baru, yang membuat struktur dependensi tumbuh. "Desain top-down, atau lebih tepatnya ketidakpraktisannya
“Struktur komponen tidak dapat dirancang dari atas ke bawah. Kesimpulan ini tidak segera tercapai segera setelah mereka mulai merancang sistem, tetapi ini pasti terjadi dengan pertumbuhan dan perubahan sistem.Mempertimbangkan diagram blok yang besar, seperti struktur dependensi komponen, kami percaya bahwa komponen-komponen tersebut bagaimanapun harus mewakili fungsi-fungsi sistem. Namun pada kenyataannya, ini bukan atribut yang sangat diperlukan dari diagram ketergantungan komponen.Bahkan, diagram dependensi komponen lemah mencerminkan fungsi aplikasi. Untuk tingkat yang lebih besar, mereka adalah cerminan dari kenyamanan perakitan dan pemeliharaan aplikasi. Ini adalah alasan utama mengapa mereka tidak dirancang pada awal pengembangan proyek. Selama periode ini, tidak ada perangkat lunak yang perlu dikumpulkan dan dipelihara, sehingga tidak perlu menyusun peta pembangunan dan pemeliharaan. Tetapi dengan munculnya semakin banyak modul pada tahap awal implementasi dan desain, kebutuhan untuk mengelola dependensi meningkat ... Selain itu, ada keinginan untuk membatasi dampak perubahan sebanyak mungkin, jadi kami mulai memperhatikan prinsip-prinsip tanggung jawab tunggal (SRP) dan perubahan terkoordinasi (CCP) dan menggabungkan kelas, yang mungkin akan berubah bersama.Salah satu tugas utama dari struktur ketergantungan seperti itu adalah isolasi variabilitas. Kita tidak memerlukan komponen yang sering berubah karena alasan terkecil dan memengaruhi komponen lain yang seharusnya benar-benar stabil. Misalnya, perubahan kosmetik pada GUI seharusnya tidak memengaruhi aturan bisnis. Menambah dan memodifikasi laporan tidak boleh memengaruhi kebijakan tingkat tinggi. Akibatnya, grafik ketergantungan komponen dibuat dan dibuat oleh arsitek untuk melindungi komponen yang stabil dan berharga dari pengaruh komponen volatil.Saat aplikasi berkembang, kami mulai khawatir tentang membuat item yang dapat digunakan kembali. Pada tahap ini, prinsip penggunaan kembali bersama (CRP) mulai mempengaruhi komposisi komponen. Akhirnya, dengan munculnya loop, kita mulai menerapkan prinsip asyclicity dependensi (ADP), sebagai akibatnya, grafik dependensi komponen mulai berubah dan tumbuh.Upaya untuk merancang struktur ketergantungan komponen lebih awal dari kelas mana pun kemungkinan besar akan gagal. Pada tahap ini, kami hampir tidak tahu apa-apa tentang rekonsiliasi perubahan, kami tidak membayangkan elemen mana yang dapat digunakan berulang kali, dan kami hampir pasti akan membuat komponen yang membentuk dependensi siklik. Oleh karena itu, struktur dependensi komponen harus tumbuh dan berkembang bersama dengan desain logis dari sistem ”Hei, apakah kamu masih di sini? Man, ini penting, Anda harus menyapa ini setidaknya untuk memasukkan makna bagian selanjutnya, akan ada tutorial baku tentang penggunaan tulza.SDP: Prinsip Dependensi Stabil - prinsip dependensi stabil.Ketergantungan harus diarahkan pada stabilitas!“Apa yang dimaksud dengan“ keberlanjutan ”? Bayangkan sebuah koin berdiri di tepi. Apakah posisinya stabil? Kemungkinan besar Anda akan menjawab "tidak". Namun, jika Anda melindunginya dari getaran dan tiupan angin, itu bisa tetap dalam posisi ini untuk waktu yang lama. Artinya, keberlanjutan tidak terkait langsung dengan frekuensi perubahan. Koin tidak berubah, tetapi hampir tidak ada orang yang mengatakan bahwa, berdiri di tepi, ia dalam posisi stabil.Kamus penjelasan mengatakan bahwa keberlanjutan adalah "kemampuan untuk mempertahankan kondisi seseorang di bawah pengaruh eksternal". Keberlanjutan terkait dengan jumlah pekerjaan yang perlu dilakukan untuk mengubah keadaan. Di satu sisi, koin yang berdiri di tepi dalam keadaan tidak stabil karena dibutuhkan sedikit usaha untuk menjatuhkannya. Di sisi lain, meja berada dalam kondisi yang sangat stabil, karena membutuhkan usaha yang jauh lebih besar untuk memberi tip.Apa hubungannya semua ini dengan perangkat lunak? Ada banyak faktor yang mempersulit perubahan komponen, seperti ukuran, kompleksitas, dan kejelasannya. Tetapi kita akan mengesampingkan semua faktor ini dan fokus pada hal lain. Ada satu cara pasti untuk membuat komponen perangkat lunak sulit diubah dengan membuat banyak komponen lain yang bergantung padanya. Komponen dengan banyak dependensi yang masuk sangat stabil, karena merekonsiliasi perubahan dengan semua komponen dependen memerlukan usaha yang cukup besar. "
Bagaimana cara mengevaluasi stabilitas komponen? Penulis menyarankan menghitung jumlah dependensi yang masuk dan keluar dan atas dasar mereka menghitung ukuran stabilitasnya.- Fan-in ( ): . , .
- Fan-out ( ): . , .
- I: : I = Fan-out ÷ (Fan-in + Fan-out). [0, 1]. I = 0 , I = 1 – .
Jadi, prinsip ini mengatakan bahwa metrik komponen I harus lebih dari metrik komponen I yang bergantung padanya. Artinya, metrik saya harus berkurang ke arah ketergantungan.Penting untuk dicatat bahwa jika semua komponen sistem sekestabil mungkin, sistem seperti itu tidak akan mungkin berubah. Karena itu, tidak semua komponen harus stabil.Sobat, jangan tertidur, saya dekat. Hanya sedikit yang tersisa!SAP: Prinsip Abstraksi Yang Stabil - prinsip stabilitas abstraksi. Stabilitas komponen sebanding dengan abstraknya.“Beberapa bagian dari sistem perangkat lunak harus berubah sangat jarang. Potongan-potongan ini mewakili arsitektur tingkat tinggi dan keputusan penting lainnya. Tidak ada yang ingin keputusan seperti itu berubah-ubah. Oleh karena itu, perangkat lunak yang merangkum aturan tingkat tinggi harus berada dalam komponen yang stabil (I = 0). Volatile (I = 1) seharusnya hanya berisi kode yang bisa diubah - kode yang dapat dengan mudah dan cepat diubah.Tetapi jika Anda menempatkan aturan tingkat tinggi dalam komponen stabil, ini akan mempersulit perubahan dalam kode sumber yang mengimplementasikannya. Ini dapat membuat seluruh arsitektur tidak fleksibel. Bagaimana membuat komponen dengan stabilitas maksimum (I = 0) sangat fleksibel sehingga tetap stabil selama perubahan? Jawabannya terletak pada prinsip keterbukaan / penutupan (OCP). Prinsip ini mengatakan bahwa adalah mungkin dan perlu untuk membuat kelas yang cukup fleksibel sehingga mereka dapat diwarisi (diperluas) tanpa perubahan. Kelas mana yang mematuhi prinsip ini? Abstrak.SAP (prinsip stabilitas abstraksi) membangun hubungan antara stabilitas dan abstrak. Di satu sisi, ia mengatakan bahwa komponen stabil juga harus abstrak sehingga stabilitasnya tidak menghambat ekspansi, dan di sisi lain, ia mengatakan bahwa komponen yang tidak stabil harus konkret, karena ketidakstabilan membuatnya mudah untuk mengubah kodenya.Artinya, komponen yang stabil harus terdiri dari antarmuka dan kelas abstrak sehingga dapat dengan mudah diperluas. Komponen tangguh yang tersedia untuk ekspansi cukup fleksibel untuk tidak terlalu membatasi arsitektur.Prinsip stabilitas abstraksi (SAP) dan dependensi stabil (SDP) bersama-sama sesuai dengan prinsip invensi ketergantungan (DIP) untuk komponen. Ini benar karena prinsip SDP mensyaratkan bahwa ketergantungan diarahkan pada keberlanjutan, dan prinsip SAP menyatakan bahwa keberlanjutan menyiratkan abstrak. Artinya, ketergantungan harus diarahkan ke abstrak.Namun, prinsip DIP dirumuskan untuk kelas, dan dalam kasus kelas tidak ada midtone. Kelasnya abstrak atau tidak. Prinsip-prinsip SDP dan SAP berlaku untuk komponen dan memungkinkan situasi di mana komponen sebagian abstrak atau sebagian stabil. "Bagaimana mengukur abstrak komponen? Di sini juga, semuanya sangat sederhana.Nilai ukuran komponen abstrak ditentukan oleh rasio jumlah antarmuka dan kelas abstrak dengan jumlah total kelas.- Nc: jumlah kelas dalam komponen.
- Na: jumlah kelas dan antarmuka abstrak dalam komponen.
- A: abstrak. A = Na ÷ Nc .
Nilai metrik A bervariasi dalam kisaran dari 0 hingga 1. 0 berarti tidak adanya elemen abstrak dalam komponen, dan 1 berarti bahwa komponen tersebut tidak berisi apa pun kecuali kelas dan antarmuka abstrak.Ketergantungan antara I dan AJika Anda menampilkan pada grafik (Y - abstraksi, X - ketidakstabilan) komponen "baik" dari kedua jenis: abstrak stabil dan beton tidak stabil, kami mendapatkan ini:
Tetapi, karena komponen memiliki derajat abstrak dan stabilitas yang berbeda, jauh dari semua masuk ke dalam 2 poin ini (0, 1) atau (1, 0), dan karena tidak mungkin mengharuskan semua komponen ada di dalamnya, kita harus mengasumsikan bahwa pada grafik A / Saya ada beberapa poin yang menentukan posisi optimal untuk komponen.Himpunan ini dapat diturunkan dengan mendefinisikan area di mana komponen tidak boleh ditempatkan - dengan kata lain, mendefinisikan zona pengecualian.
Zona NyeriPertimbangkan komponen yang terletak di dekat titik (0, 0).Mereka sangat stabil dan spesifik. Komponen seperti itu tidak diinginkan sejak itu terlalu tangguh. Mereka tidak dapat diperluas, karena mereka tidak abstrak dan sangat sulit untuk berubah karena stabilitas mereka yang besar. Semakin kita mengubah komponen yang memasuki zona nyeri, semakin banyak rasa sakit yang ditimbulkannya. Ini karena kompleksitas perubahannya.Komponen yang dirancang dengan benar biasanya tidak boleh mendekati titik (0, 0).Namun, pada kenyataannya, ada entitas perangkat lunak yang termasuk dalam zona ini. Sebagai contoh, skema database, adalah sespesifik mungkin dan banyak dependensi meregang ke arah itu. Ini adalah salah satu alasan mengapa perubahan skema database biasanya dikaitkan dengan rasa sakit yang hebat.Zona Tak BergunaPertimbangkan komponen yang terletak di dekat titik (1, 1).Komponen seperti itu juga tidak diinginkan, karena mereka seabstrak mungkin dan tidak memiliki ketergantungan. Mereka sama sekali tidak berguna. Seringkali ini adalah kelas abstrak yang belum pernah diterapkan.Bagaimana cara menghindari masuk ke zona pengecualian?Tempatkan komponen di dekat atau pada urutan utama. Komponen semacam itu tidak "terlalu abstrak" untuk stabilitasnya dan tidak "terlalu tidak stabil" untuk abstraknya. Mereka tidak berguna dan tidak menyebabkan banyak rasa sakit. Komponen-komponen lain bergantung padanya sampai pada tingkat keabstrakannya, dan mereka sendiri bergantung pada yang lain sampai tingkat kekhususan.Posisi yang paling diinginkan untuk komponen adalah titik akhir dari urutan utama. Namun, dalam sistem besar akan selalu ada beberapa komponen yang tidak cukup abstrak dan tidak cukup stabil. Komponen tersebut memiliki karakteristik yang sangat baik ketika berada di atau dekat urutan utama.Jarak ke urutan utamaKarena diinginkan bahwa komponen terletak pada atau dekat urutan utama, dimungkinkan untuk menentukan metrik yang menyatakan jarak komponen dari ideal.- D: jarak. D = | A + I - 1 | . Metrik ini mengambil nilai dari rentang [0, 1]. Nilai 0 menunjukkan bahwa komponen langsung pada urutan utama. Nilai 1 menunjukkan bahwa komponen terletak pada jarak maksimum dari urutan utama.
Dengan mengadopsi metrik ini, Anda dapat menjelajahi seluruh desain yang berdekatan dengan urutan utama. Metrik D dapat dihitung untuk komponen apa pun. Setiap komponen dengan nilai metrik D jauh dari nol memerlukan revisi dan restrukturisasi.
Kesimpulan penulis (Robert Martin)
"Metrik manajemen ketergantungan yang dijelaskan dalam bab ini membantu Anda mengukur konsistensi struktur ketergantungan dan abstraksi desain dengan apa yang saya sebut desain" baik ". Pengalaman menunjukkan bahwa ada ketergantungan yang baik, ada yang buruk. Peringkat ini mencerminkan pengalaman ini. Namun, metrik bukanlah kebenaran pamungkas; ini hanya pengukuran berdasarkan standar arbitrer. Metrik ini tidak sempurna - yang terbaik, tetapi saya harap Anda menemukan mereka berguna. "Man, aku senang jika kau masih bersamaku. Itu mungkin bagian pertama dari itu. Meskipun masih ada banyak topik, dan pemikiran rinci penulis tetap tidak terpengaruh. Tetap saja, tujuan utama artikel saya bukan untuk menceritakan kembali buku itu, kalau tidak, Anda pasti akan lebih senang membaca aslinya. Saya, mendaki, dan sudah secara khusus pergi terlalu jauh dengan jumlah konten, tetapi saya akan menjadi bajingan, saya mencoba untuk tidak mengembang semampu saya. Bulat!Hari kedua. Umm, yaitu Bagian 2
pengantar
Apa yang sudah lama saya gosipkan di sana? "Ah, ya ... Kita seperti arsitek, atau kita benar-benar ingin menjadi mereka, kan?"Apa yang kita miliki - Beberapa jenis proyeksi yang menyedihkan, atau mungkin sistem yang mengerikan, PROYEK, ibunya, yah, atau akhirnya belum ada nifig, tetapi kita hanya menggosok tangan, melihat kalender dan mencari tahu seberapa baik kita harus berbicara.Tidak ada kita, saya bekerja sendiri! Atau mungkin kita, dengan seorang sahabat karib, di garasi, akan mengisi Apple baru, mengapa tidak? Baik, kita adalah tentara dan kita semua adalah bagian dari perusahaan besar, kita bekerja keras, seperti orang kulit hitam orang miskin di rumah (yaitu, orang Afrika-Amerika, tentu saja, Anda mengerti), atau mungkin kita menendang pelan sehingga kita tidak dipecat. Untuk gaji besar dengan bonus, cookie dan pemandangan dari Moskow-kota atau untuk antusiasme kosong, untuk sebuah ide dan saham dalam sebuah startup yang secara alami neraka ketika lepas landas.Faktanya, itu tidak masalah. Yang penting adalah ini: kita semua, pada akhirnya, hanya ingin gagasan kita untuk tidak membungkuk sebelum waktunya, yah, setidaknya sebelum keberangkatan kita, dan ada semua kemungkinan untuk itu. Ya, ya ...Dan apa yang harus dilakukan sekarang, Anda bertanya? Jadi, jika Anda tidak memiliki kakak laki-laki di kantor, maka bro tidak dapat melakukannya tanpa mata ketiga.Ringkasan bagian pertama
Di bagian terakhir artikel, kami berbicara sedikit tentang metrik yang memungkinkan arsitek mengukur angka mereka dalam angka untuk mencerminkan tingkat kualitas arsitektur sistem mereka.Sebuah - abstraksi komponenI - ketidakstabilan komponenD - jarak ke urutan utama pada grafik A / I zona sensitif seksual dari para nyeri dan kesia-siaan zona yangterungkap . Kami sampai pada kesimpulan bahwa, idealnya, A harus naik dan turun dalam proporsi ke penurunan dan, karenanya, peningkatan dalam IAlat dan proyek uji. Pengantar topik
Fuf, semuanya tampak seperti teori ... Sekarang Anda bahkan bisa membuat tangan Anda kotor untuk detail.Dan saya sekarang tidak memiliki tentang kuda abstrak dalam vakum untuk menggosok, dan Anda memiliki akhir pembacaan kurang alasan untuk menelepon saya mudiloy, karena yang Anda fucked menghabiskan begitu banyak waktu, saya telah prosrat menghabiskan sedikit, dan untuk mempersiapkan demo proyek, yang, sobstna, kita sekarang akan melakukan hara-kiri. Untuk cowok "super berbakat" yang pasti akan dan ingin bergaul dalam komentar, mengenai detailnya, saya tekankan - ini adalah proyek DEMO .Saya memotongnya sekitar setengah hari, secara kasar, di lutut pacar saya. Lagipula, saya tidak bisa mengambil dan mengeringkan kepada masyarakat umum rincian proyek pertempuran yang harus saya kerjakan ... Orang-orang yang terluka tidak akan mengerti, mereka akan menunjukkan kepada saya, tetapi apakah saya membutuhkannya? Nah, jika Anda adalah anak yang sederhana, bukan salah satu dari "yang sangat luar biasa," maka saya payah untuk pengenalan yang begitu lama, saya hanya harus mengambil risiko dan mengurangi potensi ancaman berkembang biak di komentar pasar tentang apa-apa.Jadi, proyek itu sendiri ada di sini github.com/Chetkov/php-clean-architecture-example-project .Di masa depan, ia bisa menjadi toko online yang lengkap. Saya memang perfeksionis yang ganas, tetapi Anda harus menjadi omong kosongpemakan sinar matahari dan hati yang panjang, selain menderita insomnia, untuk menghabiskan begitu banyak waktu pada "kelinci percobaan" dan membuat permen dari itu. Seperti yang Anda pahami, proyek ini tidak akan pernah sampai pada kesimpulan logisnya , namun, seperti yang lainnya, bahkan proyek pertempuran.Meskipun tidak terlalu buruk. Saat ini memiliki: pengguna, produk dan pesanan , serta skenario: pendaftaran pengguna, perubahan kata sandi, menambahkan produk dan pemesanan pesanan .Proyek ini kurang lebih berfungsi, Anda dapat mengkloningnya sendiri dan menjalankan skrip dari folder sandbox, walaupun pada kenyataannya, saya bahkan tidak bisa melakukan ini, karena untuk analisis arsitektur, proyek tidak memerlukan operabilitas.Di masa depan, saya akan membuang tautan ke komitmen tertentu untuk segera memperbaiki poin teknis yang dijelaskan dalam artikel.Keadaan awal. Saya kira Anda sudah berhasil berkenalan dengan struktur. Jadi kita bisa melanjutkan.Kami menyertakan PHP Clean Architecture :composer require v.chetkov/php-clean-architecture:0.0.3
Kami membuat dan mengonfigurasi file konfigurasiVisualisasi untuk analisis
Kami mengeksekusi di konsol (di root proyek):vendor/bin/phpca-build-reports
atauvendor/bin/phpca-build-reports /path/to/phpca-config.php
Dan sebagai tanggapan kita mendapatkan:Report: /path/to/reports-dir/index.html
Laporan ini terdiri dari 3 layar:1. Informasi sistem umum
Layar ini menampilkan:Grafik A / I yang
sama menunjukkan dispersi komponen:
Grafik yang menunjukkan keterpencilan komponen dari urutan utama:
Dan grafik yang menunjukkan hubungan antara komponen:
Panah menunjukkan arah ketergantungan, dan angka-angka di atasnya menunjukkan kekuatan koneksi.Karena IDE modern menyediakan cara mudah untuk melakukan refactor (mereka sendiri menemukan dan memperbaiki semua area di mana metode atau kelas secara eksplisit dipanggil, misalnya, ketika mengganti nama atau mentransfer ke namespace lain), saya mengambil sejumlah elemen dari modul dependensi yang digunakan oleh modul dependen untuk kekuatan komunikasi.Sebagai contoh: elemen-elemen modul layanan tahu tentang 12 elemen modul model , dan elemen infrastruktur tahu tentang 1 elemen layanan . DllOmong-omong, apa yang * tidak ditentukan *? Bro, pertanyaan yang diharapkan. Ini adalah modul yang dibuat secara otomatis untuk semua elemen yang, selama analisis sistem, tidak dapat dikaitkan dengan elemen yang diketahui (mis. Yang tercantum dalam file konfigurasi).Namun, jika Anda memperbaiki konfigurasi dengan cara ini:
Kemudian dalam proses menganalisis sistem, paket yang terhubung melalui komposer juga akan diperhitungkan (mereka sendiri tidak akan dipindai, tetapi gambar akan menjadi jauh lebih lengkap).Omong-omong, di vendor_path Anda perlu menentukan jalur ke direktori vendor, dan di jalur yang dikecualikan ke direktori paket yang ingin kami kecualikan (misalnya, jika kami menggambarkan beberapa paket dalam konfigurasi utama modul untuk pemindaian).Setelah mengaktifkan vendor_based_modules grafik telah berubah, meskipun kami tidak mengubah konfigurasi modul itu sendiri
2. Informasi terperinci tentang komponen
Di sini kita juga melihat:- Grafik interkoneksi , tetapi tidak dari keseluruhan sistem, tetapi hanya komponen yang terlibat
- Grafik A / I hanya menunjukkan komponen saat ini
- Fitur modul utama
dan- Grafik dependensi keluar menunjukkan jumlah dan daftar file dalam modul saat ini, tergantung pada file modul lainnya.
- Dan grafik dependensi yang masuk , menunjukkan jumlah dan daftar file dalam modul lain, tergantung pada modul saat ini.
2 grafik terakhir, menurut saya, sangat menarik, karena mudah untuk menemukan ketergantungan yang tidak diinginkan pada mereka, tetapi lebih banyak tentang itu nanti.3. Informasi terperinci tentang elemen komponen
Di sini Anda dapat melihat:- Karakteristik utama elemen, seperti abstraksi jenis, ketidakstabilan, primitif, dan komponen yang dimiliki dan pengubah akses .
"Che, pengubah akses kelas di PHP?" - Anda katakan, mengebor sebuah lubang di area kuil dengan jari Anda, bukan? Luangkan waktu Anda, saya tahu bahwa tidak ada kelas privat di panas, tetapi akan lebih keren jika mereka? Secara umum, lebih lanjut tentang itu nanti.- Grafik ketergantungan , yang mencerminkan interaksi elemen yang sedang dipertimbangkan dengan elemen lain dari sistem
- Dan tablet dengan dependensi keluar dan masuk
Dengan deskripsi layar selesai, buka konfigurasi untuk memilih dan menyodok bagaimana itu dapat dikonfigurasi.Opsi konfigurasi
Membatasi jarak maksimum yang diijinkan ke urutan utama (untuk semua komponen)Pertama, mari kita coba mengatur semua komponen ke jarak maksimum yang diijinkan ke urutan utama. Adalah bodoh untuk berpikir bahwa mereka semua akan berbaring di diagonal utama, karena dunia tidak sempurna, jadi mari kita bersikap realistis. Saya melakukan 0,3
Restart perintah pembuatan laporan dan segera melihat pelanggaran di halaman utama. Komponen model melebihi jarak yang diizinkan oleh 0,192
Membatasi jarak maksimum yang diizinkan ke urutan utama (ke komponen tertentu)Ini hebat, tapi mari kita asumsikan bahwa itu adalah komponen model yang dapat melanggar batasan ini. Berbagai hal terjadi ... Lagi pula, kita sering sudah tidak memiliki sistem ideal yang harus kita tangani, dukung, dan tingkatkan. Siapa pun mengerti bahwa tidak ada yang akan dapat dengan cepat mengurangi jarak ini, bahkan mungkin dengan dewa (saya harap dia akan memaafkan saya).Menurut pendapat saya, hal utama adalah memperbaiki keadaan saat ini, bekerja menuju perbaikan dan mengendalikan situasi agar tidak memburuk.Sekali lagi, buka config, dan atur max_allowable_distance , hanya untuk modul tertentu. Saya memperbaiki nilai saat ini 0,492
ZBS, sekarang semuanya normal kembali.
Tetapi jika, dengan beberapa ** ka Vasya, dia merokok sesuatu lagi dan menjadi lebih buruk - potong tangannya! CI / CD yang termasuk menjalankan perintah phpca-check (kita akan membicarakannya nanti) menegurnya, bahkan mungkin bahasa yang kotor, dan tentu saja itu akan menyoroti kesalahan.Pengendalian Ketergantungan KomponenApa lagi yang baik untuk dimiliki dalam gudang senjata kita untuk berurusan dengan arsitektur yang buruk? Tentu saja, kontrol ketergantungan. Siapa yang bisa tahu tentang siapa, atau sebaliknya seharusnya tidak tahu.Bagaimana menurut Anda, bisakah bagian yang paling sentral dari sistem, katakanlah domain , sehingga sangat memungkinkan bagi DDDowski untuk mengetahui sesuatu tentang beberapa infrastruktur yang bau ?Tentu saja YA, untuk beberapa itu, secara langsung, atribut kesuksesan (well, saya sedang berbicara tentang mereka yang membuat HTML bercampur dengan logika bisnis). Tapi akhirnya, seperti seharusnya, saya tidak boleh ... Saya pasti xs, tetapi semua jenis orang pintar yang berbeda dalam buku mengatakan bahwa ini bukan patsansky.Kalau begitu mari kita aduk seperti ini ... Semuanya ada di tempat yang sama, dalam konfigurasi pembatasan model .
Hmm ... Sejauh ini, semua aturan, karenamodel tentang infrastruktur benar-benar tidak tahu apa-apa ...Kalau begitu mari bersenang-senang ... Kebodohan memang jarang terjadi, tapi saya tidak menemukan sesuatu yang lebih baik. Krch, pada saat membuat pengguna kami akan "mengirim" SMS, dan pada saat membuat pesanan "mengirim" email. Dan untuk melakukan ini melalui implementasi spesifik pemberi notifikasi yang terletak pada infrastruktur .github.com/Chetkov/php-clean-architecture-example-project/commit/6bad365176b30999035967319a9c07fae69fabf9Sekarang kita melihat ke dalam laporan ... Seperti yang dapat kita lihat, grafik pada halaman berbeda dari laporan ini menyoroti koneksi ini sebagai tidak sah.Rumah.
Laporan Komponen.
Pada grafik model "ketergantungan keluar" dan "ketergantungan masuk"infrastruktur , kita segera melihat elemen yang melanggar aturan yang diperkenalkan
Dalam tabel "dependensi keluar" elemen model dan "dependensi inbound" elemen infrastruktur , sama.PHPCAEP \ Model \ Pengguna \ Pengguna
PHPCAEP \ Infrastruktur \ Pemberitahuan \ Sms \ SmsNotifier
Serta pada grafik hubungan elemen. Saya pikir di masa depan untuk menyingkirkannya sama sekali, karena itu tidak terlalu informatif (terutama untuk kelas yang digunakan secara aktif, karena panjang nama node + jumlah besar mereka)
Tindakan serupa dapat dilakukan dengan konfigurasi allow_dependencies .
Hasilnya akan benar-benar berlawanan.Dimungkinkan untuk membuat konfigurasi yang menunjukkan untuk modul dan dilarang, dan diizinkan (jika ada keinginan, kami akan membahas lebih rinci dalam komentar). Masih belum mungkin untuk menentukan satu komponen baik yang terlarang maupun yang diizinkan ... Ada pemikiran untuk memperkenalkan konfigurasi untuk menunjukkan prioritas, tetapi sejauh ini saya belum melakukan ini dan tidak yakin apa yang akan saya lakukan. Itu semua tergantung pada umpan balik Anda. Mungkin semua ini sia-sia?Kelas Publik / Privat di PHPOke, kami belajar cara mempersempit dan mengontrol berbagai pengetahuan komponen. Sudah tidak buruk. Apa berikutnya?Dan kemudian masalah lain. Musuh tidak tidur, meskipun dalam kebanyakan kasus musuh ini, kita sendiri, atau sahabat karib kita di kantor.Itu terjadi setelah semua, Anda bertemu seorang gadis, berbicara, menemukan sesuatu tentang dia, bahkan mungkin pacaran, tapi sial, itu tidak berhasil untuk Anda. Kami adalah teman dan semua itu ... Dia bisa menciummu ketika dia bertemu denganmu, dia bisa mendengarkan dan mendukungmu dengan kata yang baik, tetapi dia tidak memberimu apa pun untuk dibunuh . Jadi apa yang saya bicarakan ... Ah, ini ... Ini semua tentang aksesibilitas.Namun dalam kode, terus-menerus ... Hubungkan paket baru, bukan hari telah berlalu, tetapi sudah digunakan, tetapi langsung ke semua tempatdari semua sisi. Setengah dari basis kode Anda sudah terikat dengan berbagai kelasnya. Singkatnya, ia memiliki hubungan yang sangat intim dengan yang lain. Mungkin dalam beberapa situasi ini adalah norma, tetapi tidak dalam semua hal, bukan?Anda: “Semuanya baik, itu pemalu. Bagaimana mengatasi masalah itu? "Saya: "Biarkan hanya kelas yang diizinkan untuk berinteraksi, dan batasi akses ke yang lain."Anda: "Tapi di PHP tidak ada pengubah akses untuk kelas."Saya: "Saya setuju, tetapi ada Arsitektur PHP Bersih ."Contoh sekarang akan kembali dari pecandu narkoba, tetapi apa yang harus dilakukan.Dalam proyek nyata, tentu saja, kasing penuh kasing, tetapi mereka dapat membawa botol untuk menguras informasi dan meminta mereka untuk duduk. Itu sebabnya Anda harus menulis.Mari kita asumsikan bahwa dalam model , untuk beberapa alasan, hanya ada 2 kelas yang orang lain boleh ketahui tentang ... Pengguna dan Pesanan, yang lainnya harus disembunyikan.
Apa yang kita miliki sekarang?Andalkan yang utama.
Anda dapat segera melihat komponen mana yang perlu ditinjau.Kami memanjat untuk melihat apa yang salah dengan infrastruktur .
Pada grafik "ketergantungan keluar" kita melihat elemen yang melanggar aturan:
Pada halaman informasi elemen, sama.
Kami akan mendapatkan hasil sebaliknya jika kita menentukan private_elements di konfigurasi .
Misalnya, kami melarang semua orang tahu tentang Fio.Sekarang di
halaman utama: Di halaman informasi komponen layanan :
Dan pada halaman informasi elemen PHPCAEP \ Model \ User \ Fio :
Pemantauan pelanggaran prinsip-prinsip ADP dan SDPMasih, mungkin, kita perlu menyoroti kemungkinan termasuk pemeriksaan:- untuk pelanggaran prinsip ADP, mis. untuk keberadaan dependensi siklik dalam grafik ( check_acyclic_dependencies_principle )
- dan untuk pelanggaran prinsip SDP, mis. untuk dependensi yang diarahkan dari modul yang lebih stabil ke yang kurang stabil ( check_stable_dependencies_principle )
Tetapi ini hanya berfungsi di phpca-check sejauh ini dan tidak ditampilkan dalam laporan. Di masa depan, saya pikir saya akan memperbaikinya.Kontrol otomatis dalam CI / CD
Selama ini saya berbicara tentang bagian pertama - visualisasi. Dan analisis itu bisa dilakukan atas dasar itu.Waktunya telah tiba untuk membuat teman - teman kita govnokodera rekan terhormat menderita.Kami meluncurkan di konsol (di root proyek):vendor/bin/phpca-check
atauvendor/bin/phpca-check /path/to/phpca-config.php
Diasumsikan bahwa menjalankan perintah ini akan ditambahkan ke proses CI / CD proyek Anda. Dalam hal ini, kesalahan akan memblokir perakitan lebih lanjut.Script berakhir dengan kesalahan dan melempar sesuatu seperti ini:
Saya berikan giginya, daftar akan jauh lebih lama dalam proyek nyata.Tanya jawab- Pelanggaran prinsip asiklisitas dependensi (ADP)
- Demikian pula, tetapi siklusnya sedikit lebih pendek
- 2 elemen model (terdaftar) tergantung pada infrastruktur , yang tidak diizinkan oleh konfigurasi
- Pelanggaran ADP lagi
- Perulangan lain dan pelanggaran ADP
- Pelanggaran SDP karena lebih berkelanjutan model yang tergantung pada kurang berkelanjutan infrastruktur
- Sekali lagi ketergantungan siklik, baik itu salah
- 1 elemen layanan (terdaftar) tergantung pada Fio non-publik
Kira-kira hasil ini kami ucapkan terima kasih atas upaya dan tekun pemerintah kami .Sekarang mari kita balikkan semuanya. Ya, yaitu tidak semuanya, saya meninggalkan konfigurasi secara alami. Saya hanya memerintah kode.Sebagai permulaan, masuk akal untuk memperbaiki file yang melanggar aturan untuk mengikuti dependensi. Dalam proyek ini, sebagian besar siklus mungkin akan hilang dengan sendirinya, tetapi dalam siklus nyata, pasti harus bermain-main lebih lama (meskipun ini tergantung pada tingkat pengabaian sistem dan pengaturan konfigurasi).Pemecahan masalahSaya menghapus kecanduan yang ditemukan sebelumnya.github.com/Chetkov/php-clean-architecture-example-project/commit/f6bbbff1313bb4a22dfb6061f347ef007ba3b422fMulai ulang vendor / bin / phpca-cek
Ya, hanya ada konfigurasi untuk diedit, karena sebuah contoh benar-benar ditemukan oleh seorang pecandu narkoba.
Lagi vendor / bin / phpca-check
Dan CI / CD berjalan!Itu saja.Kata penutup
Tangkap seperlima jika Anda membacanya sampai akhir, jika tidak, mengendus kaki Anda di jalan (lagi pula, Anda tidak melihat ini).Tapi sungguh, terima kasih atas waktu Anda, tidak masalah jika Anda bergabung di tengah atau membacanya, menyelidiki setiap baris dan menganalisis setiap layar atau membalik kedua bagian secara diagonal. Bagaimanapun, terima kasih.Saya minta maaf lagi jika ada sesuatu yang salah.Mungkin, cara penyajian saya mungkin bagi seseorang yang terlalu mengesankan atau tidak sopan, saya hanya ingin sedikit melemahkan artikel dan sama sekali tidak ingin menyinggung siapa pun. Saya pikir tanpa ini, itu akan menjadi terlalu kering dan sulit dibaca.Saya benar-benar tertarik untuk mengetahui pendapat Anda dan jika Anda memiliki pemikiran, ide, saran atau keberatan, mari kita bahas dalam komentar.Kode bersih dan arsitektur fleksibel untuk Anda!