Sprint 2

Artikel ini dibuat sebagai refleksi Sprint 2 Proyek Kelas mata kuliah PMPL (Penjaminan Mutu Perangkat Lunak) di Fakultas Ilmu Komputer Universitas Indonesia.

Introduction

Pada mata kuliah PMPL, kami diminta untuk mengerjakan satu proyek kelas. Proyek kelas dikerjakan secara ‘keroyokan’ dengan tujuan untuk meningkatkan kompetensi mahasiswa dalam mengembangkan aplikasi. Di sini, kita diberi kebebasan untuk menambahkan suatu fitur, atau memperbaiki aplikasi baik itu dari segi fitur, maupun kualitas kode.

Setiap peserta diberikan kesempatan untuk mengusulkan apa yang ia ingin lakukan kepada aplikasi tersebut. Usul tersebut akan diproses, kemudian jika usul tersebut diterima, akan diubah menjadi issue. Setelah itu, akan diberikan beberapa sprint bagi peserta untuk mengimplementasikan fitur-fitur yang diusulkannya, yang di-assign ke mereka.

Beberapa fitur bisa saja diusulkan oleh beberapa mahasiswa. Oleh karena itu, issue tersebut entah dapat dikerjakan bersama, atau dikerjakan sendiri oleh mahasiswa yang pertama kali meng-assign issue tersebut ke mereka. Ini tentu berbeda per issue.

Apa yang dimaksud dengan Proyek Kelas disini?

Proyek kelas yang dimaksud adalah Digipus. Menurut deskripsi pada Repository:

Digipus is a system application that can accommodate archiving educational material from regional apparatus, academics, and practitioners, and organizing it properly so that it becomes material for increasing knowledge and skills for the community at large.

There are three personas here, Admin, Contributor, and User (General Public). As admins, they monitor contributors and material uploaded by contributors by rejecting or approving uploaded material. As contributors, they can upload a material. And as a user, they can look at the material uploaded by contributor.

Proyek ini merupakan proyek hibah dari mata kuliah PPL (Proyek Perangkat Lunak), tetapi yang unik dari proyek ini adalah fakta bahwa proyek ini merupakan proyek yang belum terselesaikan pada masa development sesuai dengan ketentuan pada mata kuliah PPL.

Pengalaman pada Sprint 2

Pada sprint 2, saya dipertemukan dengan situasi dimana kode terbaru master merupakan kode yang gagal pada saat eksekusi pada pipeline. Oleh karena itu, setelah saya pull, saya harus me-reset hard terlebih dahulu ke commit terbaru yang tidak gagal eksekusi pada pipeline. Selain itu, saya juga melaporkan hal ini kepada asdos agar dapat menyampaikan hal tersebut ke orang yang melakukan merging terakhir yang tidak lolos pipeline.

Apakah fitur yang saya kerjakan pada Sprint 2?

Fitur yang saya kerjakan pada sprint 2 adalah User Guide. User guide ini berisi panduan yang berisi fitur apa saja yang ada pada saat pembuatan user guide beserta cara menggunakannya. Fitur-fitur yang saya gunakan merupakan apa yang telah ada pada README.md, dan tidak meng-include feature yang sedang in development oleh rekan-rekan sekelas PMPL (meski dapat dengan mudah ditambahkan karena sifat modular kode yang saya buat).

Seperti biasa, karena ini menyangkut tampilan, saya membuat desainnya terlebih dahulu.

Perbedaan dari fitur ini dengan fitur yang saya buat pada Sprint 1 adalah fakta bahwa fitur ini memiliki logika backend yang baru saja saya pelajari dari buku Testing Goat, yaitu fitur metode Views yang memiliki dua return tergantung request yang datang merupakan request POST atau bukan. Logika ini harus dites dan berikut adalah cara saya membuat testnya yang tentu dilakukan sebelum membuat ‘actual code’ yang menyelesaikan issuenya.

Test yang pertama, merupakan test apakah html yang di-return adalah benar. Test ini saya rasa cukup untuk memastikan template yang di-load adalah benar, sekaligus dengan CSSnya jika telah ditempatkan pada tempat yang benar. Saya tidak mau terlalu berat untuk testing UI mengingat komplain sebelumnya jika harus mendownload geckodriver dan Firefox.

Logika saya menggunakan state variable, dimana jika statenya berubah akan menampilkan panduan yang sesuai untuk fitur yang bersangkutan. Oleh karena itu, saya memiliki empat test. Khusus untuk test state variable is int, itu dilakukan untuk membunuh mutan state yang dikirimkan berupa string. Angka minus bisa saja digunakan untuk state di masa depan, jadi tidak saya hilangkan terlebih dahulu.

Setelah menulis test-test tersebut, barulah saya membuat ‘actual code’nya. Berikut adalah snippet dari apa yang saya tulis.

Dapat dilihat ada if untuk state-statenya, yang memiliki korespondensi dengan state yang dikirim ketika tombol-tombol yang merepresentasikan fitur diklik.

Berikut adalah kode CSS custom (menimpa CSS bawaan dari base) untuk mengubah tampilan

Selain itu, saya menambahkan link ke Navigation Bar dan Home Page. Saya merasa untuk penambahan konten secara sederhana tersebut tidak baik untuk dites, sehingga saya tidak melakukannya.

Berikut adalah hasil akhir dari apa yang saya kerjakan:

Dapat dilihat bahwa desainnya sangat mirip, hanya saja sedikit berbeda karena ada navigation bar diatas yang berasal dari import oleh base.html. Adanya navigation bar diatas membuat saya bisa menghilangkan “back to homepage” link yang ada pada desain awal.

Penutup

Saya jauh lebih terbiasa dengan workflow secara keseluruhan pada sprint ini ketimbang sprint sebelumnya, sehingga tidak ada kesulitan bagi saya dari segi workflow untuk mengimplementasikan fiturnya. Hal ini membantu saya agar saya bisa lebih fokus dalam mengembangkan fitur yang telah di-assign kepada saya.

Tentu kesalahan tidak akan pernah luput dari setiap orang. Kesalahan yang saya temukan pada sprint ini terletak pada commit rekan sekelas yang tidak lulus pipeline yang saya telah jelaskan sebelumnya. Ini merupakan minor setback yang saya hadapi, dan saya beruntung saya memiliki pengetahuan untuk mem-bypass masalah ini sehingga saya bisa melanjutkan proses development secepatnya.