Persona, Refactoring, Data Seeding

Rehan Hawari
kelompok-propensi
Published in
3 min readApr 4, 2019

Persona

Persona merupakan gambaran seperti apa orang yang akan menggunakan aplikasi yang akan dikembangkan. Pada proyek yang sedang saya dan teman-teman kembangkan, terdapat dua persona. Keduanya memiliki kepentingan masing-masing, yang pada intinya mereka menggunakan simulator payment ini untuk mencari tahu bagaimana alur pembayaran ke doku. Simulator payment kami dibuat untuk memudahkan merchant yang belum mengetahui cara pembayaran di doku, jadi kedua persona tadi merupakan merchant baru atau yang sedang ditargetkan doku untuk bergabung. Keduanya memiliki keinginan melakukan transaksi pembayaran yang tidak merepotkan dan dapat menghemat waktu. Hal ini cocok dengan simulator payment yang dibuat karena simulator sangat membantu (dengan adanya ilustrasi) dan memberi gambaran bagaimana cara pembayaran ke doku.

Refactoring

Di week 7 kali ini saya juga sempat melakukan refactoring. Salah satunya adalah extract variabel. Extract variabel biasanya dilakukan ketika kode yang dituliskan sudah terlalu kompleks dan sulit untuk meng-handle-nya di kemudian hari, atau juga ketika variabel tersebut konstant tetapi sering sekali digunakan. Sebelum saya melakukan refactoring kode saya seperti berikut:

Mengingat di method lain saya juga melakukan hal yang sama, seperti berikut:

Saya akhirnya mengganti setiap key yang sebelumnya dituliskan hardcoded sebagai variabel final string. Hal ini memudahkan saya menggunakan key berkali-kali tanpa takut salah menuliskan nama key. Berikut hasil refactoring saya:

Penggunaan variabel:

Penggunaan variabel di method lain:

Refactoring diatas juga dapat diterapkan pada conditional yang kompleks (bisa mengubahnya ke variabel). Namun sayangnya, pada kode yang saya buat belum ada kode seperti itu sehingga salah satu refactoring extract variable yang mirip adalah seperti diatas.

Data Seeding

Simulator yang kami kembangkan membutuhkan data-data awal untuk beroperasi, seperti data pembelian dan data user. Pada awal-awal sprint kami belum menerapkan automatic data seeding, tetapi karena kebutuhan yg mendesak dan malas melakukan hal yang sama berulang-ulang kali. Akhirnya, salah satu teman saya mengimplementasikannya. Idenya adalah setiap kali deploy, data harus sudah ada pada database.

Penambahan properties dilakukan pada spring, yakni spring data resource yang di-set always. Artinya setiap aplikasi dijalankan, spring akan menginisialisasi kembali data-data pada database. Sejauh, ini cara tersebut bekerja dengan baik di local maupun environment development. Namun, kami mendapati issue baru. Karena selalu dilakukan initialization database, maka data-data yang dituliskan saat aplikasi berjalan hilang. Ini merupakan salah satu tradeoff dari metode ini. Nantinya kami ingin mencari cara baru lagi agar dapat ‘migrate’ data yang sudah ada sehingga tetap ada dan tidak dihapus.

--

--