(Seharusnya) Sebelum PPL

Rehan Hawari
kelompok-propensi
Published in
4 min readFeb 25, 2019

Sebelum memulai aktivitas biasanya kita perlu mempersiapkan beberapa hal demi kelancaran aktivitas tersebut. Nah, di mata kuliah PPL ini, kita juga perlu mempersiapkan diri demi ̶h̶i̶d̶u̶p̶ ̶y̶a̶n̶g̶ ̶l̶e̶b̶i̶h̶ ̶d̶a̶m̶a̶i̶ kelancaran pengembangan proyek yang kita kerjakan.

Berikut beberapa hal yang perlu kita persiapkan/ketahui, terutama saya sendiri, sebelum ngoding di PPL:

Software Development

Sudah sering dengar Scrum, Sprint, TDD (Test Driven Development), kan? Yap, istilah-istilah tersebut merupakan beberapa framework yang diterapkan dalam Agile Software Development (selanjutnya akan disingkat menjadi Agile SD).

Agile in a nutshell from http://www.webdevelopersmeme.com/2017/02/02/agile-programming/

Jadi, pada PPL kali ini diterapkan metode pengembangan perangkat lunak Agile. Agile SD merupakan cara pengembangan perangkat lunak yang menjunjung tinggi beberapa nilai. Dalam Agile SD, kita lebih menghargai:

  • Individu dan interaksi lebih dari proses dan sarana perangkat lunak
  • Perangkat lunak yang bekerja lebih dari dokumentasi yang menyeluruh
  • Kolaborasi dengan klien lebih dari negosiasi kontrak
  • Tanggap terhadap perubahan lebih dari mengikuti rencana

Hal-hal di atas lah yang lebih ditekankan dalam Agile SD atau sering disebut juga Agile SD Manifesto. Meskipun begitu, bukan berarti kita tidak menghargai hal yang di sisi kanan, kita menghargainya, tetapi kita lebih menghargai hal di sisi kiri.

Selain 4 nilai tadi, Agile SD juga menerapkan 12 Principles, salah satunya adalah:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

Untuk lebih lengkapnya bisa dilihat di sini. Nah, singkat kata, framework dan praktik seperti Scrum, Sprint, TDD, Daily Standup Meeting, dsb telah mewujudkan 4 Nilai dan 12 Principles tadi. Agile SD jarang kita dengar karena kita lebih sering mendengar & melakukan nama praktik atau framework dari Agile SD itu sendiri, padahal kita sudah sering menerapkan Agile SD.

Selanjutnya, hal yang perlu kita ketahui adalah bagaimana cara kerja Git Flow di PPL.

Git Flow

Berbicara tentang git, banyak sekali hal dapat kita bahas. Namun, kali ini saya hanya akan membahas tentang git flow secara kasar. Jadi, di PPL kali ini sesuai yang kita tahu, terdapat 3 branches (tetapi tidak terbatas hanya 3 ini):

  • Master
  • Staging
  • Development (Opsional)

Let’s say, kita sudah sama-sama mengerti pengertian dan tujuan ketiga branch tersebut. Terus flow-nya gimana sih?

  1. Develop features in US (User story) branch
    Seperti biasanya, pengembangan fitur dilakukan pada branch yang terkait fitur tersebut, begitu juga pada PPL.
  2. Try your code in development branch
    Maksud dari try disini adalah mencoba kode yang kita tuliskan di environment development, misalnya apakah CI/CD jalan dengan sempurna atau failed.
  3. Push to US branch
    Pada PPL kali ini diberlakukan US–based branch, artinya kita bekerja bersama dengan teman PPL sekelompok dalam satu branch US (jika satu US dikerjakan lebih dari satu orang). Karena itu, pastilah banyak terjadi perubahan dalam branch US, sebelum push lakukanlah pull terlebih dahulu untuk mengupdate branch lokal kita dengan remote. Jika terjadi conflicts, selesaikan dan kemudian lakukan push.
  4. Merge Request US branch to staging
    Jika semuanya sudah berjalan baik di environment development, buatlah merge request ke staging dan mintalah code review.
  5. Merge Request staging to master
    Jika sudah disetujui oleh Project Owner, buatlah merge request ke master.
Git Flow PPL diambil dari Panduan Git PPL 2018/2019

Begitulah git flow secara singkat. Selanjutnya, hal yang perlu kita siapkan adalah Software Testing

Software Testing

Di PPL, kita menggunakan Agile SD, dimana TDD (Test Driven Development) diterapkan. Bagaimana langkahnya? Berikut merupakan langkah-langkah TDD yang dimaksud:

  • RED: mengimplementasi unit test dari fungsi yang ingin dibuat
  • GREEN: mengimplementasi fungsi yang menjawab unit test
  • REFACTOR: penyesuaian dari setiap kode dalam fungsi yang telah dibuat
Simplified TDD from http://lewandowski.io/2017/02/thre-levels-of-tdd-1/

Sebelum RED, biasanya kita membuat stub/interface/class dari fungsi yang ingin diimplementasi. Hal ini termasuk tag CHORES, karena implementasinya tidak berhubungan dengan fungsionalitas.

Manfaat TDD itu apa?

Jadi kita melakukan TDD bukan tanpa alasan, berikut beberapa manfaat dari TDD:

  • Kode akan lebih terstruktur, mudah dibaca & berkualitas
  • Mencegah error karena perubahan yang tak diinginkan di masa mendatang
  • Lebih sedikit bug karena sudah dites sebelumnya
  • Menghemat waktu, tidak perlu berlama-lama mencari & menyelesaikan bug

Demikianlah persiapan/hal-hal yang perlu kita ketahui sebelum PPL. Sebenarnya, masih banyak lagi, tetapi saya rasa ini saja sudah cukup untuk post kali ini. Jika ada kesalahan, mohon dikoreksi di kolom komentar.

Terimakasih sudah membaca!

Referensi:

--

--