aulch’s — week 12
1. Susun DoD — Living documentation
Di minggu ke-12 ini, saya menyusun Definition of Done untuk setiap fitur dari aplikasi yang tim saya buat. Di sini, terdapat kolom nama fitur dan apa saja yang harus ada di fitur tersebut, sehingga nantinya menjadi parameter tersendiri untuk menentukan apakah fitur tersebut telah selesai atau bahkan terdapat perubahan.
Definition of Done ini termasuk salah satu bentuk living documentation dari sebuah proses pengembangan software.
Definition of Done dari tim kami dapat dilihat di
Maka, Definition of Done task saya adalah
- Terdapat form yang meminta pengguna untuk menginput quote,author, source, is manual, category, language untuk mencari quotenya
- Terdapat menu untuk menghapus quote baik secara satu-satu atau lebih
2. Elicitation , Analysis, and Specification
Kembali sedikit membahas mengenai Elicitation, Analysis, dan Specification. Di sini saya akan menjelaskan definisi dari 3 hal tersebut.
- Elicitation : proses mengumpulkan requirement yang masih “seadanya” dari product owner
- Analysis : proses memilah-milah dan melakukan breakdown terhadap requirement yang telah disampaikan product owner
- Specification : proses menerjemahkan hasil analisa terhadap requirement gathering tadi ke dalam Bahasa teknis yang dapat dimengerti developer team.
ketiga hal ini yang harus kita lakukan di masa pengumpulan requirement (requirement gathering)
3. Verification & Validation, Process & Product Management
Di awal proses pengumpulan requirement, kami menyusun user stories dari projek ini. Sebelum kami memulai untuk mengembangkan seluruh user stories, kami harus melakukan verifikasi, apakah user stories sudah tepat atau belum. Kami berdiskusi dengan product owner hingga akhirnya seluruh user stories kami disetujui.
Tidak berhenti di sana, setelah kami mengembangkan fitur yang dimaksud oleh tiap user stories, kami harus validasi apakah fitur yang sudah diselesaikan sesuai harapan atau belum. Maka dari itu, kami melakukan sprint review untuk mendemokan mvp yang berisi kumpulan fitur yang sudah kami buat. Di sini, product owner dapat memberikan feedback bagaimana fitur-fitur yang sudah dibuat tersebut. Semua feedback dari tiap sprint review dapat dilihat di sini:
Sprint Review 1 : https://drive.google.com/drive/folders/0B-jftFn9T-cqbm5vZ194dG9hMVk
Sprint Review 2 : https://drive.google.com/drive/folders/0B_4AuTK4PICZYzVzdjVCRGdMbkE
Sprint Review 3 : On Going
4. Standard Code Convention
Untuk hal ini, saya sudah merubah struktur kodingan pada task-task saya sehingga sesuai dengan standard code convention tim kami. Standard code convention dapat dilihat di
Di sini disebutkan bahwa:
- HTML dan CSS code harus rapih dan menggunakan indentasi yang baik.
- Penulisan tag HTML dan CSS menggunakan huruf kecil.
- Untuk file html diawali dengan <!DOCTYPE html> dan gunakan UTF-8 untuk encoding characters.
- Semua tag html harus memiliki penutup.
- HTML dan CSS jangan digabung dalam satu file, gunakan <link>.
- Penamaan class atau id untuk css menggunakan strip apabila terdiri dari 2 kata atau lebih.
Dapat dilihat bahwa di sini, saya sudah mengikuti standard code convention, yaitu
Saya sudah melakukan hal nomor 1–5. Nomor 6 tidak masuk karena tidak ada penamaan class/id CSS yang saya buat menjadi 2 kata.
Saya juga telah melakukan hal yang sama untuk halaman about
5. Code Review
Branch development adalah branch yang menyimpan latest updates dari projek kami sebelum akhirnya di-finalisasi ke branch master. Saat saya review seluruh halaman website yang kami selesaikan di sprint 2 pada branch tersebut, saya menemukan beberapa halaman yang masih belum rapih atau mengikuti standard code convention. Halaman yang saya review adalah halaman Home dan Source Code. Oleh karena itu saya mencoba untuk merapihkan source code dari halaman tersebut agar sesuai dengan standard code convention yang ada.
Di atas adalah halaman Source Code yang belum mengikuti standard code convention nomor 1 dan 5. Maka saya kembalikan strukturnya agar sesuai dengan standard code convention yang ada. Hasilnya menjadi
Dan styling CSS kita buat menjadi external CSS
Begitu juga dengan halaman Home
Menjadi
Saya juga sudah mengajukan review code ini kepada Alief dan Ega sebagai pihak yang bersangkutan di github.
6. Refactoring
Banyak cara untuk melakukan refactoring. Apa itu refactoring?
“Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.” — refactoring.com
Jadi kita hanya perlu mengubah struktur internal dari sebuah bagian code tanpa mengubah fungi eksternalnya. Anda dapat menemukan macam-macam cara refactoring di refactoring.com. Refactoring yang saya lakukan sebelumnya ialah mengubah nama sebuah method agar lebih deskriptif sesuai dengan fungsinya. Kali ini, saya mencoba refactor struktur kode dari sebuah halaman HTML. Halaman yang saya ubah adalah halaman documentation dan about, yang memang itu adalah task saya pada sprint 2. Maka di sini saya memperbaiki struktur kode saya.
Berdasarkan penjelasan mengenai inline, internal, external CSS pada website https://vineetgupta22.wordpress.com/2011/07/09/inline-vs-internal-vs-external-css/, external CSS memiliki banyak sekali keuntungannya, seperti mengurangi ukuran file, mempercepat waktu untuk halaman tersebut dimuat, dan keuntungan lainnya. Sedangkan inline CSS keuntungannya hanya memudahkan ketika masa pengembangan halaman. Untuk saat ini, halaman sudah selesai dikembangkan sehingga ada baiknya kita ubah menjadi eksternal CSS.
Di sini, masih terdapat inline CSS dan kurangnya lagi, style tersebut berulang digunakan. Jadi sebaiknya dibuat sebuah class baru untuk menyimpan styling yang sama tersebut, sehingga code menjadi seperti ini
Begitu juga dengan halaman about, namun di sini masing-masing foto memiliki style berbeda, maka kita tiap style akan kita simpan ke dalam class yang berbeda.
Menjadi
Lalu merapihkan templateinspire.css, mengefisiensikan penulisan dari cssnya
Di sini kita memiliki 2 styling untuk class footer, padahal bisa kita satukan tanpa merubah hasil akhirnya menjadi
7. Unit testing
Unit testing adalah serangkaian proses dimana kita menguji apakah tiap bagian dari program kita sudah benar dan sesuai. Salah satu tools untuk melakukan unit testing ialah PHP Unit Test. Di sini, kami menggunakan framework laravel, maka saya mencoba untuk melakukan PHP Unit Test.
Bisa dilihat cara untuk melakukan PHP Unit Test di laravel di sini https://laravel.com/docs/5.0/testing. Laravel sudah dilengkapi dengan unit testing. Jadi kita cukup jalankan phpunit pada command line untuk menjalankan test kita.
Langkah awal untuk mencoba, silakan masuk ke direktori tests dan edit file ExampleTest.php. saya coba untuk melakukan unit testing untuk halaman about, documentation, dan Contact.
Setiap fungsi akan melakukan GET request,(misalnya) untuk halaman about, method visit(‘about’) dan mengembalikan content dari halaman tersebut, jika terdapat content ABOUT API, maka fungsi bernilai true. INGATTTT!! Penamaan method harus diawali dengan kata “test” (tanpa “”) ya!
Dan ini hasilnya setelah dijalankan
Sekian progress dari saya.
