RFC (Request for Comment) , Apa dan Mengapa?
Pengertian RFC
RFC atau kepanjangannya adalah Request For Comment adalah sebuah “Design Dokumen” yang diawali oleh IETF yang mempublish research paper yang berbentuk .txt dan membentuk internet sejak tahun 2000. Kalau bahasa mudahnya, RFC merupakan “engineering planning process” yang berbentuk dokumen yang akan selalu dibuat sebelum proses development.
Mengapa RFC Penting?
Transparansi
Proses RFC ini perlu dilakukan agar setiap tim dan anggota tim itu sendiri mengetahui apa saja teknologi yang telah dibuat dan sedang dibuat oleh setiap. Sehingga saat akan mengerjakan sebuah produk atau menemukan masalah yang sama dengan tim lain, bisa membaca RFC tersebut untuk mendapatkan insight atau pengetahuan baru sebelum proses pengembangan.
Communication
Menghilangkan komunikasi dengan menuliskan RFC, terutama saat akan mengimplementasikan sebuah fitur. Karena dengan begitu, tidak akan terjadi kesalahpahaman saat akan meneruskan sebuah fitur / membuat sebuah fitur.
Selain itu, akan mengminimalisir misskomunikasi antar team. Karena sudah mengetahui apa yang sedang dikerjakan, telah dikerjakan, teknologi apa yang telah dipasang pada sebuah proses bisnis.
Dokumentasi
Informasi-informasi di RFC bisa digunakan pula untuk mengetahui alasan-alasan setiap teknologi yang digunakan / diadopsi oleh team. Sehingga ketika ada proses migrasi, pembaruan teknologi, atau maintenace kita bisa memiliki keputusan apakah tetap menggunakan teknologi tersebut atau menggantinya karena disesuaikan dengan kebutuhan bisnis.
Saat tidak ada RFC, maka akan kesulitan untuk mengetahui goal penggunaan sebuah teknologi yang mana teknologi tersebut menjadi sebuah tech debt yang harus disolve seperti migrasi atau pembaruan yang berakibat pada blocking.
Edukasi
RFC juga sekaligus sarana edukasi, menyebarkan pengetahuan kepada para Software Engineer lain. Sehingga semua orang mendapatkan pengetahuan yang sama tanpa perlu menjalani proses riset yang cukup dalam.
Culture Menulis
Menumbuhkan culture menulis, apalagi untuk engineer sangat terkenal ketidak inginan untuk menulis dokumentasi. Nah, dengan adanya RFC ini akan menumbuhkan kemampuan, kegemaran, keinginan untuk menulis. Salah satunya dengan adanya RFC ini.
Responsibility
RFC sesuai dengan namanya, Request For Comment maka siapa saja bisa memberikan komentar atas RFC yang sedang dibangun. Ini akan memberikan kita kesempatan untuk bisa mempertahankan argumen, alasan kita membuat sebuah request atas fitur yang akan kita bangun. Baik pro dan kontra fitur tersebut. Sehingga saat ada yang memberikan masukan, kita bisa menerima atau menolaknya. Bahkan ada saat kita harus menerima masukan tersebut walaupun membuat RFC kita ditolak.
Format RFC itu apa saja dan seperti apa?
Kalau melihat tulisan dari Pak Gergely Orosz, ada beberapa Format RFC yang terbuka oleh beberapa perusahaan dan list perusahaan yang menggunakan RFC.
Bagian-bagian RFC
Secara umum, menurut saya setiap RFC akan memiliki 2 komponen utama, yaitu masalah dan solusinya seperti apa.
Problem
Pada bab masalah ini, kita akan menceritakan masalah-masalah apa yang ada sehingga kita harus membuat RFC ini. Misalnya studi kasus kita ingin membuat Landingpage untuk bisa diakses oleh orang.
Solution
Pada bab solusi, kita akan menceritakan bagaimana solusi yang kita tempuh untuk bisa menyelesaikan masalah tersebut. Misalnya dengan studi kasus Landing page tadi, kita akan menggunakan Next JS untuk bisa membuat Server Side Rendering. Nah, kita ceritakan dan memberikan pembuktian bahwa NextJS menjadi jawaban atas masalah tersebut.
Beberapa Format RFC yang bisa ditemukan seperti :
- RFC Sourcegraph
- RFC Hashicorp
- RFC Soundcloud
- RFC Couchbase
- etc
Untuk melihat beberapa format RFC lain, temen-teman bisa check disini :
Public RFC
Menariknya, tidak semua RFC itu diprivate. Ada beberapa RFC yang bisa dilihat oleh public misalnya
Adanya public RFC ini akan memberikan kita knowladge bahwa setiap teknologi yang digunakan akan memiliki alasan.
Kesimpulan
RFC mungkin akan membuat sebuah proses pengembangan menjadi lebih lama karena kita ada proses menulis RFC, diskusi soal RFC tersebut, revisi RFC dan baru proses pengembangan.Namun, itu akan memberikan kita trade off yang lebih bagus seperti yang saya sampaikan sebelumnya yaitu dokumentasi, sharing knowledge, sarana komunikasi dst yang malah akan meningkatkan produktifitas tim engineer dan menghilangkan misskomunikasi antar engineer/team.