Azwar

Berbagi cerita dan informasi

Tag Archives: Software Development

HMVC Design Patern tidak dapat menggantikan Source Code Management

Pada artikel ini saya ingin membahas mengenai Design Patern pada Software Development yang saat ini sedang naik daun, nama Design Patern itu adalah HMVC.

HMVC 结构图

HMVC adalah versi pengembangan dari Design Patern MVC (Model-View-Control). HMVC sendiri adalah singkatan dari Hierarchical Model View Control. Atau bisa kita bilang sebagai versi MVC yang diimplementasikan secara hirarkis. Hirarkis di sini maksudnya adalah hirarki folder (struktur folder) yang mana menjadi modul.

Kuncinya adalah, satu modul memiliki satu MVC, atau bisa dikatan lebih gampangnya adalah, satu modul memiliki masing2 file model, file view dan file controll. Meskipun masing-masing file tersebut tidak selamanya diperlukan, ada kalanya cuma perlu file view dan controll saja.

Contoh: Saya memiliki folder modules folder ini nantinya akan saya gunakan sebagai tempat menaruh modul-modul saya. Oke, sekarang anggaplah saya ingin membuat modul produk, maka saya buat folder produk di dalam folder modules maka struktur foldernya menjadi modules/produk, di dalam folder produk ini akan kita buat folder untuk masing-masing file MVC, dengan kata lain kita akan membuat folder bernama model, view control .

Jika digambarkan, maka struktur hirarki nya akan menjadi sebagai berikut:

-modules/
….|
…+—-produk/
…….|
……+—-model/
……+—-view/
……+—-control/

File-file model akan diletakkan dalam folder model, begitu juga file view dan file control (controller) akan diletakkan ditempatnya masing-masing sesuai nama foldernya.

Keuntungan dari design pater ini, terutama bagi aplikasi web adalah, modularitas file pada aplikasi yang dikelompokkan berdasarkan fungsinya. Contohnya, file-file yang berhubungan dengan produk ditempatkan pada modul produk (file view nya produk, file controllernya produk, dan file modelnya produk).

Maksud dari pengelompokkan folder berdasarkan fungsinya tersebut adalah agar ketika ada tambahan fungsi baru pada program, misal tadi ada fungsi produk kemudian teman kita sudah membuat fungsi user maka kita tinggal mengkopikan modul user yang telah dikerjakan oleh teman kita tersebut pada folder modules/ dengan demikian maka didalam folder modules/ sekarang ada dua folder, yaitu produk dan user. Singkatnya seperti itu.

Sampai tahap ini terlihat simpel dan mudah ketika kita melakukan kerja dalam team. Nyatanya cerita pewayangan, eh salah, cerita software development model HMVC ini belum berhenti sampai disini.

Ketika ada suatu update-an file yang sifatnya tidak spesifik pada modul, maksud saya adalah perubhan diluar folder modul, maka pada saat itu bentrok update-an akan bermunculan. Misalkan saya mengedit file style.css pada folder CSS/, maka ketika ada orang lain yang juga mengupdate file style.css tersebut dan ditimpakan pada folder CSS makan akan menimpa kepunyaan saya tadi. Dengan demikian model kolaborasi ini tidak efektif jika tidak ada komunikasi yang intens, sayangnya, kebanyakan programmer pada umumnya enggan berkomunikasi tentang update-an yang seperti ini. Kebanyakan hanya main replace-replace aja tanpa peduli versi baru file tsb. Akibatnya, ini akan menjadi bencana yang tak akan pernah reda.

Masalah lain yg timbul. Masalah lainnya adalah, jika dalam folder modul kita mengupdate file yang sama. Misalkan si A da si B bertugas mengerjakan module produk pada PC nya masing-masing. Ketika salah satu akan melakukan update source code, maka masing-masing akan saling menimpa file yang telah dibuat. Lagi-lagi tanpa komunikasi dari keduanya maka semua ini hanya akan menjadi spageti monster, alias kodingan yang acak-aduk amburadul. Dan lagi-lagi, kebanyakan enggan untuk berkomunikasi.

HMVC adalah Design Patern, bukan Source Code Management, jadi jangan disamakan fungsinya. Jangan disamakan fungsi Gelas dan Pisau, jenisnya saja beda, yg satu alat untuk minum yang satu alat untuk mengiris. Apalagi kategorinya, gelas teh dan pisau lipat, apa pun kategorinya, keduanya tidak bisa disandingkan untuk dijadikan pengganti. Begitu juga dengan HMVC dengan misalkan GIT atau Mercurial atau sejensnya.

HMVC design patern, tidak bisa menggantikan GIT, Mercurial, SVN dll yang jenisnya adalah Source Code Management.

Saya pernah terpaksa menggunakan HMVC sebagai pengganti Source Code Management, karena ikut aturan main team.

Berdasarkan pengalaman saya HMVC tidak bisa efektif untuk dijadikan pengganti Source Code Management, karena HMVC tidak diciptakan untuk itu dan HMVC pun bukan “itu” (Source code Management).

HMVC = Design Patern
Git, Mercurial, SVN, Bazzar dll = Source Code Versioning
Github, Gitlab, Bitbucket = Source Code Repository untuk Source Code Versioning

Design Patern tidak bisa dibandingkan dg Source Code Versioning
(Design patern itu banyak jenisnya, pada umumnya orang cuma kenal MVC dan HMVC)

Semoga artikel ini berguna. Terimakasih.

Baca artikelnya dulu dari awal paragraf hingga akhir paragraf, baru boleh komentar ya…

Software Development: Pentingnya menggunakan framework yang mainstream

Pada artikel ini saya mau mencoba menjelaskan, pentingnya menggunakan framework yang mainstream.

Sebelum saya menjelaskannya, berikut ini saya berikan suatu kasus dimana project berjalan lambat karena kurang mengikuti mainstream.

Katakanlah ada suatu perusahaan A, perusahaan ini mengerjakan sebuah project untuk suatu aplikasi. Selama dalam tahap developmentnya, mulai awal pembuatan aplikasi tersebut, perusahaan tersebut membuat sendiri struktrur kode program atau membuat library sendiri. Ok, membuat struktur ataupun library sendiri adalah suatu nilai plus, karena secara internal berarti perusahaan tersebut punya standar sendiri. Namun bagaimana jika standar tersebut adalah sesuatu yang jauh dari standar Software Development pada umumnya (dibilang design patern juga bukan).

Bagi programmer yang membuat struktur sendiri tersebut tentu merasa nyaman menggunakannya, karena dia yang membuat sendiri maka dia paham bagaimana menggunakannya. Namun bagaimana jika ada programmer baru yang ikut bergabung mengembangkan aplikasi yang digunakan menggunakan struktur standar internal tersebut, tentu akan dibutuhkan banyak waktu dan tenaga. Butuh waktu untuk menjelaskan bagaimana menggunakannya, dan juga butuh tenaga untuk menjelaskan. Bagaimana sendainya standar struktur program tersebut tidak didokumentasikan secara profesional seperti layaknya pendokumentasian software development? Ini akan lebih membingungkan lagi, karena programmer baru tersebut tidak memiliki referensi sebagai pegangan sehingga ketika programmer baru tersebut menemukan masalah perihal penggunaan struktur program tersebut makan mau tidak mau programmer baru tersebut haru bertanya kepada programmer pembuat struktur program. Bagaimana jika programmer pembuat struktur program itu berhalangan untuk bekerja atau malah keluar/pindah? Pastilah ini akan menjadi ancaman dan menjadi ketergantungan yang besar.

Solusinya:

Gunakanlah framework yang mainstream, yaitu framework yang telah dikenal luas dan telah digunakan oleh banyak programmer, memiliki dokumentasi yang banyak dan lengkap, memiliki support komunitas yang banyak, stabil, dan segala macamnya…

Dengan menggunakan framework yang mainstream ini, jika ada programmer baru yang akan bergabung mengembangkan aplikasi yg sedang dikerjakan, maka kita tinggal bertanya pada programmer tersebut, apakah kamu bisa menggunakan framework ini? apakah pernah implementasi? dan lain sebagainya.

Jika programmer tersebut masih belum terlalu mahir, programmer tersebut bisa mencari bahan referensi berupa dokumrntasi, vidoe tutorial, buku atau malah bisa bertanya dg komunitas melalui forum, toh frameworknya sudah terkenal.

Nah sekarang timbul pertanyaan, bagaimana jika membuat framework sendiri? Apakah tidak boleh?

Jawabannya adalah boleh dan bahkan sangat boleh! Namun dengan catatan:

– Jika mau membuat framework sendiri, tentukan arsitekturnya, apakah MVC atau apa. Ini akan mempermudah si pengguna nantinya, jika menggunakan MVC misalkan, maka penggunakan akan tahu oh ini menggunakan MVC. Jika anda mengarang sendiri (tidak mengambil dari salah satu jenis software architecture) maka pengguna akan bingung terhadap, apa yg sebenarnya dia pakai.

–  Dokumentasikan framework tersebut dengan detail, lengkap dan rapih. Ini bertujuan untuk memberikan referensi bagi calon pengguna sekaligus untuk memantau fitur-fitur apa saja yang akan dikembangkan, diperbaiki atau bahkan dihilangkan.

– Publikasikan, lebih bagus lagi jika dipublikasikan, dibuat menjadi opensource, sehingga akan menambah pemngguna dan juga pengembang framework tersebut. Namun jika ingin private, tidak perlu dipublish juga tidak apa-apa.

Bagi saya ketiga poin tersebut cukup bisa membantu untuk mengurangi resiko ketika memang harus membuat framework sendiri.

Membuat framework sendiri juga bukan hal yang salah, toh beberapa framework yang terkenal pun awalnya berasal dari framework yang dipakai di lingkungan sendiri. Namun perlu diingat, jika anda membuat framework sendiri berarti anda akan membutuhkan lebih banyak tenaga, waktu dan biaya. Dan kebanyakan, para perusahaan besar lah yang membuat framework sendiri, itu pun kemudian di-open.

Demikian pendapat saya, semoga bermanfaat.

Code Sprint – Ngoding secara ekstrim

Anda pernah mendengan Code Sprint?
Sudah? Bagus..
Belum? Penasaran? Simak artikel saya ini.

Jika anda adalah seorang yang berkecimpung dalam dunia IT / mempelajari IT terutama Software Development, pasti anda sering mendengar atau menggunakan kata ngoding. Ya benar, ngoding adalah istilah non formal yang berarti membuat program, atau menulis source code. Ketika seorang membuat aplikasi, dan menuliskan source code menggunakan bahasa pemrograman tertentu, maka dia disebut sedang ngoding.

Tidak apa, jika anda bukan orang IT. Tak ada salahnya untuk tahu bukan? 🙂

Terus, apa itu Code Sprint?

Gampangnya orang ngomong, Code Sprint adalah balapan ngoding. Atau balapan membuat aplikasi. Simpelnya seperti itu.
Kalau lebih detailnya, Code Sprint ini adalah suatu aktivitas membuat program atau menulis source code secara CEPAT… Para penganut XP (Extreme Programming) sangat dekat dengan istilah Code Sprint ini. Dengan team yang kecil cuma beranggotakan beberapa orang. Mereka membuat suatu aplikasi / program / software secara ‘pecicilan’ hehe istilah apa ini pecicilan. Sangkin ekxtrimnya, dalam 1 malam seorang coder Code Sprint ini bisa membuat aplikasi utuh yang berkualitas bagus. Yang biasanya dibuat oleh programmer biasa selama berhari-hari. Wowww… menakjubkan yah 🙂

Code Sprint juga bisa berarti suatu acara, ya, bisa mengacu pada suatu acara. Acara yang namanya Code Sprint. Apa isi acara tersebut? Tidak lain dan tidak bukan, adalah acara kumpul bersama antara programmer terutama penganut Extreme Programming untuk membuat aplikasi yang disepakati. Bisa team, atau individu. Mereke berlomba membuat suatu aplikasi / software (sesuai teme.judul yg telah ditentukan) hanya dalam 1 malam!!! Ada banyak kriteria penilaian tentunya, tapi yg jelas adalah cepat dan benar!

Kira-kira seperti itu cerita yang bisa saya bagi. Btw materi ini tidak ada di perkuliahan ataupun di toko buku. Jadi jangan mencarinya di toko buku ya? 🙂 hehehe…