Siapakah Jurutera Perisian? Kejuruteraan perisian VS pengaturcaraan "hanya".

Kami membawa kepada perhatian anda adaptasi artikel oleh Samer Buna tentang perbezaan antara kejuruteraan perisian dan pengaturcaraan, atau cara membangunkan konsep perisian berbeza daripada "pengekodan sahaja." Semua jurutera perisian boleh membuat kod, tetapi tidak semua pengaturcara boleh membangunkan konsep perisian. Sesetengah orang tidak menyukai istilah "Jurutera Perisian" (aka Jurutera Perisian) kerana selalunya kita menggunakan perkataan "jurutera" apabila bercakap tentang sesuatu yang lebih fizikal - pembinaan, contohnya. Artikel kami, tentu saja, bukan mengenai istilah itu sendiri. Jika ia tiba-tiba menyebabkan anda ditolak, ia boleh digantikan dengan mudah dengan sesuatu yang berkaitan dengan kreativiti. “Pencipta Perisian”, “Pengarang Perisian”... atau “Pencipta Perisian”! Keupayaan untuk memprogram tidak secara automatik menjadikan seseorang seorang jurutera perisian. Sesiapa sahaja boleh belajar kod, dan ia lebih mudah daripada yang kelihatan. Sesiapa sahaja boleh mencipta program mudah untuk kegunaan mereka sendiri, tetapi ini tidak menjamin bahawa program yang sama akan berfungsi untuk orang lain. Contoh kegemaran saya ialah ini: ramai di antara kita menyanyi di bilik mandi, tetapi, sayangnya, persembahan ini tidak semestinya layak untuk pentas profesional. Sudah tentu, untuk pengalaman muzik yang berkualiti tinggi, kemungkinan besar anda akan beralih kepada profesional. Adakah anda memerlukan lebih banyak contoh?

• Kita semua belajar matematik dan menulis di sekolah, tetapi itu tidak menjadikan kita ahli matematik dan penulis.
• Kebanyakan kita mampu menyediakan hidangan yang boleh dimakan dan kadang-kadang sangat lazat, tetapi tidak semua orang berani memasak meja untuk 100 orang untuk majlis makan malam kedutaan. Dalam kes ini, kami mengupah tukang masak.
• Adakah anda bersedia sekarang untuk mempercayakan sepenuhnya pembinaan rumah baharu anda kepada anak jiran yang mencipta karya agung dari Lego?

Perkara utama saya yang cuba saya sampaikan dalam artikel ini ialah program mudah sangat berbeza daripada program yang direka oleh jurutera. Takrifan paling mudah bagi proses pengaturcaraan: merangka urutan tindakan yang tersusun untuk komputer untuk mendapatkan sesuatu yang khusus sebagai output, diberikan parameter input yang diberikan. Proses kejuruteraan perisian ialah reka bentuk, penulisan, pengujian, dan penyusunan atur cara komputer untuk menyelesaikan masalah bagi ramai pengguna. Ini tentang mencipta penyelesaian yang boleh dipercayai dan selamat yang akan bertahan dalam ujian masa dan bekerja untuk beberapa cabaran yang mungkin tidak diketahui di luar yang jelas. Jurutera perisian mengetahui segala-galanya tentang masalah yang mereka selesaikan, penyelesaian yang mereka cadangkan, batasan penyelesaian tersebut, privasi dan keselamatan mereka. Pada pendapat saya, jika seseorang tidak memahami intipati masalah itu, dia tidak sepatutnya mula memprogramkan penyelesaiannya.

Minda kejuruteraan - cari penyelesaian yang digunakan

Jurutera perisian tidak menganggap menulis perisian per se matlamat utama mereka. Mereka berfikir dari segi memenuhi keperluan dan menyelesaikan masalah . Ini penting kerana tidak setiap masalah memerlukan penyelesaian perisian. Sebahagian daripada mereka boleh ditangani menggunakan program sedia ada. Kejadian beberapa masalah kadangkala boleh diramalkan lebih awal, dan dengan bantuan reka bentuk program yang cekap, ia boleh dielakkan pada masa hadapan. Masalah kompleks selalunya memerlukan penulisan banyak program. Terdapat tugas yang memerlukan aplikasi berjalan selari, sementara yang lain memerlukan pelaksanaan berurutan beberapa program. Beberapa masalah boleh diselesaikan hanya dengan melatih pengguna. Sebelum mula mencipta program, seorang jurutera perisian bertanya kepada dirinya sendiri beberapa soalan:

• Apakah masalah yang perlu saya selesaikan?
• Apa lagi yang boleh anda lakukan selain menulis kod untuk menyelesaikannya?
• Apakah yang boleh saya lakukan untuk memudahkan tugasan ini dengan apl?

Kualiti program dan kualiti kod

Program yang baik adalah jelas dan boleh dibaca. Ia mudah untuk dilanjutkan, bermain dengan baik dengan program lain dan tidak akan menjadi mimpi ngeri untuk bekerjasama. Kualiti kod tidak boleh dirunding. Ia sepatutnya tinggi, itu sahaja. Apabila mempertimbangkannya, alasan seperti mood buruk pengekod atau tarikh akhir yang terlalu ketat (oh, tarikh akhir itu!) tidak boleh diterima. Salah satu aspek pembangunan perisian yang paling penting ialah mereka bentuk program sedemikian rupa sehingga mudah untuk diselenggara dan diubah suai pada masa hadapan (hello, OOP!). Hari ini, hampir semua perisian boleh diubah suai, selalunya proses ini berlaku walaupun tanpa penyertaan pengguna atau tidak memerlukan apa-apa daripada pengguna selain daripada "program anda telah dikemas kini, klik OK atau Tangguh." Sudah tentu, pengguna mempunyai hak untuk menuntut ciri baharu daripada aplikasi (terutamanya jika kita bercakap tentang perisian perusahaan yang telah lama berjalan yang ditulis dalam Java, atau permainan dalam talian yang boleh dimainkan selama bertahun-tahun). Sekeping kod dengan sendirinya tidak boleh dipanggil berguna. Kefungsian berguna perisian bermula di mana bahagian aplikasi yang berbeza berkomunikasi antara satu sama lain, bertukar data, dan bekerjasama untuk melaksanakan tugas mempersembahkan data dan antara muka kepada pengguna. Program harus direka bentuk dengan mengambil kira perkara ini! Apakah mesej yang mereka terima? Apakah peristiwa yang dipantau? Bagaimanakah pengesahan dan kebenaran berlaku? Satu lagi tanda yang sama penting bagi program yang baik ialah kejelasan kod, bukan bilangan ujian yang telah diluluskan oleh aplikasi atau liputan ujian yang baik. Soalan yang kelihatan mudah: "Bolehkah seseorang selain saya memahami kod saya?", "Adakah saya boleh menulis kod ini hari ini dan memahaminya dalam beberapa minggu?" Petikan popular mengenai dua perkara paling sukar dalam pengaturcaraan berkata: Kebolehbacaan kod adalah lebih penting daripada yang biasa dipercayai. Malangnya, tidak mungkin untuk mentakrifkan metrik atau parameter yang tepat untuk kejelasan kod. Menghafal norma bahasa yang diterima umum, model perisian yang baik, dan kaedah pembangunan sebahagiannya akan membantu. Tetapi biasanya ini tidak mencukupi. Dengan masa dan pengalaman, profesional sejati mengembangkan, boleh dikatakan, "rasa kejelasan," sesuatu yang serupa dengan gerak hati. Metafora penulisan berfungsi dengan baik di sini: mengetahui banyak perkataan tidak akan membantu anda menulis sesuatu yang ringkas dan jelas maksudnya. Keupayaan untuk membetulkan pepijat dengan cepat dan mudah adalah ciri utama perisian yang baik. Ralat dalam program harus menghantar mesej yang jelas dan dilog secara berpusat untuk penjejakan. Apabila ralat baharu dilaporkan, orang yang akan membetulkannya mesti mempunyai keupayaan untuk menyahpepijatnya. Dia perlu dengan mudah menyambung ke sistem, mengakses maklumat pelaksanaan pada bila-bila masa, dan juga boleh menyemak kefungsian mana-mana bahagian sistem dengan mudah.

Persekitaran dan ujian

Apabila jurutera perisian membangunkan aplikasi, mereka melakukan yang terbaik untuk memastikan bahawa mereka bekerja pada komputer dengan seni bina yang berbeza dan dengan sistem pengendalian yang berbeza. Adalah penting bahawa perisian berfungsi pada resolusi dan orientasi skrin yang berbeza, dan juga bahawa ia tidak "memakan" lebih banyak memori dan kuasa pemprosesan daripada yang diperlukan. Apabila ia datang kepada aplikasi web, ia mesti berfungsi dalam semua pelayar utama. Apabila membuat aplikasi desktop, anda perlu memastikan ia dilancarkan dan berfungsi dengan betul pada Mac, Windows dan Linux. Nah, program ini bergantung pada data, maka aplikasi harus berfungsi walaupun dalam hal sambungan data yang lambat atau ketiadaannya. Untuk menulis sekeping perisian, jurutera memikirkan pelbagai pilihan senario dan merancang untuk mengujinya. Semuanya bermula dengan memilih pilihan yang ideal, di mana semuanya berfungsi tanpa kesilapan. Mereka kemudian mendokumentasikan sebarang masalah yang berpotensi dan menulisnya ke dalam rancangan ujian. Sesetengah jurutera bermula dengan menulis kod, yang mereka panggil kes ujian, yang mensimulasikan senario untuk semua masalah dan ralat yang mungkin berlaku. Dan kemudian program ditulis yang boleh berfungsi dengan mana-mana pilihan yang dipertimbangkan. Keupayaan unik seorang jurutera perisian berbakat tidak mengetahui cara menulis kod, tetapi memahami apa sebenarnya yang harus dilakukan oleh aplikasi sebagai output dan cara mencapainya. Apabila keperluan perisian pelanggan tidak lengkap dan mungkin samar-samar, jurutera perlu menilai dan "memahami" dengan betul.

Kos dan kecekapan

Jurutera perisian boleh menyelesaikan masalah dengan cepat dalam kebanyakan kes. Jika anda fikir mengupah pengaturcara berpengalaman "mahal" akan meningkatkan kos anda, fikirkan semula. Lebih berpengalaman pengaturcara yang diupah, lebih cepat dia akan dapat memberikan penyelesaian yang ringkas, kemas, boleh dipercayai dan mudah digunakan. Dalam jangka panjang, ini pasti akan mengurangkan kos pembangunan perisian. Ia juga perlu untuk mempertimbangkan kos untuk melaksanakan program. Mana-mana program menggunakan sumber pengkomputeran, dan ia tidak percuma. Sebagai contoh, caching data yang kerap diakses adalah salah satu strategi yang mungkin digunakan untuk mencapai hasil yang diinginkan. Tetapi ini hanyalah salah satu daripada beratus-ratus alat dan penyelesaian yang boleh menjadikan program lebih pantas dan cekap. Seorang pengaturcara baru boleh memberi anda penyelesaian yang murah, tetapi menggunakan penyelesaian sedemikian akhirnya akan membebankan anda dan pelanggan anda lebih daripada jika anda bekerja dengan pembangun berpengalaman yang mencipta penyelesaian yang berkesan pada mulanya.

Fokus pada pengalaman pengguna

Pengaturcara yang baik membangun dengan mengambil kira Pengalaman Pengguna (UX). Interaksi manusia-mesin ialah topik dengan penyelidikan dan penyelesaian yang tidak berkesudahan. Lebih banyak penyelesaian digunakan, lebih baik program itu akan dihasilkan. Berikut ialah beberapa contoh, hanya untuk memberi anda gambaran tentang arah ini:

• Apabila mereka bentuk borang kemasukan data seperti e-mel, program yang baik harus mengabaikan kes alamat e-mel. Ia tidak sepatutnya menimbulkan ralat jika kekunci CAPSLOCK ditekan kerana alamat e-mel adalah unik dalam huruf kecil. Jika program menerima alamat e-mel baharu sebagai input, semaknya awal dalam proses input untuk memaklumkan pengguna bahawa mereka menggunakan format alamat yang salah. Penyelesaian ini termasuk kedua-dua semakan yang jelas seperti tanda "@" yang hilang dan juga yang tidak begitu jelas, seperti menyemak susunan aksara yang salah seperti "gmail.ocm"

• Apabila pengguna diubah hala untuk melakukan beberapa tindakan, program yang baik harus mengingati kedudukan semasanya dan mengembalikannya semula selepas dia selesai. Program yang baik juga harus mengingati data yang telah dihantar oleh pengguna, yang penting untuk interaksi selanjutnya dengannya.

  Katakan anda sedang mencari perjalanan udara sebagai Tetamu di Expedia. Kemudian anda membuat keputusan untuk membuat akaun. Apl itu harus menyimpan semua carian anda sebelum ini dalam akaun baharu dan anda seharusnya boleh mengaksesnya daripada peranti lain.




• Program yang baik direka bentuk dengan mengambil kira senario tingkah laku pengguna. Anda bukan sahaja perlu menambah ciri baharu secara "begitu-begitu"; letakkan diri anda dalam kedudukan pengguna. Suatu hari saya sedang menempah tiket kapal terbang dan terlupa memasukkan nombor frequent flyer saya. Selepas menerima pengesahan, saya memutuskan untuk pergi ke laman web syarikat penerbangan dan menambahnya untuk mendapatkan diskaun. Untuk mengetahui cara melakukan ini, saya bermain-main di laman web ini selama 10 minit. Aplikasi itu sangat tidak jelas sehingga saya hanya merayau tanpa hala tuju melalui halaman yang berbeza di tapak untuk mencari apa yang saya perlukan. Kemudian, saya mendapati bahawa saya telah mendarat di halaman yang betul beberapa kali, tetapi saya tidak memahaminya, kerana medan yang saya perlukan telah hilang di kalangan bidang lain yang serupa dalam bentuk yang besar.

  Ternyata untuk mengedit maklumat perjalanan, saya perlu menatal melalui kira-kira dua puluh baris borang, masukkan nombor kad kesetiaan dan nombor telefon, tanpa borang itu tidak dapat dihantar untuk pengesahan. Ini adalah contoh program yang dibangunkan tanpa memikirkan betapa selesanya pengguna dengannya.

Kebolehpercayaan, keselamatan dan keselamatan

Pada pendapat saya, perbezaan paling penting antara pembangun perisian profesional dan amatur adalah mengambil kira parameter seperti kebolehpercayaan, keselamatan dan keselamatan aplikasi semasa menciptanya. Bahagian program mesti bertolak ansur dengan input yang salah, keadaan yang salah dan interaksi yang salah. Ini sememangnya sangat sukar untuk dikuatkuasakan dan merupakan sebab utama mengapa kita mendengar cerita orang mati akibat pepijat perisian. Pengguna telah memasuki, sedang memasuki dan akan terus memasukkan data yang salah ke dalam program. Ini mesti diterima sebagai fakta. Selain itu, sesetengah orang akan melakukan ini dengan sengaja, dengan matlamat untuk memecahkan aplikasi dan mendapatkan sumber yang tersedia untuknya. Berikut ialah contoh kehidupan sebenar: Orang yang didakwa bertanggungjawab atas pelanggaran data Equifax baru-baru ini dituduh gagal dalam tanggungjawab kerjanya, iaitu untuk membangunkan penyelesaian untuk menentang input buruk dan berniat jahat dalam semua produk perisian yang tersedia kepada orang ramai. Insiden yang berkaitan dengan keselamatan maklumat bukan sahaja melibatkan input yang salah dan berniat jahat, tetapi juga data yang dimasukkan dengan salah. Jika pengguna terlupa kata laluannya, berapa kali dia boleh cuba memasukkannya? Adakah anda akan menghalangnya selepas ini? Bagaimana jika orang lain cuba menyekat akaunnya? Bolehkah pengguna menghantar bukti kelayakan mereka melalui saluran data yang tidak disulitkan? Bagaimana jika permintaan log masuk datang dari lokasi yang luar biasa? Apakah yang akan anda lakukan jika percubaan log masuk kelihatan seperti automatik? Apakah yang telah anda lakukan untuk melindungi pengguna anda daripada skrip merentas tapak, pemalsuan permintaan merentas tapak dan pancingan data biasa? Adakah anda mempunyai strategi sandaran sekiranya berlaku serangan DDoS pada pelayan anda? Soalan-soalan ini hanya menyerlahkan beberapa isu yang perlu dipertimbangkan. Program yang dilindungi tidak menyimpan maklumat penting dalam bentuk teks. Ia melindunginya dengan sifir sehala yang kompleks (yang mudah disulitkan tetapi hampir mustahil untuk dinyahsulit tanpa kunci). Ini adalah langkah sandaran sekiranya program itu digodam. Penggodam akan menemui data yang disulitkan yang tidak berguna kepada mereka. Masalah yang tidak dijangka timbul walaupun dalam program terbaik. Seorang pengaturcara yang tidak bersedia untuk kejadian mereka hampir tidak boleh dipanggil profesional. Sehingga dia mengharapkan tingkah laku yang tidak dijangka, dia bukan seorang jurutera. Dia adalah "pengarang program tidak selamat." Ralat dalam program tidak selalunya jelas. Keupayaan intelek kita untuk menjangka dan mencegah kesilapan yang diketahui adalah terhad. Inilah sebabnya jurutera perisian memahami kepentingan alat yang baik untuk membolehkan mereka menulis perisian yang betul dan selamat.

Alat yang Diperlukan

Tidak dinafikan bahawa kita memerlukan alat pembangunan yang berbeza dan baik. Peranan mereka sering dipandang remeh, tetapi sebenarnya mereka menjimatkan banyak masa dan usaha, memudahkan beberapa tugas dengan susunan magnitud. Bayangkan jika anda masih perlu memuat naik fail melalui FTP untuk penggunaan, boleh dikatakan, cara lama. Bayangkan masalah penyahpepijatan dan prestasi tanpa Chrome DevTools! Dan betapa tidak cekapnya menulis kod JavaScript tanpa ESlit dan Prettier hari ini! Sebarang alat yang mengurangkan masa maklum balas semasa anda menulis kod harus dialu-alukan. Apabila saya menemui alat yang sebelum ini saya tidak biasa, tetapi benar-benar berguna dan berkesan, saya hanya boleh menyesal kerana saya tidak menggunakannya sebelum saat gembira itu.

Evolusi kejuruteraan perisian

Tiada siapa yang boleh belajar kejuruteraan perisian dalam dua bulan, enam bulan, atau setahun. Anda tidak akan diajar cara menjadi jurutera perisian dalam kursus, universiti atau kem latihan. Saya telah belajar selama dua puluh tahun yang lalu dan terus belajar sekarang. Saya boleh dengan selesa memanggil diri saya seorang pengaturcara yang berpengalaman hanya selepas sedekad belajar dan membangun, mencipta dan menyelenggara aplikasi yang digunakan oleh beribu-ribu pengguna. Kejuruteraan perisian bukan untuk semua orang, tetapi semua orang harus belajar menyelesaikan masalah mereka menggunakan komputer. Jika anda boleh belajar menulis program mudah, anda harus. Jika anda boleh belajar menggunakan perisian yang tersedia untuk umum, anda harus. Jika anda boleh belajar menggunakan perisian sumber terbuka dan menyesuaikannya untuk diri sendiri, anda mempunyai kuasa besar! Setiap hari membawa pembangun cabaran baharu, masalah baharu, itulah sebabnya kejuruteraan perisian diperlukan. Tugas utama profesion ini adalah untuk mencipta perisian supaya orang biasa tidak perlu berurusan dengannya selama bertahun-tahun. Supaya tidak perlu pengajian panjang untuk berinteraksi dengan program. Namun begitu, jurutera perisian sentiasa berfikir tentang mencipta alat yang lebih baik yang boleh menyelesaikan masalah yang diketahui lebih kompleks, dan melakukan segala yang mungkin untuk memastikan masalah baharu muncul sejarang mungkin.