Hataları araştırmayı öğrenme [kapalı]

Bu zorluğun nasıl tanımlanacağından bile emin değilim. Bana bir işe başlamadan önce birkaç potansiyel çalışanın benden yaptıkları testi hatırlatıyor. Odada bir nesne seçerlerdi ve sonra kendime bu nesnenin ne olduğunu belirlemem için sorular sormama izin verilirdi (20 soru gibi). Bu konuda gülünç derecede iyiydim (hayır, alçakgönüllülük için asla yüksek puan almadım), bu yüzden hataları gidermede gerçekten iyi olacağımı varsaymıştım ...

Ama son zamanlarda anladığım şey bu. Bu durumda gerçekten iyiyim çünkü odadaki her şeyi görmek gerçekten kolay, bu yüzden sorunuma bileşen parçalarının bazı konseptiyle yaklaşabilirim. Özünde "bilmediğimi biliyorum". Ancak programlama ile sorunun tam olarak bilinmediği birçok durumla karşılaşıyorum. Kırıldığını biliyorum, ama nasıl kırılacağına dair hiçbir fikrim yok. Tüm talimatları izledim, teknolojiyi oldukça iyi biliyorum ...

Dürüst olursam, yanlış olabilecek şeyleri hayal etmekte zorlandığımı hissediyorum, böylece onları test edebilir ve umarım bir çözüm bulabilirim.

Bu beceriyi nasıl geliştirebilirim? Görünüşe göre, sınırlı hayal gücümün projemin muhtemelen kırılabileceği yollar bulmasına yardımcı olmak için ne yapmam gerekiyor? Beni bu konuda daha iyi hale getirebilecek alıştırmalar var mı? Muhtemelen en büyük tedavinin sadece deneyim olduğunun farkındayım ... ama eğer yapabilirsem süreci hızlandırmaya yardım etmeyi umuyorum. Bilgisayarımın ekranına bir seferde birkaç saat boş bakmak bile eğlenceli değil ...

Yazılımdaki her kusur nihayetinde varsayımlar ve gerçeklik arasındaki tutarsızlıktan kaynaklanmaktadır. Sinsi hatalar, özellikle derinlemesine varsayımlar ve gerçeklik arasındaki tutarsızlıklardır. Hataları teşhis etme yeteneği, kendi varsayımlarınızı sorgulama yeteneğinize bağlıdır ve bu gerçekten de bazı şeyleri bilmediğinizin farkında olmanızı gerektirir , onları varsaydınız ve şimdiye kadar doğruydunuz.

Açıkçası, ticaret araçları, günlük dosyaları, hata ayıklayıcılar vb. Bu varsayımları ortaya çıkarmada ve dünya modelinizi gerçek sistemle yeniden hizalamada yardımcı olur. Ancak, önemli varsayımı sorgulamaya hazır olana kadar, örneğin "Girdi kapsamlı olamaz çünkü kötü girdi olamaz", tüm zamanınızı sistemin yanlış kısımlarını kontrol ederek ya da sadece başka nereye bakacağınızı bilmeden geçirirsiniz. ilk başta.

Görünüşe göre, sınırlı hayal gücümün projemin muhtemelen kırılabileceği yollar bulmasına yardımcı olmak için ne yapmam gerekiyor?

Çoğu durumda, kesinlikle hiçbir şey söyleyemem. Programın bozulmasına neden olabilecek şeyleri hayal etmeye çalışmamalısınız. Sen sistematik edeceğine karar olmalıdır edilir onun kırılmasına yol.

Aşağıdaki bilgilerle hata ayıklama sürecine girmelisiniz:

• hata üretmek için atılan adımlar ve girilen değerler;
• bu adımlar ve girdiler verildiğinde programın ne yapması gerektiği ;
• Program ne olduğunu bu adımları ve girdileri verildiğinde yapıyor.

Bir hata mesajı varsa, bununla ilgili tüm bilgileri alın. Hata mesajının kendisi net değilse ve uygulamada ne anlama geldiğini bilmiyorsanız (bazı hata mesajları her zaman özellikle kullanışlı değildir), daha sonra bu bilgiyi öğrenmek için Google veya StackOverflow veya başka bir çevrimiçi kaynak kullanın .

Ön uçta görüntülenen bir hata mesajı yoksa, hatanın yeniden oluşturulduğu süre boyunca uygulamanın yazdığı günlükleri kontrol edin. Kod tamamlanmak üzere yürütülmüş olabilir, ancak sonuçta ortaya çıkan ve günlüklerde bir girdi oluşturan yol boyunca işlenen bir istisna ile karşılaştı. Bunları arayın, yukarıda aynısını yapın ve ne demek istediklerini tam olarak belirleyin.

Kodunuz tarafından atılan istisnalar içeren yığın izleri varsa (ve olması gerekiyorsa), belirtilen kod satırlarına bakın. Hattın kendisi, konuyu gerçekten oluşturan hat olmayabilir. Bir Java kodu parçası içinde bir NullPointerException alırsanız, stacktrace, olmamasını beklediğinizde null olan bir şeyi nerede kullanmaya çalıştığınızı söyleyecektir. Bu sizi soruna neden olan çizgiyi tam olarak göstermez, ancak genellikle hangi değişkenin beklediğiniz değere sahip olmadığını söyler, bu nedenle değeri belirlemek için bu değişkene yapılan herhangi bir referansa / atamaya bakabilirsiniz. ayarlanmamış veya değerin yanlış ayarlanmış olması.

Bunların hiçbiri yardımcı olmadıysa, hata ayıklayıcınızı ateşleyin. Kodu kodun soruna neden olduğunu bildiğiniz bir bölümüne daralttıysanız - ancak tam olarak hangi satır (lar) ı bilmiyorsanız - bu adımdan geçin. Değilse, sadece her şeyin üzerinden geçin. Bu, programın verilen girdilerle ne yapması gerektiğini tam olarak bilmeniz gereken yerdir, çünkü her satırdan sonra her bir değere bakmanız ve ne yapmayı beklediğinizden tam olarak nerede saptığını belirlemeniz gerekir.

Hala sorunun ne olduğu hakkında bir fikrin yok mu? Birinden yardım isteyin . Bir iş arkadaşı, bir arkadaş, bir çevrimiçi topluluk. Onlara az önce yaptığınız tüm işleri gösterin. Hata mesajlarını, yığın izlerini gösterin, programın genel anlamda ne yaptığını (zaten bilmiyorlarsa), bu özel durumda ne yapması gerektiğini (örn. 4 değerini döndürmek), gerçekte ne yaptığını (örn. 5 değerini döndürme). Hata ayıklayıcıdaki birkaç kod satırına daralttıysanız, "Sorunun koddaki bu satırlardan kaynaklandığını biliyorum, Y olması gerektiğinde değeri X olarak ayarlıyor, ancak göremiyorum neden oluyor ".

Ekranınıza boş bir şekilde bakmak için birkaç saat harcamak kesinlikle eğlenceli değil, ancak bunu yapmanız için hiçbir neden yok. Kodunuzla ilgili bir sorun varsa, kodu okumanız veya adım atmanız gerekir.

Bir dereceye kadar, bir ceza davasını veya akıl almaz bir bulmacayı araştırmak gibidir.

Önce kurbanı yakaladın. Bir süre davaya baktıktan sonra birkaç şüpheli belirlediniz ve ayrıca mağdurun tam olarak nasıl öldürülebileceğini gösteren bir çalışma hipotezi geliştirdiniz. Soruşturmaya devam edersiniz, daha yararlı bilgiler arar, sizi sorunun gerçek kaynağına yaklaştırırsınız.

Zaman zaman çıkmaz bir yere giriyorsunuz (cinas amaçlı). Bu onun bir parçası ve kendinizi mümkün olan en kısa sürede tekrar yoluna sokmayı başardığınız sürece yanlış bir şey yok. Anahtar, her zaman bir sonraki ihtiyacınız olan bilgiyi düşünmek için ya hipotezinizi sağlar (ve size daha fazla bilgi sağlar) ya da yanlış olduğunu kanıtlar. Ardından, bu bilgileri etkili bir şekilde elde etmenin, sonuçlarınızı çıkarmanın ve nihayetinde suçluyu mahkum edene kadar devam etmenin bir yolunu bulun.

Ve bazen, suçluyu tespit etmek için gerekli olan tüm gerçeklerin ve göstergelerin yarım saat önce önünüzde beklediğini fark ediyorsunuz. Rahatsız edici olsa da, bu en ilginç kısımlar arasındadır, çünkü eylemleriniz ve hatalarınız hakkında eleştirel bir inceleme yaparsanız, öğrenebilir ve daha iyi olabilirsiniz . Kendinize aşağıdaki gibi sorular sorun:

• Bu zaman kaybını nasıl önleyebilirdim?
• İlk başta neyi gözden kaçırdım ve neden?
• Hangi onaylanmamış ve / veya yanlış varsayımlara güvendim?

Bu yeteneklerinizi geliştirecek. Aynı zamanda bağırsak içgüdülerinizi de geliştirecektir , bu nedenle zamanla çok kolay göz ardı edilen tüm ufak şeyleri otomatik olarak fark etmeyi öğrenir ve sizi doğru cevaba daha hızlı yönlendirirsiniz. Sonunda, tamamen kasıtlı uygulama ile ilgilidir .

Son olarak, Sherlock Holmes'un bize ne öğrettiğini her zaman hatırlamıyorum: İmkansızı ortadan kaldırdığınızda, ne kadar imkansız olursa olsun, gerçek ne olmalıdır.

Görünüşe göre, sınırlı hayal gücümün projemin muhtemelen kırılabileceği yollar bulmasına yardımcı olmak için ne yapmam gerekiyor?

Tarih sizin rehberiniz olsun. Projeniz iyi yönetiliyorsa , üründe sabitlenmiş olan her hatanın bir veritabanına ve hatanın nasıl bulunduğuna, nasıl yeniden üretildiğine, nasıl analiz edildiğine ve nasıl düzeltildiğine dair bir analiziniz olmalıdır. Bu salt yazılır bir veritabanı değildir. Veritabanını okuyun ve çok yakında hata sınıflandırmaları ortaya çıkmaya başlayacaktır.

Bu, ürününüzde yanlış giden şeylere iyi bir genel bakış sağlayacaktır. Daha genel olarak, her türlü yazılımda nelerin yanlış gittiğiyle ilgileniyorsanız, özellikle güvenlikle ilgili kusurlara vurgu yaparak, CWE listesini okumanızı öneririz: http://cwe.mitre.org/data/index.html

Bu nedenle, belirli bir kusuru yeniden oluşturmaya ve düzeltmeye çalışmak yerine, ürünün bu koşullar altında çalışıp çalışmadığını görmek için ürünü araştırmak için kullanabileceğiniz yeni testleri düşünmeyi düşündüğünüze inanıyorum: kayıt sayfasının şifresi dosyalandı veya veritabanına yazarken programı zorla kapatırsam ne olur? Bu vakaları düşünmek gerçekten zor.

Son 10 yılda yazılım geliştirme (Agile / XP / TDD vb.) Yalnızca açık gereksinimleri karşılamaya ve daha sonra özelliğin bittiğini beyan etmeye ve bir şeyi kırmanın olası her yolunu bulamamaya değer olmuştur (eğer olası istisnalar vardır) NASA için çalışıyor veya beyaz şapka güvenliği yapıyor ancak o zaman bile kullanıcı hikayesinin kabul kriterlerinde bu tür şeyleri çağırmak için bir dava var).

Bu nedenle özellikleriniz, giriş, performans özellikleri, kullanıcı iş akışı eylemleri, vb. Gibi sistemlerin ne yapması gerektiğini açıkça kabul kriterleri olarak listeliyorsa, testlerin kontrol edilmesi gereken şeylerin tam bir listesine sahip olursunuz. Testler, gereksinimlerin karşılandığını doğrulamak için yapılmalıdır ve bunu yapmanın en iyi yolu, tüm gereksinimlerinizi açıkça listelemektir. Çevik Test Dörtgenlerine bir göz atın .

Bazı insanlar bu testlerin koddan önce yazılması gereken şartların açık bir beyanı, yani Önce Test (veya Test Odaklı Geliştirme) olmasını savunurlar.

Bununla birlikte, başlamadan önce kendi geliştirme en iyi uygulamalarınızı ayarlayabileceğiniz ve bunun yerine yazılım yazıldıktan ve 'test etmesi' istendikten sonra gelen yeni bir projeyi düşündüğünüzü sanmıyorum. Bu gerçekten daha zordur, ancak aynı ilkeler geçerlidir, ancak ne yapması gerektiğini bildiğinizde test edebilirsiniz. Çalışmanız için geliştirme ekibi tarafından karşılanan kapsamlı bir gereksinimler listesi yoksa, soru sormak en iyi yoldur. Ekibinize bağlı olarak, bir yazılım sistemi oluşturmadan önce gereksinimlerini açıkça listelemeyen kişiler, neyi kaçırdıklarını hatırlatmayı sevmediğinden, bu görevi iyi bir şekilde yerine getirmek için çok önemlidir.

Bir gereksinim bulduğunuzda - sağlam olmalı / güvenli olmalı, daha derine inmeye çalışın ve ne kadar güvenli olması gerektiğini veya ne kadar başarısızlığın kabul edilebilir olduğunu öğrenin, her zaman bir sınır vardır, birçok insanın NSA kanıtı yoktur güvenlik düzeyi uygulamaları için bir gereklilik olarak veya bunun için ödemek istiyorum. Ne kadar net kazarsanız, ne tür güvenlik saldırılarına karşı savunmanız ya da amaçladığınız kullanım kolaylığı olması gerekir. Bazı alan bilgisi daha sonra yararlı, güvenlikte, tasarımda, performansta vb. Bu, ekibinizde veya burada SE'de veya google / kitaplarda bulabileceğiniz uzmanlardan daha fazla soru soracağınız yerdir.