Trade-off Perisian

Setiap pilihan reka bentuk yang anda buat akan menutup pintu kepada pilihan yang lain. Perisian berfungsi melalui trade-off. Anda mesti membuat pilihan ini dengan sengaja. Jika tidak, anda akan membuatnya secara tidak sengaja.

Trade-off biasa yang anda hadapi:

• Fungsionaliti vs Prestasi Kod yang bersih sering kali berjalan lebih lambat. Kod yang pantas sering kali sukar dibaca. Gunakan kod yang mudah dibaca untuk proses berkelompok (batch processes) yang berjalan sekali sehari. Gunakan kod yang dioptimumkan untuk laluan (paths) yang berjalan beribu-ribu kali bagi setiap permintaan (request).

• Fleksibiliti vs Kesederhanaan Abstraksi yang kompleks menjadikan kod sukar difahami. Tulis kod yang paling ringkas yang berfungsi. Bina ia supaya anda boleh mengembangkannya kemudian.

• Kebolehskalaan vs Kos Mereka bentuk untuk trafik yang besar memerlukan lebih banyak wang sekarang. Mengukur kadar pertumbuhan anda membantu anda membuat keputusan. Jika anda berkembang 20% setiap bulan, rancanglah untuk masa hadapan. Jika anda mempunyai modal yang rendah, pantau kos anda.

• Keselamatan vs Kebolehgunaan Keselamatan yang melampau boleh merosakkan pengalaman pengguna. Kami pernah mewajibkan token perkakasan untuk alat pentadbir. Kejayaan log masuk jatuh daripada 98% kepada 84%. Jurutera terkunci daripada sistem semasa kecemasan. Kami beralih kepada pemberitahuan tolak (push notifications) mudah alih. Kadar kejayaan meningkat semula kepada 96%. Sasarkan keselamatan yang munasabah, bukan keselamatan maksimum.

Cara membuat keputusan yang lebih baik:

  • Nyatakan matlamat anda dengan jelas.
  • Ukur data dan bukannya meneka.
  • Mulakan dengan penyelesaian yang ringkas.
  • Optimumkan hanya apabila anda mempunyai bukti.
  • Dokumentasikan mengapa anda membuat pilihan tersebut.

Saya pernah cuba mengoptimumkan pensiri (serializer) JSON untuk menjimatkan beberapa mikrosaat. Ia menyebabkan kebocoran memori (memory leak) yang meningkat sebanyak 300 MB. Profiler menunjukkan bahawa I/O rangkaian adalah kekangan (bottleneck) yang sebenar. Sentiasa gunakan profiler sebelum anda menulis semula kod.

Hutang teknikal (Technical debt) adalah benar. Jalan pintas hari ini akan memakan masa pada masa hadapan. Apabila kami mewarisi perkhidmatan yang berselerak, kami tidak melakukan penulisan semula yang besar. Kami menggunakan perubahan kecil yang berterusan. Kami meningkatkan liputan ujian (test coverage) daripada 30% kepada 78%. Ini mengurangkan masa pembaikan pepijat daripada 4 hari kepada 1.2 hari.

Trade-off tidak bersifat kekal. Semak semula keputusan anda. Periksa sama ada pengoptimuman anda masih relevan. Bersikap sengaja (intentional) dapat mengelakkan sistem yang sederhana dalam segala hal.

Sumber: https://dev.to/lavkeshdwivedi/software-tradeoffs-44e7

Komuniti pembelajaran pilihan: https://t.me/GyaanSetuAi