#21 Henri Luk ngomong soal Static Code Analysis: NDepend, Team City dan FXCop – transkrip

ingin kontribusi membantu teman macet? ketik bagian podcast yang kamu suka di post ini ala WIKI dengan login di facebook connect disamping kanan dan klik edit this. Dengan membantu teman macet, kamu ikut berpartisipasi dalam membuat konten ini lebih mudah diakses untuk orang-orang yang tidak bisa mengkonsumsi audio

RW: Kali ini saya bersama Hendry Luk, seorang programmer yang berkelut dalam dua bidang, dia masuk di Java, masuk di .Net juga. Saya mengenal dia dari pembicaraan kita di mailing list .Net Indonesia yah. Jadi kali ini gw pengen ngajak Hendry buat ngobrol soal continuous integration yah, dan in particular tooling yang sering dipakai di continuous integration yaitu NDepend. Gw ngebaca dari blog lo Hen, lo kayanya punya sedikit insight tentang NDepend yang kayanya seru ni buat di share.

HL: Jadi NDepend, beberapa minggu lalu gw baca baca dari beberapa project open source sudah makai NDepend buat analysis, disclose dulu ni sebelon kita mulai, bahwa gw ada udang di balik batu, gw pake NDepend pake awalnya karena gw dapet license gratis, ditawarin oleh Patrick supaya gw bisa ngomong kata kata manis tentang NDepend.

RW: Terus lo awalnya ada relation, Patrick ini head of product nya NDepend yah, bener ga?

HL: Iyah, dia tech lead. Sebenernya gw ga ada hubungan sama dia, dia contack gw lewat email dan dia nawarin gw supaya gw ngomong sesuatu di blog gw tentang NDepend, jadi gitu awalnya sih.

RW: Lo mungkin mau ngejelasin dulu blog lo namanya apa, alamatnya dimana, dan lo nge blog tentang apa kebanyakan

HL: Blog gw ada di hendryluk.wordpress.com. Gw ngobrolin biasa soal tentang .Net atau technology .Net, gw ga terlalu technical, gw biasa kebanyakan soal design, architecture soalnya gw juga ga terlalu banyak main main di infrastructure .Net akhir akhir ini, jadi gw lebih banyak ngomong ngomong Unit Test, Test Driven Development, Domain Driven Design.

RW: Gw ngeliat salah satu postnya, Rob Conery yang nge reply. Lo kayanya network nya sangat sudah masuk ke dalam dunia expert sekali. Itu lo ada hubungan apa ni sama dia? Jangan jangan saudaraan juga.

HL: Ga, gw jauh sama dia hubungan family. haha. Gw ga terlalu banyak communication. Gw ada beberapa kali email dia tentang dia punya, dan soal blog reply nya dia gw ga tau dia lagi ngapain, end up di blog gw.

RW: Itu menandakan kualitas Hen

HL: Mudah mudahan

RW: Kembali kita ngomong soal NDepend lagi, jadi boleh jelasin sedikit tool NDepend itu sebenernya apa.

HL: Oke, NDepend itu sebenernya salah satu tool buat static analysis atau kalau lo mau put it in another way NDepend itu adalah tool buat ngebaca code tanpa sebenernya lo ngebaca source code lo. Cuman misalnya lo jadi architect atau tech enginner atau lead enginner, lo ga bisa baca semua source code dari application buat lo periksa satu per satu. Dan juga lo periksa source itu ga tau kemana harus ngeliat, lo bisa mengerti application lo jalannya kaya gimana, bentuknya kaya gimana, cuman lo ga ngerti dimana yang mesti liat, soalnya lo ngeliat terlalu detail. Jadi NDepend itu paling bagus buat visualization kaya peta, atlas, kalau lo pertama kali dateng ke negara yang belon pernah lo kunjungi, hal yang pertama lo cari adalah peta di airport. Nah itu buat lo ngeliat code lo structure nya kaya gimana dan dependency nya kemana ajah, terutama code yang bukan lo sendiri develop. Kalau di develop sama developer lo misalnya, lo baca source code orang lain, nah NDepend sangat berguna banget buat visualisasi.

RW: Jadi untuk make sure juga kalau uml tooling yah, kita ga mau ngeliat se detail itu. dan kita cuman mau liat landscape ajah yah, bener bener cuman warna, dependency antara satu module dan module lain, tapi ga sampai ngebahas soal class nya in particular, methodnya kaya gimana, properties nya gimana dan sebagainya. bener ga?

HL: Bener, ga particular. Jadi cuman characteristic nya. Jadi characteristics nya dari class nya bukan cara kerja dari class nya. JAdi characteristics nya mulai dari beberapa, disini ada 80 macem matrix, gw ga sure, bisa diliat dari webstitenya. Matrix yang lo bisa liat, number of dependency, complexity, sampai number of lines, number of parameters, dia depend kemana. Jadi sebenernya liat dari kualitas bukan dari sisi cara kerjanya.

RW: Terus dari 80 matrix itu, yang menurut lo menarik apa? Yang jelas kayanya paling terkenal gw rasa adalah dependency itu yah, bahwa dia bisa kasih liat seberapa tightly coupled atau loosely coupled design lo dan dia nge visualisasi nya dengan berupa kotak kotak atau bisa juga bisa dengan matrix, ngasi liat siapa dependency itu ke siapa. Tapi yang gw masih ga ngerti adalah apa gunanya buat tau hal hal ini. Maksudnya gw tau bahwa lo seorang test Driven Development guy juga yah dan kayanya salah satu test driven design focusnya adalah bukan sekedar unit test tapi malah loose coupled itu kan. Dengan lo ngelakuin Test Driven Development akhirnya design lo really really loosely coupled. Sekarang apa bagusnya, satu apa bagusnya loose coupled design. Yang kedua kenapa lo mesti pake NDepend buat tau loose coupled dependency ini?

HL: Ini sebenernya salah satu hal yang pengen gw bahas hari ini, data data yang dikasih sama NDepend itu kan terlalu gede buat developer atau tech lead, jadi dan gimana cara make data data itu dan arti data data itu. Itu yang bikin kita penasaran ini, jadi kalau lo liat NDepend. Lo udah pernah download NDepend belon Ron?

RW: Sudah pernah liat sekali, tapi gw belon pernah main main banget.

HL: Jadi NDepend ini method yang paling penting adalah dependency matrix. Kalau kita liat matrix ini mirip kaya, jadi lo bisa bayangin ada correlation matrix, ada sumbu x, sumbu y. Dan perpotongan dua sumbu itu, kalau lo click point perpotongan sumbu ini, lo bisa liat ada berapa dependency yang dari sumbu x, dan sumbu y. Jadi kalau misalnya lo highlight mouse itu, bakal generate bahasa English, dia bilang 21 members yang gw generate dari sini. Jadi dia ada tulis misalnya 21 member dari assembly a dipakai oleh 32 meter dalam assembly b. Contohnya seperti itu. Nah, assembly matrix ini ada banyak mathematika data nya, sebenernya lo ga peduli. Cuman bagaimana itu gimana dipakenya, kalau misalnya lo liat dari summary nya, dari report nya, salah satu yang bisa lo pake misalnya di summary nya. Di situ dikasih summary, bisa di baca oleh manusia, bukan orang yang hard core computer scientist. Jadi kalau lo liat di report nya, ada istilah namnaya abstractness versus instability. Jadi abstractness dan instability itu bukan berarti assembly lo stable itu bukan berarti itu bagus atau jelek. Itu adalah characteristic dari code lo. Jadi stable artinya adalah code yang dipake oleh banyak orang, jadi misalnya lo pake name space, yang banyak name space lain yang ke dalam name space itu. Makanya name space itu stable. Artinya name space itu susah di ganti, karena kalau di ganti bakal break banyak functionality. Dan itu adalah stable. Jadi kita mau, kalau code code yang sifatnya driven design yang bagian dari domain itu biasanya bagian yang paling stable , karena itu adalah bagian yang ga mau lo ganti ganti. Di satu sisi lain, ada abstractness. Jadi abstractness adalah ratio dari berapa bagian interfaces atau abstract class, jadi dia bisa tunjukin satu angka, dari 0 sampai 1. Nah disini didalam NDepend dia kasih liat, ada satu balance satu garis diagonal antara sumbu x dan sumbu y. Jadi di sumbu y ada abstractness, disumbu x ada instability. Nah disini ada satu balance, lo kepengin semua di dalam balance itu. Di ujung, suatu corner ada namanya zone of pain. Zone of pain itu adalah dimana lo masuk kedalam area itu code lo susah di ganti, susah di maintain karena zone of pain di sebagai code yang stable, artinya cukup di pakai orang banyak tapi sangat ga abstract. Iyah jadi lo sebisa mungkin menghidari daerah merah. Dan di opposite corner ada, zone of uselessness jadi kalau code lo sangat abstract, lo punya banyak interface, lo punya banyak variable tapi ga ada orang yang make.

RW: Jadi sebenernya dia punya premis tersendiri buat ngebikin 2 zone itu yah, zone of pain dan zone of uselessness. Menurut lo itu lumayan constant ga sebenernya throughout different project apa sebenernya itu relative dan kadang kadang suka ga terlalu relevant juga

HL: Itu sebenernya fluctuative cuman kalau, jadi dari project project bisa berubah rubah angkanya. Sebenernya kalau gw pribadi, gw belon experience ngeliat perkembangan project bergeraknya kemana, apa semakin bagus, apa semakin jelek, apa sudah cukup accurate, cuman sebenernya itu salah satu measurement doang, itu bukan salah satu feature yang major dari NDepend. Itu cuman summary yang paling gede tentang kualitas project lo tuh kaya gimana. Jadi di dalam NDepend tuh banyak tool lainnya. Salah satu nya dependency matrix yang lo sebut itu, jadi lo bisa liat. Misalnya lo liat di code camp server, code camp server itu yang gw pake buat review NDepend. Jadi itu project code camp server. Lo bisa liat dependency lumayan predictable. Jadi kalau lo sebagai tech engine nya gimana caranya layering application lo, cuman lo ga bisa control satu per satu developer lo bakal kerjanya kaya gimana, lo ga bisa periksa source code nya satu per satu. Kalau lo ngeliat dari dependency nya, lo ngeliatin ada unexpected dependency disitu, misalnya lo punya web, bisa punya access ke data access misalnya, itu sesuatu yang lo ga mau sebagai tech lead. Dia bisa kasih no yang jelas, bisa kasih angka 21 dependency dari web ke data access. Dan even better, kalau lo click ke angkanya, bisa ngasih detailnya, bisa kasih liat uml diagram nya, apa ajah depend dari web ke dalam unit test karena ada integration ke visual studio. Kalau lo double click, dependency nya, bisa kasi liat line of code, mana yang sebenernya make dependency itu.

RW: Wah keren skali, jadi ibaratnya kalau ngebayangin google earth atau live maps atau apa gitu, kita bisa liat zoom out peta dunia nya, dan begitu kita liat ada anomali di salah satu tertentu kita bisa zoom in sampai akhirnya nemu enough details yang kita cari yah, which is details yang paling rendah code gitu kan.

HL: Bener, sebagai google map. Ini ada salah satu video yang mirip google map, ini adalah three map. Ini kaya kotak kotak item item gede kaya NDepend, jadi kotak kotak ini mewakili satu characteristic tertentu, misalnya kalau misalnya lo liat di google map, kota yang geographically gede, kotaknya semakin gede. Tapi kalau dalam code lo bisa ganti ganti, Di sini bisa ngomong tolong kasih tunjuk gw tentang number of lines code. Jadi kotak kotak nya semakin gede, number of lines nya semakin gede. Jadi lo bisa melihat peta dunia dari code code lo gimana, liat dari sisi paling luas dengan bisa pakai mouse, bisa zoom kedalam. Semakin gede kotak nya, semakin gede class nya, semakin gede methodnya juga. Nah tujuan dari mapping ini, lo bisa liat kurang lebih dari lines of code misalnya ada 62 matrix, itu ngeliat complexity mana yang paling gede dari code lo, lo bisa melihat map nya yang paling gede mana complexity nya, dari situ ada bagian bagian yang bisa lo refactor. Ngomong ngomong soal refactor ini sebenernya, focus yang paling penting. NDepend ini bikin rule, jadi mirip effect scope. Kalau effect scope bagian painful buat lo sendiri kan. Effect scope dateng dengan berbagai macem tool, sebagian besar, lo ga bisa specific ke dalam project lo sendiri. Jadi bagian yang paling penting dalam NDepend ini yang paling unik dari tool lain adalah cql. Ini codequery language. Query language keren banget, mirip sql, cuman sql ini kan lo query ke dalam data base. Kalau cql, itu query ke dalam source code.

RW: Sangar sangar, itu bener bener dsl buat static analysis yah.

HL: Benar, ini sangat keren banget.

RW: Performance nya gimana, dipakai buat dijalanin along bersama continuous integration lo atau lo bisa kaya punya consule tinggal type in, dan langsung jawabannya instantly balik?

HL: NDepend ini ada banyak view, jadi lo bisa run dari sisi consule, bisa juga pake continuous integartion, unscripted, dia ada juga visual studio nya sendiri. Dia ada id nya sendiri. Jadi visual NDepend ini punya, sesuatu yang sequel server ga punya.

RW: Jadi udah meta programming yah? Bahwa lo programming against another code sebagai data lo kan. Iyah ga si? Lo biasa programming against user data kan, sekarang lo programming against language lo kan, code base lo. Tapi itu performance nya lumayan cepet kalau lo nanya pertanyaan yang se complex lo tadi? Lumayan cepet baliknya? dia harus go through code basenya, name space nya, data space nya, dan sebagainya.

HL: Nah ini the best part of NDepend sebenernya, jadi lo nulis query, lo bukan pencet execute, maka dia execute, dia search, keluar hasilnya, itu bukan. Selagi lo nulis dia execute. Jadi lo nulis dan keluar hasilnya dan kalau lo tulis lines of code lebih besar dari 50 dan number of comment lebih kecil dari 20 percent. Dia langsung keluar hasilnya selama lo ngetik. NDepend itu context sensitive, jadi kalau lo hasil dari query itu, bakal muncul di map yang gw sebut itu, three map itu, bakal di tandai dengan hot spot. Misalnya lo nulis complexity lebih gede dari 50, dia bakal tunjukin di map itu dengan warna merah bagian bagian yang kena warning itu mana ajah. dan lo misalnya lo double click di warna merah nya itu, dia langsung buka code itu di visual studio.

RW: Wow, thats amazing. Sekarang kalau di tie in ke continuous integration, karena NDepend banyak kemampuannya yang berdasarkan visualisasi kan. Sedangkan continuous integration kan biasanya something yang lo ga liat visualisasi, lo cuman liat bahwa yah merah atau hijau, build broken atau build stable. Gimana caranya lo integrate NDepend ke continuous integration, apakah lo bisa set rules rules rules, berdasarkan sql tadi dan untuk ngebalikin pass atau fail atau gimana? Atau ga pake NDepend continous integration, cuman hal yang pake oleh seorang team lead atau malah mungkin semua developer sebelon check in code nya harus make sure dulu gimana gimana sebelon check in. Menurut lo uses yang paling tepat yang gimana?

HL: NDepend ini sebenernya dua fold yang bisa lo pake jadi lo bisa pake sebagai architect yang lo bisa analysis dari application lo, sebenernya ini pake communitive, cek isinya kaya apa code lo. Satu lagi architect ini bisa define rule nya kaya apa dan bisa integrate. Jadi setiap orang yang commit, semua rules nya bakal di run dan lo bakal bisa ngeliat gerak nya kaya gimana, gimana progression lo bahkan bisa compare degnan version sebelonnya, ada berapa method yang lo tambain, ada brapa name space yang baru, berapa dependency yang lo introduce. Dia bakal tunjukin dalam bentuk report dan bakal nunjukin juga warning warning, dari sql yang di langgar. Jadi misalnya developer commit sesuatu hal yang jelek, masuk dalam source control akan di cek sama NDepend dan akan ngasih tau code itu melanggar sesuatu.

RW: That rise an interesting point yah bahwa continuous integration kan about automation dan mungkin ada beberapa kualitas yang blur gitu, ga jelas untuk di bilang apakah ini bagus, apakah ini jelek, apakah ini stable, apakah ini broken. Dan mungkin NDepend masuk dalam hal itu yah, bahwa memberikan kesempatan untuk human introvention kan dimana kalau setiap build, laporannya kirim ke tech lead dan tech lead nya bisa ngambil kesimpulan dari summary itu untuk stop or continue as usual yah.

HL: Tujuannya mirip FXCop yah, jadi developer dipaksa buat ngikutin guideline, jadi kalau lo punya guideline tertentu, lo bisa enforce guideline itu ke continuous integration. Dan setiap buildnya, build hari ini dan build kmaren bisa lo buka dan lo compare, di dalam report nya, mana yang lebih bagus. Nah ini fasilitas NDepend yang paling gw demen, bisa compare 2 version of code. Nah lo bisa compare dan tunjukin apa impact nya. Apakah dependency bertambah atau berkurang?

RW: Gw bisa liat NDepend ini bisa berguna buat architect yang ngadepin brown field yah. Kalau green field kan architect white board session yang ideal kaya gimana, sedangkan untuk masuk project yang sudah established ga semudah itu kan, karena seorang architect itu harus tau betul situasi nya seperti apa melihat tujuannya kaya apa dan ngelakukin gap analysis, gimana cara ngebawa dari situasi a ke situasi yang di tuju. Gw bisa ngeliat NDepend ini berguna buat overall picture nya itu yah. Ga mungkin seorang architect masuk ke satu project dan ngeliat ratusan ribu lines of code, iyah ga sih? Dan NDepend bisa jadi tool yang berguna untuk itu.

HL: Betul banget, soalnya code itu skill, berkembang seiring waktu. Architect itu ga bisa berkembang, cuman ada satu atau dua. Tapi intinya architect itu ga bisa scalable, ga bisa lo clone. Misalnya lo mesti ngecek satu per satu source code lo itu ngabisin waktu. Dan ada limitnya, sampai tahap tertentu architect ga bisa ngeliat semua source code. Jadi architect butuh visualization itu.

RW: Tapi mungkin juga sekarang gw mikir, kalau ngomongin architect orang yang sudah punya banyak pengalaman, sangat tinggi, sangat jago dan sebagainya. Tapi gw jadi mikir juga, ini tool yang sangat berguna, untuk developer, untuk any developer yang baru masuk ke project yang baru, iyah ga siy. Kalau lo masuk ke project yang baru, pasti kan lo time nya yang sangat lama, lo pengen navigate codenya secara cepat buat ngeliat overall picture nya, interaksi satu component dan component lainnya kaya gimana. Apa lagi dengan, sangat nge trend methodology methodology seperti ejal dan sebagainya yang lebih take priority buat documentasi lebih rendah, kita approach nya dari pada documentasi mending write good code. Code itu menjadi living document, dan gw ngerasa tool tool seperti ini untuk orang baru masuk ke dalam tim, apa lagi dalam situasi dimana ga banyak document around code base itu tersebut. Gw juga pengen nyambungin ke salah satu tool yang gw denger di Citcon Melbourne tahun lalu, which is Team City yah. Lo pernah denger ga?

HL: Iyah, gw pake Team City juga.

RW: Itu similar sama NDepend yah?

HL: Oh bukan, Team City itu similiar sama cruise control.

RW: Itu continuous integration ajah?

HL: Iyah.

RW: Gw kayanya waktu pas tahun lalu, gw ngeliat salah satu visualisasi nya adalah dia bisa ngeliat code tapi code nya di visualisasi secara gambar kota. Dan kalau misalnya ada satu module yang sangat complex, dia dikasih liat sebagai gedung yang sangat complex dan sebagainya. dan setiap area nya juga, sangat distinct satu sama lain dan lumayan ngegambarin gimana perbedaan landscape satu code dengan code yang lain, dan menurut gw analogy nya sangat hebat. city kan seperti itu, maksudnya yang salah satu sisinya banyak yang, style nya berbeda dengan style yang lain. Apakah itu ga mirip dengan NDepend?

HL: Gw ga yakin kita ngomongin Team City yang sama ni. Soalnya Team City yang gw tau itu ada beberapa plagin dan salah satu plagin adalah effect scope,mirip banget dengan NDepend. Ini salah satu persamaan Team City dan NDepend, cuman sebatas itu, yaitu dia punya pluggin effect scope. Sebenernya Team City bisa di extend ke NDepend. Jadi kalau lo commit sesuatu ke dalam Team City, Team City bisa bikin analyze data datanya, kaya satu yang paling sering di pake adalah coverage. Jadi test coverage bakal muncul dan lo bisa liat trend nya dimana  . Jadi lo bisa liat berapa percent dari code lo, dan di highlight di code code yang ga punya adequate, dibikin unit test nya. Dia bakal tunjukin dengan warna merah. Jadi kalau lo dibawah 80 percent bakal di kasih warna merah, bakal muncul warning di Team City nya. Jadi Team City maksa developer untuk nulis Unit Test. Ada lagi effect yaitu guideline, jadi lo bisa set apa lo melanggar compliance apa lo declare satu static variable atau lo exception generally tanpa lo declare secara specific, effect bakal nangkep itu dan bakal bikin warning di Team City. Cuman gw ga pernah liat kota segala macem. Itu Team City yakin?

RW: Jadi ga yakin setelah ngomong sama lo, haha. Gw lumayan mikir kayanya Team City, cuman namanya Team City jadi gw mikir itu team city kali yah, Gw akan google. Gw pengen nanya, gara gara ngomongin Team City yah, lo TDD juga, lo sangat resharper orientated juga?

HL: Oh banget, gw ga bisa bayangin gimana nge code tanpa visual studio.

RW: Tadi nge tied in sama effect scope kalau misalnya lo, bukan effect scope in general siy, kalau di visual studio 2008 dalam default nya kalau lo misalnya nyalain code static analysis nya, rules nya suka banyak yang bertentangan sama rules nya resharper yah. Misalnya yang classic banget, naming convention. Resharper sukanya kalau ga salah by default private variable itu boleh pakai nama sama public variable nya cuman beda satu camel casing yang satu di awalin dengan huruf kecil. Sedangkan kalau misalnya code setting visual studio, variable sama skali ga boleh ada nama yang sama, which is a fair comment karena mereka lebih mikir VB dengan C sharp VB ga support case sensitive jadi lebih baik jangan dipakai sama sekali. Lo suka nemuiin masalah yang sama ga, lo pake dua tool yang standard nya berbeda, kalau lo ngerasa gitu juga, biasanya apa yang lo lakukin?

HL: Kalau gw sebenernya, gw ngeliat rule rule yang dikasih itu adalah pilihan, mana yang lo enforce.Lo bisa nambahin rule sendiri kan dengan specific coding convention sendiri di company lo. Itu sebenernya kita make effect scope buat ngerapiin coding convensation di company kita ke dalam source code. Tapi bukan berarti effect scope nentuin coding code di company kita, jadi sebenernya effect scope itu bukan sesuatu yang harus kita ikutin.

RW: On that note, kayanya kita mesti akhirin podcast ini. Tadi lo ngomong bahwa jangan sampai tooling meng dictate apa yang lo lakukin, tapi malah kebalikannya lo menggunain tooling untuk mencapai tujuan yang lo pengen dapet dari team lo. Thank you banget Hendry sudah melukangan waktu nya buat ngobrol di teman macet.