Deneyimsiz geliştiricilerin düşünmeyi unuttukları en kötü şeyler nelerdir? [kapalı]

Genç bir geliştirici olarak, yüksek kaliteli bir uygulama geliştirmek için düşünülmesi gereken şeyler hakkında bazı tavsiyeler almayı yararlı bulurdum. Üniversite derslerimde, öğretmenlerin çoğu girdi doğrulamayı vurguladı ve bazıları güvenlik endişeleri hakkında konuştu, ancak kimse örneğin oturum açmak gibi diğer bazı şeylerin önemini kapsamıyordu.

Deneyimsiz geliştiricilerin daha deneyimli geliştiriciler için hayal kırıklığına neden olabilecek bazı hatalar nelerdir?

Yeni geliştiricilerin unutduğu ana şey, gerçek dünyada genellikle bir ekibin parçası olarak çalışıyorlar. Bu kendini şu şekilde gösterir ..

• Yapıyı bozan kodu kontrol etme
• Zaten orada olan kodu tekrar kullanmamak
• İşleri herkesle aynı şekilde yapmak yerine bakım yapmak pahalıya mal oluyor

Bu, kodlarının yalıtılmış olarak çizilmediği anlamına gelmiyor, ancak artık yalıtılmış olarak çalışmıyorlar.

1. Testler.
2. Testler.
3. Daha fazla test.
4. Kaynak kontrolü
5. Hedeflediğiniz programa uygun vergiler.

Windows'ta bu vergiler :

• Yüksek DPI ortamlarıyla ilgilenme
• Gezici Kullanıcı Profilleri
• Hızlı Kullanıcı Değiştirme
• Uzak Masaüstü (örneğin, RDP etkinken çift arabellek kullanmak istemezsiniz
• Hiyerarşik Depolama Yönetimi ile güzel oynama
• Birden Çok Monitör
• 64 bit Windows

Hemen hemen her platformda aşağıdakilerle uğraşmak zorunda kalacaksınız:

• Unicode
• yerelleştirme
• Güç Yönetimi

Deneyimlerime göre, neredeyse tüm deneyimsiz geliştiricilerin akılda kalmadıkları tek şey, (neredeyse her zaman) ticari bir ortamda çalışmanızdır. Kodunuzun iyi olması gerekir, ancak mükemmel olmamalıdır. En önemli şey mükemmellik değil, kodunuzun gönderilmesi.

Başka bir deyişle, şirketiniz büst olduktan üç ay sonra mükemmel kod parçasını teslim etmek kimseye iyi gelmez.

Bence bu, gerçek dünyadaki kalkınmanın üniversitede öğretilen kalkınmadan farklı olmasının en önemli yollarından biridir.

Gerçekten geniş bir soru; ayrıntılı olarak cevap vermek için ... birden fazla kitap.

İşte başlamanız için genel bir sistem tanımı kontrol listesi -

• Sistemdeki kritik kaynaklar nelerdir ve bunlara yönelik talepler nasıl değişebilir?
• Sistemin performans özellikleri nelerdir ve nasıl büyümeleri gerekebilir?
• Hangi gereksinim alanları gereksiz ve çıkarılabilir olabilir?
• Sistemin farklı yeteneklere sahip farklı sürümlerine sahip olma ihtiyacı var mı?
• Belirlenen değişiklikler meydana gelirse insan gücü ve bilgisayar kaynakları üzerindeki etkileri nelerdir?
• Yeni sistemin mevcut işletim sistemleri üzerinde nasıl bir etkisi olacak?
• Hangi işlev alanlarının sistemle ilgili deneyim ışığında değişiklik gerektirme olasılığı daha yüksektir?
• Sistemin gelecekteki kullanıcıları kimlerdir?
• Sistemin gelecekteki koruyucuları nelerdir?
• Sistemin gelecekteki kullanıcılarının olası olarak belirleyebileceği gelecekteki geliştirmeler nelerdir?
• Sistem kullanıcının genel planlarına nasıl uyuyor ve nasıl gelişmesi bekleniyor?

Sistemin kişinin geliştirme makinesinde ve hedef makinede temiz ayrılması, böylece "Eh, makinemde çalışır" durumlarıyla sonuçlanmaz.

Geliştirme makinenizi ne kadar hızlı bir şekilde yeniden yapılandırabilirsiniz?

• Hangi paketlere ihtiyacınız olduğunu biliyor musunuz?
• Veritabanınızı yeniden oluşturmak için bir düğme çözümünüz var mı?
• Kaynak koddaki bütünlüğü test etmek için bir basma düğmesi çözümünüz var mı?

Bence bu muhtemelen tasarım - yani bunu yapmadan önce ne yapacağınızı düşünme yaklaşımı.

Çok fazla deneyimsiz kodlayıcı (ilk başladığınızda hatırlayın) atlamak ve bir şeyler almaktan hoşlanır, sonra biraz daha ekleyin ve biraz daha reklam yapın ve biraz daha ekleyin. Bu yaklaşım bu şekilde yapmayı planladıysanız işe yarayabilir (sonuçta her bit test edilebilir), ancak çoğu deneyimsiz kodlayıcı sadece yazdıkları kısma odaklanır .. bu nedenle tüm eklemeler saldırıya uğrar üstte. Hepimiz böyle gelişen kodu gördük!

Organizasyon bir sonraki şey, genellikle nasıl yaptıklarını ve neyin gerekli olduğunu hatırlamak için yazdıkları koda odaklanmıyorlar. Bu yüzden gerekli bir bağımlılığı paketlemeyi veya belgelemeyi unutuyorlar. Onlar da düştükleri şeyler koymak eğilimindedir, geçen hafta 2 aynı dosya olan 3 wsdls ve onun yaptığı 3. parti dll bir dizi de dahil olmak üzere kök dizin kodunu kontrol eden bir junior eleştirmek zorunda kaldı bir alt dizin ve kök dizin. Kod, düşünebileceğiniz herhangi bir standarda göre biçimlendirilmedi ve mevcut olan ancak hiç çağrılmayan birkaç işlev vardı.

Açıkçası işe yaradı ama düzenli değildi ve bu kurulum ve bakım demek zahmetli olurdu.

Bence en büyük fark kodlama tekniğinde. Herkesin biraz farklı bir yaklaşımı vardır, ancak deneyimsiz geliştiriciler şu kodu üretme eğilimindedir:

• sınır davalarını ele almaz
• gerekenden çok daha uzun
• ilgili senaryolarda kötü performans özellikleri var
• endişelerin zayıf bir şekilde ayrılması
• const, mühürlü, salt okunur vb. kullanım gibi kendini koruma tekniklerinden yoksundur.
• veri döndürmenin tuhaf yolları ve veri toplama
  • bu bir platformdaki deneyimsizliği daha fazla gösterir

En kötü şeyleri sorduğunuz için, cevabım şöyle:

1. Geliştirme makinesini casus yazılımlardan, kötü amaçlı yazılımlardan ve truva atı virüslerinden temizlemeyi düşünmeyi unuttum.
2. Farklı coğrafi konumlardaki güvenli depolarda kaydedilmiş düzenli bir yedekleme yapmayı düşünmeyi unuttum.

En büyüğüm esneklik planlamayı hatırlamak. Sınıflarda, gereksinimler neredeyse her zaman başlangıçta belirtilir ve asla değişmez. Yazılımda, genellikle tam tersi: Belirsiz bir gereksinimler seti alırsınız ve sık sık değişir (günlük olarak bile). Bu konuda yardımcı olmak için yapabileceğiniz en iyi şey esnek bir şekilde kodlamaktır: gevşek bağlantı, birden fazla durumda güvenilir bir şekilde kullanılabilen küçük fonksiyonlar ve mümkün olduğu kadar kodlayıcı şeylerden kaçınmak.

Zamanla, a) neyin değişme olasılığı en yüksek ve neyin tersine değişmeyeceğini ve b) değişiklik isteklerinin nasıl tahmin edileceğini ve onlar için nasıl planlanacağını öğreneceksiniz.