Saya telah membaca banyak hal di Internet. Sangat sulit untuk menemukan apa pun tentang arsitektur perangkat lunak JAVA. Namun, arsitektur pengembangan perangkat lunak pada dasarnya sama. Oleh karena itu, saya mencari banyak artikel tentang arsitektur perangkat lunak dalam bahasa lain di Internet. Di sini sekali lagi, izinkan saya berbicara tentang pandangan saya tentang arsitektur perangkat lunak, khususnya arsitektur proyek JAVA. Itu mungkin tidak benar, tapi ini juga ringkasan saya beberapa tahun terakhir.
1. Cobalah untuk tidak mempertimbangkan penggunaan kembali di luar proyek
Banyak orang berpikir bahwa yang terbaik adalah meningkatkan penggunaan kembali perangkat lunak. Namun, situasi sebenarnya dari setiap proyek akan berbeda. Saat merancang modul atau metode tertentu dalam suatu proyek, terlalu banyak pertimbangan untuk menggunakan kembali di luar proyek pasti akan meningkatkan jumlahnya kompleksitas proyek meningkatkan overhead waktu pengembangan. Beberapa orang mungkin mengatakan bahwa ini akan mengurangi biaya proyek berikutnya. Apa proyek selanjutnya? Apa saja kebutuhannya? Apa saja faktor yang mempengaruhi dalam berbagai aspek? Siapa yang mengetahui semua ini saat ini. Jika Anda benar-benar ingin menggunakan kembali, Anda harus mengekstrak bagian yang dapat digunakan kembali setelah proyek selesai, memodifikasi dan mengoptimalkannya, dan menggunakannya sebagai aset perusahaan yang dapat digunakan kembali, bukan angan-angan dalam proyek saat ini. Pertimbangkan penggunaan kembali di luar proyek. Ini adalah kesalahan umum yang dilakukan oleh banyak programmer yang baru mengenal pekerjaan perangkat lunak. Seringkali, semakin mereka memikirkannya, semakin banyak perangkat lunak yang mereka buat gagal mencapai efek desain dan gagal menyelesaikan fungsi dasar atau proses logika kode. Banyak, fungsi program tidak sempurna dan sebagainya.
2. Sering-seringlah memeriksa struktur proyek
Arsitektur proyek biasanya merupakan sesuatu yang ditentukan sebelum pelaksanaan proyek dimulai dan merupakan desain keseluruhan. Namun saat ini pemahaman tentang kebutuhan proyek dan estimasi kompleksitas masih pada tahap awal. Jika arsitektur tidak dapat diperbaiki seiring dengan pemahaman proyek selama proses pengembangan proyek, anggota proyek pasti akan mengembangkan proyek sesuai dengan arsitektur yang salah. Oleh karena itu, arsitektur proyek harus sering diperiksa dan pemfaktoran ulang yang diperlukan harus dilakukan.
3. Pemfaktoran ulang
Beberapa orang mengatakan bahwa setelah menulis begitu banyak, merevisinya tidak membuang-buang waktu. Dia mungkin tidak menyangka bahwa suatu sore pemfaktoran ulang dapat mempercepat pengembangan dalam beberapa bulan ke depan. Waktu yang dihemat tidak terbayangkan. Selain itu, melalui refactoring, Anda biasanya dapat memikirkan metode yang lebih sederhana untuk menggantikan implementasi yang sudah ada. Pengalaman ini juga dapat menyederhanakan pengembangan modul lainnya.
4. Hindari integrasi berlebihan dan biarkan setiap modul hanya melakukan tugasnya sendiri.
Contoh pengembangan OA yang umum adalah biasanya terdapat banyak persetujuan dalam sistem bisnis, dan banyak orang akan langsung berpikir untuk membuat persetujuan menjadi modul universal. Tidak ada masalah dengan ini, tetapi masalah yang biasa terjadi adalah terlalu banyak orang yang memasukkan pemrosesan bisnis setelah persetujuan ke dalam logika bisnis modul persetujuan. Faktanya, itu adalah modul bisnis dari setiap modul bisnis, dan persetujuannya saja diselesaikan setelah persetujuan selesai. Namun, mengenai apa yang harus dilakukan setelah persetujuan selesai, biarkan modul yang melakukan proses ini menanganinya sendiri.
5. Hindari bersikap terlalu fleksibel
Desain dan kode tidak selalu sefleksibel mungkin. Contoh umum adalah ketika menggunakan obat generik, kelas atau metode dapat beroperasi pada objek yang berbeda. Namun, dalam arsitektur tiga tingkat yang umum digunakan di JAVA, jika serangkaian kelas pada awalnya dimaksudkan untuk beroperasi pada entitas tertentu, hal tersebut tidak diperlukan. untuk Menentukannya sebagai tipe generik, lalu menentukannya untuk menggunakan kelas entitas tertentu saat menggunakannya. Ini terasa berlebihan.
6. Kurangi lapisan gula pada fitur kue
Tidak ada penyegaran halaman, efek tampilan yang lebih keren, dll. Semuanya merupakan hal yang penting untuk sistem bisnis. Jika antarmuka bisnis menjadi sangat rumit karena hal ini, hal ini akan membawa serangkaian masalah pada pemrosesan bisnis Tidak peduli betapa indahnya antarmukanya, tidak ada gunanya jika Anda melanjutkan. Jika menyangkut satu nasihat, pertimbangkan saran lainnya hanya jika Anda ingin memastikan bahwa proses bisnis dilakukan dengan benar. Prasyarat untuk ini adalah komunikasi yang diperlukan dengan pengguna. Dengan kata lain, proyek yang dilaksanakan oleh JAVA fokus pada pemrosesan bisnis. Hanya ketika pemrosesan bisnis direalisasikan dengan baik, keindahan antarmuka dan indera visual pengguna dapat dipertimbangkan.
7. Pisahkan dengan tepat
Ini mirip dengan 4. Cobalah untuk mengurangi kompleksitas setiap modul sebanyak mungkin dan ubah pekerjaan mental menjadi pekerjaan fisik. Contoh umum adalah suatu formulir biasanya memiliki fungsi menambah, mengubah, menghapus, dan melihat. Namun, tiga operasi pertama biasanya hanya dilakukan oleh orang-orang pada titik fungsi tertentu, dalam keadaan tertentu, dan dengan izin tertentu (mungkin hanya di satu-satunya antarmuka dalam sistem). Namun, operasi tampilan akan didistribusikan di setiap sudut proyek. Jika keempat operasi ini ditempatkan dalam antarmuka yang sama, meskipun jumlah antarmuka dapat dikurangi, yang akan meningkat adalah kompleksitas antarmuka ini diproses. Buat penilaian yang diperlukan untuk membuat pengaturan read-only untuk elemen antarmuka. Peningkatan kompleksitas bersifat eksponensial, dan jika Anda membagi tampilan, beban kerjanya akan linier. Bahkan jika Anda harus membuat 10 antarmuka tampilan, kompleksitasnya akan tetap lebih tinggi dari yang sebelumnya. Jauh lebih mudah untuk mengubahnya menjadi 10*10, dan juga dapat dikomponen.
8. Jaga komunikasi yang baik dengan pelanggan
Banyak orang yang tidak memperhatikan menjaga komunikasi dengan pelanggan. Banyak arsitek yang percaya bahwa komunikasi dan komunikasi dengan pelanggan hanya diperlukan pada fase permintaan proyek di lingkungan. Hanya dengan menjaga komunikasi yang baik dengan pelanggan secara teratur kami dapat memahami perubahan kebutuhan pelanggan sesegera mungkin, sehingga menyesuaikan rencana struktur proyek kami untuk memenuhi kebutuhan pelanggan dalam waktu sesingkat mungkin.
9. Hubungan antara arsitektur proyek dan arsitektur database
Banyak orang percaya bahwa database tidak diperlukan selama pengembangan proyek, asalkan diimplementasikan dalam memori. Menurut saya pribadi ini adalah kebiasaan pengembangan yang sangat buruk. Meskipun database ditentukan sesuai dengan kebutuhan spesifik proyek. Namun, jika suatu proyek tidak mempertimbangkan arsitektur database sama sekali selama proses arsitektur, kemungkinan besar hal-hal yang diimplementasikan dalam proyek akan sulit untuk dicatat dalam database atau desain database akan sangat merepotkan, yang pada dasarnya akan meningkatkan biaya. kesulitan pengembangan proyek. Selain itu, tidak mempertimbangkan database selama proses pengembangan proyek dapat menyebabkan masalah seperti kegagalan mengimplementasikan beberapa logika bisnis, hilangnya data, dll. setelah proyek ditautkan ke database.
Tentu saja, banyak orang memiliki pendapat arsitektur berbeda berdasarkan gaya arsitekturnya yang berbeda, dan pendapat saya mungkin tidak benar. Saya berharap semua orang dapat belajar sesuatu dari karya saya, dan saya juga berharap semua orang dapat berbagi pandangan mereka tentang arsitektur.