Apa itu semua?  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.  Apakah Kebimbangan Merentas?  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:    ialah konsep atau komponen sistem/organisasi yang mempengaruhi (atau 'menyilang') banyak bahagian lain. Kebimbangan silang  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   , 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. Pengaturcaraan Berorientasikan Aspek (AOP)  Klasifikasi Aspek  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   dan   . Makro Mikro  Dengan aspek   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   berkaitan terutamanya dengan strategik dan peringkat tinggi keputusan. Makro makro  Dalam pada itu, aspek   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. Mikro  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.  Aspek Makro  Struktur organisasi  Apabila saya baru mula belajar tentang seni bina perisian, saya membaca banyak artikel menarik tentang undang-undang Conway dan kesannya terhadap struktur organisasi. Terutama   . Jadi, undang-undang ini menyatakan bahawa yang ini  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.    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 pertama    ialah istilah organisasi bocor ke tahap kod. Apabila struktur organisasi berubah, ia memerlukan pengubahsuaian asas kod, menggunakan sumber yang berharga. Isu lain  Oleh itu, mengikuti   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. Inverse Conway Maneuver  Bola Lumpur Besar  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.  Seni bina sistem  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.    adalah mengenai keputusan dan pilihan yang anda buat setiap hari yang memberi kesan kepada sistem yang dibina. Seni Bina Perisian  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.    ialah satu set prinsip dan corak yang menetapkan cara membina perisian. Gaya Seni Bina 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:  Hampir selalu bermula dengan gaya seni bina monolitik kerana ia menghapuskan kebanyakan masalah yang timbul akibat sifat sistem teragih. Ia juga masuk akal untuk mengikuti monolit modular untuk memberi tumpuan kepada membina komponen dengan sempadan yang jelas. Menggunakan pendekatan berasaskan komponen boleh membantu mereka berkomunikasi antara satu sama lain dengan menggunakan acara, tetapi mempunyai panggilan terus (aka RPC) memudahkan perkara pada mulanya. Walau bagaimanapun, adalah penting untuk mengesan kebergantungan antara komponen kerana jika komponen A mengetahui banyak tentang komponen B, mungkin masuk akal untuk menggabungkannya menjadi satu.  Apabila anda semakin menghampiri situasi apabila anda perlu menskalakan pembangunan dan sistem anda, anda boleh mempertimbangkan untuk mengikuti corak   untuk mengekstrak komponen secara beransur-ansur yang perlu digunakan secara bebas atau bahkan diskalakan dengan keperluan khusus. Stangler  Sekarang, jika anda mempunyai visi yang jelas tentang masa depan, yang merupakan sedikit nasib yang luar biasa, anda boleh membuat keputusan mengenai seni bina yang diingini. Pada masa ini, anda boleh membuat keputusan untuk bergerak ke arah seni bina perkhidmatan mikro dengan turut menggunakan pendekatan Orkestrasi dan Koreografi, menggabungkan corak CQRS untuk operasi tulis dan baca skala bebas, atau memutuskan untuk kekal dengan seni bina monolitik jika ia sesuai dengan keperluan anda.  Ia juga penting untuk memahami nombor dan metrik seperti   (Pengguna Aktif Harian),   (Pengguna Aktif Bulanan),   (Permintaan Sesaat) dan   (Transaksi Sesaat) kerana ia boleh membantu anda membuat pilihan kerana seni bina untuk 100 pengguna aktif dan 100 juta pengguna aktif adalah berbeza. DAU MAU RPC TPC  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.   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. Walaupun saya mengakui bahawa kadangkala ia tidak boleh menjadi pendekatan yang ramping, ideanya adalah untuk mempunyai sistem berskala tetapi belum berskala.  Pemilihan timbunan teknologi  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:    Sebagai contoh, aplikasi web mudah boleh dibina dengan rangka kerja Blazor jika pembangun anda mempunyai pengalaman dengannya, tetapi disebabkan kekurangan kematangan WebAssembly, memilih React dan Typescript untuk kejayaan jangka panjang boleh menjadi keputusan yang lebih baik Keperluan dan kerumitan projek.    Jika anda menjangkakan menerima jumlah trafik yang besar, memilih ASP.NET Core berbanding Django boleh menjadi pilihan yang bijak kerana prestasi unggulnya dalam mengendalikan permintaan serentak. Walau bagaimanapun, keputusan ini bergantung pada skala trafik yang anda jangkakan. Jika anda perlu mengurus berpotensi berbilion permintaan dengan kependaman rendah, kehadiran Pengumpulan Sampah boleh menjadi satu cabaran. Kebolehskalaan dan Keperluan Prestasi.    Dalam kebanyakan kes, ini adalah faktor yang perlu kita ambil berat. Masa untuk Memasarkan, Kos Penyelenggaraan dan Pengambilan pekerja kestabilan memacu keperluan perniagaan anda tanpa halangan. Pengambilan pekerja, Masa Pembangunan dan Kos.    Set kemahiran pasukan pembangunan anda adalah faktor kritikal. Secara amnya adalah lebih berkesan untuk menggunakan teknologi yang sudah biasa digunakan oleh pasukan anda melainkan terdapat sebab kukuh untuk melabur dalam mempelajari timbunan baharu. Kepakaran dan Sumber Pasukan.    Komuniti yang kuat dan ekosistem perpustakaan dan alatan yang kaya dapat memudahkan proses pembangunan. Teknologi popular selalunya mempunyai sokongan komuniti yang lebih baik, yang boleh menjadi tidak ternilai untuk menyelesaikan masalah dan mencari sumber. Oleh itu, anda boleh menjimatkan sumber dan memberi tumpuan terutamanya pada produk. Kematangan.    Pertimbangkan daya maju jangka panjang teknologi. Teknologi yang diterima pakai dan disokong secara meluas kurang berkemungkinan menjadi usang dan secara amnya menerima kemas kini dan penambahbaikan yang kerap. Penyelenggaraan dan Sokongan Jangka Panjang.   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.   Menghapuskan satu titik kegagalan pada semua peringkat adalah kunci untuk membina sistem yang boleh dipercayai untuk pertumbuhan. Perisian sumber terbuka mengurangkan risiko ini, kerana satu entiti tidak mengawalnya.  Titik Kegagalan Tunggal (SPOF)  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:    Laksanakan lebihan untuk komponen kritikal. Ini bermakna mempunyai komponen sandaran yang boleh mengambil alih jika komponen utama gagal. Lebihan boleh digunakan di seluruh lapisan sistem yang berbeza, termasuk perkakasan (pelayan, cakera), rangkaian (pautan, suis) dan perisian (pangkalan data, pelayan aplikasi). Jika anda mengehos segala-galanya dalam satu Pembekal Awan dan juga mempunyai sandaran di sana, pertimbangkan untuk membina sandaran tambahan biasa di tempat lain untuk mengurangkan kos anda yang hilang sekiranya berlaku bencana. Lebihan.    Edarkan sistem anda merentas berbilang lokasi fizikal, seperti pusat data atau kawasan awan. Pendekatan ini melindungi sistem anda daripada kegagalan khusus lokasi seperti gangguan bekalan elektrik atau bencana alam. Pusat Data.    Gunakan pendekatan failover untuk semua komponen anda (DNS, CDN, Pengimbang beban, Kubernetes, Gerbang API dan Pangkalan Data). Memandangkan isu boleh timbul secara tidak dijangka, adalah penting untuk mempunyai pelan sandaran untuk menggantikan mana-mana komponen dengan klonnya mengikut keperluan dengan pantas. Failover.    Pastikan perkhidmatan anda dibina untuk berskala mendatar dan sangat tersedia dari awal dengan mematuhi prinsip berikut: Perkhidmatan ketersediaan tinggi.  Amalkan perkhidmatan tanpa kewarganegaraan dan elakkan menyimpan sesi pengguna dalam cache dalam memori. Sebaliknya, gunakan sistem cache yang diedarkan, seperti Redis.  Elakkan pergantungan pada susunan kronologi penggunaan mesej semasa membangunkan logik.  Minimumkan pecah perubahan untuk mengelakkan pengguna API terganggu. Jika boleh, pilih perubahan yang serasi ke belakang. Juga, pertimbangkan kos kerana kadangkala, melaksanakan perubahan berbuka mungkin lebih menjimatkan kos.  Menggabungkan pelaksanaan migrasi ke dalam saluran paip penempatan.  Wujudkan strategi untuk mengendalikan permintaan serentak.  Laksanakan penemuan perkhidmatan, pemantauan dan pengelogan untuk meningkatkan kebolehpercayaan dan kebolehmerhatian.  Membangunkan logik perniagaan untuk menjadi idempoten, mengakui bahawa kegagalan rangkaian tidak dapat dielakkan.    Semak dan kurangkan pergantungan luaran secara kerap. Setiap pergantungan luar boleh memperkenalkan SPOF yang berpotensi, jadi penting untuk memahami dan mengurangkan risiko ini. Semakan kebergantungan.    Jangan sekali-kali lupa kepentingan menyebarkan pengetahuan dalam organisasi anda. Orang ramai boleh menjadi tidak dapat diramalkan, dan bergantung pada seorang individu adalah berisiko. Galakkan ahli pasukan untuk mendigitalkan pengetahuan mereka melalui dokumentasi. Walau bagaimanapun, berhati-hati dengan mendokumentasikan secara berlebihan. Gunakan pelbagai alatan AI untuk memudahkan proses ini. Perkongsian ilmu secara berkala.  Kesimpulan  Dalam artikel ini, kami membincangkan beberapa aspek   utama dan cara kami boleh menangani kerumitannya. Makro  Terima kasih kerana membaca! Jumpa lagi lain kali!

Read My Stories

Audio ini dihasilkan dalam bahasa asal cerita!

Terlalu panjang; Untuk membaca

Make resilience your competitive advantage

Cara Menangani Kerumitan Apabila Merekabentuk Sistem Perisian

About Author

KOMEN

GANTUNG TANDA

ARTIKEL INI DIBENTANGKAN DALAM

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps