Halo teman-teman, selamat datang kembali di channel Progamer Zamanow, bersama saya Eko. Kali ini saya mau bahas tentang alur pembuatan aplikasi. Jadi ya lebih, kalau lebih kekiniannya namanya adalah Software Development Lifecycle.
Jadi kemarin itu ada teman yang nanya gimana sih alur pembuatan aplikasi yang benar gitu ya. Nah sebenarnya sih tiap perusahaan itu punya alur aplikasinya pembuatan ya, pembuatan aplikasinya itu masing-masing, kita nggak bisa samain. Apa yang saya lakuin tiap hari di kerjaan saya mungkin nggak bisa juga diimplementasiin di tempat teman-teman gitu ya. Nah jadi sebenarnya yang kita mau bahas kali ini adalah versi saya yang biasa saya lakuin.
Jadi ini apakah sama dengan di tempat teman-teman ya bisa jadi beda. Belum tentu juga lebih bagus daripada tempat yang teman-teman lakuin gitu ya. Tapi ini lebih ke sharing apa sih yang saya lakuin ya biasanya dalam pekerjaan saat membuat aplikasi.
Oke, tahapan yang pertama yang biasa saya lakuin ya saat bikin aplikasi, itu yang pertama kita akan selalu dapetin dulu yang namanya BRD atau Business Requirement Document. Nah ini biasanya sih bukan orang teknologi yang bikin ya, tapi lebih ke orang operasional atau orang produk lah ya, istilahnya, atau orang bisnis lah. Nah ini intinya apa sih?
Intinya itu nanti jadi sebelum teman-teman develop aplikasi, jadi... nggak tiba-tiba kita bikin aplikasi ya, ujuk-ujuk bikin aplikasi gitu, nggak juga. Kita harus punya data, habis punya dokumen, alurnya seperti apa. Nah, itu biasanya dalam BRD. Nah, BRD itu ya biasanya sih bentuknya dokumen ya, entah itu misalnya menggunakan Microsoft Word, atau mungkin kalau misalnya teman-teman punya dokumen manajemen sistem, kayak Confluence gitu ya, ya itu mungkin dibikin di Confluence-nya.
Jadi, intinya di dalamnya itu ada list of fitur apa, atau misalnya aplikasi apa ya, aplikasi apa sih yang mau kita buat, Habis itu fiturnya apa aja ya. Kira-kira kalau misalnya fiturnya ini gede banget gitu ya. Atau aplikasinya gede banget.
Kira-kira kita akan breakdown berapa lama timelinenya. Misalnya timelinenya misalnya 3 bulan gitu ya. 3 bulan tuh sekali sampai jadi gitu ya.
Nah tapi kan di breakdown lagi. Misalnya per bulannya teman-teman mau delivernya apa. Misalnya bulan pertama MPV-nya dulu lah gitu ya. Most Valuable MPV. MPV ya tulisannya ya.
most, oh sorry, MMPV most valuable produknya dulu apa gitu ya, nanti bulan kedua improvementnya apa, bulan ketiga itu improvementnya apa, jadi ada timelinenya abis itu yang paling penting itu adalah alurnya, jadi mirip alur ya mirip kayak flow lah ya flow chart ya lah, jadi kayak misalnya dari pertama customer, abis itu dia akan ngebuka halaman apa, abis itu dia ngelakuin proses apa, dan seterusnya kalau ada misalnya percabangan dia kemana gitu ya pokoknya ada alurnya nah ini tapi alurnya bukan alur aplikasi ya tapi lebih ke alur flow flow bisnisnya seperti apa jadi semuanya udah lengkap dokumennya apa datanya apa gitu ya jadi nggak ngawang-ngawang saat kita bikin aplikasi pokoknya udah jadi nah biasanya ini sih hasil riset antara tim produk tim bisnis sama tim operation jadi hal yang pertama dilakuin adalah ini jadi saran saya kalau teman-teman ya misalnya udah ada nih tim bisnisnya, udah ada nih tim operasionalnya, udah ada nih tim produknya tiba-tiba teman-teman diminta bikin sesuatu gitu ya saran saya minta si dokumen BRD-nya yang pertama kenapa? karena kalau tanpa dokumen BRD kita sebagai tim teknologi ya agak bingung kalau bikin contohnya misalnya saya kerja di e-commerce terus tiba-tiba ada requirement eh tolong bikinin jualan tiket pesawat dong gitu ya nah itu kan bingung ya, mau kayak gimana jualannya gitu ya Apakah jual doang gitu ya, terus gimana, connect ke siapa, gimana flow-nya gitu ya. Terus kalau alur-alur yang tidak jelas kayak misalnya tiba-tiba dibatalkan tiketnya kayak gimana, itu kan harus ada gitu ya, ada flow-nya, ada aturannya. Nah itu semuanya harus tertulis dalam BRD. Jadi teman-teman saran saya kalau dapat fitur ya, diminta bikin fitur itu minta BRD-nya, biar jelas gitu ya.
Jadi nanti kalau benar atau salahnya saat implementasi bikin aplikasinya itu nanti kita lihat lagi ke BRD-nya. Nah biasanya sih BRD-nya walaupun datang dari tim non-teknologi ya, tapi nanti kita akan review lagi bareng-bareng sama tim teknologinya. Kira-kira sih apa sih yang memang bisa diimplementasikan sama teknologi atau enggak. Ya bisa aja kan ada fitur, permintaan fitur yang enggak make sense gitu ya, enggak bisa diimplementasikan sama teknologi. Misalnya, oh saya pengen gitu ya dikirim saat ini 2 jam kemudian nyampe padahal ada di luar pulau gitu.
Nah itu enggak mungkin misalnya kayak gitu. Jadi ya intinya teman-teman nanti bakal diskusi sama tim bisnis, sama tim operation, sama tim produk pada pasir di awal. Jadi ini kita lebih diskusi ke BRD-nya, flow aplikasi, dan seterusnya.
Selanjutnya setelah BRD-nya selesai ya nanti tahapan kedua yang biasa saya lakukan adalah ini. Ini bukan tim teknologi lagi sih tergantung ya teman-teman ini timnya ada di mana di tempat teman-teman. Nah selanjutnya setelah BRD selesai itu kita akan mulai development yang namanya UI UX-nya. Nah jujur saya sendiri kurang ngerti ya gimana tahapan di dalam UI UX tapi intinya kalau saya dari sisi orang teknologi ngertinya nanti pokoknya hasil dari tim UI UX itu. Nah kebetulan di tempat saya itu UI UX maksudnya ke tim produk bukan ke tim development.
Jadi UI UX itu nanti hasilnya adalah berupa UI ini nya. UI nya dari tiap flow yang ada di BRD. Misalnya kalau di BRD itu kan ada flow tahapan pertama misalnya user registrasi. Tahapan kedua verifikasi dan sebagainya.
Nah itu semuanya ada dalam bentuk UI UX nya. Jadi ada semuanya. Jadi misalnya dari form registrasi seperti apa. Form login seperti apa. form change password seperti apa dan alurnya pun saya dari tombol ini kalau di klik dia masuk ke flow mana dari tombol ini dia di klik ke flow mana jadi semuanya jadi dulu jadi ini lebih ke ya tim UI UX yang ngerjain jadi nanti dari saya sebagai tim teknologi saya terima jadinya setelah dapet BRD BRD nya udah oke udah final gitu ya nanti akan di eksekusi sama tim UI UX nya mereka akan bikinkan si alur dalam bentuk eee gambar ya atau prototype lah ya ya bagus-bagus kalau misalnya bisa di demoin ya kayak misalnya menggunakan apa ya mungkin Adobe XD dan sebagainya gitu ya yang udah bisa langsung di klik-klik-klik jadi kita bisa lihat alurnya dengan jelas nah intinya dari sini nanti biar kita ngerti interactionnya kayak gimana nah kenapa kita butuh ini?
karena biasanya tim teknologi itu ini bikin aplikasinya sesuai dengan alur UI UX yang sudah dibuat ya jadi kita nggak tiba-tiba bikin Oh bikin aplikasi backendnya kayak gini, kayak gitu, kayak gitu gitu ya. Bikin API-nya kayak gini. Enggak, enggak kayak gitu.
Kita ngikutin dari si alur si BRD dan hasil dari tim UI UX nge-generate si ini-nya. Apa, UI UX-nya. Yang jujur saya sendiri enggak bisa bicara banyak soal UI UX. Soalnya saya bukan orang UI UX ya.
Tapi intinya tahapannya yang kedua itu adalah nanti akan diberikan ke tim UI UX untuk dibuatkan si UI UX-nya. Nanti hasilnya, hasil prototype-nya. Atau misalnya bisa pakai Adobe XD atau Zeppelin gitu ya, nanti kita tim teknologi yang mulai lihat dari situ.
Selanjutnya, tahapan selanjutnya ya, tahapan ketiga. Setelah jadi UI UX-nya, nanti dia akan jatuh ke tim yang mengerjakannya. Nah, saat di tempat saya kerja yang biasa saya lakukan adalah, saya ketika sudah jadi UI UX-nya, maka kita akan melakukan pembuatan yang namanya technical design. ya technical design ini ya simpelnya kan kalau biar itu kan lebih ke flow ya alur ya alur secara bisnisnya seperti apa nah technical design itu apa yang dilakukan nah technical design itu kan dari alurnya habis itu kita dari UI UX nya akhirnya kita bisa tentukan kira-kira kalau bikin aplikasi kira-kira butuh bikin berapa aplikasi habis itu kalau misalnya tidak perlu bikin aplikasi Misalnya kan dari UI-nya kita perlu nampilin data, maka kita butuh data dari aplikasi mana dan sebagainya.
Lalu interaksi antara aplikasinya seperti apa dan seterusnya. Jadi semua pokoknya technical implementation-nya kita harus bikin, buatkan ya dalam bentuk dokumen. Jadi biasanya sih saya nggak, ya di tempat saya biasa kerja sih nggak formal-formal banget.
Kita biasanya bikin satu confluent page gitu ya. Nanti di sana ada... ada diagramnya kayak diagram aplikasinya seperti apa gitu ya jadi yang pertama tuh yang kita bikin kayak deployment diagram deployment diagram tuh seperti apa sih misalnya misalnya kita mau bikin fitur A gitu ya nanti oh fitur A itu kita butuh aplikasi A gitu ya nanti ternyata si A itu butuh B gitu ya nanti butuh B maka dia kita butuh B aplikasi B Maka abis itu misalnya ini kan punya database, nanti kita kira-kira kita mau pakai database-nya apa gitu. Ini Postgre kak, misalnya Mongo kak, atau MySQL kak, dan seterusnya.
Nah abis itu untuk dapetin data ke sini kita mau gimana, apakah nembak di sini ke sini misalnya pakai API. Atau misalnya kita mau setup namanya message broker gitu ya. Nanti ini ngirim ke message broker, nanti ini kan diterima sama ini gitu ya.
Nanti kalau ternyata butuh... Kayak ngeagregasi beberapa service gimana gitu ya nanti kita akan bikin semua interaksinya jadi interaksi dengan aplikasi C gitu ya misalnya nanti ini akan ngirim data ke C seperti itu. Jadi semuanya akan kita buat technical designnya jadi aplikasinya pun bahkan teknologinya mau menggunakan apa dan seterusnya itu semua dibuat.
Jadi ini nggak perlu sampai ke implementasi ini sih. Tapi kalau teman-teman bisa sih ya bagus ya. Kayak contohnya teman-teman bisa bikin diagram contohnya IRD-nya. Kayak nanti teman-teman misalnya bikin service A. Nanti butuh tabelnya tabel A gitu ya.
Sama tabel B. Nah kita-kita struktur data di tabel A-nya. Struktur tabelnya seperti apa gitu ya. Ya kayak bikin relasional IRD lah ya.
Misalnya tabel A gitu, tabel B. Ini misalnya kesini one to many gitu nanti ini relasi lagi ke tabel mana tabel C ini kesini misalnya one to one kayak gitu semuanya dibuat. Ini secara technical designnya dan ini teman-teman belum coding ya jadi teman-teman bikin dulu technical designnya seperti apa.
Nah ini untuk untungannya apa sih keuntungannya adalah nanti kita bisa lihat kira-kira kalau misalnya oh ternyata kita butuh connect ke service B. Ternyata service B itu atau aplikasi B itu yang punya orang lain atau tim lain gitu ya. Maka kita bisa. bilang ke tim tersebut kalau kita pengen development kita mau manggil API-nya atau misalnya oh kita butuh data dari tim B nih tapi ternyata belum ada API-nya gitu ya.
Nah kita bisa minta di tim B itu untuk development si API yang kita butuhkan kayak gitu. Jadi kita harus tahu gambaran besarnya seperti apa cara kerja secara teknikalnya. Jadi teman-teman nggak bisa habis dari bikin UI UX tiba-tiba langsung dikerjain aja.
Tiba-tiba tengah-tengah dikerjain oh ternyata butuh A butuh B ya nggak bisa kayak gitu ya. Kita desain dulu kira-kira. kebutuhannya apa, dan kalau misalnya bikin table yang table yang bagusnya seperti apa gitu ya dan yang lain-lain jadi kalau misalnya teman-teman misalnya butuh oh ternyata saya butuh ngirim SMS gitu ya oh kita akan pakai third party misalnya disini pakai Twilio kita sebutin juga kita akan butuh Twilio untuk kirim SMS misalnya seperti itu dan yang lain-lain, jadi intinya apa yang kita pelajari di itu ya waktu kuliah atau sekolah itu yang rekayasa perangkat lunak, nah itu kita akan buat disini Cuma memang tidak sedetail saat kita kayak bikin skripsi gitu ya sampai detail banget itu enggak. Yang penting itu kalau kayak deployment diagramnya kita ngerti, abis itu IRD-nya kayak gimana. Kayak misalnya struktur kelas dan sebagainya sih itu enggak butuh ya, karena kan nanti implementasi pasti bisa berubah-ubah struktur kelas dan sebagainya.
Yang jarang berubah kan biasanya deployment diagram sama yang IRD. IRD juga kan kalau berubah pasti kita gampang nge-update-nya. Jadi ini tahapan yang selanjutnya setelah jadi UI UX-nya.
Kita akan membuatkan si technical design-nya. Setelah jadi technical design-nya, ada tahapan selanjutnya. Yang biasa saya lakukan adalah yang keempat, itu adalah namanya architecture review.
Jadi si technical design yang sudah kita buat sebelumnya, itu akan direview secara arsitektur. Jadi nanti semua... software arsitek atau technical arsitek akan nge-review apa yang sudah kita buat. Jadi technical design-nya akan di-review.
Nah kenapa butuh? Karena biasanya kan kalau misalnya kita developer atau programmer yang ngertinya kan cuma programming gitu ya. Nah kita nggak ngerti soalnya biasanya misalnya soal network lah, soal security lah, soal DevOps dan sebagainya. Nah di saat technical review nanti semua orang itu berkumpul.
Jadi ada yang tim infra aja. Jadi ada infra arsiteknya. Ada security arsiteknya, ada development arsiteknya, ada misalnya kalau ada front end berarti front end arsiteknya gitu ya. Nanti pokoknya semua arsitek itu akan berkumpul.
Nah berkumpul untuk apa? Untuk ngelakuin review technical design yang sudah kita buat. Jadi technical design ini akan direview sama sih semua arsitek di tempat kita bekerja.
Nah tujuannya buat apa sih? Tujuannya sih simple ya. Untuk mastiin bahwa apa yang kita buat ini sudah... baik dan kalau misalnya ada concern ya kira-kira nanti akan disampaikan concernnya atau problemnya yang kira-kira bakal kejadian contohnya mungkin saat kita bikin aplikasi ternyata kita lupa gitu ya oh kita mau pakai nge-encrypt password menggunakan md5 gitu nanti kan ditanya sama tim security ini kenapa pakai md5 md5 kan gampang banget gitu ya di brute force hashnya gitu ya tolong ganti pakai backcrypt misalnya Seperti ini.
Nah itu semuanya akan direview sama tim arsitek di perusahaan kita. Walaupun kalau teman-teman misalnya belum ada ya. Kayak misalnya oh di tempat kita kerja belum ada nih orang-orang arsiteknya. Yang paling penting sih kumpulin semua senior ya. Yang paling senior di teknologi.
Nanti minta review apa yang sudah kita. Apa yang mau kita buat gitu ya di technical designnya. Minta direview.
Contohnya ketika kita bikin IRD. IRD kan misalnya kalau teman-teman yang press graduate misalnya. Pasti kan kalau bikin IRD harus selalu normal gitu ya.
normalisasinya harus bagus gitu ya nah tapi ternyata mungkin pada kenyataannya nanti tim development gitu ya tim backend gitu arsitek yang backendnya bilang oh ini kemungkinan grow datanya terlalu tinggi gitu ya Kalau misalnya kita terlalu standar, itu terlalu banyak join misalnya. Oh ini bakal ngelakuin 5 join gitu ya, itu makin kesana impactnya makin lambat. Tolong jadiin flat aja gitu, tabelnya di denormalisasiin gitu ya, jadi jangan terlalu normal. Jadi input-input itu nanti akan diberikan sama ini, termasuk kayak infrastructure gitu ya. Nanti ditanya, spec servernya butuh berapa gitu ya.
Oh aplikasi kita kira-kira bakal ngendal traffic berapa gede gitu ya, ada datanya nggak. Kalau belum ada, perkiraan kita minta berapa. Aspeknya oh kita perkiraan kayak misalnya butuh 2 CPU gitu ya sama memorinya misalnya 10 GB gitu.
Nanti ini akan divalidasi sama tim infranya. Emang butuh sekian kira-kira memang dapat data sekian dari mana dan sebagainya. Jadi security semuanya akan ngasih concern kira-kira aplikasi atau technical design kita ada security hallnya atau enggak gitu ya. Nanti dari tim frontend misalnya kalau tim frontendnya ada tim frontend performance gitu ya.
Ini gimana mastiin aplikasi kita secara plan N-nya bagus dan sebagainya. Jadi semuanya akan di-review. Nah biasanya feedback-nya dari sini nanti kita akan dapat feedback semuanya. Nanti tinggal kita perbaiki lagi technical design-nya.
Kalau misalnya udah ada feedback nanti tinggal kita perbaiki. Oh contohnya, oh ini datanya aplikasi B ini terlalu slow gitu ya. Slow banget, jadi jangan pakai API contohnya.
Ini diganti jadi yang message blocker gitu ya. Biar ini nggak terlalu terbebani sama beratnya aplikasi kita dan sebagainya. Jadi semuanya akan direview sama si technical architect atau software architect di tempat kita kerja.
Jadi semuanya akan memberikan input dari technical design yang sudah kita buat. Jadi ini adalah architecture review. Jadi memastikan bahwa technical design yang sudah kita buat atau nanti aplikasi yang bakal kita develop itu ya, itu baik secara arsitektur.
Jadi ini gunanya ada istilahnya architecture review. Ini juga untuk memastikan tidak ada istilahnya kecolongan ya, tiba-tiba teman-teman bikin aplikasi tiba-tiba naik ke production gitu, kecolongan, nggak direview dulu, ternyata banyak masalah. Nah ini bisa mengantisipasi ya, kalau misalnya ada apa-apa, biasanya kan yang jadi arsitek atau teknik klasitek kan udah orang-orang yang paling senior di tempat kita kerja.
Jadi mereka harusnya udah lebih berpengalaman, jadi ketika kita bikin aplikasi itu mereka harusnya udah pada ngerti kira-kira bakal dapat masalah apa, dan kira-kira... dari arsitektur yang kita bikin di technical design itu baiknya idealnya seperti apa dibuatnya oke setelah arsitektur review selesai ya misalnya technical designnya udah oke nih udah clear nah apakah kita langsung development? nah sayangnya enggak saya yang biasa saya lakukan yaitu enggak langsung coding ya langsung bikin aplikasi kenapa?
oke gini nih saya akan ganti warna ya biar nggak bosen. Jadi tahapan yang kelima itu yang biasa saya lakukan adalah kita akan diskusi tentang API spec atau API specification. Nah kenapa butuh ini? Oke ini saya akan jelaskan dulu kenapa kita bahaya banget kalau tidak bikin API spec. Oke jadi misalnya biasanya kan kalau kita bikin aplikasi apa sih yang diperlukan dulu?
Biasanya kan aplikasi backendnya ya. Jadi aplikasi backendnya kita akan bikin dulu. Selanjutnya aplikasi backend setelah selesai, anggap aja 2 minggu.
Nah, terus apa yang dilakuin sama ProneN Engineer sama QA? Mereka ya bengong, diem. Kenapa?
Karena nungguin backendnya kelar gitu ya. Iya kalau 2 minggu kelar, kalau misalnya 4 minggu kelarnya maka sebulan mereka magabut nih. Enak banget jadi orang ProneN sama QA gitu ya.
Nah, akhirnya apa? Kenapa ini kejadian? Karena dari awal kita tidak bikin API spec.
Jadi harusnya itu idealnya saat sebelum kita development, coding ya, implementasi kode kita, kita bikin yang namanya API spec. API spec itu apa sih? API spec itu istilahnya kesepakatan. Nanti kalau misalnya mau bikin API, API-nya formatnya seperti apa, request-nya seperti apa, response-nya seperti apa, dan seterusnya.
Nah ini biasanya yang saya lakukan adalah based on ini, UI UX-nya. Jadi dari UI UX ini. Nanti kita tahu, oh UI ini misalnya butuh data A, B, C, D gitu ya.
Oke, kita akan diskusi nanti sama tim Pronen, sama tim QA. Kira-kira kita butuh endpointnya berapa nih? Oke, ternyata untuk ini, screen ini, kita akan butuh misalnya 2 API. Misalnya.
Nanti 2 API ini akan kita buat di sini. Jadi ini saya bilang salah ya, salah yang ini. Ini salah. Jadi yang benar itu adalah kita bikin API spec.
Jadi contohnya dari screen yang tadi, oke ternyata kita butuh 2 API. API-nya apa? API yang pertama adalah berarti kita slash API, misalnya slash, ya misalnya products. Untuk mendapatkan data products gitu ya. Habis itu oh ternyata di halaman products itu ada slash API.
Kita butuh juga slash banner. Jadi ada 2 API. Oh ini kira-kira nge-get data product.
Jadi kita bilang ini get. Ini juga get. Nah setelah itu nanti habis diskusi kira-kira API apa aja.
Yang dibutuhkan kita list nih. Dari aplikasi kita butuhnya berapa. Contohnya misalnya kita oh ternyata butuh total ada 20 API.
Dari 20 API setelah kelar, maka kita akan diskusi lagi tentang kira-kira tiap API butuh request dan responnya seperti apa. Nah ini juga harus didiskusikan bareng-bareng antara tim frontend, tim backend, plus tim QA-nya. Nah kenapa butuh bareng-bareng? Kita nggak bisa yang ngerjain cuma tim backend gitu, nggak bisa.
Kenapa? Karena kalau kita tim backend, biasanya orang backend itu ngerjain API berdasarkan tabel. Tabel yang ada di database. Mereka bikin, oh ada tabel produk. Mereka akan bikin API get product, update product kayak gitu.
Oh ada tabelnya, tabel member, ada get member, dan sebagainya. Padahal secara screen itu belum tentu gitu ya. Karena bisa aja ketika di halaman produk itu nggak cuma produk loh adanya. Dia butuh juga misalnya logistik, butuh juga banner, butuh juga misalnya inventory, dan sebagainya.
Artinya gabungan beberapa data. Jadi nggak bisa, jadi kita nggak bisa tiba-tiba team backend ngerjain sendiri, API speknya nggak bisa. Ini semua harus... barang-barang, nah terus gimana biar gak, ini ya, istilahnya kayak gak gontok-gontokan ya, antara team backend sama team prona atau team QA, nah kita biasanya yang dilihat adalah dari UI UX-nya simple, di UI data apa yang keluar, maka API-nya kita harus ngeluarin semua data itu, jadi kayak gitu jadi jangan dibilang, oh data ini ada di table ini, kita harus ngelakuin query join dan sebagainya, wah gak ada alasan kayak gitu, jadi pokoknya di screen-nya ini misalnya butuh data produk plus data logistik plus data promo gitu ya, berarti ada 3 data maka 1 API itu harus ngebalikin 3 data itu, jadi disini nanti di product, misalnya ada id productnya gitu ya, nanti dia harus ngeluarin json, nanti format jsonnya ditentukan juga oh jsonnya seperti ini ada field namanya product ada field namanya banner, ada field namanya promo, query parameternya adalah id product ini, seperti itu jadi semuanya udah didetailkan nah teman-teman kalau pengen tahu gimana contoh bikin API spec API spec itu nggak usah fancy-fancy nggak usah keren-keren yang penting bisa dibaca, contohnya kalau saya dulu pernah bikin di programmer jaman now itu ada project namanya Kotlin RESTful API teman-teman bisa buka nah ini contoh API spec jadi ini contoh API spec, jadi disini ada create data product nah ini endpoint API-nya kira-kira ini ya Dan kira-kira metode-nya ini dan header-nya apa dan body request-nya ini kira-kira body response-nya seperti ini. Jadi semua didetailkan.
Jadi satu aplikasi kita didetailkan. Lama dong bikinnya? Nggak masalah.
Seharian mau bikin API aspek? Nggak masalah. Yang penting apa?
Nanti teman-teman bakal lihat benefit-nya ya di tahapan selanjutnya. Nah jadi semuanya dibikin. Jadi kalau kita bikin ternyata fitur aplikasi kita butuh 20 API ya 20 API itu harus di...
Bikin semua API spec-nya. Dan semua harus disetujui sama tim frontend, backend, sama tim QA-nya. Jadi nggak ada istilahnya, oh yang setuju tim frontend doang, tim backend nggak setuju.
Ya nggak bisa. Nanti yang satu bikin apa, yang satu bikin apa. Ya nggak bisa.
Pokoknya semuanya harus sepakat. Nggak boleh ada orang yang bilang, oke saya nggak setuju dengan API spec tersebut. Nggak bisa. Pokoknya harus ketok palu.
Semuanya harus ngikutin API spec-nya. Jadi team backend harus bikin API sesuai dengan spek, team frontend pun akan menggunakan API sesuai dengan speknya. Jadi ini tahapan kelima, bikin API speknya. Jadi ini adalah tahapan yang lumayan ya mau debat, mau berantem silahkanlah di sini.
Pokoknya setelah diketok palu nggak boleh ada lagi yang perubahan gitu ya. Jadi semuanya harus sepakat dengan API spek yang akan dibuat dari fitur-fitur kita. Nah jadi kalau teman-teman tadi trip. Tips saya ya, kalau misalnya ribet, gimana cara bikin API spec, lihat dari screen-nya, screen UI UX-nya. Nanti kita bikin API-nya dari si screen ini.
Jadi screen ini, API-nya butuh apa? Datanya, silakan dibikin API-nya. Screen ini butuh apa? Silakan dibikin.
Screen ini butuh apa? Silakan dibikin. Kayak gitu.
Jadi API spec itu penting untuk kesepakatan di awal. Jadi jangan sampai teman-teman tengah jalan berubah-rubah lagi, apalagi tiba-tiba berubah nggak ngasih tahu pihak lain. Jadi API spec wajib dibuat.
Tahapan selanjutnya, kalau misalnya API spec-nya udah jadi ya, udah kelar dan semua orang sudah sepakat antara tim backend dan juga tim frontend dan juga tim QA, Nah baru yang kita lakukan adalah tahapan ke-6 adalah development. Developmentnya itu semuanya secara paralel langsung. Team backendnya, team frontendnya, dan juga team QA-nya. Jadi team backend akan bikin API-nya, team frontend dia akan bikin frontendnya, di mana dia pakai API spec yang sudah ada, dan team QA dia akan bikin... QA automation based on API spec yang sudah disepakati nah ini enaknya di depan kita bikin API spec, jadi kalau udah bikin API spec ya nanti jalannya paralel kayak gitu, jadi kalau ini timeline gitu ya, timeline misalnya kita project termin pertama atau MPP-nya kelar dalam waktu satu bulan gitu ya satu atau empat minggu ya empat minggu, nah berarti ini semuanya jalan bareng Antara backend, antara frontend, dan juga tim QA.
Jadi semuanya jalan. Ngikutin ini, kesepakatan yang sudah kita buat di API spec-nya. Nah inilah untungnya kenapa tadi saya bilang, mendingan kita berantemnya pas dibikin API spec-nya. Daripada bayangin kalau yaudah backendnya jalan dulu gitu ya, tengah jalan, setelah selesai baru tim frontendnya bikin. Tiba-tiba primonnya jalan.
tiba-tiba tim frontend bilang, eh kayaknya API ini nggak kayak gini, harusnya ada data ini akhirnya dirubah lagi, team backendnya itu kan ribet gitu ya, mendingan dari awal udah sepakatin API spec-nya seperti apa, nanti team frontend, team backend, team QA semuanya jalan jadi nanti team QA bakal bikin QA automation based on API spec tim frontend juga sama, bikin frontend dia akan konsum API yang sesuai dengan API spec ini, dan team backend juga akan bikin aplikasi backend plus database-nya, ngikutin si API spec yang sudah dikerjain Jadi ini adalah untungnya kalau kita dari awal sudah bikin API spec atau kesepakatan. Jadi semuanya bisa jalan paralel. Tidak kayak waterfall lah. Jadi nunggu, nunggu, nunggu gitu enggak.
Jadi ini langsung paralel dan bisa selesai bareng. Jadi kalau ini misalnya kelar dalam waktu 3 minggu gitu ya. Nah ini bisa langsung kita kelar.
Jadi nanti kita punya spare waktu 1 minggu lagi untuk ke tahapan selanjutnya. Nah ini adalah proses developmentnya. Jadi di proses development itu nggak ada istilahnya team back-end, eh sorry team front-end nungguin team back-end nggak ada. Team QA nungguin team back-end nggak ada. Pokoknya semua jalan bareng sesuai ngikutin dari API spec yang sudah ditentukan.
Selanjutnya kalau misalnya sudah kelar semuanya ya developmentnya antara team back-end, team QA, dan juga team front-end semuanya kelar semua. Nah selanjutnya kita akan melakukan proses yang namanya develop. sorry deployment, nah tapi tidak langsung ke production, kita ada istilahnya itu, kalau saya istilahnya adalah non-prod deployment nah ini tergantung tiap perusahaannya ya, kalau perusahaan itu kan biasanya ada sebelum ke environment production ada beberapa environment ya, nah biasanya kan istilahnya bukan production, nah contohnya ada mungkin yang namanya dev environment ada QA environment, ada staging environment, ada yang bilangnya sandbox gitu ya, outdoor dan yang lain-lain lah.
Istilahnya yang penting ini intinya dia bukan di production. Nah kita akan lakukan deploy ke sini semuanya. Jadi backendnya kita deploy ya, frontendnya kita deploy ya ke semuanya. Terserah teman-teman kalau misalnya adanya QA aja ya berarti di deploynya ke QA.
Kalau adanya istilahnya staging ya berarti ke staging. Nah selanjutnya yang kita lakukan adalah setelah ini, Semuanya kelar. Nah biasanya sih ini dilakukannya otomatis ya. Nggak harus manual.
Kalau saya sih biasanya bikin CICD-nya. Jadi kita bikin CICD-nya. Jadi setelah developer selesai, dia akan ngerilis versi gitu ya.
Ketika ngerilis, ya ngerilisnya sesimpel. Misalnya kayak bikin tag di git gitu ya misalnya. Nanti setelah selesai, nanti CICD-nya akan baca dari repo-nya. Repo-nya misalnya menggunakan git gitu ya, nanti baca misalnya di sini ada tag baru, nanti tag ini akan di-deploy sama si ICD-nya, entah itu ke dev, ke QA, ke staging, dan ke sandbox misal, kalau misalnya ada banyak ya. Tapi kalau misalnya, biasanya sih saya selalu implementasi QA-nya 2 misalnya ya, kenapa QA-nya 2?
Karena pada saat yang bersamaan bisa aja ada 2 project yang jalan bareng. Nah kalau QA-nya gabung nanti ketimpa-timpa lagi project A ngerjain A gitu ya dimasukin ke QA. Habis itu project B masukin ke QA lagi padahal project A lagi jalan gitu ya lagi dites. Maka akan berubah-ubah sih fitur yang di QA.
Nah biasanya sih ada yang QA1 misalnya ada yang istilahnya QA. dua environmentnya atau misalnya dev1 dev2 dan seterusnya jadi intinya setelah selesai development kita akan jalankan semuanya di non production deployment nah ini adalah moment of truth ya jadi kayak apakah yang kita lakukan selama ini di backend dan di frontend beneran sesuai dengan janji yang sudah kita lakukan di api aspek atau tidak Selanjutnya setelah semua di deploy ya misalnya ke deploy ke semua QA environment atau dev environment maka selanjutnya yang akan kita lakukan adalah kita akan jalankan si testingnya. Nah testing disini bukan teman-teman bikin unit test ya bukan unit test itu ya harusnya pas bikin development udah dibikin unit testnya gitu ya. Nah testing disini lebih ke end to end test jadi ada jenisnya banyak sih testingnya. Nah yang bisa dilakukan adalah end to end test.
end-to-end test ya atau yang sudah dibuat sama tim QA ketika development jadi yang tim QA development ini kan dia bikin QA automation ya nah ini tim QA nya akan ngerunning si testnya end-to-end testnya jadi dia akan call langsung service yang benar di development atau misalnya di QA environment jadi semuanya dilakukan atau kalau teman-teman misalnya punya tim performance dia juga nanti mereka akan melakukan performance test Atau kalau ada tim security-nya, ada yang istilahnya security test. Semuanya akan dilakukan tergantung environment-nya ya, bisa QA environment, atau dev environment, atau staging, dan seterusnya. Jadi semua dilakukan. Nah ketika end-to-end test, atau QA automation yang dijalankan, nanti kan pasti ketemu masalahnya.
Apakah oh ternyata masalahnya ada tim UI gitu ya? Nah nanti tim UI-nya yang benerin. Oh ada masalah di backend, nanti backendnya yang dibenerin. Contohnya ada performance test juga. Contohnya misalnya ini tergantung KPI perusahaan teman-teman misalnya ya.
Misalnya KPI-nya itu, respond time API itu tidak boleh dari lebih dari 2 second misalnya. Seperti ini. Nanti performance test akan mencoba mengirim performance test ya, kayak stress test gitu ke API-nya semuanya. Nanti kita bisa list API mana aja yang kira-kira respond time-nya di atas 2 second.
Nanti kita bisa improvement, jadi kita bisa improve lagi si API-nya. Termasuk kalau security test, nanti dia akan ngelakuin security test ke semua endpoint API-nya, dan juga frontend-nya, apakah di frontend ada cross-site scripting gitu ya, XXS, ada juga kalau di backend-nya, API-nya mungkin ada SQL injection gitu ya, dan seterusnya, semuanya akan dilakukan. Nanti ketika ada report-nya, kalau security test, berarti nanti kalau misalnya ada security hole gitu ya, Ada bolong-bolongnya nih security-nya di bagian A, B, C, D, F, G, H. Nanti kita akan benerin lagi.
Jadi development lagi. Nah maka dari itu, kalau misalnya bayangin kalau tunggu-tungguan gitu ya kan. Dari awal tunggu-tungguan bikin backend dulu.
Baru kelar bikin frontend. Baru kelar bikin QA. Nah itu kan lama. Nah dengan paralel gini, jadi nanti ketika tes pun bisa jalanin paralel. Karena semuanya udah siap.
Jadi ini tahapannya. Jadi kita akan melakukan testing di environment yang bukan production. Setelah semua proses testing selesai, entah itu QA automation test, entah performance test, entah security test, dan semuanya sudah tidak ada masalah, yang terakhir yang kita lakukan adalah proses production development. Eh, sorry, kok development terus ya saya bilangnya? Deployment, sorry ya.
Jadi yang ke-9 adalah baru kita ke production deployment. Nah, jadi... Terakhir ya tujuannya pasti ini ya, kita akan deploy aplikasi kita ke production.
Jadi kalau misalnya udah melewatin ini semuanya, jadi memang panjang tahapan di awalnya dan terakhir adalah si production deployment. Nah sebenarnya ada banyak strategi ya untuk ngelakuin production deployment, tergantung tempat teman-teman ya. Kalau misalnya produk baru mungkin langsung di launching gitu ya, nah atau mungkin bisa di launchingnya di rolling ya, kayak misalnya sebagian doang. Jadi kan ada banyak, teman-teman bisa baca sih.
strategi untuk production deployment seperti apa kayak misalnya ada AB testing gitu ya ada misalnya kanari deployment ada blue-green deployment dan sebagainya itu ada banyak nah contohnya yang paling simpel adalah teman-teman bisa ngelakuin misalnya AB testing jadi kayak misalnya setelah deploy produk baru gitu ya teman-teman bisa kirim ke sebagian user dulu jadi kalau ada user gitu ya user yang lagi login gitu ya nah teman-teman dicek misalnya Misalnya kita ngasih kalau ada user ya tergantung sih ya misalnya kalau usernya pakai ID number dari 1 teman-teman maksimal ada 1 juta gitu ya. Saya 1 sampai 500 ribu kita kasih fitur A nih. ya, kasih fitur A yang baru nanti dia akan dikasih fitur yang baru ini atau yang ininya yang 500 ribu sampai 1 juta, kita kasih fitur B, maksudnya yang lama gitu bisa kayak gitu, tapi intinya ya kita deploy ke production, yang paling simple sih pokoknya deploy aja semuanya gitu ya jadi semua customer kita langsung dapet ininya, tapi saat teman-teman deploy ke production, kalau udah fitur baru, teman-teman tetap perlu ngejalanin yang namanya QA automation, ya Jadi QA automation yang dibikin ini perlu dijalankan. Cuma nggak harus se-extensive yang saat ngelakuin testing di sini. Ini nggak perlu.
Nah di sini tuh kan ketika teman-teman lakuin end-to-end test kan banyak skenario-nya ya. Kayak ada happy flow gitu ya. Kayak happy flow kalau di e-commerce kan belanja biasa gitu ya.
Kalau yang nggak happy-nya kayak misalnya ngebatarin dan sebagainya. Ya banyak lah ya flow-nya. Nah teman-teman di production tetap bisa ngelakuin QA automation. Tapi khusus yang flow yang... paling gede misalnya flow-nya adalah belanja.
Jadi nanti kayak tiap satu jam sekali kita akan bikin QA automation-nya ngerunning, coba proses belanja. Ini untuk memastikan bahwa ketika kita sudah deploy ke production aman ya aplikasinya, tidak ada masalah. Karena kan kadang-kadang ada di development atau staging, nggak ada masalah. Tiba-tiba di production ada masalah. Karena mungkin datanya lebih gede misalnya, atau traffic-nya lebih gede, kayak gitu, dan sebagainya.
Nah ini adalah proses tapan terakhir sebenarnya yaitu proses production deployment oke, ya tadi katanya terakhir ya deployment, kok mesti ada lagi sekarang materinya oke, sebenarnya ini lebih ke bukan alur kerja biasanya sih ya tapi kan kalau di ujung-ujungnya kan teman-teman biasanya kalau tentuin timeline ya udah sampai production deployment udah kelar gitu ya nah selanjutnya yang terakhir pasti ada proses yang namanya maintenance atau improvement Jadi ya kalau misalnya teman-teman kayak beli mobil kan tujuan akhirnya bukan beli mobilnya udah sekolah gitu ya, tapi kan setelah kita pakai mobilnya pasti perlu butuh yang namanya maintenance. Nah termasuk juga software, software juga yang tahapan yang perlu kita sering lakukan setelah di plug-in production adalah maintenance atau juga improvement. Jadi maintenance atau improvement.
Nah kalau teman-teman ngelakuin improvement sebenarnya simple sih, dia akan balik lagi ke tahapan awal ya. Tahapan awal dari bikin BRD dulu dan sebagainya, kira-kira mau ada fitur baru apa dan sebagainya itu balik lagi ke awal, selesai. Nah jadi ini nggak perlu saya bahas ya untuk improvement.
Nah yang saya bahas adalah tentang maintenance. Nah untuk maintenance itu kadang-kadang biasanya kita... Ya tergantung orangnya ya, kita tuh kadang-kadang kalau misalnya ada mobil gitu ya yang sakit gitu ya, mobilnya sebenarnya aduh udah agak sedikit rusak, kalau kita nggak ngerti gejala-gejalanya kita nggak akan tahu gitu ya.
Tahu-tahu dipakai aja terus gitu ya, tiba-tiba mobilnya mogok aja, padahal kita nggak tahu, padahal dia udah ada banyak tanda-tandanya kalau mobil kita misalnya udah bermasalah. Nah termasuk aplikasi, kalau aplikasi kita, kita nggak tahu kondisinya seperti apa, itu tiba-tiba mati aplikasinya, kita nggak tahu gitu ya. Nah oleh karena itu proses maintenance itu perlu.
Nah gimana cara biar maintenannya mudah? Mantenannya mudah sih simple, kita perlu istilahnya namanya bikin monitoring. Jadi kita bikin monitoring dari aplikasi kita, kayak berapa sekarang jumlah datanya, kayak total data gitu ya.
Mungkin pas awal nyala hari pertama cuma datanya puluhan mega, ternyata udah sebulan udah nyampe gigaan dan sebagainya. Kita harus monitor terus. Abis itu kayak total traffic. traffic gitu ya, abis itu ya banyak lah sebenarnya monitoring, kayak respond time gitu ya, dan sebagainya, jadi semuanya bisa dimonitor, banyak lah tool-toolnya teman-teman bisa pakai tool-tool yang sudah ada, nah dari monitoring ini teman-teman nanti bisa tahu, oh ternyata datanya sekarang makin gede, ternyata semakin gede datanya, ternyata respond time-nya semakin lambat gitu ya, akhirnya teman-teman yaudah, kalau gitu teman-teman butuh improve lagi si aplikasinya.
Nah untuk improvement kayak gini kan gak butuh BRI dan sebagainya, ini kan udah lebih ke technical problem gitu ya, bukan lagi soal business problem. Jadi gak perlu lagi dari awal lagi bikin BRI dan sebagainya. Jadi yang perlu dilakukan adalah ya optimize si algoritma cara kerja API-nya dan sebagainya. Ternyata atau tiba-tiba teman-teman di frontend-nya nambahin satu buah tracker, trackernya malah bikin lambat si web frontend-nya gitu ya.
Nanti kan berarti itu lebih ke technical problem. Jadi semuanya kita lakukan maintenance. Jadi ya mirip kayak kita... beli kendaraan gitu ya kita nggak bisa yaudah selesai beli pakai terus nggak sopir juga sama setelah bikin diplo kepedasan nggak bisa langsung pakai terus gitu ya pasti butuh yang namanya maintenance dan biar maintenancenya lebih mudah itu pastikan teman-teman punya monitoringnya jadi teman-teman bisa tahu kira-kira masalahnya apa Jadi lebih gampang ya kalau punya monitoring.
Karena teman-teman juga sebelum ada masalahnya, teman-teman bisa tahu dulu. Oh kira-kira, oh slow nih, udah mulai slow. Ternyata datanya makin banyak gitu. Bayangin kalau tiba-tiba teman-teman nggak sadar aplikasinya slow, tiba-tiba mati aja.
Nah itu kan nggak lucu gitu ya, di production tiba-tiba mati. Teman-teman nggak tahu problemnya apa. Nah jadi monitoring untuk membantu maintenance itu wajib teman-teman nanti lakukan di production.
Oke teman-teman, mungkin kayaknya sekian aja ya tentang vlog alur kerja pembuatan aplikasi atau software development lifecycle. Nah ini murni pengalaman saya ya, jadi apa yang biasa saya lakukan di kerjaan saya. Jadi bukan berarti secara ideal itu seperti ini, enggak, enggak juga ya. Mungkin teman-teman juga punya development lifecycle yang lebih baik gitu ya, atau mungkin berbeda itu enggak masalah.
Karena namanya bikin aplikasi ya tiap orang beda caranya ya. Tiap perusahaan biasanya punya aturan masing-masing gitu ya. Nah ada mungkin perusahaannya yang masih konservatif kayak bikinnya pakai water flow gitu nggak masalah.
Atau yang ada yang pakai scrub dan sebagainya. Nah ini yang biasanya saya lakukan. Jadi teman-teman silakan bisa diadopsi yang bagus-bagusnya aja.
Yang misalnya kalau ah kayaknya bagian A bagian B saya nggak cocok nih yaudah nggak usah dipakai gitu ya. Jadi ini lebih ke sharing. Jadi kalau teman-teman misalnya punya ide yang kreatif.
Atau yang punya implementasi SOP Development Cycle di perusahaan teman-teman yang kira-kira lebih baik. Ya silahkan masukkan di komen ya. Biar yang lain juga pada tahu.
Oke mungkin sekian aja ya vlognya. Takutnya kepanjangan. Kalau teman-teman ada kritik atau syaran silahkan dimasukkan di dalam komentar.
Jangan lupa. Dan jangan lupa juga share ke teman-teman yang lain. Biar videonya bermanfaat juga buat teman-teman yang lain. Dan jangan lupa follow dan juga subscribe ke beberapa sosial media ya. Programmer Zamanow sekarang nggak cuma ada di Youtube.
Ada juga di Facebook. dan juga Instagram. Oke, mungkin sekian aja.
Salam Progamer Jamanau. Bye-bye.