Jangan terkecoh dengan framework yang menjajikan mengurangi komplesitas koding dan meningkatkan produktifitas.

Sering kali kita dengar janji-janji suatu dari produk atau framework seperti ini: "Reduce Coding Complexity and Increased Productivity".

Ada harga yang harus dibayar untuk itu:

• Jika produk itu tidak gratis kita harus mengeluarkan uang untuk membelinya.
• Jika produk itu gratis kita perlu waktu untuk mempelajarinya.

Kadang-kadang suatu produk/framework hanya akan mempercepat pekerjaan atau meningkatkan produktifitas jika menggunakan tool yang tepat. Misalnya saja Struts atau Spring, dengan banyaknya konfigurasi yang dibutuhkan dalam bentuk file XML, akan menyulitkan developer untuk men-debug atau melakukan tracing jika tidak menggunakan tool/IDE yang memiliki kemampuan untuk memvalidasi file konfigurasi tersebut.

Tulisan ini berkaitan dengan proyek saya sekarang. Proyek yang saya hadapi sekarang akan menggunakan BEA Weblogic. Saya pikir Weblogic hanya sekedar Application Server dan Weblogic Workshop hanya sekedar IDE seperti halnya Eclipse, Netbeans. Tetapi ternyata banyak hal yang saya tidak tau. Weblogic Workshop memiliki framework sendiri, mereka menyebutnya Page Flow dan Control atau Apache Beehive. Dengan menggunakan framework ini pada Weblogic Workshop kita akan berhubungan dengan file-file berekstensi aneh (tidak saya temukan sebelumnya seperti jpf, jcs, jcx), Javadoc annotation, coding menggunakan gambar dan banyak melibatkan mouse untuk klak-klik memilih sesuatu.

Bukan hal mudah untuk bisa menbangun aplikasi menggunakan sesuatu yang baru, apalagi untuk mendesain. Untuk mendesain dengan menggunakan framework baru (yang belum pernah digunakan sebelumnya) akan memiliki resiko yang lebih besar dibandingkan menggunakan framework yang sudah pernah kita gunakan. Jika sudah menggunakan suatu framework kita akan memiliki list of best practice sehingga design akan dilakukan dengan menekankan best practices tersebut dipikiran kita.

Dengan menggunakan framework baru pada suatu proyek maka akan ada proses refractoring yang harus dilakukan pada perjalanan proyek tersebut. Jadi hati-hati lah menggunakan framework yang belum pernah anda gunakan sebelumnya jika tidak ada orang yang berpengalaman yang terlibat pada proyek anda.

Rencanakan dokumentasi anda!

Saat ini aya berada di sebuah proyek software (integrasi sistem) dengan beberapa technical lead, senior architect dan lain-lain. Pada awal proyek telah dijelaskan bahwa akan ada dokumen: requirement specification, functional specification dan design specification. Itu saja.

Setelah requirement spec selesai, saya rasa mereka semua bingung dengan struktur dari dokumen functional spec. Kenapa? saya pikir ini karena tidak direncanakannya dokumentasi yang akan dibuat. Buat saya requirement spec yang telah dibuat lebih menyerupai functional spec. Requirement spec yang kita buat berisi section yang dibagi berdasarkan fungsionalitasnya. Dalam tiap section terdiri dari beberapa sub-section yaitu

• Description yang menjelaskan sedikit mengenai fungsi yang ditulis dalam judul section
  
• Assumptions
  
• Use case diagram yang berisi sequence diagram (dalam terminologi UML), yang memperlihatkan interaksi antar system yang akan dibangun
• Requirements, yang mejelaskan dengan kata-kata diagram yang ada di sub-section sebelumnya atau menjelaskan kebutuhan dengan sedikit mendetail.
  
• Impacts

Bahkan di requirement spec dituliskan :

It also contains a detailed analysis of business, process, functional and operational model in order to provide context and background to the approach.

Bisa dilihat bahwa requirement spec sebenarnya adalah functional spec. Sehingga ketika kita dituntut untuk membuat functional spec yang terjadi adalah kebingung.

Kebingunan bertambah setelah seorang senior architecht yang 'dituakan' mengirimkan contoh functional spec dari project lain yang jelas-jelas di judul dokumen tersebut tertera ".... architectural documentation." Buat saya functional spec sangat berbeda dengan architectural spec.

Itulah sebabnya saya rasa perencanaan terhadap dokumen yang akan dibuat penting. Perencanaan dokumen tidak hanya merencanakan dokumen apa saya yang akan dibuat atau diberikan ke klien tapi lebih dari itu kita perlu merencakan struktur dan isinya.

Perencanaan menjadi penting juga karena biasanya tiap orang yang terlibat dalam proyek memiliki persepsi yang berbeda-beda tentang suatu dokumen. Kita tahu juga banyak sekali bentuk-bentuk dokumen standar yang digunakan dalam software development, misalnya standar IEEE, ISO, atau bahkan standar dari perusahaan. Kita bisa saja menggunakan standar dokumen yang ada tetapi sebaiknya selalu disesuaikan dengan proyek yang dijalankan.