1. Pekerjaan seorang programmer

Sangat sering pemrogram pemula menganggap pekerjaan seorang pemrogram sama sekali berbeda dari yang dipikirkan oleh pemrogram berpengalaman .

Pemula sering mengatakan sesuatu seperti "Programnya berhasil, apa lagi yang Anda butuhkan?" Seorang pemrogram berpengalaman tahu bahwa "berfungsi dengan benar" hanyalah salah satu persyaratan untuk sebuah program , dan itu bahkan bukan hal yang paling penting !

Keterbacaan kode

Hal yang paling penting adalah bahwa kode program dapat dimengerti oleh pemrogram lain . Ini lebih penting daripada program yang berfungsi dengan benar. Lebih banyak.

Jika Anda memiliki program yang tidak berfungsi dengan benar, Anda dapat memperbaikinya. Tetapi jika Anda memiliki program yang kodenya tidak dapat dipahami, Anda tidak dapat melakukan apa pun dengannya.

Ambil saja program yang dikompilasi, seperti notepad, dan ubah warna latar belakangnya menjadi merah. Anda memiliki program yang berfungsi, tetapi Anda tidak memiliki kode sumber yang dapat dimengerti: tidak mungkin membuat perubahan pada program seperti itu.

Contoh buku teks adalah ketika pengembang Microsoft menghapus permainan Pinball dari Windows karena mereka tidak dapat mem-portingnya ke arsitektur 64-bit. Dan mereka bahkan memiliki kode sumbernya. Mereka benar-benar tidak mengerti bagaimana kode itu bekerja .

Akuntansi untuk setiap kasus penggunaan

Persyaratan terpenting kedua untuk sebuah program adalah memperhitungkan setiap skenario. Sering kali, hal-hal menjadi sedikit lebih rumit dari yang terlihat.

Bagaimana seorang programmer pemula melihat mengirim pesan SMS:

Program yang bekerja dengan benar

Bagaimana seorang programmer profesional melihatnya:

Program yang bekerja dengan benar

Skenario "berfungsi dengan benar" biasanya hanya satu kemungkinan. Dan itulah mengapa banyak pemula mengeluh tentang validator tugas CodeGym: hanya satu skenario dari 10 yang berfungsi, dan programmer pemula menganggap itu sudah cukup.


2. Situasi abnormal

Situasi abnormal

Situasi abnormal dapat muncul dalam pelaksanaan program apa pun.

Misalnya, Anda memutuskan untuk menyimpan file tetapi tidak ada ruang disk. Atau program mencoba menulis data ke memori, tetapi memori yang tersedia tinggal sedikit. Atau Anda mengunduh gambar dari Internet, tetapi koneksi terputus selama proses pengunduhan.

Untuk setiap situasi abnormal, pemrogram (pembuat program) harus a) mengantisipasinya , b) memutuskan bagaimana tepatnya program harus menanganinya , dan c) menulis solusi yang sedekat mungkin dengan solusi yang diinginkan.

Itu sebabnya program memiliki perilaku yang sangat sederhana untuk waktu yang cukup lama: jika terjadi kesalahan dalam program, program dihentikan. Dan itu pendekatan yang cukup bagus.

Katakanlah Anda ingin menyimpan dokumen ke disk, selama proses penyimpanan Anda menemukan bahwa ruang disk tidak cukup. Perilaku mana yang paling Anda sukai:

  • Program berakhir
  • Program terus berjalan, tetapi tidak menyimpan file.

Pemrogram pemula mungkin berpikir bahwa opsi kedua lebih baik, karena programnya masih berjalan. Namun pada kenyataannya tidaklah demikian.

Bayangkan Anda mengetik dokumen di Word selama 3 jam, tetapi dua menit setelah proses penulisan Anda, menjadi jelas bahwa program tidak akan dapat menyimpan dokumen ke disk. Apakah lebih baik kehilangan dua menit kerja atau tiga jam?

Jika program tidak dapat melakukan apa yang diperlukan, lebih baik membiarkannya ditutup daripada terus berpura-pura bahwa semuanya baik-baik saja. Hal terbaik yang dapat dilakukan program ketika menemui kegagalan yang tidak dapat diperbaiki sendiri adalah segera melaporkan masalah tersebut kepada pengguna.


3. Latar belakang tentang pengecualian

Program bukan satu-satunya yang menghadapi situasi abnormal. Mereka juga terjadi di dalam program — dalam metode. Misalnya:

  • Suatu metode ingin menulis file ke disk, tetapi tidak ada ruang.
  • Suatu metode ingin memanggil fungsi pada suatu variabel, tetapi variabel tersebut sama dengan nol.
  • Pembagian dengan 0 terjadi dalam suatu metode.

Dalam hal ini, metode pemanggil mungkin dapat memperbaiki situasi (mengeksekusi skenario alternatif) jika mengetahui jenis masalah yang terjadi pada metode yang dipanggil.

Jika kami mencoba menyimpan file ke disk dan file seperti itu sudah ada, kami cukup meminta pengguna untuk mengonfirmasi bahwa kami harus menimpa file tersebut. Jika tidak ada ruang disk yang tersedia, kami dapat menampilkan pesan kepada pengguna dan meminta pengguna untuk memilih disk lain. Tetapi jika program kehabisan memori, itu akan macet.

Sekali waktu, pemrogram merenungkan pertanyaan ini dan menghasilkan solusi berikut: semua metode/fungsi harus mengembalikan kode kesalahan yang menunjukkan hasil eksekusinya. Jika suatu fungsi bekerja dengan sempurna, ia mengembalikan 0 . Jika tidak, itu mengembalikan kode kesalahan (bukan nol).

Dengan pendekatan kesalahan ini, setelah hampir setiap pemanggilan fungsi, pemrogram harus menambahkan tanda centang untuk melihat apakah fungsi selesai dengan kesalahan. Kode membengkak dalam ukuran dan terlihat seperti ini:

Kode tanpa penanganan kesalahan Kode dengan penanganan kesalahan
File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();
File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

Terlebih lagi, cukup sering fungsi yang menemukan bahwa terjadi kesalahan tidak tahu apa yang harus dilakukan dengannya: pemanggil harus mengembalikan kesalahan, dan pemanggil dari pemanggil mengembalikannya ke pemanggilnya, dan seterusnya.

Dalam program besar, rangkaian lusinan pemanggilan fungsi adalah norma: terkadang Anda bahkan dapat menemukan kedalaman pemanggilan ratusan fungsi. Dan sekarang Anda harus meneruskan kode kesalahan dari paling bawah ke paling atas. Dan jika di suatu tempat beberapa fungsi tidak menangani kode keluar, maka kesalahan akan hilang.

Kerugian lain dari pendekatan ini adalah jika fungsi mengembalikan kode kesalahan, mereka tidak dapat lagi mengembalikan hasil pekerjaan mereka sendiri. Hasil perhitungan harus diteruskan melalui parameter referensi. Ini membuat kode menjadi lebih rumit dan semakin meningkatkan jumlah kesalahan.