kode baik = (1).bug seminimal mungkin (2).kalo bisa ngak ada bug (mungkin ngak ya?) (3).kalo ngak mungkin, lihat no.(1)

Kode yang baik bagi saya tentunya mudah dibaca tidak hanya developer yg membuat kode itu saja, tetapi juga para maintainer dr software tersebut dan ingin menggunakan kode itu untuk diambil sebagian fungsionalitasnya. Perangkat lunak tentu harus terdefinisi dengan baik apa fungsinya,disain juga harus baik. Kode yang baik harus efektif juga, dalam penggunaan resource memori. Pada OO tentu perlu membaca buku mengenai Refactoring dari Martin Fowler,baru lah akan mendapatkan kode OO yang baik.

Usul, lebih dibahas dong prinsip-prinsip membuat framework hebat seperti Qt!!!! Software engineeringinya seperti apa? Code reviewnya bagaimana? bagaimana untuk mengimbangi antara kesempurnaan dengan schedule?

Kode yang baik bagi saya simpel aja: Simpel dan jalan sesuai kebutuhan. Hihi. Pis…

Sebenarnya kriteria untuk menentukan apakah suatu kode itu baik atau tidak juga harus bisa dianalis secara kuantitatif, alias ada metrics-nya.

Misalnya untuk kategori “readable”, bagaimana menentukan apakah sebuah potongan kode itu readable atau tidak? Kalau hanya mengandalkan penilaian developer yang lain, kan ini jadinya subyektif. Contoh metrics untuk readable: nama variable bukan singkatan aneh (iLpCnt vs loopCount), mengikuti coding style (indentasinya konsisten), ada dokumentasi tiap fungsi (untuk javadoc/doxygen), dan sebagainya.

Sama dengan “maintainable”. Ini kan terminologi yang abstrak. Contoh metrics untuk maintainable: tidak ada nested if/else lebih dari 2 level (harus direfactor), thread safe (menghindarkan “kejutan” saat terjadi locking), tiap fungsi ada unit testnya, dan seterusnya.

IMHO penting di tiap team atau project untuk mendefinisikan hal-hal seperti ini sekuantitatif mungkin (faktor subyektif pasti selalu ada). Contohnya link yang sudah diberikan (kasus desain API di Qt): http://qt.gitorious.org/qt/pages/ApiDesignPrinc…

setuju. occam razor : Of several acceptable explanations for a phenomenon, the simplest is preferable – sumber: wikipedia

http://en.wikipedia.org/wiki/Occam's_razor

Aku blm denger podcastnya, tapi menurutku kode yang baik adalah yang serve its purpose. Maksudku, jangan code demi memenuhi jargon semata. Eg: hello world bisa ditulis dgn berbagai macam cara.

#programmer gadungan yang kadang mimpi c++

valid point. ini menekankan kerelatifitas-an definisi kode baik tersebut.

sekedar entertaining that argument … sifat yang gete jelasin kan limitasi GC modern jaman skrg. My point was, dengan kemajuan jaman bukankah seharusnya ini menjadi tanggung jawab framework untuk bisa mengatur memori dengan lebih baik. Mungkin melalui reference counter atau semacemnya, GC bisa lebih agresif membersihkan memori yang sudah tidak dibutuhkan.

bukankah ini merupakan salah satu jenis persistence ignorance jg?

Sedikit promosi couldn't hurt.. post gw tentang NDepend ada di http://hendryluk.wordpress.com/2009/04/28/ndepe…
NDepend adalah topik yg challanging buat diconvey lewat audio podcast karna naturenya yang visual banget. Mungkin bisa liat2 dulu di sana buat dapet big picture apa yg dingomongin di podcast episode NDepend… dan hubungannya dengan code-quality.
Toolling bisa ngebantu buat code quality. Gak perlu lagi ngeraba2 dengan teori2. Tool kayak NDepend dan teknik kayak TDD bisa ngasih hard evidence buat ngedukung argument kita tentang code smell yang otherwise cuma bergantung instinct.

On that note, IMO TDD itu shortcut buat good design. Gak perlu lagi baca buku tebel2 ato baca teori2 software engineering. Code yang gampang ditest automatically adalah code yang bagus.
Code yang jelek penuh dependencies, dan buat execute dan memahami specific part of the application mesti ngejalanin dulu serangkaian screen ato belasan line of setup code. Ini code yang punya tight coupling dan susah banget dimaintain.

Gak peduli teori2 software engineering, ultimate goal dari good code adalah kalo setiap komponen dari application itu bisa langsung di instantiate gitu ajah, tanpa perlu setup object laen yang gak berhubungan, dan langsung bisa dicolek2 sesuka hati dan langsung muntahin result yang bisa dievaluate. Tanpa sadar kita lagi ngomongin loose-coupling.

Real world case:
Gw pernah (actually saat ini masih) deal dengan class yang namanya CustomerActivationService… yang punya direct coupling ke data-access, TML (EAI), IIM (inventory), IAM (network), QAS (address-validation), decision-intelect (credit-check), 5-6 configuration files, HttpSession, beberapa static objects dan Globals. Freakin god of the universe.
Tight coupling!… Semua component ini cuma bisa dibaca dan dimengerti together. Kalo developer pengen tau.. apa sih yang terjadi dengan customer-activation kalo inventory kehabisan stock? Easy: run freakin belasan screens di browser dan pasang debugger.
Tiap kali code ini adalah the heart of the system (CRM), dan code ini berubah terus tiap saat, dan tiap kali, user mesti “ngetes” dengan ngejalanin belasan screen dalam trial n error fashion.

Apa hubungannya dengan TDD?
Code ini gak testable. Definisi gak testable adalah, lo mo verify apa yang terjadi kalo inventory kehabisan stock, tapi sebelom gw bisa get anywhere near there, gw mesti setup ratusan objects, flags, nulis fake backend, setup database state, dan memenuhi berbagai validation criteria… yang sama sekali gak berhubungan dengan apa yang gw pengen verify. As soon as lo ngelibatin object2 yang gak berhubungan dengan apa yang pengen lo verify, ini adalah sign of pain.

Gw mau gw bisa immediately instantiate class gw on the spot, dan evaluate apa yang terjadi kalo kita stub inventory.acquireProduct() dengan out-of-stock. Ini maksa kita buat berpikir dalam layer. Class kita mesti dikompress sekecil mungkin. Data-access disembunyiin di balik “collection” semantic (i.e. repository). Segala macem configuration gak boleh leaking ke domain layer.
Domain layer adalah layer dimana lo pengen bisa maen2 dengan berbagai business scenario.. dan mo mau completely ZERO infrastructure disana.

Dan before you know it, code yg mo lo execute tiba2 tinggal: orderService.AddProduct(shoppingDetail, product, quantity, inventoryManager). Terisolasi dalam komponen kecil yang bisa dicolek2 sesuka hati dengan berbagai business scenario, dan lo tinggal observe apa hasilnya instantly. Gak ada database, gak ada configuration file, gak ada backend services, gak ada Globals dan HttpSession yang lo mesti setup.

Dan I bet code ini gampang dibaca oleh manusia biasa. TDD maksa kita think small. Tiap component berada pada ukuran yang bisa dicerna dengan sekali pandang.

TDD adalah shortcut buat good code. Kita gak perlu ngerti teori kenapa class ini mesti dipisah jadi multiple layers, napa mesti abstract dependency jadi interface, napa dependency-injection. Goal kita cuma 1: setiap component mesti bisa diinstantiate dan dicolek2 dalam isolation…

“Colek2 dalam isolation” bukanlah reference ke aksi senonoh. Sebagian menamai aksi ini sebagai:… yes, “unit-test”!

si Hendry bisa ngebahas soal NDepend lagi nih. ada ide para teman macet? mungkin ada yang merelakan diri untuk diajak diskusi? (-:

Sebenarnya yang mau aku tekankan itu: GC hanya mengatasi satu jenis masalah dengan memory: alokasi/dealokasi. Sedangkan efektifitas (efisiensi mustinya kali yak) penggunaan memory itu masalah di daerah lain (atau mungkin superset-nya). Dalam contoh baca file(s), kalau memang code-nya secara barbar menampung isi semua file di memory sekaligus, GC secanggih apapun nggak bisa apa-apa karena memory-nya memang masih ditandai aktif terpakai. Nanti ada komponen lain yang ikut campur misalnya caching/paging, yang sebenarnya mungkin nggak perlu (tanda2 code jelek).

(OOT) Protes: yang “teman macet” itu situ, kita “temannya teman macet”

Selain untuk quality, di ranah gue kerja, code analyzer juga berguna buat 'mengukur' keamanan codenya. Cuma, selain spesifik ke webapp, buanyak false positive-nya. Tapi kalau mau cover, bisa lihat2 code analysis tools di CWE http://cwe.mitre.org/compatible/organizations.html

Sip.. FB connect-nya udah bisa.. yeeey!
Episod paling dahsyat..
Posting panen komentar paling banyak.. hehehe..

Cheers,
Temannya temanmacet :p

di staticly type language, untuk ngelakuin unit testing *dengan mudah* (ini kata kuncinya) sebuah class harus focused dan loosely coupled. biasanya ini dilakukan dengan menginjek dependensi-nya dari luar.

di staticly type language ini mendorong konsep2 seperti inversion of control, separation of concern, dsb.

akhirnya seperti post panjang hendry di atas. contribute to better design = test driven design.

ini adalah salah satu contoh unit testing:
http://www.ronaldwidha.net/2009/03/22/aspnet-mv…

di obrolan bersama hendry Luk yang belum keluar kayaknya kita sempet ngebahas behavior driven design yang menyempurnakan teknik ini dengan menghilangkan kata 'test'-supaya ga ambigu, dengan kata behavior. unit test berubah dari 'ngetes sesuatu' menjadi 'spesifikasi dari sesuatu'

misanya method di unit test:
[TestFixture]
class studentTest
{
[Test]
public void enrolStudentBodohHarusDitolak() {}
}

sedangan di behavior driven menjadi:
[TestFixture]
class WhenEnrollingStudentBodoh
{
[Test]
public void ShouldDitolak() {}

[Test]
public void ShouldKirimSuratKeOrangTua() {}

[Test]
public void ShouldNotBalikinDuitRegistrasi() {}
}

Btw, 2 minggu lalu NDepend baru ajah release versi C++ nya. CppDepend.
http://www.cppdepend.com/