Ngobrolin Code Review
Ringkasan Episode
Bantu KoreksiSebelum masuk topik, mereka membahas RedwoodJS — meta framework yang menyediakan segalanya sekaligus, dari Prisma untuk basis data sampai Storybook yang biasanya paling merepotkan disiapkan sendiri — beserta alasan kenapa perkakas semacam itu sulit masuk tempat kerja: ia dirancang untuk proyek yang dimulai dari nol, sementara di kantor kita jarang benar-benar memulai dari nol. Topik utamanya code review, dibahas jujur soal biayanya: menerapkannya berarti menambah tenaga dan memperlambat pekerjaan. Imbalannya juga jelas — kita memang tidak bisa melihat kesalahan sendiri, terutama yang menyangkut logika. Panduan yang dipakai adalah engineering practices milik Google: tujuannya memastikan kesehatan kode secara keseluruhan, dan kedua belah pihak sama-sama berperan. Bagian paling berharga adalah cara memberi masukan tanpa melukai. Prinsipnya menyerang kodenya, bukan orangnya, dan sebisa mungkin bukan perintah. Contohnya konkret: menemukan hasil querySelector yang langsung dipakai tanpa diperiksa, ia tidak menulis "tolong perbaiki" berulang kali, melainkan bertanya bagaimana kalau elemennya tidak ditemukan lalu menautkan halaman MDN-nya. Ada pula pengakuan soal budaya sungkan meninjau kode orang yang lebih senior, padahal senior pun menghargai temuan yang memperbaiki kodenya. Ditegaskan soal urutan: tinjauan manusia adalah langkah terakhir, setelah ESLint, Prettier, Husky, dan unit test di CI lolos, plus tangkapan layar dan langkah pengujian sudah dilampirkan di pull request — dan masukan yang bersifat selera ditandai jelas sebagai nitpick, boleh tidak diikuti.
Poin-poin Utama
- •Code review memang menambah tenaga dan memperlambat, tapi kita memang tidak bisa melihat kesalahan sendiri — terutama yang menyangkut logika
- •Panduan yang dipakai adalah engineering practices Google: tujuannya memastikan kesehatan kode secara keseluruhan, dan kedua belah pihak sama-sama berperan
- •Prinsipnya menyerang kodenya bukan orangnya, dan sebisa mungkin masukan berbentuk pertanyaan, bukan perintah
- •Contoh konkretnya: menemukan hasil querySelector yang dipakai tanpa diperiksa, ajukan pertanyaan lalu tautkan MDN — biar yang ditinjau memikirkan solusinya sendiri
- •Sungkan meninjau kode senior itu nyata di lingkungan kita, padahal senior pun menghargai temuan yang memperbaiki kodenya
- •Yang meninjau justru banyak belajar dari cara orang lain berpikir, memecahkan masalah dari arah berbeda, dan menamai sesuatu
- •Tinjauan manusia adalah langkah terakhir — setelah ESLint, Prettier, Husky, dan unit test di CI lolos, dan masukan bersifat selera ditandai jelas sebagai nitpick
(musik)
Halo, halo, halo. Selamat malam.
Selamat malam.
Gimana kabarnya?
Baik, baik.
Hari selasa biasanya kita?
Kita bertiga.
Waktunya ngobrolin web.
Kita ketemu lagi untuk sekarang berdua.
Mudah-mudahan nanti yang satunya nyesul.
Yang paling cakep di antara kita bertiga.
Gimana kabarnya teman-teman semua?
Wah ini udah ada beberapa orang disini ya yang hadir ya.
Boleh ya komen-komen kalau yang hadir ya.
Ada yang dari, ini dari mana kamu datang? Ini bukan orang Indonesia sepertinya ya.
Pak Mako.
Kita dari Indonesia.
Ya.
Kita menggunakan bahasa Indonesia.
Selamat malam Anton.
Selamat malam.
Gimana kabarnya?
Dan lagi ngulik teknologi web apa nih?
Boleh share-share juga ya teman-teman semua.
Yang lagi belajar, yang lagi ngerjain tugas, atau yang lagi ngerjain tugas di kantor gitu kan.
Lagi pakai teknologi apa.
Ada, ada yang lagi lembur.
Ada yang lagi lembur.
Ada yang lagi tertarik mau, apa ya, mau eksplor teknologi tertentu, boleh share-share juga.
Siapa tahu nanti bisa jadi topik sendiri ya.
Lihat transkrip lengkap (861 segmen lagi)
Oke, kembali lagi seperti biasa ada Ivan, ada saya Riza, dan juga nanti Eka akan nyesul.
Kita malam ini akan ngobrolin tentang code review.
Nah, disini siapa yang di kantornya belum melakukan code review.
Tunjuk tangan, tunjuk tangan.
Oh Eka belum ya.
Itu Eka.
Kata-kata belum ya.
Munculnya pas ya.
Munculnya pas.
Nah ini seru-seru ya teman-teman disini pada eksplor Redwood.
Wah Redwood.
Lagi asik, kenapa ada yang menarik ya dari Redwood ya.
Asik ya.
Mungkin salah satu framework favorit personal.
Asik.
Kapan-kapan kita bikin edisi favorit personal.
Edisi favorit personal, oh boleh tuh menarik-menarik.
Cetet dulu.
Jadi kalau kisih-kisihnya Redwood itu metaframework, metaframework react.
Mereka itu ambil perspektif yang kalau menurut gue kayak agak kurang konvensional.
Jadi biasanya kan metaframework ya terutama yang baru-baru ya.
Kan sudut pandangnya wah ini apa kebebasannya banyak lah.
Pokoknya versatile, gampang di modi, bla-bla-bla.
Ini opinionated ya.
Sangat opinionated dan kalau di bahasa Inggris kan ada istilah itu tuh.
Everything but the kitchen sink.
Jadi kayak semua dikasih sampai seisi dapur, sampai wastafel bak cuci, bak cuci piring aja dimasukin.
Jadi kayak beneran apa aja ada dan semua udah di set up buat kita.
Termasuk code generator.
Jadi kita kayak mau bikin komponen kalau di Redwood itu istilahnya cell.
Udah ada generatornya.
Banyak magicnya ya.
Magicnya banyak banget dan ya emang belum tentu cocok buat semua proyek.
Dan mereka itu fokusnya buat start up.
Jadi mereka tuh unik karena beneran kayak nantuin satu niche yang spesifik banget.
Jadi apa audiensnya, penggunanya adalah developer, start up kecil.
Biasanya start up kalau baru mulai kan kecil ya.
Apa karyawannya belum banyak, biasanya full stack.
Mungkin pengetahuan nya ya enggak, enggak canggih-canggih amat.
Jadi kayak database segala macem udah dikasih ORM, Prisma.
Terus punya authentication ada, database ada.
Sampai admin dashboard untuk crude ada.
Dikasih semua beneran.
Oh ini karena backgroundnya ya si Redwood itu kan dibikin sama...
Yang bikin GitHub.
Ke foundernya GitHub.
Terus abis itu dia bikin dan...
Terus random buat bikin tombol.
Itu agen gak nyambung sih.
T-O-M-L.
Kayak Yamel kan.
Namanya dia Tom.
Oh gitu.
Cuma experience pake Redwood itu mereka pilih niche yang sangat spesifik.
Terus mereka pake pendekatan yang sangat berani lah.
Mereka bikin keputusan pendekatan yang kayak gitu.
Dan kalau emang kebetulan project kita sesuai itu experience nya enak sih.
Itu adalah...
Dikapel? Gampang gak?
Susah.
Ya bisa teknik lu bisa.
Cuma susah ya jangan lah.
Dia berangkat dari GitHub kan.
GitHub kan sangat Rails banget kan Ruby on Rails kan.
Jadi memang framework nya itu ala-ala Ruby on Rails.
Jadi banyak magic, lengkap.
Terus juga salah satu framework.
Oh iya sih kayak Rails tapi untuk ekosistem JS.
Oh gak ya backend juga ya?
Full stack.
Dan sampai storybook nya aja di settingin.
Oh udah testing di settingin.
Siap-siap.
Harus kita bahas ya.
Selain itu juga ada Solid Start.
Wah Solid Start.
Belum coba.
Nah ini siapa nih panggilannya Triadmoko atau Denny atau Fatros?
Belum.
Soal krab gitu.
Ini jawaban belum untuk code review.
Berarti Eka belum melakukan code review.
Belum pake.
Yang udah berarti Ivan doang ya.
Kalau saya gak kode review.
Gimana ini?
Ada, ada.
Tapi kan saya gak terjun langsung ke tim development kan.
Jadi review nya bukan kode.
Boom.
Iya.
Dan malam hari ini kita akan bahas kenapa kode review itu penting.
Apa aja opportunity di sana.
Kalau kita mendapat kode review.
Kan pasti kalau misalkan kita terapin kode review.
Arti kan harus menambah main power kan setidaknya kan.
Atau memperlambat pekerjaan kan.
Gak bisa dipungkiri kan.
Tapi di sisi lain kualitas dari produk atau dari kode kita pasti akan meningkat jauh.
Karena biasanya kita tidak bisa melihat kesalahan diri kita sendiri.
Gitu yang sering terjadi.
Bahkan kalau kita pair programming itu kadang kita gak bisa lihat ada typo.
Kalau sekarang udah ada, udah lengkap ya udah ada ISD dan lain.
Tapi kalau misalkan ada kesalahan logic misalkan.
Itu kadang-kadang kita bisa tidak terlihat.
Tapi teman kita di samping dia bisa langsung tahu.
Dan kira-kira gimana sih cara kode review yang supaya tidak menyakiti ya.
Tidak baperan.
Yang sehat.
Yang sehat.
Dan efektif ya gak sih.
Biar gak muter-muter terus itu gimana sih selama ini penasaran.
Betul.
Pertama yang akan kita bahas adalah tentang apa itu code review.
Ya.
Jadi apa itu dan kenapa gitu ya.
Jadi kalau disini di Google.
Google best practice ya.
Engineering practice nya Google itu tujuan utama dari code review adalah.
Supaya memastikan kode kita sehat.
Overall.
Check up.
Ada check and recheck ya.
Tapi yang pasti developer harus ngerjain ya.
Kalau gak dikerjain apa yang mau di review gitu kan.
Maksudnya kalau misalkan ada error ada bugs ada kesalahan.
Terus tiba-tiba di review nih tolong nih perbaiki ini.
Ya kita harus perbaiki kan.
Terus kalau kita gak improve dan tidak submit ya.
Tercuma juga ada proses code review kan.
Dan begitu juga sebaliknya.
Adalah timbal balik ya.
Kedua belah pihak itu dua-duanya berperan serta.
Untuk melancarkan pekerjaan bukan menghambat.
Ini kan ada main kucing-kucingan kan kalau misalkan bukan code review ya.
Tester sama developer gitu kan.
QA.
Kadang-kadang diumpetin sembunyiin terus tiba-tiba testernya tahu.
Ini hampir sama sih.
Si developer ngerjain begitu udah di review.
Yang reviewnya juga harus bukan tidak nge-judge sih orangnya.
Ini jelek banget sih kode lu gitu.
Sentimen.
Waktu kuliah gak belajar coding ya misalkan gitu kan.
Itu kan negatif kan.
Negatif sekali gitu.
Itu menyerang orang kan.
Itu gak boleh.
Jadi memberi feedback dan menerima feedback dua-duanya sama pentingnya gitu.
Bagaimana cara kita memberi feedback yang baik dan bagaimana cara kita menerima feedback.
Ya kalau kita baca feedback yang tidak menyerang personal ya bisa aja kan kita tetap baper kan.
Tapi kalau kita melihatnya sebagai ini sesuatu yang bisa mengimprove diri kita gitu.
Itu juga sesuatu yang harus kita lakukan.
Nah kadang ada trikinya juga ya kalau melakukan code review itu.
Kita...
Kalau ini bukan kasus saya maksudnya gini.
Kita biasanya yang penduduk Asia gitu kan.
Kalau misalnya beda level itu sungkanan orangnya.
Oh iya.
Bener, bener, bener.
Jadi kalau misalnya kita nge-review code orang yang lebih senior apalagi owner apalagi orang sakti.
Misalnya anggap aja lah FK tiba-tiba nge-review codenya.
Siapa yang bikin itu tadi.
Yang bikin redwood tadi misalnya.
Dia submit PR tiba-tiba salah nih gitu kan.
Pasti sungkan gitu ya.
Lgtm aja deh lgtm.
Itu sindrom yang pertama kali saya dapet kan waktu dulu awal bekerja di dunia proses yang waktu itu.
Aduh sungkan gitu.
Tapi ternyata enggak.
Meskipun sesenior apapun seseorang itu.
Pasti dia akan appreciate kalau misalnya di...
Code dia di review dan ditemukan sesuatu yang bisa diimprove.
Pasti dia appreciate.
Dan dengan saya membaca codenya dia pun saya belajar banyak.
Oh ada style nya, ada code style nya sendiri, maksudnya cara coding nya gitu.
Karena banyak banget kan itu.
Cara orang coding, cara orang apa namanya memberi nama variable.
Yang jelas, yang gampang dibaca itu beda banget dari satu engineer ke engineer yang lain.
Jadi dengan membaca code orang kita lebih banyak belajar.
Lebih banyak belajar.
Inilah keuntungan dari code review.
Ya salah satunya ya.
Jadi kata kuncinya adalah membaca code orang lain.
Karena kadang-kadang kita males atau enggak mau, engan gitu ya.
Padahal sebenarnya banyak hal yang bisa kita pelajari dari code.
Bagaimana seseorang itu berpikir mungkin beda ya dengan cara kita ya.
Mungkin dia menyelesaikan masalahnya dengan dari counter clockwise, kalau kita yang clockwise.
Tapi ujung-ujungnya sama.
Menyelesaikan masalah juga.
Justru karena pendekatan yang berbeda, kita bisa jadi dapat pengalaman yang itu juga.
Oh ternyata bisa begini ya, enggak hanya begitu.
Ada tambahan experience juga di sana kan.
Dan benar sekali kita bisa upgrade si junior jadi ke level berikutnya ya salah satunya dengan code reviewnya ya.
Karena kita pasti pas ngereview ngasih input yang konstruktif ya.
Dan cara ngasih input juga nanti kita bahas lanjutnya supaya bagaimana menghindari blaming.
Blaming ya itu enggak boleh.
Biar kan git yang nge-blame.
Tetapi instead kita nge-construct percakapan.
Misalnya kita tahu nih logicnya salah ya, kita tahu wah ini logicnya salah.
Ini dia bakal, kalau dia pakai logic ini akan ada kasus yang begini gitu.
Atau ada obvious yang sesuatu yang obvious.
Ini karena fatal error sih, karena dia enggak handle itu.
Tetapi daripada saya mengatakan ini salah, ini perbaiki, ini perbaiki, ini perbaiki itu enggak sehat ngasih code review seperti itu.
Oke.
Jadi misalnya gini, contohnya aja ada document.queryselector saja, itu document.queryselector class.
Kita tahu kalau document.queryselector class itu bisa nul, baliknya bisa nul.
Tetapi di bawah constant itu langsung dia pakai, langsung manipulate whatever.
Kalau nul kan berarti itu bisa jadi fatal error ya.
Apalagi enggak di-try-catch.
Nggak di-handle.
Ini ketimbang saya ngasih taunya tolong handle sanity check, tolong handle sanity check, please handle sanity check misalnya.
Itu menurut saya kurang sehat.
Karena lebih baik kita memberi input yang konstruktif.
Kita kasih tahu, gimana menurut kamu kalau misalnya elementnya nggak ditumbuhkan dan nul.
Karena document.queryselector, document.queryselector itu bisa return nul.
Saya langsung biasa kasih link menuju web MDN.
Langsung paste.
Dokumentasi.
Dokumentasinya ini dan taruh di situ.
Jadi dia, biar dia mikirin gimana solusinya.
Saya nggak perlu ngasih solusi di review.
Oke.
Unless dia sudah beberapa percakapan dan dia masih nggak dapat, baru saya ngasihin begini loh maksud saya.
Bukan langsung bilang, oh ini error, ini salah.
Betul, jadi dari sisi quote review, ada dua hal.
Pertama dari sisi reviewer, bisa numentorin.
Numentorin, nggak peduli level ya, numentorin itu nggak peduli level.
Dari sisi reviewer yang menerima feedback itu belajar dan juga berpikir yang berbeda.
Berpikir dari orang yang berbeda, menangkap oh maksudnya si orang itu gimana gitu, apa yang bisa diperbaiki.
Yes.
Dan kalau misalnya, kadang ada itu ya tulisan need itu, need n-e-t, n-e-t, need p-k-i.
Oh need p-k-i.
Nah itu kadang ada kasus-kasus tertentu yang saya punya quote style saya sendiri, yang saya punya demenan.
Contohnya saya suka written ya kan, supaya itu quote style saya, preferensi saya.
Tanpa itu sebenarnya code-nya jalan gitu, yang dia bikin itu logicnya jalan.
Tetapi quote style-nya kurang oke bagi preferensi saya.
Ngerti nggak maksudnya?
Jadi, tapi saya mau feedback dan biasanya karena saya mau feedback dan saya tulisannya need, need p-k-i.
Artinya apa ya bahasa Indonesia need p-k-i.
Cari-cari kesalahan.
Ya gitu lah, ya berusaha cari kesalahan. Ini need p-k-i.
Lo bisa coba pikirkan bagaimana, need p-k-i kalau bagi gue misalnya,
gue lebih suka erliritan supaya, direflektur supaya lebih mudah baca code-nya.
Tetapi kalau nggak direobah, nggak apa-apa.
Gak apa-apa.
Nah bentar, tanya soal need ini, need itu dari sudut pandang personal code reviewer atau dari perspektif tim atau company?
Atau organisasi gitu?
Biasanya kalau need p-k-i itu dari personal.
Karena kalau dari company itu biasanya mengatur dengan general atau dari project.
Biasanya kalau project, sebelum nyampe PR itu saya diassess by get code review kan sudah memenuhi banyak step sebelumnya.
Contohnya sudah lolos, sudah lolos linter.
Linting dan lain-lain.
Lintingnya segala macam kan sudah otomatis tuh, sudah otomatis segala macam sudah pasti lolos.
Kalau masih minta error, jangan kasih-kasih test aja gitu, percuma.
Pasti atas saya bilang, benerin dulu linternya.
Karena kalau sudah saya review, nanti lu benerin lagi linternya, itu centangnya hilang, percuma gitu.
Jadi benerin dulu nih linternya.
Terus kemudian unit test-nya.
Unit test-nya sudah benar, sudah pas semua, baru di review.
Terus kemudian codenya, biasanya kan codenya itu sudah ada di develop.
Kita kan ada 3 environment, development, staging, dan production.
Biasanya codenya sudah dia test dulu, sudah dia test di development.
Dan sudah dia kasih screenshot-nya atau videonya.
Dan sudah kasih change list-nya, change log-nya sudah ada.
Jadi di PR itu sendiri, di batang tubuh PR sudah ada tiketnya.
Title, tiket, change log, screenshot kalau ada before and after, atau video.
Steps to test, ada steps to test-nya bagaimana test di development.
Dan beberapa centang untuk misalnya, saya sudah cek di browser A, sudah cek di browser B, sudah cek di browser C, contohnya.
Sudah ada centang-centangnya.
Kalau itu semuanya sudah terpenuhi, baru terakhir code review.
Jadi yang saya nitpick itu biasanya yang personal pribadi.
Karena kalau yang sudah code styling, titik koma, spasi, tab, segala macam itu sudah di handle sama sniffer semua.
Saya tidak melihat dia salah spasi lagi, karena sudah pasti ketangkep.
Urusannya pre-tier dan e-slint dan lain-lain.
Kecuali saya lihat itu sengaja di disable, ada itu.
Ada, ada-ada aja.
Jadi supaya styling-nya lolos, dia styling disable, enggak enak.
Iya, iya, iya.
Nice try.
Nice try but no.
Biasanya kan itu juga kalau e-slint dan pre-tier juga bisa di setting kalau belum lolos, enggak bisa di push.
Bisa commit ke husky.
Iya, itu juga bisa.
Oh itu kalau yang husky yang di lokal ya.
Lokal-lokal ya.
Bisa di setting lah.
Post-hook ya.
Post-hook.
Itu masuk ke CI dulu atau sebelum CI code review itu?
Sudah, sudah CI dong.
Sudah CI kan ya.
Jadi begitu push ke github, PR-nya itu kan langsung, github action langsung jalan semua.
Ya, langsung CI kan.
Linter, begitu push satu commit, linter jalan otomatis.
Kita ada linter bot sendiri, kita punya company punya linter bot sendiri yang nge-check PHP, CSS, sama SAS, SCSS.
Udah pada paham nih, ada husky, ada lean stage ya kalau buat di lokal.
Kalau jaman dulu kita pakai Jenkins.
Jenkins.
Enggak nyamanin.
Enggak nyamanin.
Masih ada Jenkins.
Travis kan.
Oh kalau Travis pernah pakai.
Travis CI sendiri, Jenkins sendiri, Jenkinsnya open source.
Itu satu project kan, satu instansi kan.
Enggak.
Iya kayaknya.
Jenkins itu?
Travis itu service nya dia, yang bisa dipakai kalau aplikasi kita open source.
Kalau nggak open source kan harus bayar.
Kalau bayar, Travis.
Oh iya bener, Travis commercial tool, whereas Jenkins is open source.
Bener kan?
Iya, iya, iya.
Ini kita ngomongin PHP loh, Irfan ngomongin PHP loh, kok nggak bisa relate?
Oh mungkin ini kali lean stage husky kali ya.
Kalau di PHP ada dong, masa nggak ada?
Kalau di PHP pakai PHP course sniffer sama PHP.
Terus kalau saya, kalau di project yang saya selalu set up itu ada dua untuk PHP, PHP course sniffer itu untuk code styling dan pakai PHP stand untuk static analysis.
Jadi PHP stand, pakai PHP stand.
Itu udah enak banget kalau udah pakai stand, karena berbagai macam, jadi stand itu bisa ngedetect, misalnya written atau data type, data type yang salah dia bisa tau tuh.
Kalau pakai stand, ya static analysis. Jadi udah di otomatis sasi juga stand. Terus terakhir adalah human review, which is peer review manusia.
Nah beberapa, Mas Riza bisa buka apa aja sih yang kita review itu sebenarnya?
Oh yang tadi yang ini ya?
Ada listnya ya, ada how to do code review, ini kan?
Oh bagus ya ada guidelinenya.
Jadi ada beberapa signal yang kita suka review, saya suka review kan kita.
Jadi bagaimana design secara keseluruhan, saya nggak akan menangkap kalau saya nak code review, saya tidak akan menangkap, kayak tadi ya titik koma, spasi type itu nggak saya lihat lagi karena itu udah di handle otomatis.
Sedangkan yang saya tangkap itu adalah design overall, jadi saya lihat secara keseluruhan.
Ini ticketnya ngapain, terus PR nya ngapain, gitu. Solusinya bagaimana dia buat.
Saya paling big no itu kalau misalnya PR nya dicampur-campur, misalnya fiturnya A.
Komitnya sekaligus gitu ya? Komitnya sekaligus, bukan komit, PR nya.
PR nya satu tetapi isinya itu urusannya modul A, modul B, modul C, atau perbaiki modul A, perbaiki modul B.
Biasanya kalau satu orang nguruhin ticket banyak, pengen cepet selesai semua, terus males pindah-pindah brand.
Itu paling big no, karena susah. Jadi gini, saya ngasih taunya dari sisi maintainer, kayak kalau maintain sebuah project yang sudah bertahun-tahun.
Kalau sudah ada masalah itu nge-tracing nya itu setengah hidup, karena tracing nya, kemana ini kodenya masalah dan sampai di tracing itu,
change lock segala macam sampai ke belakang, sampai ketemu itu dimana letaknya, kenapa itu bisa terjadi.
Karena harus cari route analysis kan. Kalau PR nya dicampur-campur, aduh susahnya minta ampun untuk mencari itu.
Sebagai best practice kita itu kalau bisa PR itu contoh, jangan campur-campur antara kombo, misalnya gini ya, NPM update sama logic update.
Soalnya kalau mau NPM update, bikin aja satu pikiran sendiri, NPM update itu pasti approve kan itu. Gak ngapa-ngapain cuma update package lock doang, ya kan. Nah itu kan tapi lebih mudah di trace. Oh ternyata waktu dia di PR ini, ada NPM update dan library yang ke update A, B, C, D, E, F dari A ke B, dari B ke C gitu kan.
Jadi ada list nya, jadi change list itu pun lengkap di PR. Itu satu PR. Nah, terus banyak yang tanya, pernah ada juga kayak kasus.
Kalau misalnya fiturnya besar, itu gimana? Berarti PR nya dipecah-pecah, jangan sampai dicampur-campur juga. Gak apa-apa, PR nya itu misalnya PR 1, skeleton nya doang.
Let's say kita bikin waters plugin, skeleton plugin nya doang, set up skeleton, that's it, masuk satu PR. Terus kemudian bagian fitur yang kecil, buat satu file atau folder, bikin bootstrap nya segala macam, masuk satu.
Udah, jadi berangkatnya dari kecil-kecil dibangun kecil-kecil, jadi lebih mudah bagi yang ngereview untuk membacanya.
Kemana arahnya gitu, dan bisa dibagi-bagi. Dan itu, bagusnya ke depannya kalau ada emergency apapun yang tiba-tiba dadakan, taunya panik harus revert, ngebalikinnya gak susah. Iya betul. Atau nge-disable nya jampang. Nah, secara desain nih, desain konsep, ini opinionated saya.
Jadi jangan jadikan patokan yuk kalian. Kode itu, lokasi dari kode, desainnya dari folder, struktur folder itu sebisa mungkin, kode yang punya tujuan sama itu di satu ini, satu modul, satu tempat gitu.
Jadi jangan dipisah-pisah satu di WordPress ya, satu di plugin, satu di team, satu di plugin yang mana. Jadi file-file nya udah terpisah-pisah kemana-mana.
Jadi urusannya kalau misalnya nanti ada mau update atau mau modul itu dihilangkan, atau mau diganti, ngebersihinnya harus kemana-mana. Jangan sampai harus kemana-mana ngebersihin.
Jadi sebisa mungkin satu tempat gitu. Satu lokasi gitu. Jangan campur-campur.
Ini pull request ini juga, kita sebagai developer dan kita sebagai reviewer juga, sebenarnya kuncinya adalah empati. Kita berempati gimana kalau kita berada di posisi reviewer. Coba bayangkan kita berada di posisi reviewer, terus perubahannya ada 300 file gitu. Nangis nggak ngereviewnya?
Benar-benar. Itu mah percaya bro. Udah percaya. Udah gue percaya lu. Jalan ya, awas kalau gue jalan.
Terdapat berdasarkan kecayaan gitu.
Iya. Jadi nggak bisa di review juga, jadi nggak ada yang bisa ditarik pelajaran gitu.
Kalau 100 baris pun udah cukup besar sebenarnya ya. Tapi masih bisa lah ya 100 ya.
Eh, tapi berarti esensi dari review itu berarti kita emang harus baca ya. Kita harus memahami kodinganya si rekan kita itu. Jadi nggak bisa misalnya kalau shortcut kan 300 file nih pusing.
Ya, nggak feasible aja. Nggak baca satu persatu. Udah, gimana kalau kita bikin tes aja sama-sama, tes misalnya pairing atau apa, kita brainstorm, bikin aja dadakan tes A, B, C, D, E. Udah apapunnya kalau itu semua, anggap aja benar.
Berarti itu nggak masuk. Itu belum bisa dibilang nerapin code review ya?
Nggak bisa. Jadi gini, tujuannya kenapa salah satu tujuan dari ujungnya code review itu adalah bagaimana agar si penulis code itu bisa menuliskan code yang maintainable.
Orang lain bisa baca, orang lain bisa maintain karena nggak selamanya kita hidup. Atau karena kita di, nggak selamanya.
Di perusahaan itu.
Di perusahaan itu.
Itu faktor loh, nggak selamanya juga kita hidup kan.
Oh iya, kan ada istilah yang...
Besok kurik.
Iya, kalau amit-amit besok kita ketabrak bus, terus kita nggak bisa kerja gimana rekan kita gitu kan.
Ya atau yang happy lah, yang happy, holiday faktor. Tiba-tiba kita menang, kita liburan ke Las Vegas.
Bye bye, kita nggak bisa dikontakan lagi naik pesawat. Naik pesawat berapa bulan saja.
Betul.
Apakah organisasi kita bakal codebase-nya langsung jatuh karena pada nggak bisa...
Ini ada perubahan mindset. Ada perubahan mindset. Karena kalau dulu sebisa mungkin kode kita tidak bisa dibaca sama orang lain supaya kita tetap bekerja di situ.
Supaya kita tidak tergantikan.
Kalau kode kita nggak terlalu bagus, ya kan? Orang-orang mengerti, jadi...
Kitanya ada pecat.
Kita bisa tergantikan, bisa dipecat. Padahal sebenarnya, kalau kita menulis kode yang bagus, terus kemudian ada junior yang bisa mengerti dan bisa melanjutkan, kita bisa naik ke atas, jadi senior gitu.
Malah kebalikan sebenarnya.
Ya kalau masalah job security, apalagi di winter seperti sekarang, ya memang ada.
Tapi kan bukan...
Ya, justru kalau kita nulis kode-nya ngaco, sulit dibaca, malah dilihat dulu.
Review-nya malah jelek kan, gitu.
Kalau dulu saya lebih, lebih apa lagi namanya, kayak reviewzilla lagi kalau sampai commit message pun juga saya pertimbangkan.
Itu ada salah satu contohnya bagaimana menuliskan commit message yang baik, ada saya kasih link-nya.
Tapi sebelum itu ini, tadi pagi ngelihat, ngelihat memes ini, siapa yang relate, gitu.
30 menit mikirin, commit message apa gitu yang perlu ditulis ya, yang cocok.
Sudah bisa dibantu, sudah bisa dibantu sama co-pilot.
Eee, CTVT dan lain-lain ya.
Iya.
Makanya supaya yang tadi commit message yang bisa membantu kalian coba ya.
Yang mana? Yang ini ya?
Iya.
Langsung temen-temen baca aja, tapi saya bagian skip yang paling penting, agak bawah sedikit.
Karena ada kayak 50 karakter, blablabla itu sudah diatur sana, VS code sudah gampang.
Seven rule of commit message.
Subject and from body and with blend line.
Limit the subject, 50 karakter.
Capitalize subject line, do not end the subject line with a period.
Use imperative mood.
Itu, klik itu imperative.
Nggak boleh pakai deklaratif ya.
Nggak boleh pakai deklaratif ya.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Do not end the subject line, do not end the subject line with a period.
Kalau misalnya kalian yang inklu file nya tapi lupa add file nya itu kan fatal error.
Kalau di commit itu.
Ya kan kalau di revert ke commit itu.
Ya.
Kalau file nya belum ada itu bisa misalnya commit itu akan menghasilkan fatal error.
Nah jangan sampai commit itu bisa menghasilkan fatal error.
Pikirkan bagaimana supaya commit itu satu satuan.
Kalau memang mau add file nya plus kalian include ya boleh.
Langsung tep gitu.
Jadi ke mana pun misalnya kita revert commit nya ke commit tertentu.
Tetap akan program kita jalan-jalan saja.
Itu dari sisi design.
Oh itu baru yang ini ya baru yang design nya.
Desain grand design nya.
Jadi dari solusinya strukturnya, ngedesign file nya dimana, solusinya alurnya itu satu hal.
Jadi dipahami sebagai review.
Sebelum saya lanjut.
Buka lagi tadi lanjutannya design apa?
Functionality.
Tapi sebelum lanjut ini ada pertanyaan yang bagus yang mau saya highlight.
Kalau di perusahaan konsultan biasanya nggak penting untuk unit test, nggak penting code quality dan lain-lain.
Ivan Humanmade bukannya konsultan ya?
Konsultan teknologi.
Iya ini bukan jangan menjenderalisasi semua konsultan seperti ini ya. Ini adalah konsultan yang belum menerapkan best practice.
Saya mikir-mikir kata-katanya terlalu kasar.
Lebih ke price range kali ya. Maksudnya kita realistis ya.
Ini kan code review kan satu, butuh tenaga, butuh SDM ya.
Maksudnya SDM ya kualitasnya harus relatif tinggi atau minimal willing to upskill. Maksudnya mau mempelajari, mau ngulik hal-hal yang semua tadi Ivan jelasin tuh.
Itu kan satu SDM nya harus begitu dari segi resource.
Nah terus resource lainnya yang jelas finance kan, ini kan makan dev hour ya, makan main hour.
Menghabiskan waktu sekian jam yang kalau misalnya tanpa code review kan dev nya bisa langsung disuruh, udah langsung aja bikin fitur baru lagi.
Nah ini nggak sekian jam dihabiskan buat code review.
Nah berarti kan biaya yang dibebankan ke customer bakal lebih tinggi.
Cuma kan hasilnya juga, ya pasti hasilnya juga beda jadi lebih ke kelas price range ya kali.
Iya betul. Kadang-kadang juga ada faktor lainnya juga, banyak ya banyak faktor ya.
Ada konsultan ini mereka lebih memilih yang penting diselesai.
Mungkin sesuai deadline, tapi tidak memikirkan kalau seandainya si kliennya balik lagi ke klien gitu.
Seringnya kan dapat proyek ya, proyek limpahan kan.
Ini dari konsultan yang lain, oh ini codenya ancur banget kita bikin lagi dari awal gitu kan.
Karena nggak ada apa ya, nggak ada benefit kalau kita melakukan best practice disana.
Karena tuh juga begitu udah selesai kontraknya mereka cari yang lain gitu, nggak balik lagi ke kita.
Jadinya ya hal-hal yang kita butuhkan itu tidak penting gitu.
Mostly karena klien yang di handle itu kan enterprise ya, jadi paper roomnya juga banyak.
Bahkan di awal project aja mereka sudah minta misalnya test coverage nya 100%.
Accessibility nya aja sudah minta level AA.
Jadi waktu udah, apa namanya, sebelum misalnya post production cun.
Maksudnya post deployment juga kita harus masih cek nggak ada degradation yang terjadi.
Post production test ini nggak ada. Itu beda lagi, karena permintaan project.
Itu depends ya, jadi kalau klien yang skala enterprise rata-rata memang minta banyak paper work nya.
Dan mereka tech savvy ya, berarti relatif walaupun mereka nggak ngerti codenya.
Tapi mereka punya ekspektasi, mereka tahu konsep test coverage.
Mereka punya standar accessibility, ya mungkin kalau di luar, mereka bisa dituntut ya kalau kurang accessible.
Jadi konsultan in house ya, eh punya staff in house.
Mereka punya staff IT in house, jadi mereka tahu gitu.
Dan mereka yang ikut membuat best pack ke sini.
Jadi kita meskipun di hire untuk handle project, tetapi timnya itu bukan cuma kita doang, di project itu.
Mereka juga punya tim yang lain, yang agency lain, yang bekerja di satu project yang sama.
Jadi kalau misalnya nggak ada standar ini, nggak ada standar coverage seperti ini ya, codenya kita ya campur aduk berantakan segala macem.
Nah itu kan jadinya kalau sudah berantakan, ngebenerin yang berantakan itu lebih mahal daripada dari awal sudah dibenerin.
Des praktisnya.
Apalagi kalau enterprise, maksudnya ada risiko mereka dituntut lah atau apalah maksudnya kena masalah hukum dan lain-lain.
Nah kemudian pertanyaan dari Rafki lagi, kalau perusahaannya belum pakai version control, belum pakai collaboration tools.
Ya mau nggak mau harus peer review ya, bareng-bareng duduk bareng-bareng ya.
Jadi sebelum di lempar ke FTP ya bareng-bareng gitu, ya solusi yang paling mendekati lah ya.
Oh tadi pas lagi research word ini, gue jadi baca-baca sejarahnya dan ternyata apa konsep code review yang kayak kita pahamiin sekarang nih,
ternyata di-initiate-nya di IBM tahun 1976 dan maksudnya sebelum ada sistem-system kayak sekarang, mereka tuh ngeprint beneran.
Apa lah, nggak ngerti deploy-nya gimana nih ya, tapi kalaunya si developer-nya si programmer-nya ngeprint fisik, ngeprint kertas yang dia bukun.
Jadi beneran kayak dituntutin, dibaca, diprint, difotokopi, baca ya kayak misalnya kalau ada komentar, di-highlight.
Kayak skripsi ya, jadi ingat masa lalu.
Tapi sampai sekarang peer review juga masih terjadi.
Peer review? Di jurnal ilmiah?
Iya.
Peer review di-print kan?
Oh di-print ya.
Peer review misalnya kalau jurnal ilmiah ya, istri waktu ngambil program specialis maling itu misalnya dia bikin jurnal ilmiah ya,
peer review ke dosen dan segala macemnya itu handwritten semua. Masih, masih peer review.
Sama aja code review, peer review ya sama.
Code review ya peer review.
Sama, sama, sama.
Nah, dari sisi functionality, terus apa lagi tadi, code style.
Oh iya, kita lanjut lagi ya, lanjut lagi ya.
Functionality, functionality udah pasti kan, codenya sesuai nggak?
Ini biasanya ada kaitannya sama testing ya?
Testingnya bener-bener juga kan?
Testingnya di-review kan?
Spesifikasinya juga kan?
Tests casenya di-review kan?
Yes, yes, testsnya di-review.
Testsnya tuh ini, jangan hanya membuat tests case itu hanya untuk test coverage doang.
Ya, coveragenya 100% yang penting gitu.
Gak boleh, gak boleh.
Gak bisa, jadi harus testnya bener nggak gitu.
Maksudnya secara logicnya yang mau di-test itu sesuai nggak?
Jangan cuman di-test happy part-nya aja.
Di-test yang error part-nya juga harus di-test.
Yang paling saya lihat adalah complexity.
Kalau sampai saya nggak mengerti codenya,
something is wrong.
Ini maksudnya apa sih kok muter-muter gitu.
Terus abstraksinya kok banyak amat gitu.
Saya paling bingung kalau misalnya udah abstraksinya sampai kayak 3-4 level.
Ngapain gitu?
Apa bisa disimplerkan, apa bisa dipermudah gitu alurnya gitu.
Terus komen.
Gak perlu, saya nggak terlalu, ini pendapat pribadi ya.
Bukan fans untuk yang nulis komen sebanyak-banyak, seabrak-abrak.
Jadi setiap lainannya ada komen, nggak perlu.
Jadi cukup komen itu diberikan di tempat yang misalnya memang ada satu specific case kenapa itu terjadi dan kenapa itu di situ.
Contohnya, mungkin ada edge cases atau bug yang terjadi dan belum sempat diperbaiki.
Dan harus men-short circuit, men-short circuit terjadi itu supaya bug itu nggak terjadi, tetapi belum sempat dibenerin.
Kasihlah komen di situ.
Jadi yang nge-maintain, oh tahu, oh iya itu kenapa di situ, tahu.
Jadi nggak perlu, ini tiba-tiba codenya aneh sendiri di sini, ini ngapain?
Dikasih fix me, fix me, tapi nggak pernah dilihat lagi.
Iya, tuduh-tuduh akhirnya kalau dibuka tuduh ini, semua tuduh, tuduh ini apaan gitu.
Oke, itu kompleksiti ya?
Iya kompleksiti.
Oh, pernah dulu ada rekan kerja walaupun nggak satu tim di kantor pertama.
Dia sering pake fitur komentar di kodenya, yang komentar isinya puisi.
Dia mengespresikan puisi.
Setiap kode yang dia buat itu ada puisi di atasnya.
Oh itu keren sih.
Tapi tidak pada tempatnya, mendingan tarah di Google Docs pribadi aja.
Jangan di kode, kan dibaca orang.
Kalau lagi galau kan ketauan.
Oh, cuma puisinya nggak ada dibuka sama kodenya, kirain kayak pantun gitu.
Nggak ada, kalau pantun mungkin kita ketauan.
Ke pasar beli manggis, ini penambah apa yang belakangnya is.
Oh, bagus juga tuh buat commit message, kalau nggak tau pakai apa, empat baris sendiri udah pantun kan.
Itu kalau jerjit dari upin dan ipin jadi programmer mungkin, kayak gitu, sudah besar.
Nah, selanjutnya nih, naming nih.
Naming.
Ini bisa jadi seluruh episode sendiri ini kayaknya.
Naming ini salah satu yang susah-susah gampang.
To do fix me nggak boleh, di PR nggak boleh ada kan.
Konsolok, print dan lain-lain juga nggak boleh kan.
Itu tergantung projectnya.
Kalau konsolok tergantung kalau misalnya memang itu di server dan memang halus di lock sesuatu yang mau dilihat, silahkan.
Di client juga kadang-kadang ada, kalau teman-teman buka salah satu website misalkan, terus dilihat di inspect elemen tiba-tiba ada.
Kadang malah career.
Tergantung ya.
Nah, balik lagi ke naming.
Sebisa mungkin kasih nama, function, class, variable, itu yang bermakna aja.
Nggak usah terlalu yang panjang-panjang A, this variable is for whatever reason, blablabla.
Nggak usah juga, tapi misalnya kasih nama berbeda.
Itu kan kadang, itu gejala, kayak gejala dari satu metode yang melakukan terlalu banyak hal, fetch data, update, blablabla.
Nah, itu berarti kan.
Berarti udah kebanyakan.
Udah kebanyakan.
Udah kebanyakan.
Karena kan, balik lagi ke clean code kan, apa namanya, prinsipnya clean code kan misalkan, contoh aja nih ya, satu fungsi hanya melakukan satu hal.
Kalau misalkan fungsinya udah melakukan misalkan login and change flag into true, active sama dengan true.
Nah itu kan udah dua hal, jadi harus dipisah fungsinya gitu.
Login and check and report suspicious user.
Ya, ya gitu lah.
Jadi sebisa mungkin, apa, nama itu biasanya menggambarkan kompositas, betul.
Sama satu lagi, disini nggak ada, tetapi konsistensi.
Saya, saya tipe orang yang bisa mengikuti, meskipun kita satu perusahaan, kadang satu projek dengan projek lain bisa mengandung opinion yang berbeda.
Ya, opinion yang berbeda.
Yang set up duluan itu engineer yang lain dan punya opinion berbeda, meskipun nanti kesamaannya ada, karakternya ada, tetapi ada hal yang berbeda.
Contohnya spasi sebelum, contohnya penggunaan spasi, saya nggak masalah kalau memang itu sudah jadi cost style dan dipakai.
Masalah yang saya permasalahkan adalah, dua hal yang sama itu tapi tidak konsisten, itu yang saya tangkap.
Ya kalau bisa dibikin konsisten aja, contohnya dia suka pakai early return, tapi di satu tempat yang nggak pakai early return, kenapa?
Satu early return, tapi di bawah, terus di dalam satu block, dia nggak pakai early return, kenapa?
Kalau memang mau pakai early return, early return kan semua konsisten dengan code changes-nya.
Makanya kadang ketahuan, satu dia mungkin tulis sendiri, satu lagi copy dari cgpt, copy dari cgpt atau copy style overflow atau copy dari code yang lain.
Atau kadang copy dari code yang lain dia roba sedikit dan kesalahan di code lain dia bawa yang sama.
Nanti dia komen, ini kan gue copy dari tempat lain ya, kalau memang yang tempat lain salah, dulu copy ya salah juga.
Salah tambah salah bukan jadi benar, salah dan salah itu salah.
Makin salah, makin salah.
Saat apa di Liverpool?
Iya.
Masih ya.
Jadi konsistensi, konsistensi.
Konsistensi.
Oke.
Konsistensi itu bagian dari style guide ya, berarti tadi kan.
Tapi untungnya beberapa hal.
Yang mana gimana?
Lanjut, lanjut.
Gimana tadi Eka?
Dari style guide.
Itu kan bawahnya komen ada style tuh.
Berarti kan itu kan hal yang harusnya ada di style guide dong, yang kayak tadi yang kayak di return lah, atau apalah penamaan, atau casing.
Nah itu kan ada comment di bawahnya komen tuh.
Ada yang unwritten rule, ada yang unwritten rule.
Maksudnya secara dia nulis codenya itu, karena saya tahu sih misalnya kayak ada beberapa engineer itu yang cara modenya ya, copy sana, copy sini, satuin, oba-oba-oba.
Jadi gitu ada gitu, saya tahu gitu.
Nah itu akhirnya yang dia copy sana, copy sini, dia oba-oba sedikit itu, kerasa itu bedanya.
Style nya bukan style nya, ya inconsistensinya.
Ya inconsistensinya kerasa gitu.
Jadi, sebisa mungkin ya kalau emang mau, mau contoh kode orang lain, contoh aja tapi konsisten gitu, konsisten dengan apa yang kamu rubah, dengan cara nulisnya sama gitu.
Itu masalah di fundamental gak sih kalau yang kayak gitu, maksudnya kan kalau copy paste itu kan istilahnya bisa dibilang ini ya, hampir haram gitu ya.
Copy paste bener-bener copy paste buta gitu, kita gak tahu apa-apa codenya kita copy paste, terus jalanin gak berhasil kita cari yang lain sampai berhasil gitu kan.
Tapi cara yang benar copy paste atau menyontek yang benar adalah, ya kita pahami, oh maksudnya ini terus kita tulis ulang dengan gaya kita, gitu kan.
Berarti ada yang salah dengan fundamental nya dia kan.
Eh ya, itu namanya etos kerja kali ya.
Atau mungkin karena udah deadline jadi berhubung dan seterusnya dan seterusnya.
Ya itu malah bikin tambah repot nanti kalau harus ngetumin.
Itulah yang ditangkap di code review, sebisa mungkin hal-hal yang misalnya tadi kayak contohnya, contohnya saya sakit nih misalnya.
Tetapi waktu saya mulai sakit tuh minggu lalu hari ragu contohnya, tetapi saya punya satu tiket yang nanggung banget karena cuma sudah setengah saya kerjain. Akhirnya pagi-pagi meskipun domong saya kerjain keter-keter.
Saya secepat mungkin testing, lihat oke eh udah puster, ternyata waktu di code review ini nya salah, tidak salah sih apa, feedback nya banyak.
Ya namanya orang yang lagi. Ya gak lah fit belum 100% ya. Tapi akhirnya yang benerin ya tim yang lain. Nah enaknya kalau misalnya kita sudah, itu tadi yang kalau code nya kita rapi terus kemudian strukturnya bagus, konsisten.
Meskipun ada feedback karena secara design sistemnya kurang oke atau ada X cases yang terjadi. Yang tim yang lain bisa baca dan bisa perbaiki dengan benar.
Mudah mereka perbaiki aja, tinggal lanjutin code nya saya. Gak ada masalah gitu. Mereka cuma tinggal perlindungi satu atau dua commit, udah selesai gitu.
Jadi tulis, maksudnya tulis lah code yang sebisa mungkin gampang diterusin orang lain. Dan supaya gampang diterusin orang lain, gampang dibaca orang lain.
Gampang dimengerti orang lain. Setuju banget ini. Ini balik lagi tadi empati. Video nya hilang.
Mas Riza lagi berempati.
Iya harus empati ya. Bukan hanya empati kepada code reviewer dengan tidak commit terlalu banyak dan lain-lain seperti yang kita jelaskan tadi. Kita juga harus berempati kepada sesama engineer. Bayangkan kita berada di posisi dia satu saat, terus code kita berantakan, terus dia gak bisa ngerjain, terus dia jadi blocker buat dia.
Gak dapat perusahaan, jadi blocker. Gak dapat keuntungan misalkan. Gaji kita dari mana? Sebenarnya kan kalau di tilik kan begitu kan. Ujung-ujungnya kan. Jadi makanya kita harus berusaha sebisa mungkin, ya code memang dikompilasi untuk mesin.
Tapi code yang kita tulis itu sebisa mungkin dipahami oleh manusia.
Dan itu sebenarnya kultur apa ya? Kayak apa sih? Lawan katanya lingkaran setan lah. Maksud saya physical kan kalau sudah jelek, tambah jelek, lebih jelek, lebih jelek. Nah lawan katanya apa? Kenapa gak ada ya?
Ya lingkaran yang positif lah. Maksud saya kalau udah kebiasa kayak gitu, makin sering kita saling melakukan code review yang konstruktif yang kayak tadi dibahas, kan kita udah kurang lebih, makin lama tuh kayak makin paham lah cara mikir sama cara nulis code teman kita.
Kalau suatu saat kita harus tiba-tiba take over atau apa, ya udahlah kita punya pengalaman yang kemarin-kemarin tuh kayak instingnya udah kebentuk lah ya.
Betul, betul. Dan itu kultur itu juga salah satu indikator kita pantas untuk masuk ke perusahaan itu atau enggak.
Karena percuma juga kita berempati kepada orang lain, tapi orang lain di sekitar kita tidak. Jadi yang nulis code buat orang lain, cuman kita, yang lain gak peduli gitu.
Ya udahlah kalau gitu tulisin puisi aja.
Nah itu kan jadi malah, ya itu tadi jadi lingkaran setan tadi kan akhirnya yang tadinya kita berusaha untuk memperbaiki.
Tapi kita berhubung kita masih baru, mungkin kita posisinya juga masih junior, otoritas kita belum ada gitu kan, kita tulis code rapi-rapi tapi orang lain malah nulis code yang jelek gitu.
Akhirnya ya jadi terpaksa kita ngikut, ngapain kita capek-capek nulis hal yang bagus gitu, yang lain gak peduli gitu kan.
Kita juga ngereview code orang juga sepertinya berempati karena gini, kita gak tahu misalnya gini saat dia baca itu, saat dia baca review kita mungkin kondisi dia sedang capek atau sedang stres ya kan.
Makanya sebisa mungkin review yang kita tulis itu hanya menargetkan codenya, bukan orangnya. Kedua saat kita berikan feedback itu feedback yang konstruktif dan berdasarkan fakta.
Contohnya kode ini bisa fatal error loh, karena begini, pikirkan case yang begini itu akan benar-benar fatal error. Ini linknya gitu, ini linknya, ini dokumentasi, fungsinya ini bisa written sesuatu yang gak kamu tangkap contohnya, yang gak kamu cek.
Kita coba bagaimana supaya fungsi ini lebih solid lagi gitu, nanti dia perbaiki. Dan kalau memang nitpicky dan memang kayak wah ini terlalu jelimet codenya jelek atau gak.
Tapi logicnya jalan gitu, tapi jeling kompleks gitu. Bilang itu kalau itu nitpicky gitu, bilang kalau itu personal province-nya kamu ini kalau bisa direfactor supaya lebih mudah.
Jadi tadinya fungsinya besar, bisa gak ini dipisah jadi 2-3 fungsi yang lebih solid. Jadi test-nya juga lebih gampang daripada ngetest. Karena fungsinya yang panjang, case-nya jadi lebih sulit, lebih kompleks daripada fungsinya kecil.
Tapi terlalu kecil juga jadi jelimet juga kebanyakan fungsi. Jadi banyak banget. Tiap return satu string, satu fungsi. Jadi ngaco juga gitu kan, jadi harus ada balance antara berapa banyak abstraction dan berapa banyak...
Maksudnya ada yang benar-benar atomic function gitu. Satu fungsi yang cukup satu gitu. Sama satu lagi, code review itu bukan side job.
Bukan dilakukan di pekerjaan taman di tengah-tengah, ah lagi pusing mudah code review. Bukan! Jangan lakukan code review lagi pusing. Jangan lakukan code review kalau lagi pusing.
Percuma! Akhirnya cuma antara kalian approve aja atau reject. Code review itu pekerjaan utama.
Itu kalau di perusahaan gimana si ininya? Siapa yang review atau ada post review yang role-nya? Code reviewer benar-benar yang dedicated atau di rolling?
Ya. Jadi bulan ini siapa yang bertugas gitu ya? Gak, gak, gak. Gantian. Kayak diajak disitu. Satu team misalnya gini, siapa yang punya waktu aja. Jadi kan kita distributed team, jadi time zone nya beda-beda.
Kalau saya suka, code review itu pagi-pagi. Jadi misalnya yang di EMDA, Eropa, sudah kerja nih sekarang. Udah selesai, udah nge-post. Ntar lagi dia nge-post semua tuh, besok paginya saya review pagi-pagi tenang-tenang.
Nah, kan yang paling lama itu nge-review yang pertama. Setelah feedbacknya selesai, saya gak nge-review semua lagi. Saya cuma nge-review per commit. Per commit nya aja yang saya review. Gak saya review lagi dari awal.
Gitu. Jadi treat code review itu sama sebagai pekerjaan utama. Memang kalau nge-block time 2 jam untuk code review, ya block aja 2 jam untuk code review. Jadi bukan pekerjaan sampingan.
Nah, dan bukan beban ya. Bukan sesuatu yang membahannya. Kita tetap kode kita harus nge-coding 8 jam ditambah code review. Gak kan?
Nah enggak, itu kan masuk 8 jamnya itu. Kalo emang...
Masuk 8 jam. Yang misalkan code review nya 2 jam, ya coding kita waktunya 6 jam gitu kan. Jadi bukan sambilan dan bukan beban yang harus kayak apa ya, bukan lembur ya.
Bukan amal.
Amal.
Tadi ada yang menyinggung juga tentang guideline. Untungnya sekarang tools itu sudah mulai banyak kan. Contohnya kayak yang tadi ya, lean stage, husky, explain, prettier, ya formatter gitu lah ya.
Itu cukup membantu untuk styling supaya konsisten kan.
Ya mungkin ada di satu kantor misalkan, di satu team yang satu pakai titik oma, yang satu gak pakai titik oma. Terus begitu masuk per tier udah ditambahin titik oma semua misalkan.
Jadi kan udah konsisten. Jadi enaknya sekarang salah satunya itu ya. Ini berkaitan juga dengan style guide. Style guide biasanya sekarang udah ada tools nya ya.
Nah sekarang pertanyaan saya adalah, siapa yang masih pakai komen? Kayaknya sekarang gak trend lagi ya semenjak ada chat GPT dan co-pilot ya.
Jadi pakai komen-komen-komen gitu. Kalau dulu kan kayak...
Ya kan abis itu bisa dihilangin.
Oh iya.
Gak tau ya temen-temen setuju atau enggak. Kalau saya sih lebih setuju kalau kode kita gak perlu ada komentarnya, kita udah mengerti itu baru kode yang bagus.
Kalau butuh komentar artinya itu rumit, kompleks, lebih kompleks.
Kalau klik yang "how to do code review" ini itu kan ada tuh.
Kila dokumentasi code review aja lengkap banget ya.
Iya.
Sorry yang di looking for, what to look for in code review.
What to look for in code review.
Oh ini penjelasan dari setiap step nya ya.
Turun, turun, turun, turun.
Yup tuh.
Usually comments are useful when they explain why some code exists.
Bukan what ya.
Yang kayak gue bilang tadi kenapa kode itu disitu secara spesifik, tiba-tiba dia nongol disitu, kenapa gitu.
Karena kita punya konteks, jadi kita ngasih komen itu supaya yang lain atau ngebaca itu gak ngabisin waktu, bongkar-bongkar lagi.
Jadi, if the code isn't clear enough to explain, then the code should make simpler.
Iya.
Tentang kodenya ya.
Bukan what is the code for, tapi why.
Tapi itu yang spesifik ya, yang kayak yang spesifik-spesifik komen, spesifik case biasanya.
Yes. Ini kayaknya dari komentar-komentar temen-temen disini kayaknya banyak sekali yang mengalami bad experience ya dengan perusahaan.
Teknisnya sih ya, karena kayaknya faktanya rata-rata kalau misalnya perusahaan yang belum punya kultur kayak gini dan mungkin kliennya bukan klien enterprise yang juga udah familiar dengan kultur kayak gini, kayak dunianya beda banget gak sih?
Dunia yang berbeda, betul-betul.
Kayak jauh banget.
Iya. Konsultan itu identik dengan deadline dan deadline yang ketat dan lembur dan lain-lain ya kalau di Indonesia ya. Kalau di luar, setidaknya sama.
Ya deadline lah di mana-mana.
Kerjaan sama, maksudnya apa ya, kalau konsultan itu ya tipes gitu. Jaminan tipes gitu, kerjaannya parah gitu kan, gak sesuai. Kalau deadline ya udah pastilah. Semua yang buat kerja juga pasti ada deadline, kalau gak ada deadline ya gak telat-telar kan.
Jadi bukan maksudnya ada deadline atau gak ada deadline, lebih ke prosesnya, bagaimana proses mencapai kesanannya.
Mungkin gak cuma perusahaan tapi kliennya juga, customernya mungkin kalau di luar kan, customernya apa ya, ya mungkin dari yang kelas kerja rodi atau kelas kekeluargaan sampai kelas yang enterprise yang emang semua harus by the book.
Karena itu juga terikat hukum, hukum di sana kan mungkin lebih ketat juga ya kalau misalnya apalah ada security issue atau apapun itu. Jadi mungkin kalau di internasional ya kayak kita punya, kita sebagai developer punya atau apalah production house, software house atau korporat atau apa kayaknya opsinya tuh macem-macem lebih luas aja mungkin ya daripada di sini.
Nah ini ada pertanyaan bagus juga, clean code versus performance, mana yang harus didahulukan?
Biasanya saling terkait sih, kalau kode kita jelek agak susah tuh memperbaiki performance-nya, bener gak? Performance itu kan ada dua hal, satu performance dalam maintain code-nya dan kecepatan mengandalkan code, dan user dari execution speed dari kode itu sendiri kan.
Betul, betul. Jadi saya bilang itu bukan versus tapi berbanding lurus. Iya berbanding lurus. Iya. Jadi dua-duanya harus didahulukan.
Dan ada beberapa lagi yang lain untuk, ini juga pertanyaan menarik nih, kalau untuk fresh grad yang mau ngelamar junior, hal-hal kayak gini itu di-training dulu atau perusahaan sudah berharap bahwa kita udah paham?
Ada onboarding pasti di setiap perusahaan.
Itu kuncinya onboarding. Kalau emang ada, maksudnya kalau emang perusahaan merapuin hal itu. Nah kalau perusahaan kayak kan di komen pada bahas tuh, kalau perusahaan itu kan masih kolot atau biografis atau apa.
Jangan-jangan malah kita lebih tahu daripada push-push-nya. Nah kalau itu susah ya, karena emang belum ada kulturnya sama sekali. Ya udah itu mau pasang aja kali.
Ya kalian jadi, kalau belum ada kalian jadi agent of change lah. Betul. Ini juga mengingatkan teman-teman di sini yang udah jadi senior, yang dulu mengalami pembulian tanpa ada mentoring, gak ada code review dan lain-lain.
Yang udah senior, yang udah punya otoritas di kantornya, tolong dong jangan sampai hal itu kejadian sama teman-teman yang junior gitu ya.
Jangan bantu junior-nya untuk memecah lingkaran setan menjadi lingkaran yang lebih baik gitu. Jangan malah mengikuti.
Dan balik lagi ya, kultur onboarding itu biasanya ada di perusahaan-perusahaan tertentu gak di semua. Nah ini ada best practice-nya gak?
Buat milih perusahaan yang sudah menerapkan practice-practice yang kita omongin tadi.
Kecuali emang perusahaannya punya blog dan kebetulan blog post-nya ada mendetailkan code review. Enggendering blog ya. Iya tapi kan gak semua. Kalaupun ada belum tentu mereka nulis blog tentang itu kan.
Maksudnya realistis lah bergantung ke kita B.U. atau enggak. Maksudnya kita kan misalnya lagi butuh cari kerja nih. Misalnya kita gak, kecuali emang lagi nyari santai, emang udah ada job, nyari-nyari santai.
Kalau ketemu yang menarik, oke lah coba. Cuma kalau misalnya lagi belum ada kerjaan, B.U. ya udah realistis. Masa nyari yang punya engineering blog dan membahas code review dulu kayaknya.
Salah satu tipsnya sebenarnya mungkin agak susah dilakukan ya. Terutama buat fresh graduate yang masih malu-malu itu adalah kontak developer yang ada di perusahaan itu.
Entah mungkin ada teman yang di sana atau bisa contact, cari lewat link-in, langsung call, message gitu ya. Mungkin belum tentu dibalas juga sih ya. Atau pada saat interview atau pada saat datang ke kantor gitu kan.
- Terus kan ada kayak... - Kita tanya aja, kalau pas interview kan. - Iya, kayak tour gitu kan. Ini developmentnya, yaudah tukar kartu nama atau tukar nomor whatsapp gitu kan. Abis itu tanya-tanya.
- Gak ada cara lain sih. - Biasanya HR kan kalau saat interview kan pasti diujun ada yang mau ditanya. - Ada pertanyaan gak?
- Itu listnya, on-boardingnya gimana, code review. - Kalau sama SR mungkin agak sedikit berbeda ya, tapi mungkin sama...
Kalau lowest biasanya kan hapus selanjutnya pasti sama someone dari team engineeringnya.
Kalian tanya aja, bagaimana proses code review, bagaimana code styling kalian, best practicesnya ada dimana, bisa saya baca gak, tanyain semua tuh.
- Dan jawab, itu apa ya? - Reflect.
Kalau cara meyakinkan team product, ya harus di edukasi sih. Sama kayak cara meyakinkan klien, klien dari konsultan tadi.
Di luar mungkin kliennya sudah lebih di edukasi untuk oh ternyata proses yang benarnya seperti ini, memakan waktu agak lama karena ada testing, ada ini, ada ini tapi...
Bugs-nya minimal sehingga delivery-nya in total sama aja sebenarnya, cuma prosesnya mungkin agak lambat di awal gitu kan.
Itu harus di edukasi sih, kultur lagi, balik lagi ke kultur.
Kita mesti pinter ngerjemahin ke value ekonomi, kayak misalnya kalau ada bug, tapi mungkin kita harus ngumpulin data ya, ngeresepnya gimana.
Jadi misalnya kalau, apa begu-beguannya nih, kalau ada bug, ternyata selain panik, dadakan, di jam yang kita gak tahu, belum tentu ada developer on call.
Bener-nya fixing bug itu butuh main hour, dev hour itu sekian jam. Sedangkan kalau misalnya 3 jam total.
Ada risiko ketidakpastian dan downtime-nya jadi lama kalau ada isunya di jam yang gak ada yang on call atau apalah.
Ya agap aja 3 jam dan ini ada dampak negatif. Tapi kalau kita code review, itu cuma 2 jam.
Kita harus bisa membahasakan itu dengan konkret ya, kalau mau meyakinkan ke apa? Organisasi.
Tapi lagi-lagi ini hipotesa, gue juga belum pernah nyoba kayak gini sih.
Tapi kan itu satu-satunya bahasa yang mereka akan paham kan, maksudnya jadi bukan cuma karena pengen-pengenannya engineer atau karena trend.
Ya jadi ini bukan perkara selera, tapi emang ini praktek yang menguntungkan organisasi. Kita harus bisa membawa angka sih.
Membawa angka, betul-betul. Apalagi sama tim bisnis ya.
Yang ini juga apa namanya, ini kasus yang lain. Contohnya anggap aja si company itu menghayat agensi.
Jadi company itu juga punya tim IT-nya atau tim programmernya yang dimasukin ke projek yang sama.
Jadi sebenarnya emang kayak transfer knowledge. Transfer knowledge.
Jadi value editnya kita sebagai agensi, kita saling code review.
Jadi kita code review kodenya mereka supaya kita pastiin kodenya mereka sesuai dengan standard kita.
Bagi si company, timnya mereka juga grow karena dari teknologi yang mereka belum bisa, dapat teknologi dari agensi dari third party.
Sehingga timnya mereka grow juga. Yang ujung-ujungnya mereka lama-lama bisa self sustain untuk maintain code itu kan gak selamanya bisa perlu gontorin dana untuk hire agensinya.
Jadi sebenarnya sama-sama grow. Itu juga bisa.
Nah itu kan balik ke duit juga kan. Maksudnya apa, jadi mereka bisa tetap jalan itu gak kebuang, gak sia-sia mereka bisa tetap jalan entah cari agensi lain atau maintain sendiri atau apalah.
Nah itu kan berarti ada kayak value ekonomi lah finansial yang konkret. Jadi UUD, ujung-ujungnya duit semua.
Sudah pasti itu. Oke ini pertanyaannya seru-seru ya ternyata ya. Ini ada pertanyaan yang menurut saya menarik tapi masih ada hubungannya ya.
Satu codebase repository apakah dalam gitflow itu harusnya ada minimal empat brand atau bisa lebih. Maksudnya apakah brand, itu feature ya, develop feature ya harus diapus atau dipertahankan. Mungkin siapa, Charles ya. Saya mau sedikit meluruskan, sedikit meluruskan tentang gitflow.
Jadi ada artikel yang cukup viral dari Pak Vincent ini. Dulu dia yang menggagas gitflow tapi ada note-nya.
Tapi di 2020 setelah 10 tahun artikel dia beredar, dia menyatakan bahwa ini bukan untuk semua, bukan best practice lah, bukan best practice lagi.
Jadi kalau misalkan tim kita sudah melakukan continuous delivery, dia lebih menyarankan untuk mengadopsi workflow yang lebih simple. Contohnya gitflow dengan pull request dan lain-lain, atau pakai trunkbase development.
Trunkbase ini lebih sederhana karena cuma ada 2, master sama yang featuring ini tadi. Udah itu doang. Jadi nggak ada dev, nggak ada apa-apa, cuma master sama feed-feed aja. Begitu sudah selesai, dimers, yang ini dihapus.
Itu saja. Jangan cari yang sulit-sulit ya. Yang simpel-simpel aja. Dan benar tadi ya, yang melanjutkan tadi Pak, yang kita approach ke orang yang sudah bekerja di sana.
Ya kita coba aja ngobrol aja biasa. Kalau dia setelahnya respons-nya bagus, artinya ya berarti ini kayaknya oke juga nih perusahaan. Karena dia memberikan respons-nya bagus.
Kalau misalkan apaan sih? Belum gabung aja, udah nanya-nanya, nah berarti itu.
Kayaknya nggak mungkin senyolot itu. Cuman misalnya mereka nggak boleh entah karena alesan apa, nggak boleh. Nggak boleh ngomong. Expose itu kan ya paling ada deh, ya kan paling dijawab ngeles gitu kan.
Atau kalau emang mereka nggak pengen ngejawab kan ya itu. Kalau chat kan tinggal diignore aja ya.
Iya kalau chat tinggal diignore. Kayaknya nggak mungkin di marah-marahin.
Dimarahin sih nggak mungkin. Cuman maksudnya kayak tadi kan nggak boleh ngomong. Kalau nggak boleh kan tinggal ngeles aja.
Iya kalau chat nggak boleh berarti perusahaannya agak tertutup, nggak open gitu kan. Maksudnya secara kulturnya. Jadi kita bisa nilai juga gitu.
Yang terakhir itu boleh minta link-nya. Oke, link yang ini ya. - Tadi yang Trunk-based.
Ini yang Gitflow, yang ini Trunk-based. Siap.
Oke, tentang code review. Ada lagi yang mau dibahas? - Ini ada coba dibuka yang chat GPP yang di Google Docs.
Oh iya, iya. Udah dibuka, udah dibuka. Ini kan on-demand review. - Yang on-demand code review.
Tadi kayaknya ada yang komen chat GPP juga. - Bahu, Bahu.
Bahu tadi nge-check bahwa bisa jaman sekarang bisa direview oleh AI.
Dan ini bukan bahas yang tadi ya. Bukan yang apa kayak linting, formatting, bukan apa CI pipeline yang itu.
Cuma beneran literally please review my code. Ini lucu sih.
Ya gue belum pernah lihat orang yang beneran kayak gini. Cuma baru lihat di artikel ini.
Tapi maksudnya dengan adanya large language model kan LLM emang jadi bisa kayak gini.
Cuma pertanyaannya, ini cuma lucu-lucu artikel seru-seruan doang. Cuma what if, cuma ide doang.
Atau apakah ini beneran visible gitu. Soalnya si AI ini kan apakah berarti AI mempelajari seluruh code base di organisasi itu atau gimana ya itu?
Gak tahu ya. Ini gimana ya. Saya belum pernah sih nyobain tanyain GPT atau LLM.
Sekarang misalnya ada nggak cowo gitu kalau yang di screenshot ini. Coba deh lihat, scroll ke...
Saya sudah coba pakai yang Copilot. Kalau misalnya Copilot itu untuk mengerti seluruh code base, gak bisa.
Tetapi kalau untuk mengerti satu function itu bagus kok.
Ini tab bot di Github kan. Pakai GPD. Pakai OpenAI punya gitu ya.
GPD 3.35. Terus bisa pakai text Da Vinci. Da Vinci itu modelnya siapa ya?
Modelnya OpenAI. Udah gak ada. Deprecated. Sekarang yang 3.5. Yang terlama.
Jadi kalau ada yang PR masuk ke Github. Terus di review oleh review bot. Terus masuk ke git diff. Terus abis itu dia create dynamic prompt and post request.
Terus bikin promptingnya. Terus request ke API, OpenAI API. Terus dapet review suggestion-nya dikirim balik ke Github.
Ini maksudnya seru secara konsep. Ini lo malah diseru tuh, nomor satu, add more comments.
Ini mungkin bisa dibaca sebagai, saya gak ngerti kode kamu, tolong bikinin comment biar saya ngerti bahasa Inggris.
Ini kan tergantung juga, tadi kan yang kita baca itu contoh aja praktek di Google, satu perusahaan sendiri.
Soalnya ini kan si LLM-nya ini gak punya opini, gak punya basis, gak punya landasan buat melakukan kode review ya.
Terus apa ya, LLM itu kan kayak non-deterministik ya. Mungkin gak sih jangan-jangan kita manggil review bot sekarang.
Terus semua dikasih komen. Oke lah, anggap aja dia standarnya gitu. Minggu depan kita manggil review bot lagi.
Terus malah jangan kebanyakan komen. Make the variable name obvious. Itu kan malah sampai redaktif ya.
Dia random kan, ada random-nya kan. Jawabannya bisa beda-beda kan.
Mungkin ini sebagai starter aja buat guide untuk si reviewer untuk mereview.
Oh ini ada itu sih di challenge, dia si penulis artikelnya juga ngejelasin kok di bagian challenges.
Ini dia yang bikin berarti ya? Dia pengen bikin seperti ini gitu ya?
Enggak, kayaknya dia pakai package yang udah ada, cuma dia mereview. Dia ngejelasin bisa kayak gini, kita bisa melakukan ini.
Masalah apa, manfaatnya apa. Terus challenges-nya dia juga ngejelasin nih, ada context, blablabla.
This is due to a limited understanding of the codebase context.
Terus yang kedua, security and privacy, ya itu jelas. Sama yang ketiga nih, yang tadi kita bahas.
Dikit model bias, tergantung training data yang dia pakai. Nah itu kan mesti code yang dia pakai sebagai training data kan bisa lain-lain.
Itu males juga kalau minggu ini disuruh nambah komen, minggu depan disuruh remove komen.
Sama itu, halusinasi satu lagi. Biasanya kalau kodenya bahasa-bahasa yang umum gitu ya, itu masih dia masih mengerti.
Kalau misalkan kodenya, kalau kata mas Arya Hidayat tuh, kalau juur itu ngaco tuh, cat GPT.
- Karena nggak ada training datanya kali. - Iya sedikit training datanya, sedikit.
- Terus setiap bingung arang-arang aja udah sisanya. - Iya, halus jadinya kan, gitu.
Tapi menarik ya. Tools sekarang kan, ya tadi kan dari mulai styling doang, formatting doang, sekarang bahkan udah sampai dependable, itu paling sering.
Depanda bot, renovate bot.
Terus sekarang ada untuk reviewer. Jadi sebenarnya ya meskipun kalau dipakai untuk nge-review kayaknya masih belum ya, karena nggak konsisten tadi ada 3-3 problem tadi, 4 lah sama halus.
Tapi setidaknya kalau kita nggak tahu mau mulai start dari mana untuk nge-review, mungkin kita bisa lihat dulu, oh si review bot ini dia nge-review tentang ini, tentang ini, tentang ini.
Mungkin kita bisa mulai dari situ untuk belajar cara nge-review code.
Atau mungkin kalau tempat kerja kita sendiri nggak punya sistem code review, terus kita punya personal project, iseng pengen tahu gimana sih rasanya di code review.
Walaupun bukan sama orang, lumayan lah latihan di code review sama robot.
Oh iya benar, benar.
Kalau halus atau kalau rese, ya udah di-disable, tinggal dimatiin aja kan.
Benar. Cigpti soal join subquery malah dikasih sintaksnya Laravel, tapi jalan ya.
Berarti kode Laravel banyak jadi itu ya, jadi training data ya, luar biasa.
Karena Laravel itu dokumentasinya banyak, berbagi bahasa.
Dan versi nya udah banyak banget, kan udah puluhan tahun.
Iya, iya, iya. Benar, benar, benar.
Oke, ada lagi yang mau disampaikan mengenai code review? Sudah, aman?
Udah. Ini ada Marsudi, nanti datang di DevFest Depok tidak.
Saya absen dulu di Depok, kita ke Bogor loh, kita di Bogor.
Kita bertiga di Bogor nanti akan ada di Bogor.
Jadi kalau ada teman-teman yang berada di Bogor dan sekitarnya, Jakarta boleh lah ya main-main ke Bogor.
Sangal berapa? Sangal 25 November. Yes. Daging.
Nah ini, daging. Daging apa ya? Kontennya daging. Terima kasih.
Padahal kalau daging semua bahaya ya, harusnya ada tulang juga, kolester.
Oke kalau gitu, mungkin udah hand dulu untuk malam hari ini kita ketemu lagi minggu depan dengan topik yang berbeda.
Buat semuanya yang udah ikutan diskusi juga, seperti biasa kritik saran dan topik bisa kirimkan ke kesana.in/ngobrolinweb.
Mungkin minggu depan kita akan coba review yang ada di sini, yang ada di Slido untuk topik-topik yang akan kita bahas ke depannya.
Sekian dulu buat malam hari ini, kita bertiga pamit, sampai jumpa minggu depan.
Terimakasih sudah menonton.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://ksana.in/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
23 Jul 2025
Bedah Buku Problem Solving 101
Episode ini membahas buku "Problem Solving 101" karya Ken Watanabe, mantan konsultan McKinsey yang menulis buku ini seba...
15 Nov 2023
Ngobrolin RedwoodJS
Redwood dibahas sebagai contoh framework yang berani memilih ceruk yang sangat sempit. Kalau kebanyakan perkakas berusah...
8 Apr 2026
Bedah Situs
Episode ini adalah sesi bedah situs, membedah dua website yang dikirimkan lewat DomaiNesia secara langsung di depan peno...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .