Siapakah Insinyur Perangkat Lunak? Rekayasa perangkat lunak VS pemrograman “hanya”.

Kami menyampaikan kepada Anda adaptasi artikel oleh Samer Buna tentang perbedaan antara rekayasa perangkat lunak dan pemrograman, atau bagaimana mengembangkan konsep perangkat lunak berbeda dari “hanya coding.” Semua insinyur perangkat lunak dapat membuat kode, tetapi tidak semua pemrogram dapat mengembangkan konsep perangkat lunak. Beberapa orang tidak menyukai istilah “Insinyur Perangkat Lunak” (alias Insinyur Perangkat Lunak) karena paling sering kita menggunakan kata “insinyur” ketika berbicara tentang sesuatu yang lebih bersifat fisik - konstruksi, misalnya. Artikel kami, tentu saja, bukan tentang istilah itu sendiri. Jika tiba-tiba hal itu membuat Anda ditolak, bisa dengan mudah diganti dengan sesuatu yang berhubungan dengan kreativitas. “Pembuat Perangkat Lunak”, “Penulis Perangkat Lunak”... atau bahkan “Pembuat Perangkat Lunak”! Kemampuan memprogram tidak serta merta menjadikan seseorang menjadi software engineer. Siapapun bisa belajar coding, dan ini jauh lebih mudah dari yang terlihat. Siapa pun dapat membuat program sederhana untuk digunakan sendiri, tetapi hal ini tidak menjamin bahwa program yang sama akan berfungsi untuk orang lain. Contoh favorit saya adalah ini: banyak dari kita bernyanyi di kamar mandi, namun sayangnya, pertunjukan ini tidak selalu layak untuk panggung profesional. Tentu saja, untuk pengalaman musik berkualitas tinggi, kemungkinan besar Anda akan beralih ke profesional. Apakah Anda memerlukan lebih banyak contoh?

• Kita semua belajar matematika dan menulis di sekolah, tapi itu tidak menjadikan kita ahli matematika dan penulis.
• Sebagian besar dari kita mampu menyiapkan hidangan yang lumayan dan terkadang sangat lezat, namun tidak semua orang berani menyiapkan meja untuk 100 orang untuk pesta makan malam kedutaan. Dalam hal ini, kami menyewa seorang juru masak.
• Apakah Anda siap saat ini untuk mempercayakan sepenuhnya pembangunan rumah baru Anda kepada anak tetangga yang menciptakan mahakarya Lego yang mengesankan?

Poin utama yang ingin saya sampaikan dalam artikel ini adalah bahwa program sederhana sangat berbeda dengan program yang dirancang oleh para insinyur. Definisi paling sederhana dari proses pemrograman: menyusun urutan tindakan komputer untuk mendapatkan sesuatu yang spesifik sebagai keluaran, dengan mempertimbangkan parameter masukan tertentu. Proses rekayasa perangkat lunak adalah desain, penulisan, pengujian, dan kurasi program komputer untuk memecahkan masalah bagi banyak pengguna. Ini tentang menciptakan solusi yang andal dan aman yang akan bertahan dalam ujian waktu dan mampu mengatasi beberapa tantangan yang mungkin tidak diketahui dan melampaui tantangan yang sudah jelas. Insinyur perangkat lunak mengetahui segalanya tentang masalah yang mereka selesaikan, solusi yang mereka usulkan, batasan solusi tersebut, privasi dan keamanan mereka. Menurut pendapat saya, jika seseorang tidak memahami esensi masalahnya, ia tidak boleh mulai memprogram solusinya.

Pola pikir teknik - mencari solusi terapan

Insinyur perangkat lunak tidak menganggap menulis perangkat lunak sebagai tujuan utama mereka. Mereka berpikir dalam rangka memenuhi kebutuhan dan memecahkan masalah . Hal ini penting karena tidak setiap masalah memerlukan solusi perangkat lunak. Beberapa di antaranya dapat diatasi dengan menggunakan program yang ada. Terjadinya beberapa masalah terkadang dapat diprediksi sebelumnya, dan dengan bantuan rancangan program yang kompeten, masalah tersebut dapat dihindari di masa mendatang. Masalah yang kompleks seringkali memerlukan penulisan banyak program. Ada tugas yang memerlukan aplikasi yang berjalan secara paralel, sementara yang lain memerlukan eksekusi beberapa program secara berurutan. Sejumlah masalah dapat diselesaikan hanya dengan melatih pengguna. Sebelum mulai membuat sebuah program, seorang insinyur perangkat lunak menanyakan beberapa pertanyaan pada dirinya sendiri:

• Masalah apa yang harus saya selesaikan?
• Apa lagi yang dapat Anda lakukan selain menulis kode untuk menyelesaikannya?
• Apa yang dapat saya lakukan untuk mempermudah tugas ini dengan aplikasi?

Kualitas program dan kualitas kode

Program yang bagus adalah program yang jelas dan mudah dibaca. Mereka mudah untuk diperluas, cocok dengan program lain, dan tidak akan menjadi mimpi buruk untuk dikerjakan. Kualitas kode tidak dapat dinegosiasikan. Seharusnya tinggi, itu saja. Saat mempertimbangkannya, alasan seperti suasana hati pembuat kode yang buruk atau tenggat waktu yang terlalu ketat (oh, tenggat waktu itu!) tidak dapat diterima. Salah satu aspek terpenting dalam pengembangan perangkat lunak adalah merancang program sedemikian rupa sehingga mudah dipelihara dan dimodifikasi di masa mendatang (halo, OOP!). Saat ini, hampir semua perangkat lunak dapat dimodifikasi, seringkali proses ini terjadi bahkan tanpa partisipasi pengguna atau tidak memerlukan apa pun dari pengguna selain “program Anda telah diperbarui, klik OK atau Tunda.” Tentu saja, pengguna berhak meminta fitur-fitur baru dari aplikasi (terutama jika kita berbicara tentang perangkat lunak perusahaan yang sudah berjalan lama dan ditulis dalam Java, atau game online yang dapat dimainkan selama bertahun-tahun). Sepotong kode saja tidak bisa disebut berguna. Fungsionalitas perangkat lunak yang berguna dimulai ketika bagian-bagian aplikasi yang berbeda berkomunikasi satu sama lain, bertukar data, dan bekerja sama untuk melakukan tugas menyajikan data dan antarmuka kepada pengguna. Program harus dirancang dengan mempertimbangkan poin-poin berikut! Pesan apa yang mereka terima? Peristiwa apa yang dipantau? Bagaimana otentikasi dan otorisasi terjadi? Tanda lain yang sama pentingnya dari program yang baik adalah kejelasan kodenya, bukan jumlah pengujian yang telah dilewati aplikasi atau bahkan cakupan pengujian yang baik. Pertanyaan yang tampaknya sederhana: “Dapatkah orang lain selain saya memahami kode saya?”, “Apakah saya dapat menulis kode ini hari ini dan memahaminya dalam beberapa minggu?” Kutipan populer tentang dua hal tersulit dalam pemrograman mengatakan: Keterbacaan kode jauh lebih penting daripada yang diyakini secara umum. Sayangnya, tidak mungkin menentukan metrik atau parameter yang tepat untuk kejelasan kode. Menghafal norma-norma bahasa yang diterima secara umum, model perangkat lunak yang baik, dan metode pengembangan akan membantu sebagian. Namun biasanya ini tidak cukup. Seiring waktu dan pengalaman, para profesional sejati mengembangkan, bisa dikatakan, “rasa kejelasan”, sesuatu yang mirip dengan intuisi. Metafora menulis berfungsi dengan baik di sini: mengetahui banyak kata tidak akan membantu Anda menulis sesuatu yang ringkas dan jelas maknanya. Kemampuan untuk memperbaiki bug dengan cepat dan mudah merupakan fitur utama dari perangkat lunak yang baik. Kesalahan dalam program harus mengirimkan pesan yang jelas dan dicatat secara terpusat untuk pelacakan. Ketika kesalahan baru dilaporkan, orang yang akan memperbaikinya harus memiliki kemampuan untuk melakukan debug. Dia perlu terhubung dengan mudah ke sistem, mengakses informasi eksekusi kapan saja, dan juga dapat dengan mudah memeriksa fungsionalitas bagian mana pun dari sistem.

Lingkungan dan pengujian

Ketika insinyur perangkat lunak mengembangkan aplikasi, mereka melakukan yang terbaik untuk memastikan bahwa mereka bekerja pada komputer dengan arsitektur berbeda dan dengan sistem operasi berbeda. Penting agar perangkat lunak bekerja pada resolusi dan orientasi layar yang berbeda, dan juga tidak “memakan” lebih banyak memori dan daya pemrosesan daripada yang dibutuhkan. Ketika berbicara tentang aplikasi web, mereka harus bekerja di semua browser utama. Saat membuat aplikasi desktop, Anda perlu memastikan aplikasi tersebut diluncurkan dan berfungsi dengan benar di Mac, Windows, dan Linux. Ya, program bergantung pada data, maka aplikasi harus tetap berfungsi meskipun koneksi data lambat atau tidak ada. Untuk menulis sebuah perangkat lunak, para insinyur memikirkan segala macam opsi skenario dan berencana untuk mengujinya. Semuanya dimulai dengan memilih opsi ideal, di mana semuanya berfungsi tanpa kesalahan. Mereka kemudian mendokumentasikan potensi masalah dan menuliskannya ke dalam rencana pengujian. Beberapa insinyur memulai dengan menulis kode, yang mereka sebut sebagai test case, yang menyimulasikan skenario untuk semua kemungkinan masalah dan kesalahan. Dan kemudian sebuah program ditulis yang dapat bekerja dengan salah satu opsi yang dipertimbangkan. Kemampuan unik seorang insinyur perangkat lunak yang berbakat bukanlah mengetahui cara menulis kode, tetapi memahami apa sebenarnya yang harus dilakukan aplikasi sebagai keluaran dan bagaimana mencapainya. Ketika persyaratan perangkat lunak pelanggan tidak lengkap dan mungkin ambigu, teknisi perlu mengevaluasi dan “memahami” persyaratan tersebut dengan benar.

Biaya dan efisiensi

Seorang insinyur perangkat lunak dapat memperbaiki masalah dengan cepat dalam banyak kasus. Jika Anda berpikir menyewa programmer berpengalaman yang "mahal" akan meningkatkan biaya Anda, pikirkan lagi. Semakin berpengalaman programmer yang disewa, semakin cepat ia mampu memberikan solusi yang sederhana, rapi, andal, dan mudah digunakan. Dalam jangka panjang, hal ini pasti akan mengurangi biaya pengembangan perangkat lunak. Biaya pelaksanaan program juga perlu diperhitungkan. Program apa pun menggunakan sumber daya komputasi, dan tidak gratis. Misalnya, menyimpan data yang sering diakses dalam cache adalah salah satu strategi yang mungkin digunakan untuk mencapai hasil yang diinginkan. Namun ini hanyalah salah satu dari ratusan alat dan solusi yang dapat membuat program lebih cepat dan efisien. Seorang programmer pemula mungkin memberi Anda solusi yang murah, namun menggunakan solusi seperti itu pada akhirnya akan merugikan Anda dan klien Anda jauh lebih banyak dibandingkan jika Anda bekerja dengan pengembang berpengalaman yang menciptakan solusi efektif sejak awal.

Fokus pada pengalaman pengguna

Seorang programmer yang baik berkembang dengan mempertimbangkan Pengalaman Pengguna (UX). Interaksi manusia-mesin adalah topik dengan penelitian dan solusi yang tiada habisnya. Semakin banyak solusi yang diterapkan, semakin baik hasil programnya. Berikut adalah beberapa contoh, hanya untuk memberi Anda gambaran tentang arah ini:

• Saat merancang formulir entri data seperti email, program yang baik harus mengabaikan alamat email. Seharusnya tidak menimbulkan kesalahan jika tombol CAPSLOCK ditekan karena alamat emailnya unik dalam huruf kecil. Jika program menerima alamat email baru sebagai masukan, periksa di awal proses masukan untuk mengingatkan pengguna bahwa mereka menggunakan format alamat yang salah. Solusi ini mencakup pemeriksaan yang jelas seperti tanda “@” yang hilang, dan juga pemeriksaan yang tidak terlalu jelas, seperti memeriksa urutan karakter yang salah seperti “gmail.ocm”

• Ketika pengguna diarahkan untuk melakukan suatu tindakan, program yang baik harus mengingat posisinya saat ini dan mengembalikannya kembali setelah dia selesai. Program yang baik juga harus mengingat data yang telah dikirimkan oleh pengguna, yang penting untuk interaksi lebih lanjut dengannya.

  Katakanlah Anda sedang mencari perjalanan udara sebagai Tamu di Expedia. Nanti Anda memutuskan untuk membuat akun. Aplikasi ini akan menyimpan semua pencarian Anda sebelumnya di akun baru dan Anda harus dapat mengaksesnya dari perangkat lain.




• Program yang baik dirancang dengan mempertimbangkan skenario perilaku pengguna. Anda tidak hanya perlu menambahkan fitur baru secara “biasa saja”; tempatkan diri Anda pada posisi pengguna. Suatu hari saya sedang memesan tiket pesawat dan lupa mencantumkan nomor frequent flyer saya. Setelah mendapat konfirmasi, saya memutuskan untuk membuka website maskapai dan menambahkannya untuk mendapatkan diskon. Untuk mengetahui cara melakukan ini, saya menjelajahi situs ini selama 10 menit. Aplikasinya sangat tidak jelas sehingga saya hanya menjelajahi berbagai halaman situs tanpa tujuan untuk menemukan apa yang saya perlukan. Belakangan, saya menemukan bahwa saya telah mendarat di halaman yang tepat beberapa kali, tetapi saya bahkan tidak memahaminya, karena bidang yang saya butuhkan hilang di antara bidang serupa lainnya yang bentuknya sangat besar.

  Ternyata untuk mengedit informasi perjalanan, saya perlu menelusuri sekitar dua puluh baris formulir, memasukkan nomor kartu loyalitas dan nomor telepon, yang tanpanya formulir tidak dapat dikirim untuk verifikasi. Ini adalah contoh program yang dikembangkan tanpa memikirkan seberapa nyaman penggunanya.

Keandalan, keamanan dan keselamatan

Menurut pendapat saya, perbedaan paling penting antara pengembang perangkat lunak profesional dan amatir adalah memperhitungkan parameter seperti keandalan, keamanan, dan keselamatan aplikasi saat membuatnya. Bagian dari program harus toleran terhadap input yang salah, status yang salah, dan interaksi yang salah. Hal ini memang sangat sulit untuk ditegakkan dan menjadi alasan utama mengapa kita mendengar cerita orang meninggal karena bug perangkat lunak. Pengguna telah masuk, sedang masuk dan akan terus memasukkan data yang salah ke dalam program. Ini harus diterima sebagai fakta. Selain itu, beberapa orang akan melakukan ini dengan sengaja, dengan tujuan merusak aplikasi dan mendapatkan sumber daya yang tersedia untuk aplikasi tersebut. Berikut contoh nyatanya: Orang yang diduga bertanggung jawab atas pelanggaran data Equifax baru-baru ini dituduh gagal dalam tanggung jawab pekerjaannya, yaitu mengembangkan solusi untuk menolak masukan yang buruk dan berbahaya di semua produk perangkat lunak yang tersedia untuk publik. Insiden terkait keamanan informasi tidak hanya melibatkan masukan yang salah dan berbahaya, namun juga data yang dimasukkan secara salah. Jika pengguna lupa kata sandinya, berapa kali dia dapat mencoba memasukkannya? Apakah kamu akan memblokirnya setelah ini? Bagaimana jika orang lain mencoba memblokir akunnya? Bisakah pengguna mengirimkan kredensial mereka melalui saluran data yang tidak terenkripsi? Bagaimana jika permintaan login datang dari lokasi yang tidak biasa? Apa yang akan Anda lakukan jika upaya login tampak otomatis? Apa yang telah Anda lakukan untuk melindungi pengguna Anda dari skrip lintas situs, pemalsuan permintaan lintas situs, dan phishing umum? Apakah Anda memiliki strategi cadangan jika terjadi serangan DDoS di server Anda? Pertanyaan-pertanyaan ini hanya menyoroti beberapa isu yang perlu dipertimbangkan. Program yang dilindungi tidak menyimpan informasi penting dalam bentuk teks. Ia melindunginya dengan sandi satu arah yang kompleks (yang mudah dienkripsi tetapi hampir tidak mungkin didekripsi tanpa kunci). Ini adalah langkah cadangan jika program diretas. Peretas akan menemukan data terenkripsi yang tidak berguna bagi mereka. Masalah tak terduga muncul bahkan pada program terbaik sekalipun. Seorang programmer yang tidak siap menghadapi kejadian tersebut hampir tidak bisa disebut seorang profesional. Sampai dia mengharapkan perilaku yang tidak terduga, dia bukanlah seorang insinyur. Dia adalah “pencipta program yang tidak aman.” Kesalahan dalam program tidak selalu terlihat jelas. Kemampuan intelektual kita untuk mengantisipasi dan mencegah kesalahan yang diketahui terbatas. Inilah sebabnya mengapa para insinyur perangkat lunak memahami pentingnya alat yang baik untuk memungkinkan mereka menulis perangkat lunak yang benar dan aman.

Alat yang Diperlukan

Tidak ada keraguan bahwa kita memerlukan alat pengembangan yang berbeda dan baik. Peran mereka sering diremehkan, namun kenyataannya mereka menghemat banyak waktu dan tenaga, menyederhanakan beberapa tugas hingga urutan besarnya. Bayangkan jika Anda masih harus mengunggah file melalui FTP untuk diterapkan, bisa dikatakan, dengan cara kuno. Bayangkan men-debug masalah jaringan dan kinerja tanpa Chrome DevTools! Dan betapa tidak efisiennya menulis kode JavaScript tanpa ESlit dan Prettier saat ini! Alat apa pun yang mengurangi waktu umpan balik saat Anda menulis kode harus diterima. Ketika saya menemukan sebuah alat yang sebelumnya asing bagi saya, namun benar-benar berguna dan efektif, saya hanya bisa menyesal karena saya tidak menggunakannya sebelum momen bahagia itu.

Evolusi rekayasa perangkat lunak

Tidak ada seorang pun yang bisa mempelajari rekayasa perangkat lunak dalam dua bulan, enam bulan, atau bahkan satu tahun. Anda tidak akan diajari cara menjadi insinyur perangkat lunak di kursus, universitas, atau kamp pelatihan. Saya telah belajar selama lebih dari dua puluh tahun terakhir dan terus belajar sekarang. Saya dapat dengan nyaman menyebut diri saya seorang programmer berpengalaman hanya setelah satu dekade belajar dan mengembangkan, membuat dan memelihara aplikasi yang digunakan oleh ribuan pengguna. Rekayasa perangkat lunak bukan untuk semua orang, tetapi setiap orang harus belajar memecahkan masalah mereka menggunakan komputer. Jika Anda bisa belajar menulis program sederhana, Anda harus melakukannya. Jika Anda dapat belajar menggunakan perangkat lunak yang tersedia untuk umum, Anda harus melakukannya. Jika Anda dapat belajar menggunakan perangkat lunak sumber terbuka dan menyesuaikannya sendiri, Anda memiliki kekuatan super! Setiap hari menghadirkan tantangan baru bagi pengembang, masalah baru, itulah sebabnya rekayasa perangkat lunak diperlukan. Tugas utama profesi ini adalah membuat perangkat lunak sehingga orang biasa tidak harus berurusan dengannya selama bertahun-tahun. Sehingga tidak diperlukan studi yang panjang untuk berinteraksi dengan program. Namun, para insinyur perangkat lunak terus-menerus berpikir untuk menciptakan alat yang lebih baik yang dapat memecahkan masalah-masalah umum yang lebih kompleks, dan melakukan segala kemungkinan untuk memastikan bahwa masalah-masalah baru muncul sesering mungkin.