![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Setiap hari, setiap saat sepanjang kerjaya kejuruteraan kami, kami menghadapi banyak masalah berbeza dengan pelbagai kerumitan dan situasi di mana kami perlu membuat keputusan atau menangguhkannya kerana kekurangan data. Setiap kali kami membina perkhidmatan baharu, membina infrastruktur, atau bahkan membentuk proses pembangunan, kami menyentuh dunia yang besar dengan pelbagai cabaran.
Adalah mencabar, dan mungkin juga mustahil, untuk menyenaraikan semua masalah. Anda akan menghadapi beberapa isu ini hanya jika anda bekerja dalam niche tertentu. Sebaliknya, terdapat banyak perkara yang mesti kita semua fahami cara menyelesaikannya, kerana ia penting untuk membina sistem IT. Dengan kebarangkalian yang tinggi, anda akan menemui mereka dalam semua projek.
Dalam artikel ini, saya akan berkongsi pengalaman saya dengan beberapa masalah yang saya hadapi semasa membuat program perisian.
Jika kita melihat ke dalam Wikipedia, kita akan mendapati definisi berikut
Dalam pembangunan perisian berorientasikan aspek, kebimbangan silang adalah aspek program yang mempengaruhi beberapa modul, tanpa kemungkinan terkandung dalam mana-mana modul. Kebimbangan ini selalunya tidak boleh diuraikan dengan bersih daripada seluruh sistem dalam kedua-dua reka bentuk dan pelaksanaan, dan boleh mengakibatkan sama ada serakan (penduaan kod), kusut (bergantung yang ketara antara sistem), atau kedua-duanya.
Ia sangat menggambarkan apa itu, tetapi saya ingin memanjangkan dan memudahkannya sedikit:
Kebimbangan silang ialah konsep atau komponen sistem/organisasi yang mempengaruhi (atau 'menyilang') banyak bahagian lain.
Contoh terbaik kebimbangan tersebut ialah seni bina sistem, pembalakan, keselamatan, pengurusan transaksi, telemetri, reka bentuk pangkalan data dan banyak lagi. Kami akan menghuraikan banyak daripada mereka kemudian dalam artikel ini.
Pada peringkat kod, kebimbangan rentas keratan sering dilaksanakan menggunakan teknik seperti Pengaturcaraan Berorientasikan Aspek (AOP) , di mana kebimbangan ini dimodulasi kepada komponen berasingan yang boleh digunakan sepanjang aplikasi. Ini memastikan logik perniagaan diasingkan daripada kebimbangan ini, menjadikan kod lebih mudah dibaca dan diselenggara.
Terdapat banyak cara yang mungkin untuk mengklasifikasikan aspek dengan membahagikannya dengan sifat yang berbeza seperti skop, saiz, fungsi, kepentingan, sasaran dan lain-lain, tetapi dalam artikel ini, saya akan menggunakan klasifikasi skop yang mudah. Dengan ini, saya maksudkan ke mana aspek khusus ini diarahkan sama ada keseluruhan organisasi, sistem tertentu, atau elemen khusus sistem itu.
Jadi, saya akan membahagikan aspek kepada Makro dan Mikro .
Dengan aspek Makro saya maksudkan terutamanya pertimbangan yang kami ikuti untuk keseluruhan sistem seperti seni bina sistem yang dipilih dan reka bentuknya (monolitik, perkhidmatan mikro, seni bina berorientasikan perkhidmatan), tindanan teknologi, struktur organisasi, dll. Aspek makro berkaitan terutamanya dengan strategik dan peringkat tinggi keputusan.
Dalam pada itu, aspek Mikro adalah lebih dekat dengan tahap kod dan pembangunan. Sebagai contoh, rangka kerja yang digunakan untuk berinteraksi dengan pangkalan data, struktur projek folder dan kelas, atau bahkan corak reka bentuk objek tertentu.
Walaupun pengelasan ini tidak sesuai, ia membantu untuk menstrukturkan pemahaman tentang masalah yang mungkin berlaku dan kepentingan serta kesan penyelesaian yang kami gunakan kepada mereka.
Dalam artikel ini, tumpuan utama saya adalah pada aspek makro.
Apabila saya baru mula belajar tentang seni bina perisian, saya membaca banyak artikel menarik tentang undang-undang Conway dan kesannya terhadap struktur organisasi. Terutama yang ini . Jadi, undang-undang ini menyatakan bahawa
Mana-mana organisasi yang mereka bentuk sistem (ditakrifkan secara meluas) akan menghasilkan reka bentuk yang strukturnya adalah salinan struktur komunikasi organisasi.
Saya sentiasa percaya bahawa konsep ini sememangnya sangat universal dan mewakili Peraturan Emas.
Kemudian saya mula mempelajari pendekatan Reka Bentuk Dipacu Domain (DDD) Eric Evans untuk sistem pemodelan. Eric Evans menekankan kepentingan pengenalpastian Konteks Terbatas. Konsep ini melibatkan pembahagian model domain yang kompleks kepada bahagian yang lebih kecil dan lebih mudah diurus, masing-masing dengan set pengetahuan terhadnya sendiri. Pendekatan ini membantu dalam komunikasi pasukan yang berkesan, kerana ia mengurangkan keperluan untuk pengetahuan yang luas tentang keseluruhan domain dan meminimumkan penukaran konteks, sekali gus menjadikan perbualan lebih cekap. Penukaran konteks adalah perkara yang paling teruk dan paling banyak memakan sumber. Malah komputer bergelut dengannya. Walaupun tidak mungkin untuk mencapai ketiadaan penukaran konteks sepenuhnya, saya rasa itulah yang harus kita perjuangkan.
Kembali kepada Undang-undang Conway, saya telah menemui beberapa isu dengannya.
Isu pertama yang saya temui dengan Undang-undang Conway, yang mencadangkan bahawa reka bentuk sistem mencerminkan struktur organisasi, adalah potensi untuk membentuk Konteks Sempadan yang kompleks dan komprehensif. Kerumitan ini timbul apabila struktur organisasi tidak sejajar dengan sempadan domain, membawa kepada Konteks Terbatas yang sangat bergantung dan sarat dengan maklumat. Ia membawa kepada penukaran konteks yang kerap untuk pasukan pembangunan.
Isu lain ialah istilah organisasi bocor ke tahap kod. Apabila struktur organisasi berubah, ia memerlukan pengubahsuaian asas kod, menggunakan sumber yang berharga.
Oleh itu, mengikuti Inverse Conway Maneuver membantu membina sistem dan organisasi yang menggalakkan seni bina perisian yang diingini. Walau bagaimanapun, patut diberi perhatian untuk mengatakan bahawa pendekatan ini tidak akan berfungsi dengan baik dalam seni bina dan struktur yang telah dibentuk kerana perubahan pada peringkat ini berpanjangan, tetapi ia menunjukkan prestasi yang luar biasa dalam permulaan kerana mereka cepat memperkenalkan sebarang perubahan.
Corak atau "anti-corak" ini memacu membina sistem tanpa sebarang seni bina. Tiada peraturan, tiada sempadan dan tiada strategi tentang cara mengawal kerumitan yang semakin meningkat yang tidak dapat dielakkan. Kerumitan adalah musuh yang paling menggerunkan dalam perjalanan membina sistem perisian.
Untuk mengelak daripada membina jenis sistem sedemikian, kita perlu mengikut peraturan dan kekangan tertentu.
Terdapat pelbagai definisi untuk Seni Bina Perisian. Saya suka banyak daripada mereka kerana mereka merangkumi aspek yang berbeza. Walau bagaimanapun, untuk dapat membuat alasan tentang seni bina, kita perlu secara semula jadi membentuk sebahagian daripadanya dalam fikiran kita. Dan patut diberi perhatian untuk mengatakan bahawa definisi ini mungkin berkembang. Jadi, sekurang-kurangnya buat masa ini, saya mempunyai penerangan berikut untuk diri saya sendiri.
Seni Bina Perisian adalah mengenai keputusan dan pilihan yang anda buat setiap hari yang memberi kesan kepada sistem yang dibina.
Untuk membuat keputusan yang anda perlu ada dalam prinsip dan corak "beg" anda untuk menyelesaikan masalah yang timbul, adalah juga penting untuk menyatakan bahawa memahami keperluan adalah kunci untuk membina keperluan perniagaan. Walau bagaimanapun, kadangkala keperluan tidak telus atau tidak ditakrifkan, dalam kes ini, lebih baik menunggu untuk mendapatkan penjelasan lanjut atau bergantung pada pengalaman anda dan mempercayai gerak hati anda. Namun begitu, anda tidak boleh membuat keputusan dengan betul jika anda tidak mempunyai prinsip dan corak untuk dipercayai. Di sinilah saya datang kepada definisi Gaya Seni Bina Perisian.
Gaya Seni Bina Perisian ialah satu set prinsip dan corak yang menetapkan cara membina perisian.
Terdapat banyak gaya seni bina yang berbeza tertumpu pada pelbagai sisi seni bina yang dirancang, dan menerapkan berbilang daripadanya sekaligus adalah situasi biasa.
Sebagai contoh, seperti:
Seni bina monolitik
Reka bentuk dipacu domain
Berasaskan komponen
Perkhidmatan mikro
Paip dan penapis
Didorong oleh acara
Mikrokernel
Berorientasikan perkhidmatan
dan seterusnya…
Sudah tentu, mereka mempunyai kelebihan dan kekurangan mereka, tetapi perkara paling penting yang saya pelajari ialah seni bina berkembang secara beransur-ansur sambil bergantung kepada masalah sebenar. Bermula dengan seni bina monolitik ialah pilihan yang bagus untuk mengurangkan kerumitan operasi, kemungkinan besar seni bina ini akan memenuhi keperluan anda walaupun selepas mencapai peringkat Product-market Fit (PMI) untuk membina produk. Pada skala, anda boleh mempertimbangkan untuk bergerak ke arah pendekatan dipacu peristiwa dan perkhidmatan mikro untuk mencapai penggunaan bebas, persekitaran tindanan teknologi heterogen dan seni bina yang kurang gandingan (dan kurang telus sementara itu disebabkan sifat pendekatan terdorong peristiwa dan sub-pub jika ini diterima pakai). Kesederhanaan dan kecekapan adalah dekat dan mempunyai impak yang besar antara satu sama lain. Biasanya, seni bina yang rumit memberi kesan kepada kelajuan pembangunan ciri baharu, menyokong dan mengekalkan ciri sedia ada serta mencabar evolusi semula jadi sistem.
Walau bagaimanapun, sistem yang kompleks sering memerlukan seni bina yang kompleks dan komprehensif, yang tidak dapat dielakkan.
Secara adil, ini adalah topik yang sangat luas, dan terdapat banyak idea hebat tentang cara menstruktur dan membina sistem untuk evolusi semula jadi. Berdasarkan pengalaman saya, saya telah menggunakan pendekatan berikut:
Ia juga penting untuk memahami nombor dan metrik seperti DAU (Pengguna Aktif Harian), MAU (Pengguna Aktif Bulanan), RPC (Permintaan Sesaat) dan TPC (Transaksi Sesaat) kerana ia boleh membantu anda membuat pilihan kerana seni bina untuk 100 pengguna aktif dan 100 juta pengguna aktif adalah berbeza.
Sebagai nota akhir, saya akan mengatakan bahawa seni bina mempunyai kesan yang besar terhadap kejayaan produk. Seni bina yang direka bentuk dengan buruk untuk produk diperlukan dalam penskalaan, yang berkemungkinan besar membawa kepada kegagalan kerana pelanggan tidak akan menunggu semasa anda menskalakan sistem, mereka akan memilih pesaing, jadi kami perlu mendahului penskalaan yang berpotensi. Walaupun saya mengakui bahawa kadangkala ia tidak boleh menjadi pendekatan yang ramping, ideanya adalah untuk mempunyai sistem berskala tetapi belum berskala. Sebaliknya, mempunyai sistem yang sangat rumit dan sudah berskala tanpa pelanggan atau rancangan untuk mendapatkan banyak daripada mereka akan menyebabkan anda kehilangan wang untuk perniagaan anda secara percuma.
Memilih tindanan teknologi juga merupakan keputusan peringkat makro kerana ia mempengaruhi pengambilan pekerja, perspektif evolusi semula jadi sistem, kebolehskalaan dan prestasi sistem.
Ini ialah senarai pertimbangan asas untuk memilih tindanan teknologi:
Bagaimanakah susunan teknologi berbilang boleh menjejaskan pertumbuhan perniagaan?
Dari satu perspektif, memperkenalkan satu lagi tindanan boleh meningkatkan pengambilan pekerja anda, tetapi sebaliknya, ia membawa kos penyelenggaraan tambahan kerana anda perlu menyokong kedua-dua tindanan. Jadi, seperti yang saya katakan sebelum ini, pada pandangan saya, hanya keperluan tambahan yang harus menjadi hujah untuk memasukkan lebih banyak tindanan teknologi.
Tetapi bagaimana pula dengan prinsip memilih alat terbaik untuk masalah tertentu?
Kadang-kadang anda tidak mempunyai pilihan lain selain membawa alat baharu untuk menyelesaikan masalah tertentu berdasarkan pertimbangan yang sama yang dinyatakan di atas, dalam kes sedemikian, masuk akal untuk memilih penyelesaian terbaik.
Penciptaan sistem tanpa gandingan tinggi kepada teknologi tertentu boleh menjadi satu cabaran. Namun, adalah berguna untuk berusaha untuk keadaan di mana sistem tidak berganding rapat dengan teknologi, dan ia tidak akan mati jika esok, rangka kerja atau alat tertentu menjadi terdedah atau tidak digunakan lagi.
Satu lagi pertimbangan penting adalah berkaitan dengan kebergantungan perisian sumber terbuka dan proprietari. Perisian proprietari memberi anda kurang fleksibiliti dan kemungkinan untuk disesuaikan. Namun, faktor yang paling berbahaya ialah penguncian vendor, di mana anda bergantung pada produk, harga, syarat dan peta jalan vendor. Ini boleh berisiko jika vendor menukar arah, menaikkan harga atau menghentikan produk. Perisian sumber terbuka mengurangkan risiko ini, kerana satu entiti tidak mengawalnya. Menghapuskan satu titik kegagalan pada semua peringkat adalah kunci untuk membina sistem yang boleh dipercayai untuk pertumbuhan.
Titik kegagalan tunggal (SPOF) merujuk kepada mana-mana bahagian sistem yang, jika gagal, akan menyebabkan keseluruhan sistem berhenti berfungsi. Menghapuskan SPOF di semua peringkat adalah penting untuk mana-mana sistem yang memerlukan ketersediaan tinggi. Segala-galanya, termasuk pengetahuan, kakitangan, komponen sistem, pembekal awan dan kabel internet, boleh gagal.
Terdapat beberapa teknik asas yang boleh kami gunakan untuk menghapuskan satu titik kegagalan:
Dalam artikel ini, kami membincangkan beberapa aspek Makro utama dan cara kami boleh menangani kerumitannya.
Terima kasih kerana membaca! Jumpa lagi lain kali!