What’s next?
Setelah sebelumnya bermain-main dengan pembuatan database dummy, saatnya mengoding sesungguhnya.
Dimulai dari User Interface, task yang saya ambil pertama setelah membuat dummy database yaitu membuat header yang akan dimunculkan pada home dan halaman yang akan menunjukkan detail dari setiap barang yang dijual oleh partner kami. Saat pertama kali mulai membuat header dari sinilah saya baru merasakan contoh penggunaan React. Berikut tampilan header yang saya maksud.
Berikut merupakan contoh pembuatan React secara mendasar untuk header. Dimulai dari mengimport Component dari module react dan css(optional) kemudian diikuti dengan class dari yang ingin dibuat (dalam hal ini class Header) dan mengextends Component.
Alasan mengapa perlu mengextends Component dari react ini yaitu agar nantinya ketika di merge menjadi suatu halaman utuh halaman home, hal yang perlu dilakukan adalah seperti di bawah ini.
Dengan syarat adanya import dari header bersangkutan dimana dalam hal ini karena letak struktur folder seperti:
home
|-home.js
component
|- header (folder berisi header.js)
sehingga cara mengimport pun seperti di bawah ini.
Adapun setelah baru saja selesai membuat header dan berdiskusi dengan scrum master dan anggota lainnya serta mendengarkan pengalaman seorang senior yang pernah bekerja secara scrum, akhirnya kelompok kami memutuskan untuk bekerja seperti tim scrum sesungguhnya yang membuat branch berbeda untuk masing-masing task sesuai dengan task yang diambil dengan source branch yaitu branch masing-masing backlog.
Oleh karena itulah saya mulai memindahkan file yang memuat kode header beserta file stylesheetnya dan file lainnya agar dijadikan dalam suatu branch berbeda.
Kemudian, setelah membuat header, waktunya menyatukan kode sumber saya dengan kode sumber anggota lainnya melalui merge. Bukan menantang namanya jika tak ada masalah yang bernama MERGE CONFLICT.
Nah, benar saja ketika kami menggabungkan semua kode sumber, masalah yang dihadapi adalah perlunya merge terutama jika baru saja selesai mengerjakan di suatu branch dan mau pindah ke branch berikutnya, git bash akan menampilkan pesan perlunya merge. Mungkin bukan menjadi masalah jika hanya ingin berganti branch, tetapi menjadi masalah ketika sudah melakukan suatu pekerjaan untuk dipush tetapi tidak dapat dipush akibat adanya unmerge code seperti di bawah ini.
Hal yang bisa dilakukan ketika sudah tidak dapat dilakukan hal seperti di bawah ini.
Atau sudah tidak dapat dilakukan resolve karena bahkan semua sudah diresolve tetapi git masih mengatakan ada file yang belum di resolve maka terdapat 2 pilihan. Menghapus file tersebut jika memang sebenarnya file tersebut tidak digunakan atau memindahkan file tersebut keluar folder yang bukan merupakan git repository lalu mengepush baru memasukkan kembali file tersebut ketempat semula.
Karena merge conflict yang dihadapi bahkan tidak dapat diresolve karena besarnya scope kode sumber, akhirnya saya membuat agar masing-masing task tidak hanya dimasukkan ke dalam suatu branch berbeda tetapi juga kedalam folder berbeda, sehingga walaupun terdapat merge conflict, konflik tersebut tidak separah sebelumnya.
Setelah saya memindahkan masing-masing file dari task membuat header ke suatu folder dan mengepushnya ke gitlab, waktunya saya berpindah ke task berikutnya yaitu membuat grid description dan specification yang akan digabungkan ke halaman detail barang. Kemudian, ada lagi masalah yang muncul. Dan itu adalah penamaan branch. Setelah beberapa saat berdiskusi dengan anggota lainnya, akhirnya didapatkan kesepakatan dimana penamaan branch task menggunakan format nama branch backlog diikuti dengan nama task. Menjadi suatu pelajaran berharga bagi saya dimana saat melakukan sprint planning JANGAN LUPA MEMBUAT KESEPAKATAN SEBELUM MEMULAI MEMBUAT PROGRAM. Bahkan untuk hal-hal kecil seperti penamaan branch dan bagaimana alur branch yang diinginkan (diluar pengaturan branch yang sudah ditentukan). Karena sebelumnya saya berpikir hal-hal kecil yang dimaksud berupa task-task dan semua yang tercantum pada lean canvas.
Setelah selesai membuat component grid description dan specification beserta test untuk masing-masing task yang nantinya akan di atur peletakannya oleh anggota lainnya. Karena dalam hal ini, test yang dibuat untuk mengetest apakah UI sudah berjalan sesuai keinginan maka cara mengetestnya pun seperti di bawah ini dimana di cek apakah kode sumber dapat merender tanpa crash dengan kata lain User Interface dapat muncul tanpa adanya baris kode sumber yang salah.
Setelah task tersebut selesai, ada hal seru berikutnya. Apakah itu?
Tepat sekali, MERGE REQUEST. Ketika masing-masing task User Interface sudah selesai, saya pun mulai melakukan merge request. Setelah melakukan merge request terhadap branch task yang saya buat, waktunya mereview merge request yang dibuat oleh anggota lainnya.
Setelah melihat bagaimana hasil kerja anggota lainnya dan memberikan komentar, waktunya melakukan merge terhadap branch task yang sudah selesai direview dan diperbaiki oleh anggota yang bersangkutan. Saat itu, saya melakukan merge terhadap task-task yang berhubungan dengan home.
Setelah melakukan merge terhadap branch-branch task tersebut, waktunya memperbaiki merge conflict yang ada.Berbeda dengan merge conflict sebelumnya yang terjadi ketika berganti branch. Kali ini merge conflict yang seru yaitu bagaimana caranya menyelesaikan merge conflict yang ada sambil memerhatikan agar kode sumber anggota lainnya tidak mengalami masalah akibat melakukan resolve merge conflict. Selain itu, bahkan dalam merge conflict kali ini masih memiliki masalah yang sama yaitu ketika sudah selesai melakukan merge conflict kadangkala git bash menyatakan masih ada yang belum di merge sehingga tidak dapat melakukan push untuk resolve merge conflict yang ada.
Setelah menyelesaikan permasalahan merge conflict, saya berpindah ke task berikutnya yaitu membuat fungsi mengambil data dari database dummy. Namun, saat ini saya pun sedang dalam tahap membuat fungsi untuk mengambil data dari database aslinya nanti. Karena masih adanya fungsi yang belum selesai, sehingga masih perlunya penyelesaian terhadap error yang ada.
Demikian cerita pengalaman seru saya selama beberapa minggu ini bekerja dalam tim scrum.
