Dua puluh tahun lalu, saya bekerja di bidang teknologi, sepuluh tahun kemudian saya menempati posisi manajerial, dan sekarang saya telah kembali ke teknologi lagi, kali ini sebagai konsultan. Beberapa perubahan membuat saya sangat bahagia, sementara yang lain sama mengejutkan saya. Di bawah ini saya akan secara singkat berbicara tentang hal-hal utama yang hampir membunuh saya di puncak kehidupan.
Bagus dulu: Unix dan pengembang bersatu kembali
Sepanjang 1980-an dan awal 1990-an, sebagian besar pengembangan perangkat lunak profesional dilakukan pada workstation Unix yang mahal seperti Sun Sparc atau NeXT. Pada tahun sembilan puluhan, pasar ditangkap oleh WinTel dan semua orang mulai membuat kode pada Windows menggunakan alat dari pemasok besar seperti MS Visual Studio, atau beberapa opsi gratis seperti Eclipse. Linux saat itu masih dianggap sesuatu yang lebih bagi para penghobi di dunia desktop.
Pada 2001, saya bekerja di sebuah startup. Hanya ada satu pengembang Linux untuk seluruh tim kami, dan dia mengalami kesulitan saat memutuskan akses ke alat kontrol versi dan klien email Outlook. Dia biasanya mengirimi kami kode melalui surat dan meminta untuk mengisinya. Saya ingat bahwa saya sendiri menggunakan XEmacs saat itu - eh, masa lalu yang indah.
Maju cepat hingga saat ini. Unix telah menjadi platform yang sangat populer di kalangan pengembang, terutama yang menggunakan Mac, karena ia menggunakan kernel Unix. Selain itu, ada yang namanya Linux di Windows. Dalam hal ini, tidak seperti banyak orang lainnya, kembalinya saya ke TI tidak penuh dengan kesulitan. Lucunya, banyak kolega muda saya sekarang hampir tidak bisa mengelola Windows, dan di Linux mereka merasa jauh lebih percaya diri.
Manajemen rilis tidak lagi menjadi profesi
Dahulu kala, bercabang, menggabungkan, dan menyelesaikan konflik adalah pekerjaan berat yang sering kali membutuhkan intervensi dari spesialis rilis yang berdedikasi. Pada hari-hari ketika ClearCase menguasai pasar kontrol versi, ada cukup pekerjaan garpu, penggabungan, dan rilis untuk tim besar - setidaknya dalam pengalaman saya di HP pada tahun 2002.
Ide bahwa seorang pengembang dapat mengirimkan permintaan perubahan sendiri sebenarnya cukup muda. Rupanya, dia diberi permulaan transisi pengembangan ke Linux dan gelombang baru sistem kontrol versi terdistribusi: BitKeeper, Git, dan seterusnya. Sistem lama seperti ClearCase, CVS, SVN, atau PerForce tidak memiliki kemampuan untuk membuat perubahannya sendiri sehingga akan tercermin pada semua orang yang terlibat dalam alur kerja. Entah pemilik repositori yang melakukannya, atau orang yang bertanggung jawab atas manajemen rilis, atau setiap pengembang mengatur semuanya untuk dirinya sendiri. Sekarang prosesnya telah sangat disederhanakan, dan sekarang dimungkinkan untuk membangun kerja bersama dalam sebuah tim tanpa peserta tambahan.
Di mana tim QA? Pengujian unit dan integrasi berkelanjutan
Saya pertama kali mendengar tentang pengujian unit dan integrasi berkelanjutan dari Kent Beck, salah satu penulis Agile Manifesto dan pencipta metodologi pemrograman ekstrem . Dua puluh tahun yang lalu, ide-idenya revolusioner, tetapi mereka tidak segera mencapai status standar dalam pembangunan yang mereka miliki sekarang.
Menurut saya, sayang sekali tidak ada lagi penekanan pada integrasi berkelanjutan di Agile dan Scrum. Tetapi saya sudah senang bahwa praktik ini menjadi sangat populer saat ini. Saya menghadiri konferensi itu dan saya ingat Joshua Bloch, penulis Java Collections, naik ke atas panggung untuk berbicara tentang integrasi berkelanjutan, dan dia berkata, "Terima kasih (Agile atau JUnit) karena telah memberikan pesona integrasi berkelanjutan." Dan dia benar. Dulu, tes menulis dianggap membosankan, dan hanya sedikit orang yang melakukannya. Oleh karena itu, bos mempekerjakan orang-orang khusus, insinyur QA, yang mencari kesalahan bagi para pengembang! Gila, lafa itu ...
Pengujian unit dan integrasi berkelanjutan hampir menghilangkan kebutuhan akan orang-orang seperti itu - sekarang pengembang bertanggung jawab untuk menulis pengujian itu sendiri, dan infrastruktur integrasi berkelanjutan meluncurkan semuanya tepat waktu dan melaporkan kesalahan. Ini membuat perangkat lunak lebih andal dan memperpendek siklus pengembangan. Selain itu, inovasi membantu pengembang untuk mendapatkan pandangan yang lebih holistik tentang berbagai hal dan mempelajari cara menulis kode sehingga dapat dengan mudah diuji.
Docker: tidak ada lagi kekacauan dalam proses produksi
Container, yaitu Docker, telah menghapus semua hal yang tidak perlu dari manajemen paket dan meminimalkan masalah lingkungan yang muncul saat kode melewati pengujian dan masuk ke produksi. Namun sebelumnya, Anda harus mendapatkan insinyur DevOps yang baik untuk menyiapkan ekosistem Docker.
Di masa lalu, kebetulan sistem dibuat di lingkungan yang sama sekali berbeda di mana ia seharusnya digunakan (yah, yaitu, misalnya, mereka menulis kode di Windows dan digunakan di Unix). Ini pasti menyebabkan bug dan menumpuk pekerjaan tambahan di setiap siklus rilis pengujian.
Selain itu, di masa lalu, spesialis rilis, pengujian, atau DevOps akan mengambil kode dari tag di kontrol sumber dan memutuskan apa yang harus dilakukan dengan kompilasi, pengujian, dan migrasi. Biasanya, ini akan mengungkapkan sejumlah besar jalur dan variabel berkode keras, pustaka dan file yang hilang yang perlu dikerjakan ulang atau diubah agar berfungsi dengan benar.
Docker menyederhanakan proses dan menciptakan kondisi untuk integrasi berkelanjutan dan penerapan berkelanjutan dengan, sekali lagi, menyerahkan fungsi yang relevan ke tangan pemrogram.
Open Source: Terlalu Banyak Kemungkinan
Di dunia perangkat lunak open source, pilihannya sekarang, terus terang, berlimpah. Saya sedang menyiapkan Jenkins di sini dan ingin berintegrasi dengan BitBucket. Pencarian plugin untuk "bitbucket" menghasilkan lebih dari empat ratus hasil, banyak di antaranya adalah open source.
Ini menciptakan dua masalah:
- Lebih sulit untuk memilih dari banyak opsi
- Dengan kelimpahan seperti itu, beberapa instrumen pasti akan mati dan dukungannya akan terhenti.
Tetapi ada juga kelebihannya: hampir tidak perlu membuat infrastruktur dan alat dasar sendiri - temukan apa yang Anda butuhkan dari yang sudah jadi, dan gunakan. Dua puluh tahun yang lalu, Anda harus menulis perpustakaan dan struktur data untuk operasi yang paling umum, dan itu bahkan menyenangkan di suatu tempat. Saat ini, ada begitu banyak pustaka dan kerangka kerja yang berbeda untuk setiap bahasa sehingga 99% pengembang dapat hidup tanpa menulis satu pohon B, atau tabel hash, atau bahkan konektor OAuth.
Agile dan Scrum telah menguasai dunia
Dua puluh tahun yang lalu, Agile sudah hidup dan sehat (Agile Manifesto dirilis pada 2001), tetapi popularitasnya mulai tumbuh belakangan - termasuk di luar IT, dan terkadang dalam bentuk yang terdistorsi. Ia menjadi pepatah favorit di kalangan eksekutif: "Bisnis harus tetap gesit, jika tidak maka tidak akan bertahan."
Saya ingat saat-saat siklus rilis berlangsung cukup lama (tiga bulan, dan ini dalam permulaan). Setelah kembali dari pertemuan, di mana dia mengurai spesifikasi baris demi baris, pengembang dapat duduk di meja dan diam-diam bertaruh selama beberapa minggu tanpa khawatir dia harus melaporkan bagaimana keadaannya. Dan sekarang setiap hari aksi berdiri, setiap dua minggu sprint - Anda tidak bisa benar-benar bersantai!
Agile juga mendistribusikan kembali fungsi administratif - sekarang pengembang berkomunikasi langsung dengan pengguna atau manajer produk. Duduk diam tidak akan bekerja lagi. Karenanya, kemampuan berkomunikasi menjadi jauh lebih berharga dari sebelumnya.
Akhirnya, laju pembangunan telah dipercepat dengan Agile. Ini bahkan bukan tentang rapat stand-up dan usaha Scrum lainnya. Alat itu sendiri mulai menghemat waktu kami: papan tulis di Jira, permintaan perubahan, alat untuk pengembangan dan penerapan berkelanjutan - yang semuanya memungkinkan untuk bekerja lebih cepat. Di satu sisi, ini menambah kekhawatiran sehari-hari, dan di sisi lain, Anda merasakan keuntungan dari fakta bahwa Anda meluncurkan produk dalam waktu singkat dan menyelesaikan tugas secara komprehensif.
Akhirnya
Jika Anda juga meninggalkan TI dan berpikir untuk kembali, saya mendukung Anda dan berharap semoga sukses. Secara pribadi, saya dengan senang hati memperbarui keterampilan saya (meskipun saya hampir mati di sepanjang jalan). Prinsip dasar pemrograman tetap sama, jadi saya pikir saya akan berhasil. Namun perangkat telah banyak berubah, dan ini memengaruhi produktivitas.
Anda mungkin menemukan tema yang berulang dalam artikel tersebut: pengembang modern memiliki jangkauan tugas yang jauh lebih luas daripada dua puluh tahun yang lalu. Dia menulis kode, melakukan kontrol versi, menguji apa yang dia tulis, bekerja dengan container, dan sebagainya. Tentu saja, otak terkadang mendidih, tetapi Anda tidak perlu lagi membuat daftar tertaut sendiri.