Harika bir yazılım nasıl oluşturulur

Bu yazıda, şirketimin kaçındığı en önemli 10 yazılım geliştirme yanılgısını açıklayacağım. Bu efsanelerden kaçınarak ve mükemmelliğe odaklanarak, mükemmel kalitede yazılımlar yapabiliyoruz.

Efsane 1) Yazılım, geliştirme başlamadan önce detaylı bir şekilde tasarlanmalıdır, böylece net bir plan ortaya konabilir.

Gerçek) Bir tasarım ne kadar karmaşıksa, tasarımın kendisi de o kadar yazılıma benzer. Bir tasarımı mükemmelleştirerek ve ardından yazılımı o tasarıma yazarak, işi etkili bir şekilde iki kez yazarsınız. Bunun yerine, kitap benzeri bir tasarım yerine sadece bazı basit tasarım çizimleri ve veri modelleme yaparak, iyi bir geliştirme ekibi yazılım için bir kabuk oluşturabilir ve onu bitmiş ürüne doğru verimli bir şekilde iyileştirebilir. Bu iyileştirme süreci doğal prototipler yaratır, bir tasarım tarafından öngörülemeyecek sorunlar ortaya çıktığında (veya bir müşteri tarafından yeni endişeler olarak dile getirildiğinde) kolay adaptasyona olanak tanır ve toplam süreç önemli ölçüde daha az zaman alır. Bunu başarmak yakın bir ekip, beceri ve deneyim gerektirir, ancak çoğu durumda en iyi seçenek budur.

Efsane 2) Programcılar, tasarımcılar, analistler ve kullanıcılar vardır.

Gerçek) Geliştirmeyi yapılandırarak, tüm geliştiricilerin geliştirme sürecinin her bir bölümüne biraz maruz kalması için beceriler paylaşılabilir ve daha fazla içgörü kazanılabilir. Geliştiriciler yazılımı gerçekten kullanmaya teşvik edilirse, bu uzmanlığı, aksi takdirde gün ışığına çıkmayacak iyileştirmeleri düşünmek için kullanabilirler.

Efsane 3) Mutlu bir ekip, üretken bir ekiptir.

Gerçek) Çok çeşitli doğal becerilere, deneyime ve endişeye sahip, birbirini eleştiren ve en küçük ayrıntılar üzerinde ateşli bir şekilde tartışan bir ekip, aksi takdirde asla üstesinden gelinemeyecek sorunları ortaya çıkaracak ve çözecektir. Acımasız bir argüman fırını, anlayış geliştirmenin ve mükemmelliğe ulaşmanın en iyi yoludur.

Efsane 4) Yönümüzü anlamamız ve onunla taviz vermememiz önemlidir.

Gerçek) Hayat uzlaşmadır ve uzlaşma bir zayıflık değildir. Böyle bir taviz olmadan aynı anda karşılanamayacak sorunlar (verimlilik, bütçe, kullanım kolaylığı, güç, kapsam ve kolay uluslararasılaştırma ihtiyacı gibi) her zaman olacaktır.

Efsane 5) Müşterinin ne istediğini biliyoruz, sorunların ne olduğunu biliyoruz.

Gerçek) Sürekli yeniden değerlendirme yapılmadan hedefin izini kaybetmek kolaydır. Geliştiriciler, aslında gerçek pazar hedeflerinden ayrıldığında ve tamamen alakasız hale gelebildiğinde, sorunları göz önünde bulundurdukları çözülmesi gereken sorunlarla karşı karşıya kalırlar. Geliştiriciler her zaman pazar hedeflerini anlamalı ve başka şeyler değiştiğinde, hatta hedeflerin kendisi değiştiğinde uyum sağlayabilmelidir.

Efsane 6) Daha büyük daha iyidir. Özellikler harika.

Gerçek) Özellikler kullanıcıların kafasını kolayca karıştırabilir ve gerçek değerleri her zaman kafa karışıklığının maliyetine karşı dikkate alınmalıdır. Bazı durumlarda, bu tür endişeler nedeniyle çalışan özelliklerin fiilen kaldırılması mantıklıdır.

Efsane 7a) Müşteri her zaman haklıdır.

Gerçek) Çoğu müşteri, yazılım geliştiricilerin önünde cahil görünmemek için çok uğraşır ve bu nedenle önerilerini teknik bir şekilde ifade eder. Bunun etkisi, çoğu zaman önerilerin gerçekten uygun olmamasıdır, çünkü bunlar teknik konular hakkında sağlam bir anlayış üzerine kurulmamıştır.

Efsane 7b) Müşteri genellikle yanılıyor.

Gerçek) Müşterilerin ihtiyaçları genellikle söylediklerini tam anlamıyla yaparak en iyi şekilde karşılanmasa da, her zaman ne istediklerini ve neden istediklerini bilirler – ve genellikle çok iyi bir nedenle. Onları anlayın ve söylediklerini uyarlayın, onlarla tartışın, ancak onları asla göz ardı etmeyin.

Efsane 8) Kodunuzu çok yorumlayın.

Gerçek şu ki) İyi kod neredeyse hiç yorum gerektirmez, çünkü adlandırma ve boşluğun mantıklı kullanımları daha iyi alternatiflerdir. Yorumlar yalnızca açık olmayanları açıklamalı veya standart API dokümantasyonu sağlamalıdır.

Efsane 9) Şuna ve şuna ihtiyaç vardır, şudur ve böyle büyüktür.

Gerçek) Kötü bir işçi aletlerini suçlar. Bazı geliştirme araçları geliştirmeye önemli ölçüde yardımcı olurken, iyi bir geliştirici, kendilerine sunulan çoğu şeyde harika sonuçlar elde edebilir. Microsoft Access veya assembly dili gibi birkaç istisna vardır, ancak genel olarak kalite sonuçlarındaki fark, geliştiricilerin araçlarının kalitesinden çok becerilerinden kaynaklanmaktadır.

Efsane 10) Müşteri, verimli ve kullanımı kolay bir arayüz olup olmadığını anlayacaktır.

Gerçek) Arayüzün sadece kullanımı kolay olması gerekmez, genel bir sistem anlayışı olmadan gezinebilir olması gerekir. Ekranların kendi kendini tanımlaması gerekir.