Programlama korkunç, her gün hatalar yazıyoruz
Geliştiriciler olarak hata yazma yolundayız, ancak en iyisi ne tür bir koddur? Hata ayıklama için doğru duruşta nasıl ustalaşılır?
Silmesi ve hata ayıklaması kolay bir kod yazın
Hata ayıklanabilen kod, beyniniz kadar akıllı olmayan kod olmalıdır. Gerçek hayatta her zaman, gizli davranışa sahip kod, zayıf hata işlemeli kod, belirsiz anlamı olan kod, çok düşük veya çok yüksek yapıya sahip kod veya değiştirme işlemi gibi hata ayıklaması kolay olmayan bazı kodlarla karşılaşırız. Kodda. Projenin boyutu yeterince büyükse, sonunda anlayamadığınız bir kodla karşılaşırsınız.
Eski projelerde, hangi kodu yazdığınızı hatırlamazsınız, eğer commit günlüğü için olmasaydı, bunların başkaları tarafından yazıldığını düşünebilirsiniz. Projenin boyutu büyüdükçe, kodun her bir parçasının işlevini hatırlamak gittikçe zorlaşıyor ve kodun davranışı beklentilerle tutarsızsa daha da zorlaşıyor. Anlamadığınız kodu değiştirirken, yalnızca içeri girmenin en zor yolunu kullanabilirsiniz: hata ayıklama .
Hata ayıklaması kolay kod yazmanın ilk adımı, yazdığınız tüm kodu unutacağınızı fark etmektir. İkinci olarak, aşağıdaki kurallara uymalıyız:
İyi kodun dezavantajları da vardır
Birçok misyoner, anlaşılması kolay kod yazmanın temelde temiz kod yazmak olduğunu söylüyor. Bu cümlenin kilit noktası, anlamı tamamen bağlama bağlı olan "temiz" kelimesidir. Bazen temiz kodun nedeni, kötü kodun başka bir yere yazılmasıdır. Bu nedenle, iyi kod mutlaka temiz kod değildir.
Kodun temiz veya kirli olup olmadığı, bakımı veya değiştirilmesinin kolay olup olmadığını değerlendirmek yerine, aslında bir geliştirici olarak özgüveninizi veya utancınızı değerlendiriyor. Bu nedenle, aradığımız şey temiz kod değil, açık bir modifikasyon yöntemi ile "sıkıcı" koddur. Ulaşılabilecek herhangi bir değişikliğe sahip bu tür kodların başkalarının katkıda bulunmasının daha kolay olduğunu görüyorum. Bu nedenle, en iyi kod, hızlı bir şekilde çözülebilen koddur:
- Çirkin soruları güzel göstermeyi veya sıkıcı soruları ilginç kılmayı düşünmeyin.
- Hatalar açık olmalı ve davranış net olmalıdır. Bariz hatalar ve belirsiz davranışlar olmadan koda ihtiyacımız yok.
- Kodun dokümantasyonunun mükemmel olmasına gerek yoktur.
- Kodun davranışı çok açıktır ve herhangi bir geliştirici onu değiştirmenin sayısız yolunu düşünebilir.
Bazen kod iğrenç görünür, ancak onu değiştirmeye yönelik herhangi bir girişim onu daha da kötüleştirir. Sonuçlarını anlamadan temiz kod yazmak, bakımı yapılabilir kodu toplamaya çalışmakla eşdeğerdir.
Temiz kod kötü değildir, ancak bazen temiz kod yazmak daha çok kiri bir halının altına saklamak gibidir. Hata ayıklanabilir kodun temiz olması gerekmez ve hata denetimi ve işlemeyle dolu kodun okunması genellikle hoş değildir.
Bilgisayar her zaman çökecek
Bilgisayar her zaman takılır ve program en son çalıştırıldığında her zaman kilitlenir.
Bir programcının yapması gereken ilk şey, başka bir iş yapmadan önce başlangıçta bilinen, iyi ve güvenli bir durumu sağlamaktır. Bazen kullanıcı silme, bilgisayar yükseltmesi vb. Nedenlerle durum temiz değildir. Program en son çalıştırıldığında çökecek ve tekrar başlatıldığında çelişkili bir duruma düşmemelidir, ancak her zaman ilk çalıştırma kadar temiz olacaktır.
Örneğin, bir dosyadan durumu okumak ve yazmak isterseniz, aşağıdaki bir dizi sorun ortaya çıkabilir:
- Dosya eksik;
- Hasarlı dosyalar;
- Dosya eski bir sürüm veya programdan daha yeni bir sürümdür;
- Dosyada yapılan son değişiklik tamamlanmadı;
- Dosya sistemi yanlış veri döndürdü;
Bunlar yeni konular değil, veri tabanı sistemi bu konularla zamanın başından beri (1 Ocak 1970) ilgilenmektedir. SQLite gibi şeyleri kullanmak birçok benzer problemle başa çıkmanıza yardımcı olacaktır, ancak program son çalıştırıldığında çöktüyse, kod çalıştığında yanlış verilerle karşılaşabilir veya yanlış şekilde çalışabilir.
Örnek olarak düzenli çalışan bir programı ele alırsak, aşağıdaki kazaların yaşanacağını garanti edebilirim:
- Yaz saati uygulaması, programın aynı anda iki kez çalışmasına neden olur;
- Operatör çalıştırıldığını unuttuğu için iki kez çalışır;
- Makinenin dolu disk alanı veya gizemli ağ sorunları nedeniyle bir çalışmayı kaçırdınız;
- İşlem süresi bir saati aşıyor ve sonraki işlemin gecikmesine neden oluyor;
- Günün yanlış saatinde koş;
- Aritmetik hatalara kaçınılmaz olarak sınır saatlerinde (gece yarısı, ay sonu, yıl sonu gibi) neden olur.
Sağlam yazılım yazmanın ilk adımı, son çalıştırmanın sonucunun bir çökme olduğunu varsaymaktır ve nasıl ilerleyeceğinizi bilmediğinizde aktif olarak kilitlenmeniz gerekir. Bir istisna atmanın en iyi yolu, istisnaya "Bu durum olmamalıdır" gibi bir yorum bırakmaktır, böylece bir kez gerçekleştiğinde, hata ayıklamaya nereden başlayacağınızı bilebilirsiniz.
Hata ayıklaması kolay olan kod, işlemleri gerçekleştirmeden önce durumun doğru olup olmadığını kontrol etmelidir, kolayca bilinen iyi bir duruma dönebilir ve tekrar deneyebilir ve hataları mümkün olan en kısa sürede ortaya çıkarmak için birden çok savunma katmanına sahiptir.
Kod kendisiyle savaşacak
Google'ın en büyük DoS saldırısı kendisinden geliyor. Sistemimiz çok büyük İnsanlar her zaman sistemimizi stres testi için ücretlendirmeyi önermiş olsalar da, bu iş için en uygun kişi olduğumuza inanıyoruz.
Bu, herhangi bir sistem için geçerlidir.
-Astrid Atkinson, Long Game mühendisi
Yazılım her zaman en son çalıştırıldığında çökecek, her zaman tüm CPU'ları kullanacak, tüm belleği kaplayacak ve tüm sabit sürücüleri kullanacaktır. Tüm çalışan işlemler boş kuyruklarla karşılaşacak, her işlem zaman aşımına uğramış ağ isteklerini yeniden deneyecek ve tüm sunucular aynı anda çöp toplama için askıya alınacaktır. Sistem sadece yok edilmekle kalmayacak, aynı zamanda her an kendini yok etmeye çalışacaktır.
Sistemin gerçekten çalışıp çalışmadığını kontrol etmeye çalışmak bile çok zor olabilir.
Sunucunun çalışıp çalışmadığını kontrol eden kodu uygulamak kolaydır, ancak sunucu isteği işleyemezse, o kadar kolay değildir. Çalışma süresini kontrol etmediğiniz sürece, kontroller arasında programın çökmesi mümkündür. Sağlık kontrolleri de hataları tetikleyebilir: Bir keresinde bir sağlık kontrolü kodu yazmıştım, ancak üç ay sonra kod, koruduğu kodu iki kez bozdu.
Yazılımda, hata işleme kodu yazmak, kaçınılmaz olarak, çoğu hata işleme kodunun kendisinden kaynaklanan, ele alınması gereken daha fazla hataya yol açacaktır. Benzer şekilde, performans optimizasyonu genellikle sistemin darboğazı haline gelir ve uygulamaların bir etiket içinde sorunsuz çalışmasına izin vermek, aynı anda 20 kopya çalışırken kullanımı zorlaştırabilir.
Başka bir örnek, ardışık düzen içindeki bir çalışan işlemin çok hızlı çalışması ve ardışık düzen içindeki bir sonraki adım yürütülmeden önce tüm belleği tüketmesidir. Araba ile benzerlik, trafik sıkışıklığıdır. Trafik sıkışıklığının suçlusu hızlanıyor ve trafik sıkışıklığı, trafik akışında geriye doğru hareket eden sıkışık kısım olarak düşünülebilir. Optimizasyon, sistemin yüksek basınç altında gizemli bir şekilde çökmesine neden olabilir.
Diğer bir deyişle, süreç ne kadar hızlı olursa, ertelemek o kadar zor olur ve sistem süreci erteleyemezse, o zaman bir çökme kaçınılmazdır.
Geri basınç, sistemdeki bir geri bildirim türüdür ve hata ayıklaması kolay programlar, kullanıcıların, sistemin tüm kasıtlı veya kasıtsız, gerekli veya istenmeyen davranışlarını görüntülemek için geri bildirim döngüsüne katılmasına izin verebilir. Ayarlanabilir kodun incelenmesi kolaydır, böylece içinde olan her şeyi gözlemleyebilir ve anlayabilirsiniz.
Şimdi çözemezseniz, daha sonra hata ayıklamanız gerekecek
Diğer bir deyişle, programdaki değişkenlerin anlamlarına bakmak ve ona ne olduğunu anlamak zor olmamalıdır. Bir tür doğrusal cebir kullanarak, kodun durumunu mümkün olan en net şekilde ifade etmek mümkün olmalıdır. Başka bir deyişle, programdaki değişkenlerin anlamını değiştirmeye benzer şeyler yapmayın, yani bir değişkeni iki farklı amaç için kullanın.
Bu aynı zamanda yarı-yüklem probleminden kaçınmak anlamına gelir, yani bir çift değeri (boolean, count) temsil etmek için asla bir değişken (sayı) kullanmayın. Sonucu belirtmek için pozitif bir sayı döndürmek ve eşleşme olmadığını belirtmek için -1 döndürmek gibi şeyler yapmayın. Nedeni çok basit, "0, ancak gerçek" bir gereksinim olabilir (belirtilmesi gerekir, Perl 5 bu işleve sahiptir) veya yazılan kodun sistemin diğer bölümleriyle birleştirilmesi zordur (sonraki program için) Başka bir deyişle, -1 geçerli bir giriş olabilir, bir hata olmayabilir).
Bir değişkeni iki amaç için kullanmaya ek olarak, bir amaç için iki değişken kullanmak da eşit derecede kötüdür, özellikle her ikisi de boole ise. Bir aralığı temsil etmek için iki değer kullanmanın kötü olduğunu söylemiyorum, ancak programın durumunu temsil etmek için birden çok Boolean değeri kullanma durumu olduğunu söylemiyorum. İkincisinin özü genellikle bir durum makinesidir.
Durumun akışı yukarıdan aşağıya, örneğin bir döngü gibi değilse, o zaman durum için bir değişken tanımlamak ve mantığı temizlemek en iyisidir. Bir nesnenin içinde birden çok Boolean değeri varsa, bunları state adlı bir enum değişkeni (veya kaydetmeniz gerekiyorsa bir dizeyle) değiştirebilirsiniz. İf ifadesi, if bad_name! Alternate_option yerine state == name gibi yazılabilir.
Durum makinesi açıkça yazılmış olsa bile, kötü kod yazmak mümkündür: bazı kodlar iki durum makinesi içerebilir. Her bir durum makinesini açıkça yazana ve bağlantı durumunu ve ayrıştırma durumunu ayrı ayrı izleyene kadar bir HTTP proxy yazarken büyük zorluklarla karşılaştım. İki durum makinesi bir arada birleştirilirse, yeni durumlar eklemek veya mevcut durumu yargılamak zordur.
Bu makale, hata ayıklamayı kolaylaştırmaktan ziyade kodun hata ayıklanmasını nasıl engelleyeceğiyle ilgilidir. Geçerli durumları listelemek, yanlışlıkla bir veya iki geçersiz durumun geçmesine izin vermek yerine geçersiz durumları reddetmeyi kolaylaştırır.
Kasıtsız davranış beklenen davranıştır
Bir veri yapısı hakkında derinlemesine bir anlayışa sahip değilseniz, kullanıcılar boşlukları doldurur, böylece kodunuzun kasıtlı veya kasıtsız olası herhangi bir davranışı sonunda bir yerde görünecektir. Örneğin, birçok ana programlama dilinin karma tabloları vardır. Çoğu durumda, karma tablolar genellikle çapraz geçiş yaparken ekleme sırasını korur
Bazı diller, anahtarların eklenme sırasına göre geçiş yaparak karma tablonun mümkün olduğunca çoğu kullanıcının beklentilerini karşılamasına izin verir, ancak diğer diller her geçişte tamamen farklı bir sırayla geri dönecektir. İkinci durumda, bazı kullanıcılar bu davranışın yeterince rastgele olmadığından şikayet edeceklerdir.
Ne yazık ki, programdaki herhangi bir rasgelelik, sonunda istatistiksel simülasyon işlemi için kullanılacak veya daha kötüsü, şifreleme için kullanılacak ve en sonunda herhangi bir sıralama, sıralama için kullanılacaktır.
Veritabanında, bazı tanımlayıcılar diğerlerinden daha fazla bilgi içerir. Bir tablo oluştururken, geliştiriciler farklı türleri birincil anahtarlar olarak kullanabilir. Doğru yol, UUID veya UUID'ye benzer bir şey kullanmaktır. Diğer türler yalnızca benzersizlik sağlamakla kalmaz, aynı zamanda düzen de sağlar, yani yalnızca a == b sağlamaz, aynı zamanda bir < = b, hatta bazıları doğrudan otomatik artış türünü kullanır.
Otomatik artış türü, tabloya her yeni satır eklendiğinde otomatik olarak 1 artar. Bu, belirsiz bir düzene yol açar - insanlar verilerdeki hangi niteliğin sıralama için bir kıyaslama olarak kullanılabileceğine karar veremez. Başka bir deyişle, anahtar değerine göre mi yoksa zaman damgasına göre mi sıralamalıyız? Daha önce bahsedilen karma tablo gibi, insanlar doğru yaklaşımın ne olduğunu düşündüklerine kendileri karar verecekler. Bu yaklaşımla ilgili diğer bir sorun, kullanıcıların birincil anahtarın yakınındaki diğer kayıtları kolayca tahmin edebilmesidir.
Sonunda, UUID'den daha akıllı olduğunu düşünen herhangi bir çözüm yanlışlıkla kendinize zarar verecektir. Posta kodlarını, telefon numaralarını ve IP adreslerini denedik ve hepsi başarısızlıkla sonuçlandı. UUID, kodda hata ayıklamayı kolaylaştırmayabilir, ancak daha az kasıtsız davranış, daha az kaza anlamına gelir.
İnsanların birincil anahtardan aldıkları bilgiler, siparişten daha fazlasıdır. Veritabanının birincil anahtarı diğer alanlar aracılığıyla oluşturulmuşsa, insanlar diğer verileri atacak ve diğer verileri yeniden yapılandırmak için doğrudan birincil anahtarı kullanacaktır. Yani iki sorun var: programın durumu ikiden fazla yerde saklanıyor ve ikisi tutarsızlıklara meyilli. Hangisinin değiştirildiğini ve hangisinin değiştirilmesi gerektiğini belirleyemezseniz, senkronizasyon imkansızdır.
Kullanıcıların ne yapmasına izin verirseniz verin, sonunda yapacaklardır. Hata ayıklanabilir kod yazmak, verilerin ne zaman kötüye kullanıldığını önceden düşünmek ve başkalarının verileri nasıl kullanabileceğini düşünmek anlamına gelir.
Devreye alma önce sosyal bir süreç, ardından teknik bir süreçtir
Bir yazılım projesi birden fazla bileşene ve sisteme bölündüğünde, hataları bulmak genellikle çok zor hale gelir. Hatanın nedenini anladıktan sonra, genellikle hatayı düzeltmek için birden fazla ekiple koordinasyon içinde olmak gerekir. Büyük bir projede bir projeyi değiştirmenin ana görevi, hataları bulmak değil, başkalarını hatanın var olduğuna ikna etmek, hatta diğerlerini hatanın düzeltilebilir olduğuna ikna etmektir.
Yazılımın her yerinde hatalar vardır, çünkü hatalardan kimin sorumlu olduğundan kimse emin değildir. Diğer bir deyişle, sorumluluklar net değilse, kodda hata ayıklamak zor olacaktır.Her şey önce Slack'e (sohbet grubu aracı) sorulmalıdır ve bu sorular ancak gerçekten bilen biri çevrimiçi olduktan sonra cevaplanacaktır.
Planlar, araçlar, süreçler ve belgeler, bu sorunu çözmenin anahtarıdır.
Planlama beklenmedik baskıyı önleyebilir ve planlı bir yapı kazaları yönetebilir. Plan, müşterinin projenin ilerlemesini anlamasına, gerektiğinde personeli değiştirmesine, sorunları takip etmesine ve gelecekteki riskleri azaltmak için değişiklikler yapmasına olanak tanır. Araçlar, iş için gerekli becerileri azaltarak başkalarının işi tamamlamasına izin verebilir. Süreç, bireysel kontrole güvenmekten kaçınabilir ve kontrolü takıma iade edebilir.
İnsanlar değişecek, iletişim değişecek, ancak süreç ve araçlar ekibe aktarılacak. Bu, ikincisindeki değişikliklerin öncekinden daha önemli olduğu anlamına gelmez, ancak birincideki değişikliklerin ikincisini inşa ederek desteklenmesi gerektiği anlamına gelir. Süreç, ekip kontrolünü ortadan kaldırmada da rol oynayabilir, bu nedenle iyi ve kötü arasında bir ayrım yoktur, ancak her zaman işe yarayacak bazı süreçler vardır, yazılı olmasa bile, belgeleme eylemi başkalarının onu değiştirmesi için ilk adımdır.
Belgeler sadece .txt değildir: belgeler sorumlulukların nasıl yerine getirileceği, yeni gelenlerin nasıl hızlandırılacağı ve değiştirilen içeriğin bu değişikliklerden etkilenenlere nasıl iletileceği ile ilgilidir. Belge yazmak, kod yazmaktan daha fazla duygusal iletişim ve daha fazla beceri gerektirir.Kod gibi doğruluğu sağlamak için basit derleyici etiketleri veya yazım denetleyicileri gerektirmez ve birçok saçma belge yazmak kolaydır. .
Belgeleme olmadan, insanların akıllıca kararlar almasını ve hatta yazılım kullanmanın sonuçlarını kabul etmesini nasıl bekleyebilirsiniz? Dokümantasyon, araçlar veya süreçler olmadan, bakım yükünü paylaşmak ve hatta görevden halihazırda sorumlu olan personeli değiştirmek imkansızdır.
Basitleştirilmiş hata ayıklama, programlama süreci ve diğer kodların kendisi için de geçerlidir.Hatayı düzeltmek için nerede durmanız gerektiğini bulmanız gerekir.
Hata ayıklaması kolay kodun açıklanması kolaydır
Hata ayıklamada yaygın bir durum, sorunu başkalarına açıklarken sorunu çözmenin anahtarını keşfetmektir. Bu nedenle, orada kimse olmasa bile, durumu, sorunu ve onu baştan yeniden üretme adımlarını açıklamaya kendinizi zorlamalısınız. Genellikle bu süreç cevabı bulmamız için yeterlidir.
Yardım istediğimizde, çoğu zaman konuyu kaçırırız ve ben de herkes kadar depresyondayım - aslında bu yaygın ve can sıkıcı bir sorudur. Bir adı vardır: "XY sorusu": Dosya adının son üç harfini nasıl alabilirim? Oh? Hayır, söylemek istediğim dosya uzantısının nasıl alınacağı.
Anladığımız çözümlerden sorunlar hakkında konuşur, fark ettiğimiz sonuçların çözümlerini tartışırız. Hata ayıklama, istenmeyen sonuçları anlamanın ve alternatif çözümler bulmanın zor bir yoludur Hata ayıklama aynı zamanda programcıların yapması gereken en zor şeylerden birini içerir: yanlış olduklarını kabul etmek.
Sonuçta, bu bir derleyici hatası değildir.
Orijinal: https://programmingisterrible.com/post/173883533613/code-to-debug
Eser sahibi: tef
Çevirmen: Crescent Moon, Kurgu: Tu Min
"Belgeler için çağrı"
CSDN halka açık hesabı, "on binlerce teknik insanla büyüme" kavramına bağlıdır. Teknik insanların ilk kez ilgilendikleri endüstri odak olaylarını teknik insanların benzersiz bakış açılarından tanımlamak için yalnızca "inek başlıkları" ve "konuşma" sütunlarını kullanmakla kalmaz, aynı zamanda "Teknoloji Başlıkları" sütunu, sektördeki popüler teknolojilerin ve uygulamaların derinlemesine bir yorumunu sunarak, tüm geliştiricilerin teknolojik trendlere ayak uydurmasına, uyanık bir teknolojik anlayışı sürdürmesine ve sektör eğilimleri ve teknolojileri hakkında daha kapsamlı bir anlayışa sahip olmasına olanak tanır.
Yüksek kaliteli makaleleriniz veya sektörün sıcak olayları, teknoloji trendleri hakkında içgörüler veya derinlemesine uygulama uygulamaları, senaryolar vb. Hakkında yeni içgörüleriniz varsa, gönderimler için lütfen CSDN ile iletişime geçin. İletişim: WeChat (guorui_1118, lütfen gönderim + ad + şirket pozisyonunu not edin), e-posta (guorui@csdn.net).
