Program yang berfungsi dengan betul

1. Tugas seorang pengaturcara

Selalunya pengaturcara pemula memikirkan kerja pengaturcara sama sekali berbeza daripada cara pengaturcara berpengalaman memikirkannya.

Pemula sering mengatakan sesuatu seperti "Program ini berfungsi, apa lagi yang anda perlukan?" Seorang pengaturcara yang berpengalaman tahu bahawa "berfungsi dengan betul" hanyalah salah satu keperluan untuk program , dan ia bukanlah perkara yang paling penting !

Kebolehbacaan kod

Perkara yang paling penting ialah kod program boleh difahami oleh pengaturcara lain . Ini lebih penting daripada program yang berfungsi dengan betul. Banyak lagi.

Jika anda mempunyai program yang tidak berfungsi dengan betul, anda boleh membetulkannya. Tetapi jika anda mempunyai program yang kodnya tidak dapat difahami, anda tidak boleh berbuat apa-apa dengannya.

Hanya ambil mana-mana program yang disusun, seperti notepad, dan tukar warna latar belakangnya kepada merah. Anda mempunyai program yang berfungsi, tetapi anda tidak mempunyai kod sumber yang boleh difahami: adalah mustahil untuk membuat perubahan pada program seperti itu.

Contoh buku teks ialah apabila pembangun Microsoft mengalih keluar permainan Pinball daripada Windows kerana mereka tidak dapat memindahkannya ke seni bina 64-bit. Dan mereka juga mempunyai kod sumbernya. Mereka tidak dapat memahami cara kod itu berfungsi .

Perakaunan untuk setiap kes penggunaan

Keperluan kedua yang paling penting untuk program adalah untuk mengambil kira setiap senario. Selalunya, perkara menjadi lebih rumit daripada yang kelihatan.

Bagaimana pengaturcara baru melihat menghantar mesej SMS:

Bagaimana seorang pengaturcara profesional melihatnya:

Senario "berfungsi dengan betul" biasanya hanya satu yang mungkin. Dan itulah sebabnya ramai pemula mengadu tentang pengesah tugas CodeGym: hanya satu senario daripada 10 karya, dan pengaturcara baru berpendapat itu sudah cukup.

2. Situasi yang tidak normal

Situasi tidak normal mungkin timbul dalam pelaksanaan mana-mana program.

Sebagai contoh, anda memutuskan untuk menyimpan fail tetapi tiada ruang cakera. Atau program cuba menulis data ke memori, tetapi memori yang tersedia adalah rendah. Atau anda memuat turun gambar dari Internet, tetapi sambungan terputus semasa proses muat turun.

Bagi setiap situasi yang tidak normal, pengaturcara (pengarang program) mesti a) menjangkakannya , b) memutuskan bagaimana sebenarnya program itu harus mengendalikannya , dan c) menulis penyelesaian yang sedekat mungkin dengan yang dikehendaki.

Itulah sebabnya program mempunyai tingkah laku yang sangat mudah untuk masa yang agak lama: jika ralat berlaku dalam program, program itu ditamatkan. Dan itu adalah pendekatan yang cukup baik.

Katakan anda ingin menyimpan dokumen ke cakera, semasa proses simpan anda mendapati bahawa ruang cakera tidak mencukupi. Tingkah laku manakah yang paling anda suka:

• Program ditamatkan
• Program ini terus berjalan, tetapi tidak menyimpan fail.

Seorang pengaturcara baru mungkin berfikir bahawa pilihan kedua adalah lebih baik, kerana program itu masih berjalan. Tetapi pada hakikatnya tidak begitu.

Bayangkan anda menaip dokumen dalam Word selama 3 jam, tetapi dua minit dalam proses penulisan anda, ternyata program itu tidak akan dapat menyimpan dokumen ke cakera. Adakah lebih baik kehilangan dua minit kerja atau tiga jam?

Jika program tidak dapat melakukan apa yang diperlukan, lebih baik biarkan ia ditutup daripada terus berpura-pura bahawa semuanya baik-baik saja. Perkara terbaik yang boleh dilakukan oleh program apabila ia menghadapi kegagalan yang tidak dapat dibetulkan sendiri adalah dengan segera melaporkan masalah tersebut kepada pengguna.

3. Latar belakang tentang pengecualian

Program bukan satu-satunya yang menghadapi situasi tidak normal. Ia juga berlaku di dalam program — dalam kaedah. Sebagai contoh:

• Kaedah ingin menulis fail ke cakera, tetapi tiada ruang.
• Kaedah ingin memanggil fungsi pada pembolehubah, tetapi pembolehubah adalah sama dengan nol.
• Pembahagian dengan 0 berlaku dalam kaedah.

Dalam kes ini, kaedah panggilan mungkin boleh membetulkan keadaan (laksanakan senario alternatif) jika ia mengetahui jenis masalah yang berlaku dalam kaedah yang dipanggil.

Jika kami cuba menyimpan fail ke cakera dan fail sedemikian sudah wujud, kami hanya boleh meminta pengguna mengesahkan bahawa kami harus menulis ganti fail tersebut. Jika tiada ruang cakera yang tersedia, kami boleh memaparkan mesej kepada pengguna dan meminta pengguna memilih cakera lain. Tetapi jika program kehabisan memori, ia akan ranap.

Pada suatu masa dahulu, pengaturcara memikirkan soalan ini dan menghasilkan penyelesaian berikut: semua kaedah/fungsi mesti mengembalikan kod ralat yang menunjukkan hasil pelaksanaannya. Jika fungsi berfungsi dengan sempurna, ia mengembalikan 0 . Jika tidak, ia mengembalikan kod ralat (bukan sifar).

Dengan pendekatan ralat ini, selepas hampir setiap panggilan fungsi, pengaturcara terpaksa menambah semakan untuk melihat sama ada fungsi selesai dengan ralat. Kod bersaiz belon dan kelihatan seperti ini:

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)
{
   ...
}

Lebih-lebih lagi, selalunya fungsi yang mendapati bahawa ralat berlaku tidak tahu apa yang perlu dilakukan dengannya: pemanggil terpaksa mengembalikan ralat itu, dan pemanggil pemanggil mengembalikannya kepada pemanggilnya, dan seterusnya.

Dalam program besar, rangkaian berpuluh-puluh panggilan fungsi adalah perkara biasa: kadangkala anda juga boleh menemui kedalaman panggilan ratusan fungsi. Dan kini anda perlu menghantar kod ralat dari bahagian paling bawah ke bahagian paling atas. Dan jika di suatu tempat di sepanjang jalan beberapa fungsi tidak mengendalikan kod keluar, maka ralat akan hilang.

Satu lagi kelemahan pendekatan ini ialah jika fungsi mengembalikan kod ralat, mereka tidak lagi dapat mengembalikan hasil kerja mereka sendiri. Hasil pengiraan perlu diluluskan melalui parameter rujukan. Ini menjadikan kod itu lebih rumit dan meningkatkan lagi bilangan ralat.