Ngobrolin Code Review - Ngobrolin WEB

1:41Oke, kembali lagi seperti biasa ada Ivan, ada saya Riza, dan juga nanti Eka akan nyesul.

1:49Kita malam ini akan ngobrolin tentang code review.

1:54Nah, disini siapa yang di kantornya belum melakukan code review.

2:01Tunjuk tangan, tunjuk tangan.

2:03Oh Eka belum ya.

2:05Itu Eka.

2:07Kata-kata belum ya.

2:09Munculnya pas ya.

2:11Munculnya pas.

2:13Nah ini seru-seru ya teman-teman disini pada eksplor Redwood.

2:18Wah Redwood.

2:19Lagi asik, kenapa ada yang menarik ya dari Redwood ya.

2:22Asik ya.

2:24Mungkin salah satu framework favorit personal.

2:26Asik.

2:28Kapan-kapan kita bikin edisi favorit personal.

2:33Edisi favorit personal, oh boleh tuh menarik-menarik.

2:37Cetet dulu.

2:39Jadi kalau kisih-kisihnya Redwood itu metaframework, metaframework react.

2:46Mereka itu ambil perspektif yang kalau menurut gue kayak agak kurang konvensional.

2:52Jadi biasanya kan metaframework ya terutama yang baru-baru ya.

2:58Kan sudut pandangnya wah ini apa kebebasannya banyak lah.

3:02Pokoknya versatile, gampang di modi, bla-bla-bla.

3:06Ini opinionated ya.

3:08Sangat opinionated dan kalau di bahasa Inggris kan ada istilah itu tuh.

3:14Everything but the kitchen sink.

3:16Jadi kayak semua dikasih sampai seisi dapur, sampai wastafel bak cuci, bak cuci piring aja dimasukin.

3:24Jadi kayak beneran apa aja ada dan semua udah di set up buat kita.

3:30Termasuk code generator.

3:32Jadi kita kayak mau bikin komponen kalau di Redwood itu istilahnya cell.

3:36Udah ada generatornya.

3:38Banyak magicnya ya.

3:41Magicnya banyak banget dan ya emang belum tentu cocok buat semua proyek.

3:46Dan mereka itu fokusnya buat start up.

3:49Jadi mereka tuh unik karena beneran kayak nantuin satu niche yang spesifik banget.

3:54Jadi apa audiensnya, penggunanya adalah developer, start up kecil.

4:00Biasanya start up kalau baru mulai kan kecil ya.

4:03Apa karyawannya belum banyak, biasanya full stack.

4:08Mungkin pengetahuan nya ya enggak, enggak canggih-canggih amat.

4:12Jadi kayak database segala macem udah dikasih ORM, Prisma.

4:16Terus punya authentication ada, database ada.

4:19Sampai admin dashboard untuk crude ada.

4:22Dikasih semua beneran.

4:24Oh ini karena backgroundnya ya si Redwood itu kan dibikin sama...

4:29Yang bikin GitHub.

4:31Ke foundernya GitHub.

4:33Terus abis itu dia bikin dan...

4:35Terus random buat bikin tombol.

4:38Itu agen gak nyambung sih.

4:39T-O-M-L.

4:41Kayak Yamel kan.

4:43Namanya dia Tom.

4:45Oh gitu.

4:47Cuma experience pake Redwood itu mereka pilih niche yang sangat spesifik.

4:53Terus mereka pake pendekatan yang sangat berani lah.

4:58Mereka bikin keputusan pendekatan yang kayak gitu.

5:00Dan kalau emang kebetulan project kita sesuai itu experience nya enak sih.

5:07Itu adalah...

5:08Dikapel? Gampang gak?

5:11Susah.

5:13Ya bisa teknik lu bisa.

5:16Cuma susah ya jangan lah.

5:18Dia berangkat dari GitHub kan.

5:21GitHub kan sangat Rails banget kan Ruby on Rails kan.

5:24Jadi memang framework nya itu ala-ala Ruby on Rails.

5:27Jadi banyak magic, lengkap.

5:29Terus juga salah satu framework.

5:31Oh iya sih kayak Rails tapi untuk ekosistem JS.

5:35Oh gak ya backend juga ya?

5:37Full stack.

5:39Dan sampai storybook nya aja di settingin.

5:42Oh udah testing di settingin.

5:45Siap-siap.

5:47Harus kita bahas ya.

5:49Selain itu juga ada Solid Start.

5:51Wah Solid Start.

5:53Belum coba.

5:55Nah ini siapa nih panggilannya Triadmoko atau Denny atau Fatros?

6:00Belum.

6:03Soal krab gitu.

6:05Ini jawaban belum untuk code review.

6:09Berarti Eka belum melakukan code review.

6:14Belum pake.

6:16Yang udah berarti Ivan doang ya.

6:18Kalau saya gak kode review.

6:20Gimana ini?

6:22Ada, ada.

6:24Tapi kan saya gak terjun langsung ke tim development kan.

6:30Jadi review nya bukan kode.

6:33Boom.

6:34Iya.

6:37Dan malam hari ini kita akan bahas kenapa kode review itu penting.

6:41Apa aja opportunity di sana.

6:44Kalau kita mendapat kode review.

6:46Kan pasti kalau misalkan kita terapin kode review.

6:48Arti kan harus menambah main power kan setidaknya kan.

6:55Atau memperlambat pekerjaan kan.

6:57Gak bisa dipungkiri kan.

7:00Tapi di sisi lain kualitas dari produk atau dari kode kita pasti akan meningkat jauh.

7:07Karena biasanya kita tidak bisa melihat kesalahan diri kita sendiri.

7:12Gitu yang sering terjadi.

7:15Bahkan kalau kita pair programming itu kadang kita gak bisa lihat ada typo.

7:22Kalau sekarang udah ada, udah lengkap ya udah ada ISD dan lain.

7:26Tapi kalau misalkan ada kesalahan logic misalkan.

7:29Itu kadang-kadang kita bisa tidak terlihat.

7:31Tapi teman kita di samping dia bisa langsung tahu.

7:34Dan kira-kira gimana sih cara kode review yang supaya tidak menyakiti ya.

7:43Tidak baperan.

7:45Yang sehat.

7:47Yang sehat.

7:49Dan efektif ya gak sih.

7:51Biar gak muter-muter terus itu gimana sih selama ini penasaran.

7:55Betul.

7:58Pertama yang akan kita bahas adalah tentang apa itu code review.

8:01Ya.

8:03Jadi apa itu dan kenapa gitu ya.

8:06Jadi kalau disini di Google.

8:12Google best practice ya.

8:14Engineering practice nya Google itu tujuan utama dari code review adalah.

8:19Supaya memastikan kode kita sehat.

8:23Overall.

8:26Check up.

8:28Ada check and recheck ya.

8:30Tapi yang pasti developer harus ngerjain ya.

8:34Kalau gak dikerjain apa yang mau di review gitu kan.

8:37Maksudnya kalau misalkan ada error ada bugs ada kesalahan.

8:40Terus tiba-tiba di review nih tolong nih perbaiki ini.

8:43Ya kita harus perbaiki kan.

8:45Terus kalau kita gak improve dan tidak submit ya.

8:49Tercuma juga ada proses code review kan.

8:52Dan begitu juga sebaliknya.

8:55Adalah timbal balik ya.

8:56Kedua belah pihak itu dua-duanya berperan serta.

9:01Untuk melancarkan pekerjaan bukan menghambat.

9:06Ini kan ada main kucing-kucingan kan kalau misalkan bukan code review ya.

9:10Tester sama developer gitu kan.

9:13QA.

9:15Kadang-kadang diumpetin sembunyiin terus tiba-tiba testernya tahu.

9:19Ini hampir sama sih.

9:22Si developer ngerjain begitu udah di review.

9:25Yang reviewnya juga harus bukan tidak nge-judge sih orangnya.

9:30Ini jelek banget sih kode lu gitu.

9:33Sentimen.

9:35Waktu kuliah gak belajar coding ya misalkan gitu kan.

9:38Itu kan negatif kan.

9:41Negatif sekali gitu.

9:43Itu menyerang orang kan.

9:45Itu gak boleh.

9:48Jadi memberi feedback dan menerima feedback dua-duanya sama pentingnya gitu.

9:52Bagaimana cara kita memberi feedback yang baik dan bagaimana cara kita menerima feedback.

9:57Ya kalau kita baca feedback yang tidak menyerang personal ya bisa aja kan kita tetap baper kan.

10:04Tapi kalau kita melihatnya sebagai ini sesuatu yang bisa mengimprove diri kita gitu.

10:09Itu juga sesuatu yang harus kita lakukan.

10:15Nah kadang ada trikinya juga ya kalau melakukan code review itu.

10:19Kita...

10:21Kalau ini bukan kasus saya maksudnya gini.

10:26Kita biasanya yang penduduk Asia gitu kan.

10:31Kalau misalnya beda level itu sungkanan orangnya.

10:34Oh iya.

10:36Bener, bener, bener.

10:39Jadi kalau misalnya kita nge-review code orang yang lebih senior apalagi owner apalagi orang sakti.

10:45Misalnya anggap aja lah FK tiba-tiba nge-review codenya.

10:49Siapa yang bikin itu tadi.

10:53Yang bikin redwood tadi misalnya.

10:55Dia submit PR tiba-tiba salah nih gitu kan.

10:59Pasti sungkan gitu ya.

11:01Lgtm aja deh lgtm.

11:06Itu sindrom yang pertama kali saya dapet kan waktu dulu awal bekerja di dunia proses yang waktu itu.

11:11Aduh sungkan gitu.

11:13Tapi ternyata enggak.

11:15Meskipun sesenior apapun seseorang itu.

11:19Pasti dia akan appreciate kalau misalnya di...

11:24Code dia di review dan ditemukan sesuatu yang bisa diimprove.

11:29Pasti dia appreciate.

11:32Dan dengan saya membaca codenya dia pun saya belajar banyak.

11:37Oh ada style nya, ada code style nya sendiri, maksudnya cara coding nya gitu.

11:42Karena banyak banget kan itu.

11:44Cara orang coding, cara orang apa namanya memberi nama variable.

11:52Yang jelas, yang gampang dibaca itu beda banget dari satu engineer ke engineer yang lain.

12:00Jadi dengan membaca code orang kita lebih banyak belajar.

12:07Lebih banyak belajar.

12:09Inilah keuntungan dari code review.

12:12Ya salah satunya ya.

12:14Jadi kata kuncinya adalah membaca code orang lain.

12:17Karena kadang-kadang kita males atau enggak mau, engan gitu ya.

12:22Padahal sebenarnya banyak hal yang bisa kita pelajari dari code.

12:28Bagaimana seseorang itu berpikir mungkin beda ya dengan cara kita ya.

12:31Mungkin dia menyelesaikan masalahnya dengan dari counter clockwise, kalau kita yang clockwise.

12:37Tapi ujung-ujungnya sama.

12:39Menyelesaikan masalah juga.

12:41Justru karena pendekatan yang berbeda, kita bisa jadi dapat pengalaman yang itu juga.

12:46Oh ternyata bisa begini ya, enggak hanya begitu.

12:48Ada tambahan experience juga di sana kan.

12:53Dan benar sekali kita bisa upgrade si junior jadi ke level berikutnya ya salah satunya dengan code reviewnya ya.

13:02Karena kita pasti pas ngereview ngasih input yang konstruktif ya.

13:09Dan cara ngasih input juga nanti kita bahas lanjutnya supaya bagaimana menghindari blaming.

13:21Blaming ya itu enggak boleh.

13:23Biar kan git yang nge-blame.

13:25Tetapi instead kita nge-construct percakapan.

13:32Misalnya kita tahu nih logicnya salah ya, kita tahu wah ini logicnya salah.

13:39Ini dia bakal, kalau dia pakai logic ini akan ada kasus yang begini gitu.

13:46Atau ada obvious yang sesuatu yang obvious.

13:50Ini karena fatal error sih, karena dia enggak handle itu.

13:53Tetapi daripada saya mengatakan ini salah, ini perbaiki, ini perbaiki, ini perbaiki itu enggak sehat ngasih code review seperti itu.

14:01Oke.

14:03Jadi misalnya gini, contohnya aja ada document.queryselector saja, itu document.queryselector class.

14:15Kita tahu kalau document.queryselector class itu bisa nul, baliknya bisa nul.

14:23Tetapi di bawah constant itu langsung dia pakai, langsung manipulate whatever.

14:30Kalau nul kan berarti itu bisa jadi fatal error ya.

14:34Apalagi enggak di-try-catch.

14:36Nggak di-handle.

14:39Ini ketimbang saya ngasih taunya tolong handle sanity check, tolong handle sanity check, please handle sanity check misalnya.

14:52Itu menurut saya kurang sehat.

14:55Karena lebih baik kita memberi input yang konstruktif.

15:02Kita kasih tahu, gimana menurut kamu kalau misalnya elementnya nggak ditumbuhkan dan nul.

15:09Karena document.queryselector, document.queryselector itu bisa return nul.

15:16Saya langsung biasa kasih link menuju web MDN.

15:22Langsung paste.

15:24Dokumentasi.

15:26Dokumentasinya ini dan taruh di situ.

15:30Jadi dia, biar dia mikirin gimana solusinya.

15:33Saya nggak perlu ngasih solusi di review.

15:36Oke.

15:38Unless dia sudah beberapa percakapan dan dia masih nggak dapat, baru saya ngasihin begini loh maksud saya.

15:49Bukan langsung bilang, oh ini error, ini salah.

15:58Betul, jadi dari sisi quote review, ada dua hal.

16:02Pertama dari sisi reviewer, bisa numentorin.

16:09Numentorin, nggak peduli level ya, numentorin itu nggak peduli level.

16:15Dari sisi reviewer yang menerima feedback itu belajar dan juga berpikir yang berbeda.

16:28Berpikir dari orang yang berbeda, menangkap oh maksudnya si orang itu gimana gitu, apa yang bisa diperbaiki.

16:35Yes.

16:38Dan kalau misalnya, kadang ada itu ya tulisan need itu, need n-e-t, n-e-t, need p-k-i.

16:46Oh need p-k-i.

16:48Nah itu kadang ada kasus-kasus tertentu yang saya punya quote style saya sendiri, yang saya punya demenan.

16:56Contohnya saya suka written ya kan, supaya itu quote style saya, preferensi saya.

17:04Tanpa itu sebenarnya code-nya jalan gitu, yang dia bikin itu logicnya jalan.

17:08Tetapi quote style-nya kurang oke bagi preferensi saya.

17:14Ngerti nggak maksudnya?

17:16Jadi, tapi saya mau feedback dan biasanya karena saya mau feedback dan saya tulisannya need, need p-k-i.

17:25Artinya apa ya bahasa Indonesia need p-k-i.

17:28Cari-cari kesalahan.

17:31Ya gitu lah, ya berusaha cari kesalahan. Ini need p-k-i.

17:34Lo bisa coba pikirkan bagaimana, need p-k-i kalau bagi gue misalnya,

17:40gue lebih suka erliritan supaya, direflektur supaya lebih mudah baca code-nya.

17:47Tetapi kalau nggak direobah, nggak apa-apa.

17:50Gak apa-apa.

17:53Nah bentar, tanya soal need ini, need itu dari sudut pandang personal code reviewer atau dari perspektif tim atau company?

18:04Atau organisasi gitu?

18:06Biasanya kalau need p-k-i itu dari personal.

18:14Karena kalau dari company itu biasanya mengatur dengan general atau dari project.

18:20Biasanya kalau project, sebelum nyampe PR itu saya diassess by get code review kan sudah memenuhi banyak step sebelumnya.

18:34Contohnya sudah lolos, sudah lolos linter.

18:40Linting dan lain-lain.

18:42Lintingnya segala macam kan sudah otomatis tuh, sudah otomatis segala macam sudah pasti lolos.

18:48Kalau masih minta error, jangan kasih-kasih test aja gitu, percuma.

18:52Pasti atas saya bilang, benerin dulu linternya.

18:55Karena kalau sudah saya review, nanti lu benerin lagi linternya, itu centangnya hilang, percuma gitu.

19:03Jadi benerin dulu nih linternya.

19:05Terus kemudian unit test-nya.

19:08Unit test-nya sudah benar, sudah pas semua, baru di review.

19:13Terus kemudian codenya, biasanya kan codenya itu sudah ada di develop.

19:22Kita kan ada 3 environment, development, staging, dan production.

19:27Biasanya codenya sudah dia test dulu, sudah dia test di development.

19:33Dan sudah dia kasih screenshot-nya atau videonya.

19:37Dan sudah kasih change list-nya, change log-nya sudah ada.

19:41Jadi di PR itu sendiri, di batang tubuh PR sudah ada tiketnya.

19:49Title, tiket, change log, screenshot kalau ada before and after, atau video.

20:00Steps to test, ada steps to test-nya bagaimana test di development.

20:07Dan beberapa centang untuk misalnya, saya sudah cek di browser A, sudah cek di browser B, sudah cek di browser C, contohnya.

20:20Sudah ada centang-centangnya.

20:22Kalau itu semuanya sudah terpenuhi, baru terakhir code review.

20:29Jadi yang saya nitpick itu biasanya yang personal pribadi.

20:37Karena kalau yang sudah code styling, titik koma, spasi, tab, segala macam itu sudah di handle sama sniffer semua.

20:47Saya tidak melihat dia salah spasi lagi, karena sudah pasti ketangkep.

20:53Urusannya pre-tier dan e-slint dan lain-lain.

20:57Kecuali saya lihat itu sengaja di disable, ada itu.

21:02Ada, ada-ada aja.

21:04Jadi supaya styling-nya lolos, dia styling disable, enggak enak.

21:11Iya, iya, iya.

21:14Nice try.

21:16Nice try but no.

21:22Biasanya kan itu juga kalau e-slint dan pre-tier juga bisa di setting kalau belum lolos, enggak bisa di push.

21:30Bisa commit ke husky.

21:32Iya, itu juga bisa.

21:34Oh itu kalau yang husky yang di lokal ya.

21:37Lokal-lokal ya.

21:39Bisa di setting lah.

21:41Post-hook ya.

21:43Post-hook.

21:45Itu masuk ke CI dulu atau sebelum CI code review itu?

21:53Sudah, sudah CI dong.

21:55Sudah CI kan ya.

21:57Jadi begitu push ke github, PR-nya itu kan langsung, github action langsung jalan semua.

22:03Ya, langsung CI kan.

22:05Linter, begitu push satu commit, linter jalan otomatis.

22:08Kita ada linter bot sendiri, kita punya company punya linter bot sendiri yang nge-check PHP, CSS, sama SAS, SCSS.

22:19Udah pada paham nih, ada husky, ada lean stage ya kalau buat di lokal.

22:24Kalau jaman dulu kita pakai Jenkins.

22:27Jenkins.

22:29Enggak nyamanin.

22:33Enggak nyamanin.

22:35Masih ada Jenkins.

22:37Travis kan.

22:39Oh kalau Travis pernah pakai.

22:42Travis CI sendiri, Jenkins sendiri, Jenkinsnya open source.

22:47Itu satu project kan, satu instansi kan.

22:50Enggak.

22:52Iya kayaknya.

22:54Jenkins itu?

22:56Travis itu service nya dia, yang bisa dipakai kalau aplikasi kita open source.

23:04Kalau nggak open source kan harus bayar.

23:06Kalau bayar, Travis.

23:09Oh iya bener, Travis commercial tool, whereas Jenkins is open source.

23:16Bener kan?

23:17Iya, iya, iya.

23:19Ini kita ngomongin PHP loh, Irfan ngomongin PHP loh, kok nggak bisa relate?

23:23Oh mungkin ini kali lean stage husky kali ya.

23:26Kalau di PHP ada dong, masa nggak ada?

23:28Kalau di PHP pakai PHP course sniffer sama PHP.

23:34Terus 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.

23:50Jadi PHP stand, pakai PHP stand.

23:56Itu 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.

24:17Kalau pakai stand, ya static analysis. Jadi udah di otomatis sasi juga stand. Terus terakhir adalah human review, which is peer review manusia.

24:38Nah beberapa, Mas Riza bisa buka apa aja sih yang kita review itu sebenarnya?

24:45Oh yang tadi yang ini ya?

24:47Ada listnya ya, ada how to do code review, ini kan?

24:51Oh bagus ya ada guidelinenya.

24:55Jadi ada beberapa signal yang kita suka review, saya suka review kan kita.

25:07Jadi 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.

25:25Sedangkan yang saya tangkap itu adalah design overall, jadi saya lihat secara keseluruhan.

25:32Ini ticketnya ngapain, terus PR nya ngapain, gitu. Solusinya bagaimana dia buat.

25:45Saya paling big no itu kalau misalnya PR nya dicampur-campur, misalnya fiturnya A.

25:56Komitnya sekaligus gitu ya? Komitnya sekaligus, bukan komit, PR nya.

26:04PR nya satu tetapi isinya itu urusannya modul A, modul B, modul C, atau perbaiki modul A, perbaiki modul B.

26:17Biasanya kalau satu orang nguruhin ticket banyak, pengen cepet selesai semua, terus males pindah-pindah brand.

26:26Itu paling big no, karena susah. Jadi gini, saya ngasih taunya dari sisi maintainer, kayak kalau maintain sebuah project yang sudah bertahun-tahun.

26:39Kalau sudah ada masalah itu nge-tracing nya itu setengah hidup, karena tracing nya, kemana ini kodenya masalah dan sampai di tracing itu,

26:49change lock segala macam sampai ke belakang, sampai ketemu itu dimana letaknya, kenapa itu bisa terjadi.

26:57Karena harus cari route analysis kan. Kalau PR nya dicampur-campur, aduh susahnya minta ampun untuk mencari itu.

27:07Sebagai best practice kita itu kalau bisa PR itu contoh, jangan campur-campur antara kombo, misalnya gini ya, NPM update sama logic update.

27:22Soalnya 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.

27:48Jadi ada list nya, jadi change list itu pun lengkap di PR. Itu satu PR. Nah, terus banyak yang tanya, pernah ada juga kayak kasus.

28:00Kalau 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.

28:18Let'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.

28:42Udah, jadi berangkatnya dari kecil-kecil dibangun kecil-kecil, jadi lebih mudah bagi yang ngereview untuk membacanya.

28:52Kemana 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.

29:17Jadi 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.

29:46Jadi 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.

29:59Jadi 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.

30:13Jadi sebisa mungkin satu tempat gitu. Satu lokasi gitu. Jangan campur-campur.

30:24Ini 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?

30:48Benar-benar. Itu mah percaya bro. Udah percaya. Udah gue percaya lu. Jalan ya, awas kalau gue jalan.

30:54Terdapat berdasarkan kecayaan gitu.

30:56Iya. Jadi nggak bisa di review juga, jadi nggak ada yang bisa ditarik pelajaran gitu.

31:04Kalau 100 baris pun udah cukup besar sebenarnya ya. Tapi masih bisa lah ya 100 ya.

31:12Eh, 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.

31:26Ya, 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.

31:42Berarti itu nggak masuk. Itu belum bisa dibilang nerapin code review ya?

31:48Nggak 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.

32:09Orang lain bisa baca, orang lain bisa maintain karena nggak selamanya kita hidup. Atau karena kita di, nggak selamanya.

32:18Di perusahaan itu.

32:20Di perusahaan itu.

32:22Itu faktor loh, nggak selamanya juga kita hidup kan.

32:25Oh iya, kan ada istilah yang...

32:28Besok kurik.

32:30Iya, kalau amit-amit besok kita ketabrak bus, terus kita nggak bisa kerja gimana rekan kita gitu kan.

32:38Ya atau yang happy lah, yang happy, holiday faktor. Tiba-tiba kita menang, kita liburan ke Las Vegas.

32:45Bye bye, kita nggak bisa dikontakan lagi naik pesawat. Naik pesawat berapa bulan saja.

32:49Betul.

32:51Apakah organisasi kita bakal codebase-nya langsung jatuh karena pada nggak bisa...

32:58Ini 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.

33:09Supaya kita tidak tergantikan.

33:12Kalau kode kita nggak terlalu bagus, ya kan? Orang-orang mengerti, jadi...

33:18Kitanya ada pecat.

33:21Kita 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.

33:34Malah kebalikan sebenarnya.

33:36Ya kalau masalah job security, apalagi di winter seperti sekarang, ya memang ada.

33:41Tapi kan bukan...

33:44Ya, justru kalau kita nulis kode-nya ngaco, sulit dibaca, malah dilihat dulu.

33:51Review-nya malah jelek kan, gitu.

33:53Kalau dulu saya lebih, lebih apa lagi namanya, kayak reviewzilla lagi kalau sampai commit message pun juga saya pertimbangkan.

34:05Itu ada salah satu contohnya bagaimana menuliskan commit message yang baik, ada saya kasih link-nya.

34:14Tapi sebelum itu ini, tadi pagi ngelihat, ngelihat memes ini, siapa yang relate, gitu.

34:2230 menit mikirin, commit message apa gitu yang perlu ditulis ya, yang cocok.

34:30Sudah bisa dibantu, sudah bisa dibantu sama co-pilot.

34:33Eee, CTVT dan lain-lain ya.

34:35Iya.

34:38Makanya supaya yang tadi commit message yang bisa membantu kalian coba ya.

34:44Yang mana? Yang ini ya?

34:47Iya.

34:49Langsung temen-temen baca aja, tapi saya bagian skip yang paling penting, agak bawah sedikit.

34:56Karena ada kayak 50 karakter, blablabla itu sudah diatur sana, VS code sudah gampang.

35:06Seven rule of commit message.

35:08Subject and from body and with blend line.

35:12Limit the subject, 50 karakter.

35:15Capitalize subject line, do not end the subject line with a period.

35:19Use imperative mood.

35:21Itu, klik itu imperative.

35:24Nggak boleh pakai deklaratif ya.

35:30Nggak boleh pakai deklaratif ya.

35:36Do not end the subject line, do not end the subject line with a period.

35:37Do not end the subject line, do not end the subject line with a period.

35:39Do not end the subject line, do not end the subject line with a period.

35:41Do not end the subject line, do not end the subject line with a period.

35:43Do not end the subject line, do not end the subject line with a period.

35:45Do not end the subject line, do not end the subject line with a period.

35:47Do not end the subject line, do not end the subject line with a period.

35:49Do not end the subject line, do not end the subject line with a period.

35:51Do not end the subject line, do not end the subject line with a period.

35:53Do not end the subject line, do not end the subject line with a period.

35:56Do not end the subject line, do not end the subject line with a period.

36:01Do not end the subject line, do not end the subject line with a period.

36:03Do not end the subject line, do not end the subject line with a period.

36:05Do not end the subject line, do not end the subject line with a period.

36:07Do not end the subject line, do not end the subject line with a period.

36:09Do not end the subject line, do not end the subject line with a period.

36:11Do not end the subject line, do not end the subject line with a period.

36:13Do not end the subject line, do not end the subject line with a period.

36:15Do not end the subject line, do not end the subject line with a period.

36:17Do not end the subject line, do not end the subject line with a period.

36:19Do not end the subject line, do not end the subject line with a period.

36:22Do not end the subject line, do not end the subject line with a period.

36:27Do not end the subject line, do not end the subject line with a period.

36:29Do not end the subject line, do not end the subject line with a period.

36:31Do not end the subject line, do not end the subject line with a period.

36:33Do not end the subject line, do not end the subject line with a period.

36:35Do not end the subject line, do not end the subject line with a period.

36:37Do not end the subject line, do not end the subject line with a period.

36:39Do not end the subject line, do not end the subject line with a period.

36:41Do not end the subject line, do not end the subject line with a period.

36:43Do not end the subject line, do not end the subject line with a period.

36:45Do not end the subject line, do not end the subject line with a period.

36:48Do not end the subject line, do not end the subject line with a period.

36:52Do not end the subject line, do not end the subject line with a period.

36:54Do not end the subject line, do not end the subject line with a period.

36:56Do not end the subject line, do not end the subject line with a period.

36:58Do not end the subject line, do not end the subject line with a period.

37:00Do not end the subject line, do not end the subject line with a period.

37:02Do not end the subject line, do not end the subject line with a period.

37:04Do not end the subject line, do not end the subject line with a period.

37:06Do not end the subject line, do not end the subject line with a period.

37:08Do not end the subject line, do not end the subject line with a period.

37:10Do not end the subject line, do not end the subject line with a period.

37:13Do not end the subject line, do not end the subject line with a period.

37:18Do not end the subject line, do not end the subject line with a period.

37:20Do not end the subject line, do not end the subject line with a period.

37:22Do not end the subject line, do not end the subject line with a period.

37:24Do not end the subject line, do not end the subject line with a period.

37:26Do not end the subject line, do not end the subject line with a period.

37:28Do not end the subject line, do not end the subject line with a period.

37:30Do not end the subject line, do not end the subject line with a period.

37:32Do not end the subject line, do not end the subject line with a period.

37:34Do not end the subject line, do not end the subject line with a period.

37:36Do not end the subject line, do not end the subject line with a period.

37:39Kalau misalnya kalian yang inklu file nya tapi lupa add file nya itu kan fatal error.

37:45Kalau di commit itu.

37:47Ya kan kalau di revert ke commit itu.

37:49Ya.

37:50Kalau file nya belum ada itu bisa misalnya commit itu akan menghasilkan fatal error.

37:56Nah jangan sampai commit itu bisa menghasilkan fatal error.

38:00Pikirkan bagaimana supaya commit itu satu satuan.

38:07Kalau memang mau add file nya plus kalian include ya boleh.

38:10Langsung tep gitu.

38:12Jadi ke mana pun misalnya kita revert commit nya ke commit tertentu.

38:22Tetap akan program kita jalan-jalan saja.

38:26Itu dari sisi design.

38:30Oh itu baru yang ini ya baru yang design nya.

38:35Desain grand design nya.

38:38Jadi dari solusinya strukturnya, ngedesign file nya dimana, solusinya alurnya itu satu hal.

38:53Jadi dipahami sebagai review.

38:56Sebelum saya lanjut.

38:58Buka lagi tadi lanjutannya design apa?

39:01Functionality.

39:04Tapi sebelum lanjut ini ada pertanyaan yang bagus yang mau saya highlight.

39:10Kalau di perusahaan konsultan biasanya nggak penting untuk unit test, nggak penting code quality dan lain-lain.

39:19Ivan Humanmade bukannya konsultan ya?

39:23Konsultan teknologi.

39:27Iya ini bukan jangan menjenderalisasi semua konsultan seperti ini ya. Ini adalah konsultan yang belum menerapkan best practice.

39:37Saya mikir-mikir kata-katanya terlalu kasar.

39:40Lebih ke price range kali ya. Maksudnya kita realistis ya.

39:43Ini kan code review kan satu, butuh tenaga, butuh SDM ya.

39:50Maksudnya SDM ya kualitasnya harus relatif tinggi atau minimal willing to upskill. Maksudnya mau mempelajari, mau ngulik hal-hal yang semua tadi Ivan jelasin tuh.

40:00Itu kan satu SDM nya harus begitu dari segi resource.

40:04Nah terus resource lainnya yang jelas finance kan, ini kan makan dev hour ya, makan main hour.

40:10Menghabiskan waktu sekian jam yang kalau misalnya tanpa code review kan dev nya bisa langsung disuruh, udah langsung aja bikin fitur baru lagi.

40:18Nah ini nggak sekian jam dihabiskan buat code review.

40:21Nah berarti kan biaya yang dibebankan ke customer bakal lebih tinggi.

40:26Cuma kan hasilnya juga, ya pasti hasilnya juga beda jadi lebih ke kelas price range ya kali.

40:35Iya betul. Kadang-kadang juga ada faktor lainnya juga, banyak ya banyak faktor ya.

40:41Ada konsultan ini mereka lebih memilih yang penting diselesai.

40:47Mungkin sesuai deadline, tapi tidak memikirkan kalau seandainya si kliennya balik lagi ke klien gitu.

40:55Seringnya kan dapat proyek ya, proyek limpahan kan.

41:00Ini dari konsultan yang lain, oh ini codenya ancur banget kita bikin lagi dari awal gitu kan.

41:06Karena nggak ada apa ya, nggak ada benefit kalau kita melakukan best practice disana.

41:13Karena tuh juga begitu udah selesai kontraknya mereka cari yang lain gitu, nggak balik lagi ke kita.

41:17Jadinya ya hal-hal yang kita butuhkan itu tidak penting gitu.

41:23Mostly karena klien yang di handle itu kan enterprise ya, jadi paper roomnya juga banyak.

41:28Bahkan di awal project aja mereka sudah minta misalnya test coverage nya 100%.

41:36Accessibility nya aja sudah minta level AA.

41:44Jadi waktu udah, apa namanya, sebelum misalnya post production cun.

41:54Maksudnya post deployment juga kita harus masih cek nggak ada degradation yang terjadi.

41:59Post production test ini nggak ada. Itu beda lagi, karena permintaan project.

42:05Itu depends ya, jadi kalau klien yang skala enterprise rata-rata memang minta banyak paper work nya.

42:21Dan mereka tech savvy ya, berarti relatif walaupun mereka nggak ngerti codenya.

42:27Tapi mereka punya ekspektasi, mereka tahu konsep test coverage.

42:32Mereka punya standar accessibility, ya mungkin kalau di luar, mereka bisa dituntut ya kalau kurang accessible.

42:39Jadi konsultan in house ya, eh punya staff in house.

42:44Mereka punya staff IT in house, jadi mereka tahu gitu.

42:48Dan mereka yang ikut membuat best pack ke sini.

42:53Jadi kita meskipun di hire untuk handle project, tetapi timnya itu bukan cuma kita doang, di project itu.

43:02Mereka juga punya tim yang lain, yang agency lain, yang bekerja di satu project yang sama.

43:08Jadi kalau misalnya nggak ada standar ini, nggak ada standar coverage seperti ini ya, codenya kita ya campur aduk berantakan segala macem.

43:21Nah itu kan jadinya kalau sudah berantakan, ngebenerin yang berantakan itu lebih mahal daripada dari awal sudah dibenerin.

43:32Des praktisnya.

43:33Apalagi kalau enterprise, maksudnya ada risiko mereka dituntut lah atau apalah maksudnya kena masalah hukum dan lain-lain.

43:42Nah kemudian pertanyaan dari Rafki lagi, kalau perusahaannya belum pakai version control, belum pakai collaboration tools.

43:52Ya mau nggak mau harus peer review ya, bareng-bareng duduk bareng-bareng ya.

43:57Jadi sebelum di lempar ke FTP ya bareng-bareng gitu, ya solusi yang paling mendekati lah ya.

44:03Oh tadi pas lagi research word ini, gue jadi baca-baca sejarahnya dan ternyata apa konsep code review yang kayak kita pahamiin sekarang nih,

44:13ternyata di-initiate-nya di IBM tahun 1976 dan maksudnya sebelum ada sistem-system kayak sekarang, mereka tuh ngeprint beneran.

44:25Apa lah, nggak ngerti deploy-nya gimana nih ya, tapi kalaunya si developer-nya si programmer-nya ngeprint fisik, ngeprint kertas yang dia bukun.

44:36Jadi beneran kayak dituntutin, dibaca, diprint, difotokopi, baca ya kayak misalnya kalau ada komentar, di-highlight.

44:44Kayak skripsi ya, jadi ingat masa lalu.

44:47Tapi sampai sekarang peer review juga masih terjadi.

44:54Peer review? Di jurnal ilmiah?

44:56Iya.

44:58Peer review di-print kan?

45:00Oh di-print ya.

45:02Peer review misalnya kalau jurnal ilmiah ya, istri waktu ngambil program specialis maling itu misalnya dia bikin jurnal ilmiah ya,

45:17peer review ke dosen dan segala macemnya itu handwritten semua. Masih, masih peer review.

45:26Sama aja code review, peer review ya sama.

45:29Code review ya peer review.

45:31Sama, sama, sama.

45:33Nah, dari sisi functionality, terus apa lagi tadi, code style.

45:38Oh iya, kita lanjut lagi ya, lanjut lagi ya.

45:41Functionality, functionality udah pasti kan, codenya sesuai nggak?

45:45Ini biasanya ada kaitannya sama testing ya?

45:48Testingnya bener-bener juga kan?

45:50Testingnya di-review kan?

45:52Spesifikasinya juga kan?

45:54Tests casenya di-review kan?

45:56Yes, yes, testsnya di-review.

45:58Testsnya tuh ini, jangan hanya membuat tests case itu hanya untuk test coverage doang.

46:11Ya, coveragenya 100% yang penting gitu.

46:15Gak boleh, gak boleh.

46:16Gak bisa, jadi harus testnya bener nggak gitu.

46:20Maksudnya secara logicnya yang mau di-test itu sesuai nggak?

46:25Jangan cuman di-test happy part-nya aja.

46:28Di-test yang error part-nya juga harus di-test.

46:32Yang paling saya lihat adalah complexity.

46:37Kalau sampai saya nggak mengerti codenya,

46:40something is wrong.

46:43Ini maksudnya apa sih kok muter-muter gitu.

46:46Terus abstraksinya kok banyak amat gitu.

46:49Saya paling bingung kalau misalnya udah abstraksinya sampai kayak 3-4 level.

46:54Ngapain gitu?

46:56Apa bisa disimplerkan, apa bisa dipermudah gitu alurnya gitu.

47:05Terus komen.

47:11Gak perlu, saya nggak terlalu, ini pendapat pribadi ya.

47:20Bukan fans untuk yang nulis komen sebanyak-banyak, seabrak-abrak.

47:25Jadi setiap lainannya ada komen, nggak perlu.

47:29Jadi cukup komen itu diberikan di tempat yang misalnya memang ada satu specific case kenapa itu terjadi dan kenapa itu di situ.

47:43Contohnya, mungkin ada edge cases atau bug yang terjadi dan belum sempat diperbaiki.

47:54Dan harus men-short circuit, men-short circuit terjadi itu supaya bug itu nggak terjadi, tetapi belum sempat dibenerin.

48:05Kasihlah komen di situ.

48:07Jadi yang nge-maintain, oh tahu, oh iya itu kenapa di situ, tahu.

48:11Jadi nggak perlu, ini tiba-tiba codenya aneh sendiri di sini, ini ngapain?

48:17Dikasih fix me, fix me, tapi nggak pernah dilihat lagi.

48:22Iya, tuduh-tuduh akhirnya kalau dibuka tuduh ini, semua tuduh, tuduh ini apaan gitu.

48:31Oke, itu kompleksiti ya?

48:40Iya kompleksiti.

48:43Oh, pernah dulu ada rekan kerja walaupun nggak satu tim di kantor pertama.

48:50Dia sering pake fitur komentar di kodenya, yang komentar isinya puisi.

48:56Dia mengespresikan puisi.

48:59Setiap kode yang dia buat itu ada puisi di atasnya.

49:04Oh itu keren sih.

49:07Tapi tidak pada tempatnya, mendingan tarah di Google Docs pribadi aja.

49:13Jangan di kode, kan dibaca orang.

49:16Kalau lagi galau kan ketauan.

49:20Oh, cuma puisinya nggak ada dibuka sama kodenya, kirain kayak pantun gitu.

49:24Nggak ada, kalau pantun mungkin kita ketauan.

49:27Ke pasar beli manggis, ini penambah apa yang belakangnya is.

49:32Oh, bagus juga tuh buat commit message, kalau nggak tau pakai apa, empat baris sendiri udah pantun kan.

49:40Itu kalau jerjit dari upin dan ipin jadi programmer mungkin, kayak gitu, sudah besar.

49:51Nah, selanjutnya nih, naming nih.

49:54Naming.

49:56Ini bisa jadi seluruh episode sendiri ini kayaknya.

50:00Naming ini salah satu yang susah-susah gampang.

50:08To do fix me nggak boleh, di PR nggak boleh ada kan.

50:12Konsolok, print dan lain-lain juga nggak boleh kan.

50:17Itu tergantung projectnya.

50:20Kalau konsolok tergantung kalau misalnya memang itu di server dan memang halus di lock sesuatu yang mau dilihat, silahkan.

50:28Di client juga kadang-kadang ada, kalau teman-teman buka salah satu website misalkan, terus dilihat di inspect elemen tiba-tiba ada.

50:35Kadang malah career.

50:37Tergantung ya.

50:43Nah, balik lagi ke naming.

50:48Sebisa mungkin kasih nama, function, class, variable, itu yang bermakna aja.

50:54Nggak usah terlalu yang panjang-panjang A, this variable is for whatever reason, blablabla.

51:03Nggak usah juga, tapi misalnya kasih nama berbeda.

51:07Itu kan kadang, itu gejala, kayak gejala dari satu metode yang melakukan terlalu banyak hal, fetch data, update, blablabla.

51:17Nah, itu berarti kan.

51:19Berarti udah kebanyakan.

51:21Udah kebanyakan.

51:23Udah kebanyakan.

51:26Karena kan, balik lagi ke clean code kan, apa namanya, prinsipnya clean code kan misalkan, contoh aja nih ya, satu fungsi hanya melakukan satu hal.

51:36Kalau misalkan fungsinya udah melakukan misalkan login and change flag into true, active sama dengan true.

51:47Nah itu kan udah dua hal, jadi harus dipisah fungsinya gitu.

51:52Login and check and report suspicious user.

51:56Ya, ya gitu lah.

51:59Jadi sebisa mungkin, apa, nama itu biasanya menggambarkan kompositas, betul.

52:06Sama satu lagi, disini nggak ada, tetapi konsistensi.

52:12Saya, saya tipe orang yang bisa mengikuti, meskipun kita satu perusahaan, kadang satu projek dengan projek lain bisa mengandung opinion yang berbeda.

52:29Ya, opinion yang berbeda.

52:32Yang set up duluan itu engineer yang lain dan punya opinion berbeda, meskipun nanti kesamaannya ada, karakternya ada, tetapi ada hal yang berbeda.

52:44Contohnya spasi sebelum, contohnya penggunaan spasi, saya nggak masalah kalau memang itu sudah jadi cost style dan dipakai.

53:05Masalah yang saya permasalahkan adalah, dua hal yang sama itu tapi tidak konsisten, itu yang saya tangkap.

53:22Ya kalau bisa dibikin konsisten aja, contohnya dia suka pakai early return, tapi di satu tempat yang nggak pakai early return, kenapa?

53:30Satu early return, tapi di bawah, terus di dalam satu block, dia nggak pakai early return, kenapa?

53:45Kalau memang mau pakai early return, early return kan semua konsisten dengan code changes-nya.

53:54Makanya 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.

54:06Atau kadang copy dari code yang lain dia roba sedikit dan kesalahan di code lain dia bawa yang sama.

54:12Nanti dia komen, ini kan gue copy dari tempat lain ya, kalau memang yang tempat lain salah, dulu copy ya salah juga.

54:20Salah tambah salah bukan jadi benar, salah dan salah itu salah.

54:25Makin salah, makin salah.

54:28Saat apa di Liverpool?

54:31Iya.

54:33Masih ya.

54:35Jadi konsistensi, konsistensi.

54:38Konsistensi.

54:40Oke.

54:42Konsistensi itu bagian dari style guide ya, berarti tadi kan.

54:45Tapi untungnya beberapa hal.

54:49Yang mana gimana?

54:50Lanjut, lanjut.

54:52Gimana tadi Eka?

54:54Dari style guide.

54:56Itu kan bawahnya komen ada style tuh.

54:58Berarti kan itu kan hal yang harusnya ada di style guide dong, yang kayak tadi yang kayak di return lah, atau apalah penamaan, atau casing.

55:09Nah itu kan ada comment di bawahnya komen tuh.

55:12Ada yang unwritten rule, ada yang unwritten rule.

55:16Maksudnya 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.

55:32Jadi gitu ada gitu, saya tahu gitu.

55:35Nah itu akhirnya yang dia copy sana, copy sini, dia oba-oba sedikit itu, kerasa itu bedanya.

55:44Style nya bukan style nya, ya inconsistensinya.

55:46Ya inconsistensinya kerasa gitu.

55:48Jadi, 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.

56:06Itu 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.

56:17Copy 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.

56:24Tapi 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.

56:35Berarti ada yang salah dengan fundamental nya dia kan.

56:37Eh ya, itu namanya etos kerja kali ya.

56:44Atau mungkin karena udah deadline jadi berhubung dan seterusnya dan seterusnya.

56:49Ya itu malah bikin tambah repot nanti kalau harus ngetumin.

56:54Itulah yang ditangkap di code review, sebisa mungkin hal-hal yang misalnya tadi kayak contohnya, contohnya saya sakit nih misalnya.

57:08Tetapi 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.

57:28Saya secepat mungkin testing, lihat oke eh udah puster, ternyata waktu di code review ini nya salah, tidak salah sih apa, feedback nya banyak.

57:43Ya 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.

58:00Meskipun 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.

58:13Mudah mereka perbaiki aja, tinggal lanjutin code nya saya. Gak ada masalah gitu. Mereka cuma tinggal perlindungi satu atau dua commit, udah selesai gitu.

58:22Jadi tulis, maksudnya tulis lah code yang sebisa mungkin gampang diterusin orang lain. Dan supaya gampang diterusin orang lain, gampang dibaca orang lain.

58:36Gampang dimengerti orang lain. Setuju banget ini. Ini balik lagi tadi empati. Video nya hilang.

58:44Mas Riza lagi berempati.

58:49Iya 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.

59:11Gak 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.

59:26Tapi code yang kita tulis itu sebisa mungkin dipahami oleh manusia.

59:31Dan 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?

59:44Ya 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.

1:00:02Kalau 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.

1:00:11Betul, betul. Dan itu kultur itu juga salah satu indikator kita pantas untuk masuk ke perusahaan itu atau enggak.

1:00:20Karena 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.

1:00:30Ya udahlah kalau gitu tulisin puisi aja.

1:00:36Nah itu kan jadi malah, ya itu tadi jadi lingkaran setan tadi kan akhirnya yang tadinya kita berusaha untuk memperbaiki.

1:00:44Tapi 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.

1:00:57Akhirnya ya jadi terpaksa kita ngikut, ngapain kita capek-capek nulis hal yang bagus gitu, yang lain gak peduli gitu kan.

1:01:04Kita 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.

1:01:20Makanya sebisa mungkin review yang kita tulis itu hanya menargetkan codenya, bukan orangnya. Kedua saat kita berikan feedback itu feedback yang konstruktif dan berdasarkan fakta.

1:01:42Contohnya 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.

1:02:02Kita 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.

1:02:24Tapi 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.

1:02:41Jadi 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.

1:03:04Tapi 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...

1:03:27Maksudnya ada yang benar-benar atomic function gitu. Satu fungsi yang cukup satu gitu. Sama satu lagi, code review itu bukan side job.

1:03:42Bukan 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.

1:04:00Percuma! Akhirnya cuma antara kalian approve aja atau reject. Code review itu pekerjaan utama.

1:04:15Itu 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?

1:04:31Ya. 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.

1:04:47Kalau 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.

1:05:07Nah, 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.

1:05:25Gitu. 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.

1:05:46Nah, dan bukan beban ya. Bukan sesuatu yang membahannya. Kita tetap kode kita harus nge-coding 8 jam ditambah code review. Gak kan?

1:05:56Nah enggak, itu kan masuk 8 jamnya itu. Kalo emang...

1:05:58Masuk 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.

1:06:10Bukan amal.

1:06:12Amal.

1:06:15Tadi 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.

1:06:29Itu cukup membantu untuk styling supaya konsisten kan.

1:06:35Ya 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.

1:06:46Jadi 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.

1:06:58Nah sekarang pertanyaan saya adalah, siapa yang masih pakai komen? Kayaknya sekarang gak trend lagi ya semenjak ada chat GPT dan co-pilot ya.

1:07:05Jadi pakai komen-komen-komen gitu. Kalau dulu kan kayak...

1:07:08Ya kan abis itu bisa dihilangin.

1:07:10Oh iya.

1:07:12Gak 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.

1:07:23Kalau butuh komentar artinya itu rumit, kompleks, lebih kompleks.

1:07:28Kalau klik yang "how to do code review" ini itu kan ada tuh.

1:07:31Kila dokumentasi code review aja lengkap banget ya.

1:07:40Iya.

1:07:42Sorry yang di looking for, what to look for in code review.

1:07:47What to look for in code review.

1:07:51Oh ini penjelasan dari setiap step nya ya.

1:07:53Turun, turun, turun, turun.

1:07:55Yup tuh.

1:07:57Usually comments are useful when they explain why some code exists.

1:08:03Bukan what ya.

1:08:05Yang kayak gue bilang tadi kenapa kode itu disitu secara spesifik, tiba-tiba dia nongol disitu, kenapa gitu.

1:08:14Karena kita punya konteks, jadi kita ngasih komen itu supaya yang lain atau ngebaca itu gak ngabisin waktu, bongkar-bongkar lagi.

1:08:33Jadi, if the code isn't clear enough to explain, then the code should make simpler.

1:08:41Iya.

1:08:44Tentang kodenya ya.

1:08:45Bukan what is the code for, tapi why.

1:08:50Tapi itu yang spesifik ya, yang kayak yang spesifik-spesifik komen, spesifik case biasanya.

1:09:03Yes. Ini kayaknya dari komentar-komentar temen-temen disini kayaknya banyak sekali yang mengalami bad experience ya dengan perusahaan.

1:09:14Teknisnya 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?

1:09:29Dunia yang berbeda, betul-betul.

1:09:31Kayak jauh banget.

1:09:34Iya. Konsultan itu identik dengan deadline dan deadline yang ketat dan lembur dan lain-lain ya kalau di Indonesia ya. Kalau di luar, setidaknya sama.

1:09:45Ya deadline lah di mana-mana.

1:09:48Kerjaan 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.

1:10:09Jadi bukan maksudnya ada deadline atau gak ada deadline, lebih ke prosesnya, bagaimana proses mencapai kesanannya.

1:10:24Mungkin 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.

1:10:40Karena 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.

1:11:08Nah ini ada pertanyaan bagus juga, clean code versus performance, mana yang harus didahulukan?

1:11:19Biasanya 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.

1:11:47Betul, betul. Jadi saya bilang itu bukan versus tapi berbanding lurus. Iya berbanding lurus. Iya. Jadi dua-duanya harus didahulukan.

1:12:00Dan 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?

1:12:19Ada onboarding pasti di setiap perusahaan.

1:12:23Itu 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.

1:12:34Jangan-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.

1:12:45Ya 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.

1:13:01Yang udah senior, yang udah punya otoritas di kantornya, tolong dong jangan sampai hal itu kejadian sama teman-teman yang junior gitu ya.

1:13:10Jangan bantu junior-nya untuk memecah lingkaran setan menjadi lingkaran yang lebih baik gitu. Jangan malah mengikuti.

1:13:18Dan balik lagi ya, kultur onboarding itu biasanya ada di perusahaan-perusahaan tertentu gak di semua. Nah ini ada best practice-nya gak?

1:13:32Buat milih perusahaan yang sudah menerapkan practice-practice yang kita omongin tadi.

1:13:44Kecuali 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.

1:14:04Maksudnya 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.

1:14:16Kalau 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.

1:14:31Salah 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.

1:14:46Entah 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.

1:15:06- 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.

1:15:18- Gak ada cara lain sih. - Biasanya HR kan kalau saat interview kan pasti diujun ada yang mau ditanya. - Ada pertanyaan gak?

1:15:28- Itu listnya, on-boardingnya gimana, code review. - Kalau sama SR mungkin agak sedikit berbeda ya, tapi mungkin sama...

1:15:36Kalau lowest biasanya kan hapus selanjutnya pasti sama someone dari team engineeringnya.

1:15:44Kalian tanya aja, bagaimana proses code review, bagaimana code styling kalian, best practicesnya ada dimana, bisa saya baca gak, tanyain semua tuh.

1:15:55- Dan jawab, itu apa ya? - Reflect.

1:16:02Kalau cara meyakinkan team product, ya harus di edukasi sih. Sama kayak cara meyakinkan klien, klien dari konsultan tadi.

1:16:15Di 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...

1:16:25Bugs-nya minimal sehingga delivery-nya in total sama aja sebenarnya, cuma prosesnya mungkin agak lambat di awal gitu kan.

1:16:31Itu harus di edukasi sih, kultur lagi, balik lagi ke kultur.

1:16:36Kita mesti pinter ngerjemahin ke value ekonomi, kayak misalnya kalau ada bug, tapi mungkin kita harus ngumpulin data ya, ngeresepnya gimana.

1:16:46Jadi 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.

1:16:58Bener-nya fixing bug itu butuh main hour, dev hour itu sekian jam. Sedangkan kalau misalnya 3 jam total.

1:17:07Ada risiko ketidakpastian dan downtime-nya jadi lama kalau ada isunya di jam yang gak ada yang on call atau apalah.

1:17:16Ya agap aja 3 jam dan ini ada dampak negatif. Tapi kalau kita code review, itu cuma 2 jam.

1:17:26Kita harus bisa membahasakan itu dengan konkret ya, kalau mau meyakinkan ke apa? Organisasi.

1:17:33Tapi lagi-lagi ini hipotesa, gue juga belum pernah nyoba kayak gini sih.

1:17:38Tapi kan itu satu-satunya bahasa yang mereka akan paham kan, maksudnya jadi bukan cuma karena pengen-pengenannya engineer atau karena trend.

1:17:50Ya jadi ini bukan perkara selera, tapi emang ini praktek yang menguntungkan organisasi. Kita harus bisa membawa angka sih.

1:17:58Membawa angka, betul-betul. Apalagi sama tim bisnis ya.

1:18:03Yang ini juga apa namanya, ini kasus yang lain. Contohnya anggap aja si company itu menghayat agensi.

1:18:18Jadi company itu juga punya tim IT-nya atau tim programmernya yang dimasukin ke projek yang sama.

1:18:26Jadi sebenarnya emang kayak transfer knowledge. Transfer knowledge.

1:18:31Jadi value editnya kita sebagai agensi, kita saling code review.

1:18:38Jadi kita code review kodenya mereka supaya kita pastiin kodenya mereka sesuai dengan standard kita.

1:18:44Bagi si company, timnya mereka juga grow karena dari teknologi yang mereka belum bisa, dapat teknologi dari agensi dari third party.

1:19:01Sehingga 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.

1:19:18Jadi sebenarnya sama-sama grow. Itu juga bisa.

1:19:26Nah 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.

1:19:36Nah itu kan berarti ada kayak value ekonomi lah finansial yang konkret. Jadi UUD, ujung-ujungnya duit semua.

1:19:47Sudah pasti itu. Oke ini pertanyaannya seru-seru ya ternyata ya. Ini ada pertanyaan yang menurut saya menarik tapi masih ada hubungannya ya.

1:20:01Satu 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.

1:20:20Jadi ada artikel yang cukup viral dari Pak Vincent ini. Dulu dia yang menggagas gitflow tapi ada note-nya.

1:20:33Tapi di 2020 setelah 10 tahun artikel dia beredar, dia menyatakan bahwa ini bukan untuk semua, bukan best practice lah, bukan best practice lagi.

1:20:51Jadi 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.

1:21:08Trunkbase 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.

1:21:24Itu 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.

1:21:41Ya 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.

1:21:54Kalau misalkan apaan sih? Belum gabung aja, udah nanya-nanya, nah berarti itu.

1:21:58Kayaknya 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.

1:22:11Atau kalau emang mereka nggak pengen ngejawab kan ya itu. Kalau chat kan tinggal diignore aja ya.

1:22:16Iya kalau chat tinggal diignore. Kayaknya nggak mungkin di marah-marahin.

1:22:22Dimarahin sih nggak mungkin. Cuman maksudnya kayak tadi kan nggak boleh ngomong. Kalau nggak boleh kan tinggal ngeles aja.

1:22:30Iya kalau chat nggak boleh berarti perusahaannya agak tertutup, nggak open gitu kan. Maksudnya secara kulturnya. Jadi kita bisa nilai juga gitu.

1:22:47Yang terakhir itu boleh minta link-nya. Oke, link yang ini ya. - Tadi yang Trunk-based.

1:22:53Ini yang Gitflow, yang ini Trunk-based. Siap.

1:23:00Oke, tentang code review. Ada lagi yang mau dibahas? - Ini ada coba dibuka yang chat GPP yang di Google Docs.

1:23:12Oh iya, iya. Udah dibuka, udah dibuka. Ini kan on-demand review. - Yang on-demand code review.

1:23:17Tadi kayaknya ada yang komen chat GPP juga. - Bahu, Bahu.

1:23:21Bahu tadi nge-check bahwa bisa jaman sekarang bisa direview oleh AI.

1:23:28Dan ini bukan bahas yang tadi ya. Bukan yang apa kayak linting, formatting, bukan apa CI pipeline yang itu.

1:23:38Cuma beneran literally please review my code. Ini lucu sih.

1:23:42Ya gue belum pernah lihat orang yang beneran kayak gini. Cuma baru lihat di artikel ini.

1:23:47Tapi maksudnya dengan adanya large language model kan LLM emang jadi bisa kayak gini.

1:23:52Cuma pertanyaannya, ini cuma lucu-lucu artikel seru-seruan doang. Cuma what if, cuma ide doang.

1:24:00Atau apakah ini beneran visible gitu. Soalnya si AI ini kan apakah berarti AI mempelajari seluruh code base di organisasi itu atau gimana ya itu?

1:24:11Gak tahu ya. Ini gimana ya. Saya belum pernah sih nyobain tanyain GPT atau LLM.

1:24:22Sekarang misalnya ada nggak cowo gitu kalau yang di screenshot ini. Coba deh lihat, scroll ke...

1:24:30Saya sudah coba pakai yang Copilot. Kalau misalnya Copilot itu untuk mengerti seluruh code base, gak bisa.

1:24:35Tetapi kalau untuk mengerti satu function itu bagus kok.

1:24:41Ini tab bot di Github kan. Pakai GPD. Pakai OpenAI punya gitu ya.

1:24:52GPD 3.35. Terus bisa pakai text Da Vinci. Da Vinci itu modelnya siapa ya?

1:25:01Modelnya OpenAI. Udah gak ada. Deprecated. Sekarang yang 3.5. Yang terlama.

1:25:11Jadi 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.

1:25:26Terus bikin promptingnya. Terus request ke API, OpenAI API. Terus dapet review suggestion-nya dikirim balik ke Github.

1:25:38Ini maksudnya seru secara konsep. Ini lo malah diseru tuh, nomor satu, add more comments.

1:25:51Ini mungkin bisa dibaca sebagai, saya gak ngerti kode kamu, tolong bikinin comment biar saya ngerti bahasa Inggris.

1:25:59Ini kan tergantung juga, tadi kan yang kita baca itu contoh aja praktek di Google, satu perusahaan sendiri.

1:26:10Soalnya ini kan si LLM-nya ini gak punya opini, gak punya basis, gak punya landasan buat melakukan kode review ya.

1:26:21Terus apa ya, LLM itu kan kayak non-deterministik ya. Mungkin gak sih jangan-jangan kita manggil review bot sekarang.

1:26:35Terus semua dikasih komen. Oke lah, anggap aja dia standarnya gitu. Minggu depan kita manggil review bot lagi.

1:26:41Terus malah jangan kebanyakan komen. Make the variable name obvious. Itu kan malah sampai redaktif ya.

1:26:48Dia random kan, ada random-nya kan. Jawabannya bisa beda-beda kan.

1:26:53Mungkin ini sebagai starter aja buat guide untuk si reviewer untuk mereview.

1:27:06Oh ini ada itu sih di challenge, dia si penulis artikelnya juga ngejelasin kok di bagian challenges.

1:27:15Ini dia yang bikin berarti ya? Dia pengen bikin seperti ini gitu ya?

1:27:18Enggak, kayaknya dia pakai package yang udah ada, cuma dia mereview. Dia ngejelasin bisa kayak gini, kita bisa melakukan ini.

1:27:29Masalah apa, manfaatnya apa. Terus challenges-nya dia juga ngejelasin nih, ada context, blablabla.

1:27:38This is due to a limited understanding of the codebase context.

1:27:42Terus yang kedua, security and privacy, ya itu jelas. Sama yang ketiga nih, yang tadi kita bahas.

1:27:50Dikit model bias, tergantung training data yang dia pakai. Nah itu kan mesti code yang dia pakai sebagai training data kan bisa lain-lain.

1:28:01Itu males juga kalau minggu ini disuruh nambah komen, minggu depan disuruh remove komen.

1:28:06Sama itu, halusinasi satu lagi. Biasanya kalau kodenya bahasa-bahasa yang umum gitu ya, itu masih dia masih mengerti.

1:28:18Kalau misalkan kodenya, kalau kata mas Arya Hidayat tuh, kalau juur itu ngaco tuh, cat GPT.

1:28:24- Karena nggak ada training datanya kali. - Iya sedikit training datanya, sedikit.

1:28:30- Terus setiap bingung arang-arang aja udah sisanya. - Iya, halus jadinya kan, gitu.

1:28:35Tapi menarik ya. Tools sekarang kan, ya tadi kan dari mulai styling doang, formatting doang, sekarang bahkan udah sampai dependable, itu paling sering.

1:28:47Depanda bot, renovate bot.

1:28:49Terus 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.

1:29:01Tapi 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.

1:29:11Mungkin kita bisa mulai dari situ untuk belajar cara nge-review code.

1:29:16Atau 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.

1:29:26Walaupun bukan sama orang, lumayan lah latihan di code review sama robot.

1:29:32Oh iya benar, benar.

1:29:35Kalau halus atau kalau rese, ya udah di-disable, tinggal dimatiin aja kan.

1:29:42Benar. Cigpti soal join subquery malah dikasih sintaksnya Laravel, tapi jalan ya.

1:29:48Berarti kode Laravel banyak jadi itu ya, jadi training data ya, luar biasa.

1:29:56Karena Laravel itu dokumentasinya banyak, berbagi bahasa.

1:30:04Dan versi nya udah banyak banget, kan udah puluhan tahun.

1:30:07Iya, iya, iya. Benar, benar, benar.

1:30:11Oke, ada lagi yang mau disampaikan mengenai code review? Sudah, aman?

1:30:16Udah. Ini ada Marsudi, nanti datang di DevFest Depok tidak.

1:30:21Saya absen dulu di Depok, kita ke Bogor loh, kita di Bogor.

1:30:25Kita bertiga di Bogor nanti akan ada di Bogor.

1:30:28Jadi kalau ada teman-teman yang berada di Bogor dan sekitarnya, Jakarta boleh lah ya main-main ke Bogor.

1:30:36Sangal berapa? Sangal 25 November. Yes. Daging.

1:30:41Nah ini, daging. Daging apa ya? Kontennya daging. Terima kasih.

1:30:46Padahal kalau daging semua bahaya ya, harusnya ada tulang juga, kolester.

1:30:52Oke kalau gitu, mungkin udah hand dulu untuk malam hari ini kita ketemu lagi minggu depan dengan topik yang berbeda.

1:31:03Buat semuanya yang udah ikutan diskusi juga, seperti biasa kritik saran dan topik bisa kirimkan ke kesana.in/ngobrolinweb.

1:31:13Mungkin minggu depan kita akan coba review yang ada di sini, yang ada di Slido untuk topik-topik yang akan kita bahas ke depannya.

1:31:23Sekian dulu buat malam hari ini, kita bertiga pamit, sampai jumpa minggu depan.

1:31:33Terimakasih sudah menonton.