Joel on Software   Pojok Software Joel

Artikel-artikel "Joel on Software" lain dalam bahasa Indonesia

Artikel-artikel "Joel on Software" lain dalam bahasa Inggris

Email pengarang (hanya dalam bahasa Inggris)

Pada tahun 1982, keluarga saya mengambil barang kiriman sebuah IBM-PC pertama di Israel. Kami sampai turun ke gudangnya dan menunggu PC kami dibawa dari pelabuhan. Dengan berbagai cara, saya menyakinkan ayah saya untuk membeli versi yang bertingkat, dan dua buah printer, sebuah printer dot-matrix (untuk yang cepat) dan sebuah printer Daisy Wheel kualitas surat merek Brother, yang berbunyi mirip sekali dengan senapan mesin saat beroperasi, tapi lebih berisik. Saya pikir kami sudah membeli hampir semua asesori yang tersedia: PC-DOS 1.0, manual referensi teknis seharga $75 dengan daftar source code lengkap untuk BIOS, Macro Assembler, dan layar IBM Monochrome yang keren dengan 80 kolom penuh dan... huruf kecil semua! Semuanya itu berharga $10,000 termasuk pajak import di Israel yang tidak masuk akal. Luar biasa!

Sekarang, “semua orang” tahu bahwa BASIC merupakan bahasa anak kecil yang mengharuskan anda menulis kode seperti bakmi dan menjadikan otak anda seperti keju Camembert. Jadi kami membeli IBM Pascal seharga $600, yang berupa 3 disket floppy. Kompilasi pertama ada pada disket 1, kompilasi kedua ada pada disket 2, dan linker ada pada disket 3. Saya menulis sebuah program sederhana “hello world” dan meng-kompilasi-kannya. Total waktu yang dibutuhkan: 8 menit.

Hmm. Itu merupakan waktu yang lama. Saya menulis sebuah batch file untuk meng-otomatis-kan proses tersebut dan memangkas waktunya menjadi 7 ½ menit. Lumayan. Namun saat saya mencoba menulis program yang panjang seperti Othello saya yang keren yang selalu mengalahkan saya, saya menghabiskan sebagian besar waktu saya untuk kompilasi. “Ya, “ seorang programmer professional mengatakan kepada saya, “kami biasanya meletakkan sebuah papan sit-up di kantor dan melakukan sit-up ketika sedang kompilasi. Setelah beberapa bulan melakukan programming, saya mempunyai otot perut yang menakutkan.”

Suatu hari, sebuah program yang keren bernama Compas Pascal muncul dari Denmark, yang dibeli oleh Philippe Kahn dan diubah menjadi Borland Turbo Pascal. Turbo Pascal merupakan sebuah kejutan, karena dia bisa melakukan segalanya yang bisa dilakukan oleh IBM Pascal, namun dia hanya memerlukan 33K memori termasuk text editor. Bukan hanya itu. Yang lebih mencengangkan adalah sebuah kenyataan bahwa anda bisa melakukan kompilasi sebuah program kecil dalam waktu kurang dari 1 detik. Ini seperti jika sebuah perusahaan yang belum pernah anda dengar sebelumnya memperkenalkan mobil Buick LeSabre yang bisa berlari 1,000,000 Km per Jam dan dapat mengelilingi dunia dengan bensin yang sebegitu sedikitnya sehingga dapat diminum oleh semut tanpa membuat dia mabok.

Tiba-tiba saya menjadi sangat lebih produktif.

Kala itu adalah saat saya belajar tentang konsep lingkaran REP. REP singkatan dari “Read, Eval, Print” (baca, proses, tampilkan), dan hal itu menjelaskan apa yang dilakukan oleh sebuah interpreter: dia “membaca” input anda, evaluasikan, dan tampilkan hasilnya. Sebuah contoh dari lingkaran REP adalah seperti ini: Saya mengetik sesuatu dan interpreter membacanya, mengevaluasi, dan menampilkan hasilnya.

Pada skala yang sedikit lebih besar, saat anda menulis program, anda sedang berada pada sebuah lingkar REP bernama lingkar Edit-Compile-Test. Anda edit kode anda, kompilasikan, dan uji, dan lihat bagaimana dia bekerja.

Hal yang penting di sini adalah anda perlu menjalankan lingkaran tersebut berulang-ulang untuk menulis sebuah program, dan disebutkan bahwa semakin cepat lingkar Edit-Compile-Test, semakin produktiflah anda, dibatasi oleh batas kecepatan alamiah proses kompilasi. Itu adalah alasan formal mengapa programmer komputer menginginkan hardware yang sangat cepat dan pembuat compiler akan melakukan apa pun yang bisa dilakukan untuk menghasilkan lingkar Edit-Compile-Test yang super cepat. Visual Basic melakukannya dengan melakukan parsing dan lex-ing setiap baris saat anda ketik, sehingga kompilasi akhir akan menjadi sangat cepat. Visual C++ melakukannya dengan kompilasi bertingkat, header yg dikompilasi dulu, dan linking bertingkat.

Namun segera setelah anda mulai bekerja di sebuah tim yang lebih besar dengan banyak programmer dan tester, anda akan mengalami pengulangan yang sama lagi, namun lebih besar (bentuk fractal). Seorang tester menemukan bug di kode, dan melaporkan bug tersebut. Programmer memperbaiki bug tersebut. Berapa lama waktu yang dibutuhkan sebelum tester mendapatkan versi kode yang telah diperbaiki? Pada beberapa organisasi pengembangan, lingkar Report-Fix-Retest ini akan memakan waktu beberapa minggu, yang berarti seluruh organisasinya berjalan dengan tidak produktif. Untuk menjaga agar seluruh proses pengembangan berjalan dengan mulus, anda perlu fokus agar bisa mendapatkan lingkar Report-Fix-Retest yang lebih singkat.

Sebuah langkah bagus untuk melakukan hal ini adalah dengan build harian. Build harian adalah sebuah build yang otomatis, setiap hari, dan lengkap atas semua cabang source yang ada.

Otomatis – karena anda menyiapkan kode untuk dikompilasi setiap hari pada waktu yang tetap, menggunakan cron job (di UNIX) atau scheduler service (di Windows).

Harian – atau lebih sering. Akan ada godaan untuk terus menerus melakukan build, namun mungkin anda tidak akan bisa, karena masalah kontrol source yang mana akan saya bicarakan sebentar lagi.

Lengkap – kemungkinannya adalah, kode anda mempunyai beberapa versi, beberapa operating system, atau versi high-end/low-end. Build harian perlu mem-build semua-nya. Dan perlu build semua file dari awal, tanpa mengandalkan kemampuan kompilasi bertahap dari compiler tersebut yang mungkin tidak sempurna.

Berikut beberapa keuntungan build harian:

1. Saat sebuah bug diperbaiki, tester mendapatkan versi yang baru dengan cepat dan dapat mengetes ulang untuk melihat apakah bug-nya telah benar-benar diperbaiki.

2. Pengembang dapat merasa lebih aman atas perubahan yang telah dibuat tidak merusak 1024 versi yang dihasilkan, tanpa perlu memiliki sebuah kotak OS/2 di atas meja mereka untuk diuji.

3. Pengembang yang memasukkan perubahan yang mereka lakukan sebelum build harian mengetahui bahwa mereka tidak akan “merusak build tersebut” -- artinya, sesuatu yang menyebabkan tidak ada yang bisa compile. Hal ini sama dengan Kematian Layar Biru bagi semua tim programming, dan sering terjadi bila seorang programmer lupa memasukkan sebuah file yang baru mereka buat ke dalam tempat penyimpanan. Build berjalan dengan baik di mesin mereka, namun saat diambil oleh orang lain, mereka mendapatkan kesalahan linker dan langsung berhenti seketika itu juga.

4. Group yang lain seperti marketing, pelanggan beta, dan yang lainnya yang ingin menggunakan produk yang belum matang dapat memilih sebuah build yang mereka ketahui cukup stabil dan terus menggunakannya untuk sementara waktu.

5. Dengan memelihara arsip dari semua build harian, saat anda menemukan sebuah bug baru yang sangat aneh, dan anda tidak tahu persis apa penyebabnya, anda dapat menggunakan pencarian binary di arsip yang lampau untuk menemukan kapan bug tersebut pertama kali muncul. Dikombinasikan dengan kontrol source yang baik, anda mungkin bisa mencari tahu check-in yang mana yang menyebabkan masalah tersebut.

6. Saat seorang tester melaporkan sebuah masalah yang dirasakan oleh programmer sudah diperbaiki, tester dapat mengatakan pada build yang mana masalah tersebut didapati. Lalu programmer mencari tahu kapan dia check in perbaikan itu dan mendapati apakah bug tersebut benar-benar sudah diperbaiki.

Bagaimana melakukan semua itu. Anda perlu sebuah server untuk build, yang mana merupakan komputer tercepat yang anda miliki. Tulis sebuah script yang akan mengambil salinan source code terkini yang lengkap dari tempat penyimpanan (anda menggunakan source control kan?) dan kemudian build, dari awal, setiap versi yang anda buat. Jika anda mempunyai sebuah installer atau program setup, build -kan juga. Apa pun yang anda kirim ke customer harus dihasilkan dari proses build harian. Letakkan masing-masing build ke dalam directory-nya sendiri, diberi nama sesuai tanggal. Jalankan script anda pada waktu yang pasti setiap hari.

• Sangatlah penting bahwa semua yang dilakukan untuk build akhir dikerjakan oleh script build harian, dari pengambilan kode sampai disimpan ke web server agar bisa di-download oleh umum( walaupun selama proses pengembangan, ini haruslah merupakan sebuah server test, tentu saja). Itu adalah satu-satunya cara untuk memastikan bahwa tidak ada proses build yang hanya “terdokumentasi” oleh satu orang saja. Anda tidak akan terjebak dalam sebuah situasi di mana anda tidak bisa merilis sebuah produk karena hanya Shaniqua yang tahu bagaimana caranya membuat installer dan dia ditabrak bis. Di tim Juno, satu-satunya hal yang perlu diketahui untuk membuat sebuah build dari awal adalah di mana build server-nya, dan bagaimana caranya untuk klik-ganda pada icon “Build Harian”.

• Tidak ada yang lebih memusingkan dibandingkan saat anda ingin merilis kode, dan hanya ada satu bug kecil , lalu anda memperbaiki bug kecil itu di build server dan rilis. Sebagai golden rule, anda hanya boleh merilis kode yang telah dihasilkan oleh sebuah build yang penuh dan bersih yang dimulai dari checkout yang lengkap.

• Ubah compiler anda ke level peringatan maksimum (-W4 di lingkungan Microsoft; -Wall di lingkungan gcc) dan minta mereka untuk berhenti jika mereka menemukan peringatan yang paling kecil sekalipun.

• Jika sebuah build harian gagal, anda harus mengambil resiko dengan menghentikan seluruh tim. Hentikan semuanya dan terus build ulang sampai berhasil. Dalam beberapa hari, anda mungkin memiliki lebih dari satu build harian.

• Script build harian anda harus melaporkan kegagalan, melalui email, kepada semua anggota tim pengembang. Tidaklah sulit untuk mengambil catatan “kesalahan” atau “peringatan” dan melampirkannya pada email tersebut. Script tersebut juga bisa nambahkan laporan status ke sebuah halaman HTML yang dapat dilihat oleh semua orang sehingga baik programmer maupun tester dapat dengan cepat menentukan build mana yang berhasil.

• Satu aturan yang kami ikuti pada tim Microsoft Excel, yang sangat efektif, adalah siapa pun yang menggagalkan build tersebut harus bertanggung jawab menjaga build tersebut sampai orang lain merusaknya lagi. Hasil sampingan atas insentif yang pintar ini untuk menjaga build terus bekerja adalah, hampir semua orang secara bergiliran mendapatkan pekerjaan sebagai buildmaster sehingga setiap orang belajar bagaimana build tersebut dihasilkan.

• Jika tim anda bekerja dalam zona waktu yang sama, saat yang bagus untuk melakukan build adalah saat makan siang. Dengan demikian setiap orang check in kode terakhirnya sesaat sebelum makan siang, build-nya berjalan selagi mereka makan siang, dan saat mereka balik lagi, jika build-nya gagal, semua orang sudah berkumpul di situ untuk memperbaikinya. Segera setelah build-nya berhasil, semua orang dapat mengambil versi terakhir tanpa keraguan mereka akan terganggu dengan build yang gagal.

• Jika tim anda bekerja dalam dua zona waktu, jadwalkan build hariannya sedemikian rupa sehingga orang yang di satu zona waktu tidak mengganggu orang di zona waktu yang lain. Pada tim Juno, orang di New York akan memasukkan kode pada jam 7 malam waktu New York dan pulang. Jika mereka merusak build-nya, di Hyderabad, tim India akan masuk kerja (sekitar pukul 8 malam waktu New York) dan tidak bisa bekerja sepanjang hari. Kami mulai melakukan 2 build harian, sekitar satu jam sebelum anggota tim pulang ke rumah, dan menyelesaikan semua masalah yang muncul.

Untuk bacaan lebih lanjut:

• Beberapa diskusi tentang alat untuk build harian

• Karena build harian sedemikian pentingnya sehingga ia merupakan satu dari 12 langkah untuk kode yang lebih baik.

• Ada banyak hal menarik tentang build (mingguan) yang dilakukan oleh tim Windows NT di bukunya G. Pascal Zachary Showstopper.

• Steve McConnell menulis tentang build harian di sini.