Doğru çalışan bir program

1. Bir programcının işi

Çoğu zaman acemi programcılar, bir programcının işini deneyimli programcıların düşündüğünden tamamen farklı düşünürler.

Yeni başlayanlar genellikle "Program çalışıyor, başka neye ihtiyacınız var?" Deneyimli bir programcı, "doğru çalışmasının" bir programın gereksinimlerinden yalnızca biri olduğunu bilir ve bu en önemli şey bile değildir !

Kod okunabilirliği

En önemli şey, program kodunun diğer programcılar tarafından anlaşılabilir olmasıdır . Bu, doğru çalışan bir programdan daha önemlidir. Daha fazla.

Düzgün çalışmayan bir programınız varsa, onu düzeltebilirsiniz. Ancak kodu anlaşılmaz bir programınız varsa, onunla hiçbir şey yapamazsınız.

Not defteri gibi herhangi bir derlenmiş programı alın ve arka plan rengini kırmızı olarak değiştirin. Çalışan bir programınız var ama anlaşılır bir kaynak kodunuz yok: Böyle bir programda değişiklik yapmanız imkansız.

Bir ders kitabı örneği, Microsoft geliştiricilerinin Pinball oyununu 64 bit mimariye taşıyamadıkları için Windows'tan kaldırmalarıdır. Ve kaynak koduna bile sahiplerdi. Kodun nasıl çalıştığını anlayamadılar .

Her kullanım durumu için muhasebe

Bir program için en önemli ikinci gereklilik, her senaryoyu hesaba katmaktır. Çoğu zaman, işler göründüğünden biraz daha karmaşıktır.

Acemi bir programcı SMS mesajları göndermeyi nasıl görür:

Profesyonel bir programcı bunu nasıl görür:

"Düzgün çalışıyor" senaryosu genellikle olası birçok senaryodan yalnızca biridir. İşte bu yüzden birçok acemi CodeGym'in görev doğrulayıcısından şikayet ediyor: 10 senaryodan yalnızca biri çalışıyor ve acemi programcı bunun yeterli olduğunu düşünüyor.

2. Anormal durumlar

Herhangi bir programın yürütülmesinde anormal durumlar ortaya çıkabilir.

Örneğin, bir dosyayı kaydetmeye karar verdiniz ancak disk alanı yok. Veya program belleğe veri yazmaya çalışıyor, ancak kullanılabilir bellek az. Veya internetten bir resim indirirsiniz, ancak indirme işlemi sırasında bağlantı kesilir.

Her anormal durum için, programcı (programın yazarı) a) bunu tahmin etmeli , b) programın bunu tam olarak nasıl ele alması gerektiğine karar vermeli ve c) istenen duruma mümkün olduğunca yakın bir çözüm yazmalıdır.

Bu nedenle programların oldukça uzun bir süre çok basit davranışları vardı: programda bir hata oluşursa program sonlandırılırdı. Ve bu oldukça iyi bir yaklaşımdı.

Diyelim ki bir belgeyi diske kaydetmek istiyorsunuz, kaydetme işlemi sırasında yeterli disk alanı olmadığını keşfediyorsunuz. En çok hangi davranışı istersiniz:

• program sonlandırılır
• Program çalışmaya devam eder, ancak dosyayı kaydetmez.

Acemi bir programcı, program hala çalıştığı için ikinci seçeneğin daha iyi olduğunu düşünebilir. Ama gerçekte öyle değil.

Word'de bir belgeyi 3 saat boyunca yazdığınızı, ancak yazma sürecinizin iki dakikasında programın belgeyi diske kaydedemeyeceğinin netleştiğini hayal edin. İki dakikalık çalışmayı kaybetmek mi yoksa üç saati kaybetmek mi daha iyidir?

Program yapması gerekeni yapamıyorsa, her şey yolundaymış gibi davranmaya devam etmektense onu kapatmak daha iyidir. Bir programın kendi başına çözemeyeceği bir arıza ile karşılaştığında yapabileceği en iyi şey, sorunu hemen kullanıcıya bildirmektir.

3. İstisnalar hakkında arka plan

Anormal durumlarla karşılaşan yalnızca programlar değildir. Ayrıca programların içinde - yöntemlerde de bulunurlar. Örneğin:

• Bir metot diske bir dosya yazmak istiyor ama yer yok.
• Bir yöntem, bir değişken üzerinde bir işlev çağırmak ister, ancak değişken null'a eşittir.
• 0'a bölme bir yöntemde gerçekleşir.

Bu durumda, çağıran yöntem, çağrılan yöntemde ne tür bir sorun oluştuğunu bilirse muhtemelen durumu düzeltebilir (alternatif bir senaryo yürütebilir).

Bir dosyayı diske kaydetmeye çalışıyorsak ve böyle bir dosya zaten varsa, kullanıcıdan dosyanın üzerine yazmamız gerektiğini onaylamasını isteyebiliriz. Kullanılabilir disk alanı yoksa, kullanıcıya bir mesaj görüntüleyebilir ve kullanıcıdan farklı bir disk seçmesini isteyebiliriz. Ancak programın belleği tükenirse çökecektir.

Bir zamanlar programcılar bu soru üzerinde kafa yormuş ve şu çözümü bulmuşlardı: tüm yöntemler/işlevler, uygulamalarının sonucunu gösteren bir hata kodu döndürmelidir. Bir işlev mükemmel çalıştıysa, 0 döndürürdü . Değilse, bir hata kodu (sıfır değil) döndürdü.

Hatalara bu yaklaşımla, neredeyse her işlev çağrısından sonra programcılar, işlevin bir hatayla bitip bitmediğini görmek için bir kontrol eklemek zorunda kaldılar. Kodun boyutu balonlaştı ve şöyle görünmeye başladı:

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

Dahası, çoğu zaman bir hatanın oluştuğunu keşfeden bir işlev, bununla ne yapacağını bilemez: arayanın hatayı döndürmesi gerekiyordu ve arayanın arayanı arayana geri döndürdü, vb.

Büyük bir programda, düzinelerce işlev çağrısından oluşan bir zincir normdur: bazen yüzlerce işlevden oluşan bir çağrı derinliği bile bulabilirsiniz. Ve şimdi hata kodunu en alttan en üste geçirmeniz gerekiyor. Ve yol boyunca bir yerde bazı işlevler çıkış kodunu işlemezse, o zaman hata kaybolacaktır.

Bu yaklaşımın diğer bir dezavantajı, fonksiyonların bir hata kodu döndürmesi durumunda artık kendi çalışmalarının sonuçlarını döndürememesidir. Hesaplamaların sonucunun referans parametreler aracılığıyla iletilmesi gerekiyordu. Bu, kodu daha da hantal hale getirdi ve hata sayısını daha da artırdı.