Akrobat kecil…

Bisa ??

Sendok ditempel tanpa alat bantu apapun…

Bad Smells in Code

Menyambung tulisan tentang refactoring, ada beberapa arahan untuk menemukan bagian program yang harus di-refactor, bad smells in code…

Berikut adalah diantaranya

• duplicated code; kode-kode yang sama atau mirip di banyak tempat…
• long method; sebuah prosedur atau fungsi yang terlalu panjang; mungkin terlalu banyak yang dikerjakan…
• large class; sebuah kelas yang terlalu banyak tanggung-jawabnya; kurang fokus…
• long parameter list; sebuah method dengan parameter yang banyak akan menyulitkan client yang mengaksesnya…
• dan masih banyak lagi…

Mika Mantyla mencoba membuat taksonominya, agar kita mudah memahami bad smells in code tersebut dan dapat mengenali keterkaitan diantaranya. Taksonominya bisa dilihat di sini.

Nah, siapa yang mau membuat bad smells in code detector ??

Real Time Database

RT software yang cukup intensive mengolah data umumnya harus terhubung ke suatu basisdata. Akan tetapi, karena response time adalah hal yang penting, maka biasanya dipilih pendekatan untuk membuat basisdata terdistribusi. Keuntungannya adalah agar antrian tasks untuk mengakses basisdata bisa diperpendek. Selain itu, kita bisa memisah antrian untuk read basisdata saja atau write ke basisdata. Kerusakan pada satu basisdata juga tidak akan mengakibatkan kegagalan seluruh sistem, jika basisdata tersebut diduplikasi seluruhnya di site lain.

Hanya saja, ada beberapa effort yang harus disiapkan untuk memastikan konsistensi basisdata. Ya, sebuah update terhadap basisdata harus dilanjutkan dengan meng-update basisdata lain yang menyimpan data yang sama. Sinkronisasi harus dilakukan. Master clock dan time stamp harus dikelola agar semua tasks dan DBMS punya referensi waktu yang sama. Agar diketahui dengan persis, mana data versi terakhir…

Spaghetti…

(diambil dari http://blogs.sun.com/kazem/)

Refactoring

Refactoring adalah usaha untuk mengubah struktur kode program agar lebih mudah dibaca dan lebih mudah dimodifikasi. Ya, karena terburu-buru mengejar deadline, seringkali kita membuat kode program ‘kusut’ sehingga sulit dipahami. Meskipun tentu saja sudah bisa dieksekusi dengan benar.

Kode program yang kita buat itu seharusnya mudah dibaca dan dipahami karena bukan kita saja yang akan membacanya. Suatu saat nanti, mungkin kode program tersebut harus dimodifikasi oleh orang lain. Selain itu, kode program harus dibuat sedemikian rupa agar penambahan fitur baru tidak menyebabkan kita harus menelusuri dan mengubah bagian-bagian kode program versi sebelumnya. Idealnya, menambah fitur baru cukup dengan membuat kode program baru kemudian ‘digabung’ dengan kode program sebelumnya. Jika struktur program kurang baik, seringkali proses ‘menggabung’ ini jadi butuh effort yang besar.

Awalnya, refactoring tidak dikenal secara formal, tapi hanya sebatas pengetahuan programmer yang tidak terstruktur dengan baik (programmer lore). Akibatnya, ‘ilmu’ tersebut tidak bisa dibagikan ke programmer lain. Dua orang yang mulai paham tentang penting refactoring adalah Kent Beck dan Ward Cunningham. Kalau anda cari, mulai banyak buku-buku yang membahas tentang refactoring ini…

You married mine…

Ayo main logika…

“Daddy,” said a six-year-old boy, “I’d like to get married.”
“Sure son,” said his father. “Anyone special in mind ?”
“Yes,” answered the boy, “Grandma.”
“Now, wait a minute,” said his father.
“You don’t think I’d let you marry my mother, do you ?”
“Why not ?” the boy asked, “You married mine..”

(adapted from humormatters.com)

Process Improvement

Setiap organisasi harus terus tumbuh dan memperbaiki diri. Salah satunya adalah dengan melakukan process improvement. Ya, kalau kita tidak melakukan improvement, kita tidak pernah belajar memanfaatkan pengalaman sebelumnya. Kita tidak bisa meningkatkan kualitas hasil proses. Kita berjalan di tempat…

Software Process Improvement dapat dilakukan dengan mengacu pada CMMI (capability maturity model integration) -nya SEI (Software Engineering Institute). Sempat dibahas sedikit di sini. CMMI mendefinisikan beberapa level maturity. Untuk naik ke level yang lebih tinggi, sejumlah key process area harus selalu  dilakukan.

Tapi memang, process improvement perlu dilakukan pada saat yang tepat, dan disesuaikan dengan kebutuhan. Hal ini karena proses tersebut akan menyita banyak effort. Nilai tambahnya mungkin tidak akan terasa langsung…

Refreshing…

Foto di bawah ini adalah Didit (anak terkecil saya – 4 tahun) sedang dipandu melakukan ‘penyebrangan basah’ di Curug Brugbrug (sekitar Villa Istana Bunga, ke arah Cimahi).

Ya, minggu lalu, saya ikut anak-anak Sekolah Alam Bandung (SAB) ke lokasi ini. Secara rutin, anak-anak SAB memang dijadwalkan untuk melakukan kegiatan di luar sekolah. Karena ini adalah outing pertama Didit, saya usahakan untuk ikut. Dan saya cukup surprised karena anak bungsu saya itu cukup mandiri dan bersemangat mengikuti kegiatan tersebut.

Jalan menuju lokasi adalah pematang sawah/kebun yang cukup sempit, berbatu, dan becek, serta diselingi beberapa jembatan bambu di atas sungai kecil. Perjalanan cukup jauh untuk ukuran anak TK A. Tapi, anak-anak ini dengan gembira berjalan pelan-pelan sambil bercerita atau menyanyi…

Lumayan juga, refreshing di tengah hari kerja…

Inovasi itu…

Saat ini, banyak hal yang dipermudah dengan bantuan software. Salah satunya adalah software untuk mengelola social networking (saya juga terkena ‘demam’ salah satu jenis software ini; jadi waktu untuk blogging dan blog walking terpaksa berkurang … ). Dengan bantuan software tersebut, kita bisa berhubungan lagi dengan teman-teman kita di dunia maya. Kita bisa tau kegiatan apa yang sedang mereka lakukan saat ini. Kita bisa saling berkirim pesan singkat. Kita bisa sharing foto atau cerita bersama sekelompok teman. Ya, apa yang dulu membutuhkan effort besar, sekarang bisa dilakukan dengan mudah.

Yang lainnya adalah perkembangan software untuk instant messaging. Bukan lagi sekedar bertukar pesan singkat, tapi kita bisa ‘bertatapan’ wajah meski jarak jauh memisahkan. Contohnya, adik bungsu saya yang di Delft bisa ikut berlebaran dan ‘bertatap muka’ dengan keluarga besar di Bandung…

Itulah inovasi. Inovasi memberikan banyak manfaat bagi banyak orang. Yang dibangun atau dikembangkan tidak perlu yang rumit-rumit…

SART

Ini adalah metode untuk melakukan analisis kebutuhan real time software. Mirip dengan metode terstruktur untuk non real time software, kita memodelkan kebutuhan dalam bentuk DFD (data flow diagram). Hanya saja, DFD-nya ditambahi dengan control flow dan control specification (C-SPEC).

Jadi, kalau pada DFD hanya ada aliran data dan pemrosesan data, maka pada DFD/CFD diagram ditambahi dengan aliran control dan control node yang dijelaskan lagi lebih detil dalam C-SPEC. C-SPEC bisa dibuat dalam beberapa cara, misalnya Decision Table, Process Activation Table, State Transition Diagram, atau State/Event Matrices. C-SPEC menjelaskan bagaimana kombinasi input control diterjemahkan menjadi output control atau process activation/deactivation...