Kod hata ayıklama yöntemleri (Kabus durumu)

Sık sık işimdeki bir uygulamada hata ayıklamakla görevlendirildim. Test ortamını ve üretim ortamını içeren işletmelere dağıttığımız bir BI Uygulamasıdır. Bu kısıtlamalara dayanarak insanların önerebileceği uygulamalar / araçlar / yöntemler olup olmadığını merak ediyorum:

1. Hata ayıklayıcı, istemci sitesinde veya yerel olarak kullanılamaz, çünkü yazılım, test ortamlarına sahip olmadığımız özel üçüncü taraf uygulamalarına bağlıdır. (DÜZENLEME: adil olmak gerekirse, bazı durumlarda yerel olarak hata ayıklamak mümkündür. Çekirdek kod dışında bir şey kullanmazsak. Sorunlu kodun çoğu üçüncü tarafa özel iletişimi kapsayan bir dll'de bulunur: soketler, proses boruları, sabun çağrıları, Çekirdek kodun davranışını değiştiren özel mantık. Genellikle bir istemci için uygulama veya geliştirme sırasında bu alana yeni bir kod yazardık.)

2. Uygulamalarımızda neredeyse hiç günlük kaydı yok. Birim testi yoktur.

3. Sürüm kontrolü, tam çözümün yalnızca 1 sürümüne sahiptir (2005 safe safe kullanarak). Bu nedenle, tüm çözümün önceki bir sürümünü elde etmek mümkün değildir, sadece tek tek dosyalar. (Birisi bunun yollarını bilmediği sürece).

4. Yerel olarak çoğaltılamaz, çoğu zaman zamanlar test ortamında çoğaltılamaz (Test ve üretimin aynı sürüm olmaması yüksek olasılıktır).

5. İstemcinin kullandığı sürümün kaynak kasadakinden farklı olma olasılığı yüksektir. Bunun nedeni, belirli bir istemci için özel mantık katıştırılmış tek tek dosyaların güncelleştirilmesidir. Çoğu zaman, diğer birkaç ikili dosyada değişiklik gerektiren bir ikili dosyada güncelleme yapılır, ancak bir taahhüt tamamlandığında, hiç kimse bununla ilgili herhangi bir kayıt veya bilgiye sahip değildir. Gördüğüm biraz yaygın bir hata, bir istemci ortamında 'İşlev / Yöntem bulunamadı' veya 'Yöntem çağrısı çok fazla / çok az parametre belirtildi'.

6. Bu bir .net VB çözümüdür

7. İstemci sitelerine herhangi bir yazılım yüklenemez, ancak yerel olarak yüklenebilir

8. Uygulamamız son derece özelleştirilebilir, ancak maalesef özelleştirme mantığı, istemci başına veritabanında yapılan özel değişiklikler de dahil olmak üzere ön uçtan veri katmanına kadar tüm sınıflara ve dosyalara yayılmıştır.

9. Kodda neredeyse hiç yorum yok. Mimari hakkında hiçbir belge yoktur. API hakkında hiçbir belge yok. Sahip olduğumuz tek şey, neler olup bittiğini biraz açıklayan yüzlerce e-posta zinciri. Kodu bilen tek kişi, orijinal olarak onu yazan kodlardır, ancak artık söyleyecek şekilde geliştirici değildirler, bu yüzden çok fazla dahil olmuyorlar.

Ve söylemeden önce ... evet biliyorum; Kendimi de vurmak istiyorum. Spagetti kodu, yüzlerce derleyici uyarısı ve GERÇEKTEN düzeltilmesi gereken kırık polimorfizm olmasına yardımcı olmaz, ancak içinde bir sözüm yok.

Karşılaştığım en yaygın hata türleri null referans hataları, geçersiz dökümler ve eksik işlevler / işlev imza uyumsuzluklarıdır. Bazen şanslıyım ve olay görüntüleyici sınıfı, yöntemi ve istisna mesajını kaydedecektir. En yararlı değil, ama yine de bir şey. En kötüsü, izleme olmayan, ekran görüntüsünün yanı sıra repro adımları olmayan hatalardır ve yukarıda belirtilenler gibi genel hata mesajlarıdır. Bazen neden ortaya çıktıklarını bulmak mümkün değildir, sadece ortamın düzgün yapılandırılmadığından ve daha sonra ortadan kalkacağından dua etmek mümkün değildir.

Bunun biraz rant olarak geldiğini biliyorum ve bir dereceye kadar öyle. Ama seçenekler için umutsuzum. Kullanabileceğim başka yöntemler / araçlar var mı?

Robert Harvey'in tavsiyesi muhtemelen en iyisidir, ancak kariyer tavsiyesi konu dışı olduğundan, hangi cevabı verebileceğimi vereceğim:

Çok dik bir dağın dibindesiniz, bramble ve çamur ve sinirli dağ keçileriyle kaplı. Kolay bir yol yok. Eğer zirveye çıkmak istiyorsanız, her seferinde çok acı verici bir adım atmanız gerekiyor.

Görünüşe göre işlerin nasıl çalışması gerektiğini biliyorsunuz . Eğer başka hiç kimse size yardımcı olmazsa (yine, kariyer tavsiyesini görmezden gelmek) tek seçeneğiniz bu şeyleri kendiniz düzeltmeye başlamaktır.

İlk olarak, kutsal olan her şey için, bunları gerçek bir sürüm kontrol sisteminde alın. Kokuşmuş bir çöp yığını olarak bilinen Source Safe dışında hemen hemen her şey. gitücretsizdir ve oldukça kolay bir şekilde kurulabilir. Geçmiş sürüm kontrolü eksikliğiyle ilgili sorunları çözemezsiniz, ancak en azından sorunun geleceğe devam etmesini durduramazsınız.

Ardından, günlük kaydını inceleyin. Bir günlük sistemi bulun veya en kötü ihtimalle yazın ve kullanmaya başlayın. İstemci sitelerinde de kullanılabilecek bir tane kullanın, böylece işler yanlara gittiğinde en azından bir şeyiniz olur.

Ve en azından yaptığınız yeni değişiklikler için testler yazmaya başlayın.

Şeker kaplaması yoktur: burada çok fazla iş içermeyen veya bunu bir kariyer sorunu olarak ele almayan bir cevap yoktur.

1) Hata ayıklayıcı istemci sitesinde kullanılamaz ...

Bu tamamen normal.

... veya yerel olarak

Şimdi bu bir problem.

2) Uygulamalarımızda neredeyse hiç günlük kaydı yok.

Logging , Üretim Hata Ayıklamasıdır.

Birim testi yoktur.

Ah hayatım. Yine de hepsi ortak.

3) Sürüm kontrolü, tam çözümün yalnızca 1 sürümüne sahiptir

O zaman Sürüm Kontrolü kullanmıyorsunuz.

4) Yerel olarak çoğaltılamaz, çoğu zaman zamanlar test ortamında çoğaltılamaz (Test ve üretimin aynı sürüm olmaması yüksek olasılıktır).

Yani sadece konuşlandırılmış istemci ortamı hataları gösterir.

Bu durumda, uygulama kodu gömülü disgnostic günlüğü gerektiğini, (a) tuzakları ve [tam] kayıtları [ölümcül] hatalar ve (b) olan ek, sürekli, teşhis üretmek için talep üzerine "yukarı çevrilen" olabilir kullanışlı içinde problem (ler) in izlenmesi.

5) İstemcinin kullandığı sürümün, kaynak kasadakinden farklı olma olasılığı yüksektir.

Yine, sürüm kontrolünü kendi yararınıza kullanmıyorsunuz.

8) Bizim uygulama son derece özelleştirilebilir

Bu oldukça tipik.

Siteye özgü farklılıklar Sürüm Kontrolü "Dallanma" yoluyla yönetilmelidir.

9) Kodda hemen hemen hiç yorum yok.

Yine, bu çok yaygın, çünkü Geliştiriciler "kendi kendini belgeleyen" kod yazıyorlar, değil mi?
Ya da en azından, yazdıkları gün anladıkları kodu.

Mimari hakkında hiçbir belge yoktur.

Ah hayatım.

API hakkında hiçbir belge yok.

Ah canım, ah canım.

Ve söylemeden önce ... evet biliyorum; Kendimi de vurmak istiyorum.

Hayır; tüm bunları yazan insanları vurmak, belgelenmemiş, sürdürülemez bir karışıklık yaratmak ve sonra yeni meralara geçmek ve geride bırakılamayan karışıklığı geride bırakmak istiyorsunuz.

Karşılaştığım en yaygın hata türleri null referans hataları, geçersiz dökümler ve eksik işlevler / işlev imza uyumsuzluklarıdır.

Boş başvurular ve geçersiz yayınlar çalışma zamanı hatalarıdır; bir dereceye kadar, onları beklemelisiniz ve onları sık sık aldığınız gerçeği, orijinal yazarlar tarafından savunmacı bir programlama eksikliği (veya iyimserlik fazlası) olduğunu göstermektedir.

İşlev imzası uyuşmazlıkları bozuk bir yapıya neden olmalıdır ; bunlar "kırık yapılara" neden olmalı ve asla kapıdan çıkmamalı!

Günlük kaydı ile başlayın. Bunun en büyük etkisi olacaktır. Kod tabanına Log4Net veya benzeri bir günlük çerçevesi uygulayın. Kodun ne yaptığını günlüğe kaydetmeye başlayın.

Hata ayıklama yerel olarak mümkün olmalıdır. Değilse, meydana gelen sorunların tam bir resmini elde etmek için 3. taraf dlls hata ayıklamak böylece sembol dosyaları (PDB) alma üzerinde çalışın. WINDBG gibi araçlar, sistem çöküyorsa hangi DLL'lerin sorunlu olduğunu gösterebilir. Herhangi bir sunucu, bir çökme olduğunda bellek dökümü alacak şekilde yapılandırılabilir. Temel olarak, sorun ortaya çıktığında neler olup bittiğine dair bir anlık görüntü. Olanlar hakkında ipuçları bulmak için yerel olarak çöplükler incelenebilir. Hata ayıklama mümkün değilse, bunu mümkün kılmak için çalışın. Hata ayıklamak için gerekli adımları belgeleyin. Bazen karmaşık sistemlerde, tamamen hata ayıklamak için çok fazla kurulum gerekir.

Hata izleme ... Birini kullanmıyorsanız, kullanmaya başlayın. Bu, uygun bir sürüm kontrol sistemi ile el ele gider. Temel olarak, kodunuzun hatalarını ve düzeltmelerini izlemeye başlayın. Sistemin bir geçmişini oluşturmaya başlayın.

Statik Kod Analizi yapın. ReSharper gibi bir araca yatırım yapın. Tüm olası boş referans istisnalarını ve diğer kötü kodlama uygulamalarını hızlı bir şekilde gösterecektir. Sadece birkaç tıklama ile kodu daha iyi bir şekilde elde etmenize yardımcı olabilir ve kod biçimlendirme, değişken adlandırma vb. Gibi sıkıcı öğeleri otomatikleştirebilirsiniz.

Refaktör ve Birim testleri. Muhtemelen yazılan kodun çoğunun çok test edilebilir olmadığını varsayacağım, bu yüzden bunun için testler eklemeye çalışmaktan rahatsız olmazdım. Herhangi bir yeni kod, bir test projesi oluşturun ve hem birim hem de entegrasyon testleri yazmaya başlayın. Ünite testleri başarısız olursa derleme başarısız olur. Yani, refactor olarak, testler olmalı. Testlerle ilgili bir şey, herhangi bir yöntemi çağırmak için bir test yazabilir ve tüm uygulamayı veya kod tabanını yüklemeden bu yöntemde hata ayıklayabilir. Bu, sorunların giderilmesine yardımcı olmak için kullanışlıdır.

Aşiret bilgisini gerektiği şekilde belgeleyin. Kod kendi kendine belgelenmelidir, bu yüzden yorumlar çok seyrek olmalıdır, ancak birçok sistem bir şeyler yapmanın "olağandışı" yollarına sahiptir, kodlama WIKI veya başka bir tür gayri resmi depoda bunları işaret eder. Ayrıca, kodlama standartları ve uygulamaları geliştirmeyi düşünün. Resharper gibi bir araç setiyle bu standartları uygulayın. Kodun çoğu muhtemelen herhangi bir standart ve yönergelere uymadığından, standartları yeni kod üzerine uygulayın.

Senin yeni beri, ben bir görev turu gibi davranın. 6 aydan 2 yıla kadar ve sonra kalmayı veya devam etmeyi seç. İşleri bir önceki günden biraz daha iyi hale getirmekten memnuniyet duyun.

İlk olarak, yukarıdakilerin hepsi ... aynen.

Bazı buluşsal yöntemler:

• Geliştirme bilgisayarınızda kaynak kontrolünü kullanın. Yaptığım en iyi şey. Bu, sahip olduğumuz projenin sürüm kontrolünün yerine geçmez. Korkusuzca deney yapma, hackleme, problemleri eşzamanlı olarak bağımsız olarak vb. İnanılmaz bir özgürlük veren bir araçtır.
  • Git ve Mecurial arasındaki fark nedir?
  • Git Mcgyver, Mecurial James Bond
• Zekayı değerlendirmek için yorum eklediğinizde, genel arayüz öğelerine öncelik verin. Hata ayıklama maceralarınız sırasında deşifre ederken bunu yapın.
• Küçük düzeltmelerde ısrarcı olun. Er ya da geç, belirli bir kod yığını için, sınıflar arasında gereksiz kod KURMA gibi büyük yeniden düzenlemelere olanak tanıyan kritik bir kütleye ulaşacaksınız.
• Kod yeniden biçimlendirmesini ve gerçek değişiklikleri aynı sürüm denetiminde karıştırmayın.
• KATI prensipler
  • Asla tek bir sorumluluğu göz ardı etmeyin. Aferin, bu nesneye yönelik vaat yoludur ; BENİM NACİZANE FİKRİME GÖRE.
  • Her zaman Açık / Kapalı'yı dikkate almayın.
  • Burada yeni kod konuşmuyoruz.
  • Amaçlı tasarım olmadan arayüzler yapmak bakım gerektirmez.
• üstlenmeden
  • Bunun için bir metodoloji var. Kitabı satın al.
  • Yeniden Düzenleme: Mevcut Kod Tasarımını Geliştirmek
• Bazı kod dosyaları, hata ayıklamaya başlamadan önce tam yeniden biçimlendirme, değişken yeniden adlandırma vb. Visual Studio'nun refactor menüsünü birim testleri olmadan kullanmaktan çekinmeyin.
• Yanlış yerleştirilemeyen tek belge kod dosyalarındadır.
• Eğer sürüm kontrolü olsun VC planına önceden vermek vermek. Ve belgeleyin! Ve büyük yazılım sürümlerini ve kilometre taşlarını vurgulayacak dallar, etiketler için bir adlandırma kuralı geliştirin.
• İyi ekipman kullanın
  • Dönen bir monitör alın. Dikey, kodu hızlı bir şekilde okumanın yoludur.
  • Yedeklemeler için harici sürücü , doğru tuşlara sahip klavye , çok fonksiyonlu fare. En az 1 gerçekten iyi bir USB sürücü. Kendi Herman Miller sandalyem bile var .
  • Çok iyi bir karşılaştırma yazılımı edinin. Beyond Compare ile mutluyum .
• Rubber Ducky Hata Ayıklama Uygulaması
• Bazen olabilecek en kötü şey, sizi kovmamalarıdır.

Düzenle

.NET'te Brownfield Uygulama Geliştirme

Bu kitabı deneyin. Okumayı kapsayan ilk kapak muhtemelen en iyisidir. Bu kitap, büyük resmi, olasılıkları ve hem stratejik hem de taktik saldırı planlarını geliştirmeyi düşünmenize yardımcı olacaktır.

Çıkarma

Mümkünse 1.5 yıl kalın; deneyimsel ilerleme kaydettiğinizi bilmek için yeterince uzun. 2 yıllık deneyim veya 6 aylık deneyim 4 kez alıp almadığınızı bileceksiniz.

"1/2 yıllık tecrübesi ile genç" olmak Potansiyel bir işverenin bunu kesmek için erken kurtarma olarak göreceğinden endişe ediyorum. Z, y, x öğrendiğinizi, bazı isimler aldığınız ve bazı kıçlarınızı tekmelediğinizi söylemek yeterli ama yeteneklerinize katkıda bulunmanıza izin verilmedi; ve bir diğeri de açıklama yoluyla işi, kodu, yönetimi vb.

Bu temelden uzak olabilir ama benim "en iyi ve en kötü zaman" tam anlamıyla sürdürülemez kod oldu 1 işim oldu. Bana bazı önemli programları yeniden yazmak için yer verdi büyük bir amiri vardı (geri kalanı yönetim üreme programı). Bu deneyim vahiydi.

son Düzenle

İlk önce düzeltmeniz gereken (5) olduğunu söyleyebilirim. Hangi kodun üretimde çalıştığını bilmiyorsanız, sorunları yeniden oluşturmanın ve çözmenin güvenli bir yolu yoktur. Bu, ortaya koyduğunuz diğer değişiklikleri tehlikeli hale getirir, çünkü öngöremediğiniz ve yeniden üretemeyeceğiniz sorunlara neden olabilir.

Hangi kod sürümlerinin ve hangi kitaplıkların dağıtıldığını anlamak için biraz dedektiflik çalışması ve belki de tersine mühendislik yapmanız gerekebilir. (Ayrıca, dağıtılan tüm kodun kaynak kontrolü ile uyumlu hale getirilmesi için tutarlı bir derleme ve dağıtım sistemine sahip olmanız gerekir.)

Çeşitli dağıtımları çoğaltmak için birden çok test ortamı oluşturmanız gerekebilir. (Tabii ki en basit düzeltme, yeni bir temiz yapı oluşturmak ve onu her yere tutarlı bir şekilde dağıtmaktır, ancak bu mümkün değil mi?)

Yalnızca tam sürümlerin dağıtıldığını ve karşılık gelen test ortamlarına sahip olduğunuzu bildiğinizde, kodu düzeltmeye / iyileştirmeye çalışmalısınız.

Bir sonraki önceliğiniz, her yere dağıtılabilen tek bir kod tabanıyla birleştirmek olmalıdır. Özelleştirme nedeniyle çeşitli kod sürümlerinin dağıtıldığı anlaşılıyor mu? Tek bir sürüme birleştirmeniz ve ardından özel mantık için yapılandırma anahtarlarını kullanmanız gerekir.

Bundan sonra, daha kolay hata ayıklamaya izin vermek için kod tabanını dikkatlice geliştirmeye başlayabilirsiniz. Günlük eklemek muhtemelen en az riskli gelişmedir.

Otomatik testler eklemek isteyeceksiniz, ancak başlangıçta test için tasarlanmamış bir projeye birim testler eklemek genellikle zordur. Bunun yerine otomatik uçtan uca entegrasyon testleriyle başlamanızı öneririm. Bunlar kurulumu daha zordur, ancak çözümü yeniden yapılandırmanızı gerektirmez, bu nedenle daha az risklidir.

Ekibinizdeki sorunları göz ardı ederek, ele alınacak ilk konu, üretimdeki kodla eşleşen kodu ayıklamak gibi görünüyor. Aksi takdirde, "Kaynak kontrolünüzde" bulunan kodda önceden düzeltilmiş bir hatayı takip ediyor olabilirsiniz. Bu .NET olduğu için kolayca kod sahip olan ile karşılaştırmak için üretim ikili dosyaları "koda" olabilir. Bu kolay bir görev değil, ancak başarılı olursanız, yayınlanan sürümleri etiketleyebilen daha iyi bir kaynak kontrol aracı için güçlü bir argüman.