Kriteria arsitektur perangkat lunak yang baik

Efisiensi

Pemrogram berpengalaman dapat dengan mudah membedakan arsitektur yang baik dari yang buruk, tetapi jika diminta untuk mendeskripsikannya dalam beberapa kata, mereka tidak mungkin dapat melakukannya. Tidak ada kriteria tunggal untuk arsitektur yang baik dan tidak ada definisi tunggal.

Namun, jika dipikir-pikir, Anda dapat menulis sejumlah kriteria yang harus dipenuhi oleh arsitektur yang baik. Arsitektur yang baik , pertama-tama, adalah arsitektur logis yang membuat proses pengembangan dan pemeliharaan program menjadi lebih sederhana dan efisien.

Ketika sebuah program memiliki arsitektur yang baik, selalu cukup mudah untuk memahami cara kerjanya dan di mana harus menulis kode. Program yang dirancang dengan baik lebih mudah untuk diubah, diuji, di-debug, dan dikembangkan. Orang pintar telah merumuskan kriteria berikut untuk arsitektur yang baik:

• Efisiensi;
• Fleksibilitas;
• Perluasan;
• Skalabilitas;
• testabilitas;
• Pemeliharaan kode.

Efisiensi sistem. Program tersebut tentunya harus menyelesaikan tugas yang diberikan dan menjalankan fungsinya dengan baik, dan dalam berbagai kondisi. Tampaknya program apa pun melakukan apa yang seharusnya dilakukan (jika ditulis), tetapi seringkali tidak demikian.

Anda akan selalu menemukan program yang tidak melakukan apa yang diklaimnya.

• Libre Office adalah pengganti penuh untuk Microsoft Office (tidak juga);
• Browser Edge mendukung semua standar web (tidak juga);
• Bank peduli dengan keamanan data pribadi penggunanya (sebenarnya tidak).

Dan kami belum menyentuh kinerja, keandalan, perbaikan bug tepat waktu, atau publikasi informasi tentang kerentanan yang diketahui.

Jelas bahwa tidak ada orang yang sempurna, tetapi program harus menyelesaikan tugas utamanya. Oleh karena itu, tanpa efisiensi, tidak ada tempat.

Fleksibilitas

Satu-satunya hal yang lebih penting daripada efisiensi menurut saya adalah fleksibilitas. Aplikasi apa pun harus berubah seiring waktu, karena persyaratan berubah, yang baru ditambahkan. Semakin cepat dan nyaman melakukan perubahan pada fungsionalitas yang ada, semakin sedikit masalah dan kesalahan yang ditimbulkannya, semakin fleksibel arsitektur sistem.

Sangat sering, pemrogram / arsitek pemula berpikir bahwa mereka membutuhkan arsitektur yang ideal untuk tugas saat ini. TIDAK. Anda memerlukan arsitektur yang ideal untuk tugas-tugas yang akan diumumkan kepada Anda dalam setahun. Anda, yang sekarang tidak mengetahui tugas-tugas yang akan datang, harus tahu akan seperti apa tugas itu nantinya.

Tidak masuk akal untuk mencoba memprediksinya, karena akan selalu ada sesuatu yang tidak terduga. Tetapi Anda harus memperhitungkan bahwa tugas seperti itu akan muncul. Oleh karena itu, dalam proses pengembangan, cobalah mengevaluasi apa yang diperoleh dalam hal bagaimana hal itu perlu diubah.

Tanyakan pada diri Anda: "Apa yang terjadi jika keputusan arsitektur saat ini ternyata salah?", "Berapa banyak kode yang akan diubah?". Mengubah satu fragmen sistem seharusnya tidak memengaruhi fragmen lainnya.

Kapan pun memungkinkan, keputusan arsitektural tidak boleh dibuat kaku, dan konsekuensi dari kesalahan arsitektural harus dibatasi secara wajar. "Arsitektur yang baik memungkinkan Anda MENUNDA keputusan penting" (Bob Martin) dan meminimalkan "biaya" kesalahan.

Salah satu pendekatan ini adalah membagi aplikasi menjadi layanan mikro: mudah untuk memecah logika yang sudah ada menjadi beberapa bagian. Tetapi masalah terbesar adalah membuat perubahan di masa mendatang pada selusin layanan sekaligus untuk mengimplementasikan satu fitur kecil.

Skalabilitas

Skalabilitas adalah kemampuan untuk mengurangi waktu pengembangan dengan menambahkan orang baru ke proyek. Arsitektur harus memungkinkan proses pengembangan diparalelkan sehingga banyak orang dapat mengerjakan program pada saat yang bersamaan.

Tampaknya aturan ini dilakukan dengan sendirinya, tetapi dalam praktiknya semuanya justru sebaliknya. Bahkan ada buku yang sangat populer, The Mythical Man-Month , yang menjelaskan mengapa menambahkan orang baru ke proyek akan meningkatkan waktu pengembangan.

Perluasan

Ekstensibilitas adalah kemampuan untuk menambahkan fitur dan entitas baru ke sistem tanpa merusak struktur intinya. Pada tahap awal, masuk akal untuk memasukkan hanya fungsionalitas dasar dan paling penting ke dalam sistem.

Inilah yang disebut prinsip YAGNI - Anda tidak akan membutuhkannya , “Anda tidak akan membutuhkannya”. Pada saat yang sama, arsitektur harus memungkinkan Anda untuk dengan mudah meningkatkan fungsionalitas tambahan sesuai kebutuhan. Dan agar pengenalan perubahan yang paling mungkin membutuhkan usaha paling sedikit.

Persyaratan bahwa arsitektur sistem harus fleksibel dan dapat diperluas (yaitu, mampu berubah dan berevolusi) sangat penting bahkan dirumuskan sebagai prinsip terpisah - "Prinsip Terbuka/Tertutup " . Prinsip Terbuka-Tertutup adalah yang kedua dari lima prinsip SOLID: entitas perangkat lunak (kelas, modul, fungsi) harus terbuka untuk ekstensi, tetapi tertutup untuk modifikasi .

Dengan kata lain: harus dimungkinkan untuk mengubah dan memperluas perilaku sistem tanpa menulis ulang bagian sistem yang ada .

Ini berarti bahwa aplikasi harus dirancang sedemikian rupa sehingga mengubah perilakunya dan menambahkan fungsionalitas baru dapat dicapai dengan menulis kode baru (ekstensi), tanpa harus mengubah kode yang sudah ada.

Dalam hal ini, munculnya persyaratan baru tidak memerlukan modifikasi logika yang ada, tetapi dapat diimplementasikan terutama dengan memperluasnya. Prinsip ini adalah dasar dari "arsitektur plug-in" (Arsitektur Plugin). Teknik-teknik untuk mencapai hal ini akan dibahas nanti.

Ingat servlet dan filter? Mengapa filter diperlukan, dan bahkan dengan antarmuka terpisah, jika, pada kenyataannya, semua logika yang sama dapat diimplementasikan menggunakan servlet?

Itu adalah penemuan konsep filter (servlet layanan) yang memungkinkan untuk memindahkan berbagai fungsi layanan ke lapisan terpisah. Dan di masa mendatang, saat mengubah perilaku filter, servlet tidak perlu diubah.

Sebelum penemuan filter, semua logika layanan yang bertanggung jawab untuk mengarahkan ulang permintaan terletak di servlet itu sendiri. Dan seringkali satu perubahan kecil dalam logika akan mengarah pada kebutuhan untuk melewati semua servlet dan membuat berbagai perubahan pada semuanya.

Testabilitas

Jika Anda adalah Pengembang Java Backend, maka aplikasi server Anda sering menampilkan serangkaian metode sebagai REST API. Dan untuk memeriksa apakah semua metode Anda berfungsi sebagaimana mestinya, metode tersebut harus ditutup dengan pengujian.

Secara umum, cakupan pengujian API adalah gaya yang bagus. Ini memungkinkan Anda untuk memastikan bahwa API Anda benar-benar melakukan apa yang seharusnya dilakukan. Dan juga, yang lebih penting, Anda dapat membuat perubahan pada logika server dan dengan mudah memeriksa bahwa Anda tidak merusak apa pun secara tidak sengaja .

Segera setelah Anda mulai menulis pengujian, Anda akan menyadari bahwa sebagian besar kode tidak dapat diuji sama sekali: metode privat, penggabungan kuat, kelas dan variabel statis.

“Mengapa kita membutuhkan tes jika kodenya berfungsi?”, seorang pemula akan bertanya.

“Mengapa kita membutuhkan kode yang berfungsi jika tidak dapat diuji?”, profesional akan bertanya.

Kode yang mudah diuji akan mengandung lebih sedikit bug dan lebih andal. Tetapi pengujian tidak hanya meningkatkan kualitas kode. Hampir semua pengembang pada akhirnya sampai pada kesimpulan bahwa persyaratan “keterujian yang baik” juga merupakan kekuatan penuntun yang secara otomatis mengarah pada desain yang baik.

Berikut kutipan dari buku Ideal Architecture: "Gunakan prinsip "testabilitas" suatu kelas sebagai "uji lakmus" dari desain kelas yang baik. Bahkan jika Anda tidak menulis satu baris pun kode uji, jawab pertanyaan ini dalam 90 % kasus akan membantu untuk memahami bagaimana semuanya baik" atau "buruk" dengan desainnya."

Ada keseluruhan metodologi untuk mengembangkan program berdasarkan tes, yang disebut Test-Driven Development (TDD). Ini tentu saja ekstrem lainnya: tulis kode sebelum Anda menulis kode.

Pemeliharaan kode

Sebagai aturan, banyak orang mengerjakan program - beberapa pergi, yang baru datang. Waktu kerja rata-rata seorang programmer di perusahaan IT adalah satu setengah tahun. Jadi jika Anda datang ke proyek yang berumur 5 tahun, maka hanya 20% rekan Anda yang mengerjakannya sejak awal.

Mempertahankan dan mengembangkan program yang telah ditulis orang lain sangatlah sulit. Sekalipun program sudah ditulis, seringkali perlu untuk terus memeliharanya: memperbaiki kesalahan dan melakukan koreksi kecil. Dan seringkali ini harus dilakukan oleh orang yang tidak ikut menulisnya.

Oleh karena itu, arsitektur yang baik harus membuatnya relatif mudah dan cepat bagi orang baru untuk memahami sistem tersebut . Proyek harus:

• Terstruktur dengan baik.
• Jangan mengandung duplikasi.
• Memiliki kode yang diformat dengan baik.
• Sebaiknya sertakan dokumentasi.
• Penting untuk menerapkan solusi standar dan familiar bagi pemrogram.

Anda dapat dengan mudah menilai proyek yang sedang Anda kerjakan pada skala 5 poin . Hitung saja dua poin untuk masing-masing persyaratan ini . Dan jika Anda mendapatkan 5 atau lebih, maka Anda beruntung.

Pemrogram bahkan memiliki prinsip yang paling tidak mengejutkan : semakin eksotis sistemnya, semakin sulit bagi orang lain untuk memahaminya. Biasanya, ini digunakan dalam kaitannya dengan antarmuka pengguna, tetapi juga berlaku untuk menulis kode.