Cara Menangani Kerumitan Apabila Merekabentuk Sistem Perisian

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:

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.

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 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.

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 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.

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.

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:

1. Seni bina monolitik

2. Reka bentuk dipacu domain

3. Berasaskan komponen

4. Perkhidmatan mikro

5. Paip dan penapis

6. Didorong oleh acara

7. Mikrokernel

8. 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:

1. 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.
2. Apabila anda semakin menghampiri situasi apabila anda perlu menskalakan pembangunan dan sistem anda, anda boleh mempertimbangkan untuk mengikuti corak Stangler untuk mengekstrak komponen secara beransur-ansur yang perlu digunakan secara bebas atau bahkan diskalakan dengan keperluan khusus.
3. 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 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.

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:

• Keperluan dan kerumitan projek. 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
• Kebolehskalaan dan Keperluan Prestasi. 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.
• Pengambilan pekerja, Masa Pembangunan dan Kos. 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.
• Kepakaran dan Sumber Pasukan. 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.
• Kematangan. 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.
• Penyelenggaraan dan Sokongan Jangka Panjang. 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.

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)

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:

1. Lebihan. 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.
2. Pusat Data. 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.
3. Failover. 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.
4. Perkhidmatan ketersediaan tinggi. Pastikan perkhidmatan anda dibina untuk berskala mendatar dan sangat tersedia dari awal dengan mematuhi prinsip berikut:
   • 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.
5. Semakan kebergantungan. Semak dan kurangkan pergantungan luaran secara kerap. Setiap pergantungan luar boleh memperkenalkan SPOF yang berpotensi, jadi penting untuk memahami dan mengurangkan risiko ini.
6. Perkongsian ilmu secara berkala. 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.

Kesimpulan

Dalam artikel ini, kami membincangkan beberapa aspek Makro utama dan cara kami boleh menangani kerumitannya.

Terima kasih kerana membaca! Jumpa lagi lain kali!