Programming

Methodology / design pattern / development driven apa yang paling bagus?

Saat sedang melihat-lihat group programming di facebook, saya pernah melihat beberapa job opportunity dengan slogan seperti berikut: “Perusahaan kami menerapkan agile dan scrum!”. Banyak juga bahasan mengenai “agile” lebih baik dari waterfall, adalah metodologi terbaik. Tidak sedikit pula junior programmer atau analyst atau project manager baru di kantor-kantor yang bersikukuh bahwa team harus mulai menerapkan agile dan scrum. Hal yang sama juga berlaku pada TDD (Test Driven Development). Benarkah scrum + TDD adalah metodologi yang terbaik?

Sebelum saya melanjutkan dengan pembahasan yang lebih detail, akan menekankan hal yang menurut saya pribadi paling penting dalam pengembangan applikasi / system:

Pergunakan tools / cara apapun yang dirasa terbaik untuk menghasilkan applikasi yang bekerja dengan baik, dan mudah diubah. “Make it works, and changeable!”

Individuals and interactions over processes and tools

Salah satu manifesto yang cukup penting dan sering dilupakan dalam agile adalah “individuals and interactions over processes and tools“, atau bisa disingkat sebagai “people over process“. Sebagai programmer / developer / analyst, terkecuali kamu adalah ConcernedApe yang men-develop indie game “Stardew Valley”seorang diri dulunya, kamu akan bekerja dalam team, berinteraksi dan membuat keputusan-keputusan bersama.

Preferensi setiap orang berbeda-beda, dan metolodogi tertentu bisa bekerja di satu kelompok orang, bisa juga tidak berfungsi di kelompok orang lainnya. Bagaimana kamu dan team developer bisa bekerja dengan baik adalah yang terpenting, proses / metodologi adalah “alat bantu” yang bisa digunakan untuk mencapainya. “Scrum user story“, “Kanban board” tidak lebih dari hanya alat bantu untuk bekerja dalam team.

Bila dalam beberapa situasi tools tersebut tidak dapat digunakan dalam team, misalnya mayoritas tidak mengerti cara pakainya, atau tidak merasa ada manfaatnya, atau misalnya projectnya cukup kecil sehingga tidak diperlukan, maka carilah alternatif tools yang lebih dapat bermanfaat bagi team. Misalnya post-it notes di cubicle kerja masing-masing, atau minutes of meeting yang di-share dalam email, atau bug tracker.

Pernah saya berdiskusi dengan seorang project manager yang cukup berpengalaman, mengapa beliau tidak menerapkan daily standup meeting, yang umumnya adalah senjata pemungkas di scrum. Beliau menjelaskan bahwa teamnya bekerja secara remote di berbagai daerah yang berbeda, sehingga daily standup meeting tidak dapat dilakukan. Selain itu, tidak selalu ada hal yang dapat di-share dalam daily meeting, sehingga beliau menerapkan rule weekly report, dan contact langsung apabila ada (laptop, mouse rusak misal atau approval) yang diperlukan. Itu adalah contoh “people over process“.

Management juga tidak akan serta merta mengubah metodologi yang sedang berjalan secara tiba-tiba, untuk mengadopsi scrum secara mendadak. Perubahan itu terlalu beresiko, apabila team tidak terbiasa dan banyak yang tidak mengerti, maka perubahan hanya akan membawa musibah daripada manfaat. Terkecuali memang ada kebutuhan untuk meningkatkan metodologi development, jangan memaksa management untuk berubah demi ego sendiri atau “hanya karena scrum lebih baik”.

Metodologi sebaik apapun tidak akan berguna bila team tidak dapat menghasilkan applikasi yang berfungsi dengan baik

Scale it!

Salah satu hal yang menarik yang saya cermati adalah tidak banyak orang yang menyadari bahwa metodologi yang berbeda bisa diterapkan dalam skala yang berbeda pula, dalam satu organisasi. Misalnya project manager dan customer menggunakan iterative waterfall untuk memecah-mecah feature development ke dalam project-project, sebagai team bisa saja development dilakukan secara agile / scrum.

Atau hingga dalam skala personal sebagai programmer, kamu bisa saja memecah task list yang diberikan menjadi iterasi2 yang bisa menghasilkan feedback dalam 2 minggu (iterasi standar scrum), dan melaporkannya ke project manager / team lead secepatnya.

Don’t forget to make it changeable!

Saya berani bertaruh, tidak ada development plan / requirement yang tidak berubah saat development. Perubahan requirement adalah sangat wajar dan sangat mungkin terjadi. Di luar negosiasi finansial yang memang bukan ranah developer, mengembangkan applikasi agar bisa mudah diubah-ubah sesuai dengan perubahan requirement adalah penting. Applikasi yang mudah diubah juga penting agar dapat menambahkan fitur dengan mudah di kemudian hari. Hal ini juga tersirat dalam agile manifesto, “Responding to change over following a plan“.

Lalu bagaimana dapat mengembangkan applikasi yang mudah dikembangkan / diubah? Salah satunya adalah dengan membuat “low coupling, high cohesion” modul (class / function). Dan TDD dapat membantu mengembangkan kode yang low coupling tersebut. Namun dengan efek samping development time yang meningkat hingga 2x dari biasa dan kompleksitas dalam unit test, tidak semua team dapat menggunakan TDD (namun pastikan menggunakan TDD bila memungkinkan).

Ada 2 pemahaman lain yang juga dapat membantu mengembangkan kode “low coupling high cohesion”, yaitu Single Responsibility Principle, dan Dependency Injection. Keduanya adalah bagian dari SOLID principle, yang menurut saya lebih bermanfaat dari ke-3 pemahaman lain dari SOLID principle.

Conclusion

Pergunakan development method yang paling cocok dan bermanfaat untuk team. Kembangkan applikasi yang berfungsi, bisa digunakan dan mudah untuk diubah. Kembangkan kode yang “Low coupling High cohesion” agar applikasi dapat diubah dengan lebih mudah.

Advertisements

Node await is synchronous

Starting from node 8, or node 6 with babel, we can use a feature named async await. It makes programming asynchronous code in synchronous way. For example, let’s say a function getNumberis returning Promise with resolve, we can call the function using await like this:

async function processNumber(){
  var number = await getNumber();
  number = number + 2;
  return number;
}

Async function will always return Promise, even though it isn’t described in code. Pretty neat huh, now that we can treat the promise as function that return something (synchronously). However, as I had previously assumed, await statement is executed synchronously.

I am using the test scripts at the following github repository. The code in app.js is using Promise.all, while the code in app2.js is using async await. In both code, they will execute same function, called execThings.

var execThings = function(i){
	return new Promise(function(resolve){
		var curIndex = i;
		setTimeout(function(){
			console.log(curIndex, model);
    		resolve(model.num++);
		}, 120 - ((i * i) - (2 * i) + 5));
    });
};

This function is accepting a numeric parameter, then it will resolve an incrementing number, defined in model.num. For the sake of some randomness and asynchronous process, I use setTimeout with randomized timeout based on input argument. When executed, here is one of the result:

12 { num: 0 }
13 { num: 1 }
14 { num: 2 }
15 { num: 3 }
16 { num: 4 }
17 { num: 5 }
18 { num: 6 }
19 { num: 7 }
11 { num: 8 }
10 { num: 9 }
9 { num: 10 }
8 { num: 11 }
7 { num: 12 }
6 { num: 13 }
0 { num: 14 }
5 { num: 15 }
1 { num: 16 }
4 { num: 17 }
3 { num: 18 }
2 { num: 19 }
[ 14, 16, 19, 18, 17, 15, 13, 12, 11, 10, 9, 8, 0, 1, 2, 3, 4, 5, 6, 7 ]

The top list is the log for each promise when executed. The bottom array is the Promise.all result. As we can see here, that Promise.all is executing all functions simultaneously, because the log is in unordered index. But the result is sorted according to executed promise. In the result, index 0, with value 14 is also in index 0 of Promise.all result. Index 1, same with result index, valued 16, and so on.

Now when executing app2.js (I’m using babel due to still using node 6), the result is:

0 { num: 0 }
1 { num: 1 }
2 { num: 2 }
3 { num: 3 }
4 { num: 4 }
5 { num: 5 }
6 { num: 6 }
7 { num: 7 }
8 { num: 8 }
9 { num: 9 }
10 { num: 10 }
11 { num: 11 }
12 { num: 12 }
13 { num: 13 }
14 { num: 14 }
15 { num: 15 }
16 { num: 16 }
17 { num: 17 }
18 { num: 18 }
19 { num: 19 }
[ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 ]

As we can see here, async await is executed in synchronous process. The index is sorted neatly and the result is also as expected. And when executing the app2.js, it takes around 5 seconds, due to waiting for timeout delay. Meanwhile app.js is executed in up to 1 second.

Conclusion

Despite being very convenient, be aware that async await feature in node 8 or above (or babel) is being executed synchronously. Meanwhile the more complex Promise.all is execute the same process asynchronously. If you have a long-running process that need to be executed in parallel, Promise.all is the answer. However if you certain that the process is still very fast when executed synchronously, it’s okay to use async await since it’s more readable.

Again, you can get the complete test scripts in this  github repository.

Kuliah IT tidak berguna? Betulkah?

Pagi ini saya sempat membaca satu artikel yang cukup menarik, mengenai 4 alasan yang membuat kuliah IT tidak berguna. Sebelum saya membahasnya, perlu saya ingatkan bahwa gelar sarjana atau S1 komputer cukup menjadi faktor penting atau bahkan faktor utama diterimanya bekerja di Indonesia sebagai programmer.

Gelar S1 Komputer (Sarjana Komputer)

Kemungkinan terbesar seseorang berniat menjalani dan menyelesaikan perkuliahan adalah untuk mendapatkan gelar S1. Minimal, gelar s.komp berlaku di perusahaan-perusahaan besar yang bidang usaha utamanya bukan di IT. Misal perbankan dan finansial sejenisnya, exportir-importir besar, perusahaan perminyakan, perusahaan produksi seperti mi instant dan lainnya. Startup-startup baru sepertinya lebih longgar mengenai gelar s1 saat perekrutan programmer.

Sepertinya bagus untuk dilakukan survey, untuk mencari tahu seberapa relevan gelar S1 komputer sebagai programmer saat ini.

Algoritma, analisa dan soft skill

Ada hal-hal yang tidak bisa diperoleh hanya dengan mempelajari pemograman saja dari internet, di antaranya algoritma, analisa, soft skill dan pengetahuan mengenai sistem. Perlu pengalaman dan latihan sendiri untuk mengasah kemampuan-kemampuan itu. Mungkin tidak tampak saat coding, bahwa skill-skill tersebut cukup besar manfaatnya dalam pengembangan sistem.

Tahukah anda, bahwa ada beberapa faktor yang menjadi tolak ukur kualitas system? Ini adalah beberapa di antaranya. Tahukah anda apa itu SDLC (Software Development Life Cycle)? OOAD (Object Oriented Analysis and Design)? Algoritma bubble sort, linked list, recursive? Soft skill seperti cara presentasi, komunikasi, kerja group dan diskusi. Banyak skill tersebut yang mungkin tidak anda kenal bila hanya mempelajari pemograman saja, tetapi diajarkan di universitas.

Note: skill-skill di atas berdasarkan pada pengalaman saya saat kuliah S1 Sistem Informasi di Bina Nusantara (BINUS).

Unit Kegiatan Mahasiswa (UKM), koneksi dan networking

Perkuliahan tidak hanya belajar saja. Koneksi, relasi dan networking bisa dibangun selama perkuliahan. Bisa saja anda menemukan partner yang tepat untuk membangun startup selama masa kuliah. Atau bisa saja menemukan pasangan hidup :).  UKM-UKM di universitas sangat berguna dan memberi pengalaman yang baik seperti mengatur seminar / acara, berhubungan dengan orang-orang yang bisa saja berpengaruh (seperti CEO startup atau pembicara), dan sekali lagi networking. Memiliki banyak networking sangat bermanfaat di dunia profesional nantinya.

Secara pribadi, saya memang tidak mengikuti UKM saat kuliah dulu. Berkaca pada saat ini, saya sangat menyarankan para mahasiswa/i untuk mengikuti UKM yang berhubungan dengan profesi yang ingin digeluti nantinya, misal computer club, atau yang dapat mengembangan soft skill, seperti english club. Pengalaman dalam UKM juga dapat disertakan di CV (curriculum vitae) sebagai pendukung sertifikasi.

Dosen juga manusia

Gali ilmu dan pengalaman dosen

Dan yang perlu ditekankan, dosen (apalagi dosen senior) adalah orang yang sudah berpengalaman di bidangnya, dan sudah/sedang mengalami dunia profesionalisme.

Jangan menyamakan kuliah dengan sekolah, di mana anda datang ke kelas, mengikuti pelajaran yang diberikan lalu pulang. Buat relasi dengan dosen, gali pengalaman-pengalaman dosen dan cari tahu pandangannya mengenai dunia profesionalisme. Asah kemampuan di rumah dan diskusikan hambatan-hambatan yang anda temui saat bertemu dengan dosen, setelah selesai kelas misalnya.

Sesi bimbingan dengan dosen, misal saat skripsi, sangat berguna dan tidak boleh disia-siakan. Dapatkan ilmu sebanyak-banyaknya dari orang yang sudah berpengalaman.

Take a project

Masa-masa perkuliahan memiliki waktu luang yang sangat banyak. Jadwal kuliah seminggu mungkin hanya sekitar 40 jam. Libur semester genap saja bisa sampai 1 bulan. Waktu yang ada itu jangan disia-siakan. Anda bisa mengambil project berbayar, mengambil part time, atau melakukan hobby project untuk sekedar melatih ilmu. Pergunakan github atau public repository lainnya dalam hobby project, agar nantinya dapat disertakan di CV.

Bekerja paruh waktu dan kuliah malam juga biasanya menjadi pilihan untuk mengambil gelar di saat tetap produktif.

Sistem perkuliahan IT

Berhubungan dengan artikel awal, 4 alasan yang membuat kuliah IT tidak berguna, tidak dapat dipungkiri bahwa perkuliahan IT di Indonesia masih kurang maksimal. Point 3 yang berbunyi “BANYAK SARJANA KOMPUTER TIDAK MAMPU JADI PROGRAMMER, HANYA JADI INSTALLATOR” juga adalah fakta. Akhirnya mahasiswa perlu melakukan usaha lebih untuk menutup kekurangan-kekurangan dari tidak efektifnya sistem perkuliahan.

Di samping itu, faktor mahalnya biaya perkuliahan bisa dianggap menjadi hambatan, dan menurunkan pandangan orang terhadap nilai-nilai tambah yang bisa diperoleh dalam dunia perkuliahan.

Kesimpulan

Kuliah tidak berguna bila skill yang mau dikembangan hanya sebatas skill pemograman saja. Tetapi bila ingin berkarya di dunia profesional, satu skill pemograman saja biasanya tidak cukup. Perkuliahan dapat membantu, atau lebih tepatnya menyediakan jalan untuk melengkapi skill-skill tersebut.

Newbie? Baca ini dulu

“Liburan sebentar lagi nih, iseng-iseng mau belajar programming ah”

“Mau coba cara bikin website e-commerce nih”

“Mau coba pemograman android nih”

Mulai dari mana ya?

Pemula-pemula yang baru mau mulai masuk ke dunia programming / IT biasanya dipenuhi pertanyaan-pertanyaan seperti “bagaimana caranya”, “mulai dari mana”, “cari di mana”, “ada contohnya nggak” dan lain-lainnya. Sementara, sebagian besar programmer berpengalaman, yang sehari-hari kerjaannya nge-google nyari-nyari info dan solusi, rata-rata nggak suka dengan pertanyaan seperti itu. Rata-rata programmer memang harus bisa mandiri dan bisa cari (baca: google) solusi sendiri. Tapi pemula yang nggak ngerti apa-apa juga akan bingung mau cari apa. Maka dari itu, sebelum mulai bertanya ada baiknya baca petunjuk-petunjuk ini dulu:

(more…)