Home > Uncategorized > Say No to DELete

Say No to DELete

disadur dari Don’t Delete – Just Don’t

Fitur delete hampir pada setiap aplikasi dapat kita temui terutama di IS. Ada form. Tinggal lihat button2 maka tombol delete pun tidak susah ditemukan. Ntah mw single entry ato multiple dll. Yg penting ada data pasti bisa di delete. Nah sebenarnya di balik tombol delete itu apa sih yg terjadi ?

Cara yg paling simple implementasi dari delete adalah.. ya delete aja langsung dari database. Ga ush pikir panjang. Loh.. kok gitu. Coba misalnya kita mw delete Item dari daftar barang jualan. Gimana dengan pemesanan yg pernah ada terhadap barang itu. Apa mw di delete juga? Gimana dengan Invoice dan dll. Mw di delete juga. Apa semua yg berhubungan harus di cascade. Trus klo invoicenya dibuang gimana dengan accounting. Bisa kacau dong.. Gak bisa ke track dong. Weleh.. Apa harus kalkulasi ulang semuanya?

Ada juga yg bikin implementasi delete itu dengan nambahin satu field di DB.. IsDeleted atau IsActive dll. Alasannya supaya gak ada data yg hilang. Bisa tracking dsb. Audit. dll Tapi kadang kita gak tw ngapain sih kita delete suatu item. Ngapain kita delete suatu data. Apa skenario yg sebenarnya di dunia nyata. Kenapa kita harus mendelete suatu data. Emang user benar2 minta fitur delete ya? Ato kita yg menyarankan tersedianya fitur itu untuk mereka ?

Emang udh salah dari awal bos. Dari dulu kita emang menyajikan data ke user selalu dalam bentuk CRUD. Setiap entity ada C R U D. jadi bahasa kita pada saat requirement pun seperti itu. Menjadi Ubiquitous Language. Cuman sayang. Salah besar bahasanya. Hahahah.

Nah. Sebenarnya kita harus mikir. ngapain sih si user itu mendelete item? Sebenarnya yg mw mereka lakukan apa? Kita ambil contoh. Kita mw menghapus product A. hapus? Sebenarnya sih product A itu udh gak mw diproduksi lagi. Itu sebenarnya yg terjadi di dunia nyata. Efek dari product yg tidak diproduksi itu lagi pasti ada dong. Sudah jelas. Namanya aja objectnya berubah state. Jd nanti product tersebut gak bakal tampil lagi di daftar produk yg akan ditawarkan untuk dijual ke consumen. Di inventory tidak terdaftar. Gak di order lagi dari supplier. Tapi di sisi lain tetap aja produk merupakan interest bagi satu pihak. Meskipun di pihak yg lain tidak. Contohnya warehouse. Jadi gak se simple hilangkan satu row dari DB man.

Modelkan Task nya. Bukan datanya.

Kita kembali ke masalah product yg tidak diproduksi lagi. Gimana kita merepresentasikan nya dalam aplikasi. Yg sering kita buat biasanya seperti ini. Pilih sebuah row pada suatu grid dan klik delete button maka muncul alert ‘Are u sure want to delete ?’

Coba kita telaah lebih lanjut.

1. Order itu gak di delete tapi di cancel. Ato dibatalkan. Banyak peraturan yg terjadi jika order dibatalakan. Masalah biaya, administrasi, perjanjian ato yg lainnya.
2. Employee gak di delete. Tapi dipecat ato pensiun. Tentu dapat tunjangan dll dong.
3. Job available itu gak di delete. Tapi mungkin udh ada yg ngisi lowongan itu ato yg lainnya.

Jadi sebenarnya aplikasi itu lebih dekat kepada apa yg sebenarny user mw lakukan. Bukan gimana kita aduk2 entity itu dengan CRUD. Ini yg perlu dicermati di dalam membuat aplikasi.

Status

Kita udh liat contoh di atas. Kata delete yg cuman satu huruf itu menyesatkan. Menyembunyikan bisnis proses yg ada di belakangnya. Trus gimana dengan field wasDelete ato isActive itu. Klo pake itu bisa gak? Gak jugalah coy. Itu juga gak jelas aktif nya kenapa ato gak. Emang statusnya hanya aktif dan gak? Kita harus membuat bussines status itu jadi explicit. Status yg dimengerti oleh user. Karena setiap user itu berbeda2 perlakukaan nya terhadap satu barang dengan status tertentu.

Bagian warehouse harus tahu barang2 apa yg gak dilanjutin lagi. Jadi dia ntar gak perlu order lagi barang itu dari supplier. Ato ngebatalin kontrak. Klo untuk customer ya barang2 itu gak keliatan lagi. Karena udh gak dijual lagi sama perusahaan itu. Beda kan? Padahal statusnya dari barang itu sama aja discontinued. Tapi sudut pandangnya yg beda.

Rules and Validation

Udh jelas kan. Gak seperti membalikkan telapak tangan. Delete. Zup. Lenyap. Misalnya cancel order. Banyak kasus yg mungkin terjadi dan perlu dipertimbangkan. Klo misalnya barang tersebut kebetulan udh diantar dsb.

Jadi status dari entity tersebut sangat bergantung terhadap business proses yg ada. State transition itu sangat bergantung kepada konteks dan waktu. Pada saat ini mungkin task itu bisa dilakukan tapi waktu lain tidak. Mungkin aja ada beberapa entity yg terpengaruh karena perubahan state dari suatu object.

Summary

Mungkin kt mikir .. Ah.. gak sekompleks itu kok system ku. Ya delete aja. Ya selesai. Habis perkara. Tapi pernah gk kita nanya ke user. Kok lu delete tu barang sih? Ada gak yg terpengaruh dengan pendeletan tersebut. Statusnya apa sih? Peraturannya apa?

Sebenarnya kita dibayar mahal2 kan untuk mengcapture itu semua. Status2 tadi itu. Jadi user lebih mudah dan terbantu. Aplikasinya kaya. Dan sesuai dengan domainnya. Jadi bisnis mereka bisa jalan dengan lancer. Klo gak gitu. Kok gak kasih aja tu user MS Access?

Nah.. Karena yg kita kasih sama user itu bukan MS Access. Jadi jangan DELETE. Perhatikan alasan2nya. Perhatikan Statusnya. State Change. Group2 user yg mana aja yg care sama status A ato B dan C. Gimana efeknya sama masing2 group user.

Jadi. Jangan Delete. JANGAN.

Categories: Uncategorized
  1. apparamu
    December 11, 2009 at 7:26 am

    hahahaha….
    SAY YES TO DELETE…..
    :D:D:D:D
    tergantung kasus nya juga pra.
    kalau si empunya aplikasi pengen ada delete gimana pra???

    • weltam
      December 11, 2009 at 7:53 am

      seperti yg kubilang di atas lah.. si user itu apa yg kw sarankan mungkin aja di turutin nya..
      dan dia juga gak perduli gimana kw merepresentasikan data itu..
      yg diperdulikannya pekerjaannya bisa terbantu dengan itu..
      jadi jangan pengaruhi pikiran user mu dengan membawa teknis..

      sebenarnya yg memperkenalkan delete itu kan developer.
      ato edit..

      harus lebih explicit..
      😀

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: