Yazılım mühendisliğinin Kutsal Kase'sini soruyorsunuz ve henüz kimsenin bu sorunun cevabını "henüz" bilmiyor.
Önemli olan, yaptığınız hata türlerini izlemeniz ve ardından ortak bir eğilim olup olmadığını belirlemek için bu hataların bir analizini yapmanızdır. Kök neden analizi bu tür bir iç gözlemin resmi adıdır ve web üzerinde bununla ilgili çok fazla materyal vardır.
Profesyoneller bir hata takip sistemi kullanırlar, böylece (1) neyin düzeltilmesi gerektiğini bilirler, (2) olaydan sonra neyin düzeltilmesi gerektiğini analiz ederler. Resmi olmanıza gerek yok - not defterinde bir taksit tutmak sadece sizin için iyi olabilir.
Tasarım Aşaması Hataları
Hatalarınızın çoğunun sorun bildiriminin yanlış anlaşılmasından kaynaklandığını tespit ederseniz veya sorunların çözümünde izlenmesi için yanlış algoritmayı veya yolu seçtiğinizi sürdürürseniz, tasarım aşamasında sorunlarınız olur.
Projenin başlangıcında daha fazla zaman ayırmanız ve tam olarak ne yapılması gerektiğini ve nasıl yapması gerektiğini yazmanız iyi olacaktır. Bu çalışmayı dikkatlice gözden geçirin ve asıl problemi tekrar gözden geçirin ve doğru şekilde ele alıp almadığınızı belirleyin. Başlangıçta fazladan bir veya üç saat, yolun aşağısında sizi saatlerce koruyabilir.
Kodlama Hataları
Tasarımınız sağlamsa, ancak kodladığınız dille sürekli olarak savaşıyorsanız, kendinize kodunuzu analiz edecek ve sizi erken ve sıklıkla hata yaptığınız konusunda uyaracak bazı araçlar edinin.
C dilinde programlama yapıyorsanız, tüm derleyici uyarılarını açın, benzer bir anlam denetleyicisi lintkullanın ve valgrindgenel dinamik bellekle ilgili sorunları yakalamak için bir araç kullanın .
Eğer Perl programlama yapıyorsanız, açmak strictve warningsne yazdığını ve heed.
Hangi dili kullanıyor olursanız olun, hata ayıklama aşamasına gelmeden çok önce yaygın hataları yakalamanıza yardımcı olacak birçok araç vardır.
Entegrasyon Aşaması Hataları
İyi modülerlik uygulamalarından sonra kodunuzu geliştirirken, ayrı parçaları birbirine yapıştırmaya başlamanız gerekir. Örneğin, kodunuzun farklı bölümleri kullanıcı girişi, veritabanı etkileşimi, veri görüntüleme, algoritmalar / mantık ile ilgili olabilir ve bunların her biri birbirinden göreceli olarak bağımsız inşa edilmiştir (yani, eldeki bölüme konsantre olma eğilimindedir). her şeyle entegrasyon hakkında endişelenmek yerine).
Test güdümlü geliştirme (TDD) çok kullanışlı geliyor burada. Kodunuzun her modülü nasıl tasarlandıklarına göre çalıştıklarını doğrulayan testlere sahip olabilir. Bu testler işlemin başında veya çok erken yazılmalıdır, böylece sizi dürüst tutacak bir dizi "yardımcı" alabilirsiniz. Her şeyin birlikte çalışmasını sağlamaya başladığınızda ve bunun veya bunun nasıl uygulandığını değiştirmek veya başka bir alt sistemle etkileşime girmek zorunda kaldığınızı fark ettiğinizde, yaptığınız şeyi yaptığınızdan emin olmak için testlerinize geri dönebilirsiniz. hepsi birlikte çalışmak kodun doğruluğunu kırmaz.
Ve bunun gibi...
Yazılım mühendisliği ve pratik kodlama teknikleri ile ilgili bazı kitaplar edinin; böylece gelişimi daha az kaotik ve daha güvenilir hale getirmenin birçok farklı yolunu öğreneceksiniz. Ayrıca, sadece eski tecrübenin - sert vuruş okulundan bir derece kazanmanız - sizi de forma sokacağını göreceksiniz.
Neredeyse her şeyin kaynaştığı şey, biraz zaman ve açık sözlü çalışmanın, daha sonra geliştirme / bırakma sürecinde büyük kâr payları ile karşılanmasıdır.
Bu sorunları kariyerinizde çok erken fark ettiğiniz gerçeği geleceğiniz için iyi konuşuyor ve size başarılar diliyorum.