The Journey Begins: Individual Review #1
Halo semuanya! Saya Rahmania Astrid Mochtar, atau biasa dipanggil Aci. Saya hacker dari tim Slovneek PPL D6, khususnya frontend. Di kesempatan kali ini saya ingin berbagi pengetahuan dan pengalaman saya dalam men-developt produk di sprint pertama ini. Sekalian claim nilai individual review pertama, he he.
Version Control, Team Coding, Git Flow
Sebelum PPL, memang sudah banyak tugas-tugas kuliah dimana kita diharuskan mengerjakan proyek di dalam satu repository bersama-sama. Namun belum pernah kita terapkan dengan membuat branch-branch berdasarkan user story dan penggunaan branch staging. Branch yang dibuat dulu selalu berupa nama developer dan yang mengerjakan di satu branch hanya satu orang.
Di PPL, saya memulai dengan membuat branch “US-0-Set-up-frontend” untuk set environment react beserta membuat component-component yang akan di-reuse di berbagai page. Dan bukan hanya saya yang mengerjakan task di branch tersebut, teman saya Hilya juga mengerjakan task membuat component-component basic.
Setiap saat saya ingin melakukan git push ke branch, saya selalu mencek kembali branch untuk update-an dengan melakukan git pull. Sebelumnya tentu saya melakukan git add dan git commit dulu untuk menyimpan pembaharuan yang saya buat. Setelah melakukan git pull, jika ada merge conflict maka saya harus me-resolve conflict terlebih dahulu sebelum kemudian git commit lagi dan akhirnya dapat melakukan git push.
Setelah itu saya berpikir, “Oh kalo yang ini udah selesai, langsung merge ke master,” tapi ternyata tidak! Saya harus membuat branch bernama staging terlebih dahulu sebagai bahan untuk sprint review, jika disetujui oleh Product Owner, barulah kita dapat melakukan merge ke branch master. Jika Product Owner menolak, kita harus melakukan perbaikan di branch baru bernama coldfix. Jika coldfix sudah selesai, di-merge kembali ke dalam branch staging untuk di review kembali. Dan ternyata jika di branch master terdapat bug atau test yang failed, kita harus membuat branch bernama hotfix untuk diperbaiki. Setelah itu barulah kita merge kembali ke branch master.
Software Methodology: TDD
Nah, pasti semuanya berpikir bahwa di PPL agar dapat mengejar tuntutan partner, kita harus cepat-cepat membuat working function dan component. Tapi tidak semudah itu, Fergusso! (Saya masih tidak tahu Fergusso itu siapa)
PPL menerapkan sebuah software methodology berupa TDD atau Test Driven Development. Dalam metodologi ini, kita diwajibkan untuk selalu membuat test terlebih dahulu sebagai preventif untuk bug dan ekspektasi terhadap function atau component yang kita buat. Test ini juga berguna untuk lebih mengerti kodingan teman satu team.
Untuk membuat test terhadap component React, kita menggunakan ‘react-testing-library’. Pertama dibuat test untuk component yang ingin dibuat. Misalnya saya membuat test untuk component TableComponent.
Setelah selesai, saya melakukan git add dan git commit dengan tag [RED] sebagai tanda saya telah membuat test dan test tersebut failed. Mengapa failed? Karena component yang bersangkutan belum ada! Nah, selanjutnya dibuat component TableComponent untuk dapat membuat test yang kita buat menjadi passed. Commit ini ditandai dengan tag [GREEN]. Namun bagaimana dengan code coverage-nya? Ternyata meskipun sudah passed, belum tentu code coverage-nya 100%. Untuk itu selalu memerhatikan code coverage saat melakukan testing dengan menggunakan: npm test — coverage.
Sudah selesai, kan? Nope! Belum! Terkadang kodingan component yang sudah kita buat itu redundant atau tidak rapi karena ingin mengejar code coverage 100%. Oleh karena itu, kita perlu melakukan refactoring agar kodingan yang kita buat lebih rapi dan efektif. Commit message dari task ini cukup diberikan tag [CHORES]. Dan jangan lupa kalau refactoring tidak mengubah fungsional dari component yang sudah dibuat.
Understanding Agile
“…and all will go well.” Boy were we wrong.
Saat pertama bertemu dengan partner, kita sudah diberi PBI (atau product backlog item) lengkap yang akan menjadi rancangan pembuatan aplikasi kita. Kita lalu berpikir, “Oke tinggal ikutin aja urutan prioritas PBI yang udah dibuat and all will go well.” Boy were we wrong.
Di saat kita sedang melakukan sprint planning pertama kita, Product Owner mengirimkan revisi perubahan design pada salah satu PBI kita. Di tengah-tengah kebingungan membagi task-task kepada setiap anggota kelompok, kita menjadi tambah bingung. “Kok ada revisi? Kok di tengah-tengah sprint planning pertama? Kok saya masih lapar padahal sudah makan?” Kita menjadi resah.
Ternyata ini adalah bagian dari Agile! Product Owner kami ternyata sedang mempraktekkan salah satu manifesto Agile, yaitu customer collaboration over contract negotiation. Yaitu dimana selain kesepakatan pertama, Product Owner dapat mengajukan perubahan pada rencana terutama jika itu dapat membuat kualitas produk lebih baik. Perubahan yang diberi dapat dimasukkan ke dalam sprint berikutnya. Dan itulah yang kita lakukan dengan request revisi PO.
Kemudian ditengah-tengah sprint, ternyata Oracle (DBMS yang ingin kita gunakan), harus bayar agar dapat digunakan di portainer. Tentunya ini memaksakan kita untuk mengubah rencana dan teknologi yang digunakan. Kita akhirnya menggunakan PostgreSQL sebagai DBMS kita. Perubahan rencana ini ternyata juga termasuk dari salah satu manifesto Agile, yaitu, responding to change over following a plan.
Jadi apa sih itu agile? Agile itu adalah sebuah framework project management yang bersifat iteratif. Agile membantu team development dalam merespon terhadap perubahan atau feedback pada produk. Dalam agile terdapat 4 manifesto dengan value yang sangat penting:
- Individuals and interactions over processes and tools.
Memprioritaskan kerjasama ketimbang dengan teknologi yang canggih. - Working software over comprehensive documentation.
Memprioritaskan produk yang fungsional ketimbang dengan dokumentasi lengkap. - Customer collaboration over contract negotiation
Partner yang ikut berdiskusi mengenai rencana produk. - Responding to change over following a plan
Tidak berpaku terhadap rencana yang sudah dibuat, melainkan menjadi fleksibel atas perubahan.
We he he, heboh juga ya sprint pertama-nya ya? But it’s okay! Ini termasuk dari proses pembelajaran kita sebagai mahasiswa PPL. No pain no gain, right?
Sekian post pertama dari saya. Mari lanjut koding!
