Bahaya Race Condition, Bisa Sebabkan Kerugian Finansial Fatal

Bahaya Race Condition, Bisa Sebabkan Kerugian Finansial Fatal

by with No Comment article 
Perhatikan contoh kasus ini!

Tritan memiliki aplikasi web toko online yang menjual produk elektronik. Terpantau, ada 3 buyer sedang mengakses halaman produk yang sama secara bersamaan.

  1. Buyer 1 lihat stok produk smart TV merek xyz ada 10
  2. Buyer 2 lihat stok produk smart TV merek xyz ada 10
  3. Buyer 3 lihat stok produk smart TV merek xyz ada 10

Nah, ketiga buyer tadi mengklik tombol ‘Beli’ di saat yang sama. Jika ketiga permintaan itu dikirim ke server secara bersamaan, kemungkinan buruk apa yang akan terjadi, dan bagaimana cara mengatasinya? Lanjutkan membaca! Setelah kejadian klik tombol ‘Beli’ bersamaan, kemungkinan urutan kejadian yang muncul bisa jadi:

  1. Buyer 1 – server mengurangi stok produk smart TV merek xyz jadi 9
  2. Buyer 2 – server mengurangi stok produk smart TV merek xyz jadi 9
  3. Buyer 3 – server mengurangi stok produk smart TV merek xyz jadi 9

Setelah ketiga permintaan diproses, stok produk smart TV merek xyz tetap menjadi 9. Kondisi ini terjadi karena ketiga permintaan tadi saling bersaing untuk mengurangi stok tanpa melihat jika tindakan satu buyer bisa mempengaruhi aksi buyer lainnya. Kondisi yang terjadi pada kasus tadi dikenal dengan istilah Race Condition. Dalam konteks aplikasi backend, #racecondition muncul jika perilaku atau hasil dari aplikasi tergantung pada waktu / urutan kejadian. Pada aplikasi backend, race condition bisa menjadi masalah serius seperti:

  1. Korupsi data
  2. Inkonsistensi, dan
  3. Kesalahan lain yang bisa berdampak buruk pada fungsionalitas dan performa aplikasi

Dalam konteks transaksi finansial, masalah konsistensi data akibat race condition akan sangat berbahaya. Bahkan, bisa menyebabkan kerugian finansial yang serius. Contoh kasus sederhana, meski sudah melakukan 5 kali transaksi, saldo nasabah hanya berkurang Rp 10.000, padahal harusnya berkurang Rp 50.000.

Berdasarkan kasus itu, Kita simpulkan bahwa perjalanan saldo pada column balance_before dan balance_after mengalami kekacauan. Jadi saldo tidak bergerak sebagaimana mestinya. Penyebabnya karena transaksi terjadi nyaris bersamaan. Sehingga transaksi berikutnya muncul sebelum transaksi sebelumnya menyelesaikan proses update current_balance.

Apa yang bisa tim IT developer lakukan untuk menyelesaikan persoalan tadi?
Pessimistic Locking pada JPA menjadi salah satu solusi yang bisa dipakai untuk mengatasi masalah race condition.

Deleloper backend bisa mengaplikasikan mekanisme sinkronisasi seperti penguncian (locking) atau transaksi atomik. Dengan menerapkan mekanisme sinkronisasi yang tepat, kita dapat menghindari race condition dan memastikan integritas data dalam aplikasi backend. Seperti apa simulasi penerapan Pessimistic Locking pada JPA? Simak pembahasannya pada artikel lain.

Auhor: Herry Pramono

Membangun kolaborasi efektif antara QA dan Developer

Membangun kolaborasi efektif antara QA dan Developer

by with One Comment article

Tahukah Kamu, suksesnya pengembangan perangkat lunak itu kuncinya pada tim Quality Assurance dan developer? Kok hanya dua tim itu yang disebut? Begini penjelasannya. 

Developer bertanggung jawab untuk merancang, mengembangkan dan menguji code sistem aplikasi. Sementara tugas tim QA memastikan standar kualitas aplikasi yang sudah dibuat oleh developer.  

Nah, sekarang coba bayangkan jika kedua divisi tadi tak punya hubungan harmonis alias kolaborasinya tidak berjalan efektif! Pengembangan aplikasi pasti akan mengalami kerugian, diantaranya:

Kualitas produk menurun

Tim QA seringkali dianggap lawan karena pekerjaannya yang suka mencari-cari kesalahan developer. Anggapan tadi tentu tidak benar ya. Sesuai job desk, tim QA bertanggung jawab untuk menguji dan memastikan software sudah memenuhi standar kualitas yang ditetapkan, sebelum diserahkan ke user. Tanpa kolaborasi yang baik, software aplikasi mungkin tidak akan berjalan maksimal. Alhasil, user mengalami kerugian bisnis karena aplikasi yang dikembangkan sering error.

Proses deliver produk tak sesuai timeline

Proses pengembangan dan uji coba aplikasi biasanya berlangsung paralel. QA bisa melakukan pengujian sistem tanpa harus menunggu developer menyelesaikan semua code aplikasinya. Jika developer dan QA tidak bekerja sama, proyek pengembangan aplikasi tidak akan berjalan efektif sesuai timeline yang disepakati. 

Kurangnya transparansi

Tim QA tidak punya visibilitas penuh dalam progress pengembangan. Akibatnya, mereka sering kesulitan untuk merencanakan pengujian. Sehingga, QA akan menanggung kelebihan beban kerja pada tahap akhir proyek dan menyebabkan peningkatan risiko pada kualitas produk.

Ketidakcocokan prioritas

Kerjasama yang kurang baik memicu risiko ketidakcocokan prioritas antara QA dan developers. QA mungkin fokus pada peningkatan kualitas dan stabilitas, sementara developers lebih fokus ke pengiriman fitur-fitur baru. Konflik ini bisa mengganggu keseimbangan kualitas, kecepatan pengiriman, dan produknya bisa jadi tidak memenuhi ekspektasi pelanggan.

Untuk menghindari beberapa kerugian di atas, Kita perlu memberdayakan developer dan QA agar bisa berkolaborasi dengan efektif. Beberapa langkah strategis yang perlu dibiasakan, seperti:  

  • Komunikasi terbuka

Membiasakan komunikasi terbuka bisa dilakukan dengan cara mengadakan pertemuan reguler, pemakaian tool kolaborasi, dan komunikasi langsung antar anggota tim. Saat pertemuan langsung, developer dan QA bisa menyampaikan update proyek, berbagi pengetahuan, dan membahas masalah yang mungkin dihadapi oleh kedua tim. 

  • Keterlibatan QA sejak awal:

Keterlibatan QA sejak tahap awal pengembangan bisa memberi masukan soal standar kualitas, desain, dan pengujian sebelum kode dikembangkan. Dengan begitu, potensi perubahan besar atau perbaikan bisa teridentifikasi lebih awal, sehingga tidak menghabiskan waktu dan tenaga.

  • Kolaborasi dalam perencanaan:

Merencanakan proyek bisa dikerjakan bersama. QA bisa memberi input pengujian yang diperlukan. Sementara developers akan mengestimasikan waktu dan sumber daya.

  • Retrospektif dan pembelajaran:

Setelah tahap iterasi, biasanya QA dan developer akan melakukan retrospektif. Gunanya, untuk mengevaluasi segala hal seperti pengembangan yang sukses, apa yang perlu diperbaiki, dan bagaimana  keduanya bisa bekerja sama lebih efisien di masa depan. Dengan berpegang pada sikap belajar dan terus meningkatkan proses, tim dapat terus tumbuh dan memberikan hasil yang lebih baik.

  • Budaya Kolaboratif:

Membangun budaya kerja kolaboratif itu penting. Tim QA dan developer harus dihargai dan didorong untuk bekerja sama secara timbal balik. Menghargai kontribusi masing-masing anggota tim dan mengakui kerja keras mereka akan memotivasi mereka untuk bekerja bersama dan mencapai

Teknologi yang wajib dikuasai oleh Programmer selain coding

Jangan Cuma Coding, Programmer Juga Wajib Kuasai Teknologi ini!

by with No Comment article

Kemampuan membuat kode dalam bahasa pemrograman tertentu menjadi skill wajib seorang programmer. Tetapi, profesi programmer saat ini tidak hanya berkutat pada produksi kode program atau aplikasi saja. Banyak skill dan teknologi lain di luar pemrograman yang perlu juga programmer pahami jika ingin karirnya berkembang. Artikel ini akan menjelaskan beberapa teknologi yang hukumnya wajib dikuasai oleh programmer jika mau tetap relevan di dunia IT. Continue Reading