RAD ortamında sürüm kalitesini artırmanın basit yolları

Burada biraz arka plan - büyük bir yazılım dışı şirkette dahili yazılım geliştirmeden sorumlu RAD geliştiricilerinden oluşan küçük bir ekibiz (5 kişiden). "Dahili yazılım", MSSQL sunucusunu kullanan bir masaüstü .NET uygulamasından, arka planda çalışan Python komut dosyalarının arka planı olarak çalışan MS Word belgelerine ve şablonlarına - bir teknoloji hayvanat bahçesine - değişir.

Tüm ekip, kullanıcıların gereksinimlerini karşılayabilen, kodlayabilen, test edebilen ve üretime yerleştirebilen çok yönlü uzmanlardan oluşur. Üretimdeki yazılım bir kez başka bir ekip tarafından bakılıyor ancak bir şeyler ters giderse müdahale etmemiz genellikle kolay.

Şimdiye kadar tüm sesler iyi, ama bir sorun var - bir RAD ekibi olarak sık sık yayınlamamız gerekiyor ve bir veya iki uygulamanın yeni sürümlerini yayınlamadan bir gün geçmiyor (veya bir senaryo, güncellenmiş kelime belgesi olabilir) , C ++ konsol uygulaması vb.) Bir geliştirme testi yapıyoruz ve ayrıca son kullanıcıları, yazılımı UAT ortamında çalıştırmalarına izin vererek dahil ediyoruz ...

... ama böcek yine de üretime geçiyor. Kullanıcılar, bu hataların ve ara sıra kararsızlığın, istediklerini gerçekten hızlı bir şekilde elde etmek için ödedikleri fiyat olduğunu anlıyorlar, ancak aynı zamanda bizi düşündürüyor - belki de geliştirmemizi iyileştirebilir veya yeni bir işlev eklerken tanıttığımız hata sayısını azaltır.

İyi şey - ilk etapta gerçekten çok fazla sürecimiz yok, bu yüzden geliştirmeye başlamak kolay olmalı, kötü şey - küçük bir RAD ekibi olarak, uygulamak için gerçekten fazla zamanımız ve kaynağımız yok büyük bir şey, ancak aşağıdaki girişimleri düşünüyoruz ve herhangi bir geri bildirim, ipucu, ipucu ve öneriyi memnuniyetle karşılarız.

1. Şu anda uygulamaların bazıları geliştirici testinden hemen sonra üretime girerek kullanıcı kabul testini atlıyor. Bu uygulama durdurulmalı ve küçük bir değişiklik bile son kullanıcı tarafından test edilmelidir. Her uygulama, son kullanıcılardan seçilen özel bir beta test kullanıcısına sahip olacaktır. Sadece bir beta-test cihazı yeni sürümü tamamladıktan sonra testten üretim ortamına yükseltilir.

2. Kod incelemeleri yapmıyoruz - ancak birimiz değişiklik kümesini kontrol etmeden önce kod incelemeleri yapmaya başlayacağız. Ben de bir "sunum gözden geçirme" hakkında düşünüyordum - temelde geliştiricilerden biri diğer oturmak onu yazılım sunum (kopya ikili dosyaları, güncelleme yapılandırma, veritabanına yeni tablo eklemek, vb) yapıyor onu izlemek zorunda - genellikle 5-10 dakikanızı alır, bu yüzden "kullanıma sunma" süresinin çoğunu almaz.

3. Yeni bir sürümün üretimden çekilebilecek kadar iyi olduğu ve önceki iyi bir sürümle değiştirileceği kanıtlandığında geri alma süresinin en aza indirilmesi. Bir sürüm geri gitmeyi kolaylaştırmak için tüm sürümlerin (ikili olarak) bir geçmişini saklıyoruz - ve hızlı bir şekilde "önceki sürüm ikili dosyalarına sahip yeni çıkan bir ikili dosyaların üzerine yaz" olsa da hala hataya meyilli olan manuel bir işlemdir. ve "geri alma başarısız olursa ve sistemi buggy yerine kullanılamaz hale getirecekse" isteyerek.

Burası fikirlerimiz tükendi ve bunlar hakkında geri bildirim almak istiyoruz ve bazı basit sürüm / geliştirme süreci iyileştirme önerilerini paylaşabilseydiniz - bu harika olurdu.

Harika bir konuya dokunmak için +1. "Sık sık erken bırakma" geliştirme çizgisini gerçekleştirdiğimizde, işler gerçek hız kazanır ve ivme arttıkça (açıkladığınız gibi) pek çok sorun ortaya çıkar, aksi takdirde başa çıkmaya çok hazır değiliz. En kötü korku, insanların hızı iyi işlerin düşmanı olarak görmeleridir.

Bununla ilgili çok sınırlı literatür gördüm, ancak kesinlikle yardımcı olan budur:

1. Etkili Hata takibi
Hata takibini daha etkili hale getirin - yaptığımız sadece hataların ve onay işaretlerinin bir listesini tutmak değil, kapatıldığında "tekrarlanabilir problemler miydi?" Gibi belirli şeyleri de tanımlamamız gerekir, bu kalıcı bir çözümdür veya iş düzeltmesi? "," sorunun temel nedeni nedir? " Bu, bu hatanın en son ne zaman görüldüğüne dair neler olduğunu bilmenizi sağlar. Bu, hataların sık tekrarlanmamasını sağlamak için anahtardır.

2. Anahtar geri dönüş noktalarını tanımlayın
Hepimiz hataların geleceğini biliyoruz, bu yüzden en sık çalışan etkili geri dönüş sağlamamız gerekecek. Her seferinde en güvenilir şekilde her yerde çalışan en yaygın bir sürümü tekrar tekrar sonuçlandırıyoruz (bizim durumumuzda her 10'dan yaklaşık 1 oranında). Toplam sürüm sayısı çok olabilir, ancak bir şey ters giderse, geri dönüşler azdır ve daha fazla geri gitmenize gerek yoktur. En iyi geri dönüşü bilmenin en basit yollarından biri, üretimde en uzun süren ve çok fazla sorun yaşamayan en eski sürümü görmektir.

3. Riskli ve kararlı veya küçük hata düzeltme sürümlerini ayırt edin
Önemli bir algoritma değişikliğimiz olduğunu bildiğimizde, hataların öngörülmeyen senaryolarda kayma olasılığı daha yüksektir. Sorunların çok küçük (veya iyi anlaşılmış) olduğu kadar az risk olduğu zamanlar olduğu yerlerde. Bu tür işlevselliği ve basit hataları aynı sürümlerde KULLANMAYIN . Her zaman önce daha küçük bir hatayı düzeltin, bu da gerektiğinde gitmelidir. Özel özellik kümeleri için ayrılmış sürümleri en iyi şekilde kullanabilirsiniz, ancak bu özelliği kullanımdan kaldırabilirsiniz, ancak diğer tüm önemli hatalar önceki sürümde sabit olarak kullanılabilir.

4. Önemli özellik gelişimi
için branş Tasarım etkisi olan değişiklikleri ilişkilendiren her şey bir branşta ayrı ayrı yapılmalıdır. Küçük hatalara kıyasla daha büyük gelişme hızlı bir şekilde tamamlanmaz. Halen kullanılmayan özelliklerle ilgili 'kısmi' çalışmanın potansiyel bir hata giriş bölgesi olduğu ara taahhütleri ortaya koyarsak; bu özellik için tam çalışma atomik olarak tamamlanmış olsaydı ortaya çıkmayacak olan hatalar - dolayısıyla bunlar, dallar olsaydı çözmemiz gereken hatalardır.

5. Her zaman temaya dayalı sürümü planlayın
Birçok kez birçok farklı hata farklı sürümlere ulaşır - ancak benzer modülleri etkileyen hataların (ve özelliklerin) düzenlenmesi en iyisidir, tekrar çalışmasını kolaylaştırır ve bu işten kaynaklanan hata sayısını en aza indirir. Her zaman serbest bırakma yol haritasını önceden hazırlayın; böcekler dökülmeye devam eder - ve bu, iyi bir sürümde birlikte çekilecek iyi bir böcek grubunun en iyi şekilde elde edilmesi için farklı hedef sürümlerine düşer. Benzer hatalar bir araya getirildiğinde, çelişkili senaryolar hakkında her zaman daha iyi bir fikir verir.

6. Yeni sürümleri ilk önce birkaç müşteriye uzatın
Bizim durumumuzda, bunu ilk önce birkaç sitede test ediyoruz ve diğer tüm sitelere yalnızca bir talep olduğunda bir sürüm uygulanmaktadır. Çoğu zaman bazı (veya çoğu) kullanıcılar yalnızca kararlı sürümden yalnızca başka kararlı sürümlere atlarlar.

7. Regresyon Testi
Toplanan böcek çizgileri boyunca - regresyon kıyafeti oluşturun. Ayrıca mümkünse, serbest bırakma adayı gerçekten serbest bırakılmadan önce test edilecek minimum yeterlilik kriterleri haline gelen kritik hataları ve testi en önemli olacak şekilde işaretleyin.

8. Duraklatma ve yansıtma
Birçok şey tam hızda gittiğinde, biraz mola vermek için zaman olmalıdır - bir duraklama yapın ve işlevsel olarak daha iyi olmayan sürümlere sahip olun. Aslında bir süre için yayınların tatil var. (süre frekansla ters orantılıdır). Örneğin, çoğu zaman, işlevsellik açısından yeni bir şey elde etmeyen "temizleme" sürümlerine sahibiz - ancak bu, kodun korunmasını sağlamada çok yardımcı olur. Bu tür yayınların çoğu, ondan önceki tarihi neredeyse hiç hatırlamadığınız harika geri dönüş noktalarıdır.

9. Belki de en garip
bu sık sık uygulanması zor buluyorum ama kesin bir atış iyi hile. Belirli modüllerin sahibini değiştirin. İnsanlardan kod incelemelerinin yapılması istendiğinde, bu uygulamadan çok fazla şey çıkmaz. Ancak bu yeni kodla ciddi bir şekilde uğraşmanız gerektiğinde, yazarları değiştirdiğinizde, potansiyel "kötü" rahatsızlıklar kodu kirletmeye başlamadan önce çok çabuk fark edilir. Tabii ki, bu hızı azaltır - ancak bunu sık sık yaparsanız, insanların kodun çeşitli bölümlerinde ustalaşmaları ve öğretilmesi çok akıllıca olan tüm ürün hakkında bilgi edinmeleri ihtimali vardır.

10. Son fakat en az değil
Beyaz tahtaya sık sık dönmeyi öğrenin. Daha siz düşünmek yeniden bu özellik bizim en baştaki tasarımın bir parçası olurdu eğer, nasıl o zaman tasarımın düşünebilirdi? Bazen, artımlı çalışma ile ilgili en büyük zorluk, ilk önce inşa ettiğimiz işlevsellik sırasına göre çok kısıtlandığımız ve çoğu zaman temellere geri dönemeyeceğimizdir. İşin püf noktası, bu yeni özelliği veya senaryoyu barındırmak yerine nasıl genelleştireceğimizi görmeye devam etmektir. Bu, tasarımın güncel kalmasını gerektirir ve bu sadece geri döndüğümüzde sık sık çizim tahtasına gidersek olur. Ayrıca, yeni nesil programcılar katıldıkça, sadece yamaları yerleştirmek yerine düşünce tankının bir parçası haline gelirler.

DÜZENLEME
11. Çözüm ve tasarım boşluklarını takip edin.
Çoğu zaman, hatayı düzeltmek ve üretimde serbest bırakmak için zaman çizelgeleri baskısı altındayız. Bununla birlikte, hata tasarım düzeyinde olduğunda, birkaç şeyin değişmesi gerekir, ancak insanlar genellikle son tarihi karşılamak için bazı kısa yollarla giderir. Bu Tamam . Bununla birlikte, çözümlerin etrafındaki bu tür çoklu çalışmalar arttıkça, kod kırılgan hale gelir. Zaten kaç tasarım boşluğunun gittiğini özel olarak takip edin. Tipik olarak, zaman çizelgelerini proje yöneticisi ile görüştüğünüzde, üretimden tasarruf etmek için bunu kısa yolla teslim edeceğimize dair taahhütte bulunmak en iyisidir. kalıcı çözüm elde etmek için zaman çizelgesi ve kaynaklar.

Küçük bir geliştirme ekibinde de çalışıyorum (sadece ikimiz) ve bahsettiğiniz benzer sorunları yaşadık. Bizim için asıl mesele, ikimizin de ayrı görevler üzerinde çalışma eğiliminde olması ve bir görevi / özelliği tamamlamamız, test etmemiz (yalnızca geliştirici tarafından test edildi) ve hızlı bir şekilde serbest bırakmamızın yaygınlaşmasıydı. Bu, kullanıcıların testlerde kolayca toplanması gereken küçük hatalar bildirdikleri birçok küçük sürümle sonuçlandı.

Süreçimizi iyileştirmek için bir Kanban panosu tanıtarak başladım . Tahta ile başlamak çok basitti ve sadece birkaç sütun vardı (bir beyaz tahta, dizin kartları ve renkli mıknatıslar kullanarak kurulum):

İş Listesi | Yapılacak | Bitti

Ancak bu, gerçek sürecimizi yansıtmak için hızla gelişti:

İş Listesi | Geliştirme | Dev. Test | UAT | Tamamlandı | Yayınlandı

Anakartla birlikte, her bir Görev / Özelliğin başka bir geliştirici (ve özelliği uygulayan geliştirici tarafından) test edilmesi gerektiğine dair bir kuralımız var. Dolayısıyla, bir kart 'Bitti' sütununa ulaştığında, en az 2 geliştirici tarafından test edilmeli ve ayrıca Kullanıcı Kabul Testi test edilmelidir.

Kanban'ı kullanmanın başka birçok faydası vardır. Bizim için iletişimi geliştirdi ve her görevde bir dereceye kadar yer aldığımız için bilgiyi paylaşmamıza yardımcı oldu. Ayrıca, hangi görevlerin / özelliklerin serbest bırakılmaya / yapılmaya hazır olduğunu tam olarak görebildiğimiz ve bazen diğer görevlerin yakında yapılacağını bildiğimizde serbest bırakmaya devam edebileceğimiz için yayınlama sürecimizi de geliştirdi. Ekip dışındaki kişiler için, kurul ayrıca hangi görevleri planladığımızı, devam etmekte olan çalışmaları ve son zamanlarda yayımlananları görmek için hızlı bir referans görevi görür.

Bir kenara olduğu gibi, üzerinde çalıştığımız kartı işaretlemek için renkli mıknatıslar (geliştirici başına bir tane) kullanıyoruz, ancak başka bir seçenek, geliştirici başına bir tane ve Kanban kartlarını ilgili yüzme şeritlerine yerleştirmek için yüzme şeritleri (satırlar) eklemektir. Yine bu, her geliştiricinin şu anda ne üzerinde çalıştığını görmek için hızlı bir referans olarak yardımcı olur.

Yararlı bulduğum diğer bağlantılar:

Kanban Yazılım Geliştirmeye Uygulandı: Agile'dan Lean'a

Yazılım Mühendisliği için Kanban Sistemi - Video

Umarım Kanban sorunuzun 1. noktasına hitap eder. Kod incelemeleriyle ilgili olarak, bunu geliştirme test aşamasında yaparız, böylece incelemeden sonra gerekli olan tüm değişiklikler UAT'a gitmeden önce geliştirici testinden geçirilir. Geri alma ortamınıza bağlıdır, ancak geçerli dosyaları yeniden adlandıran ve merkezi bir sunucudan yeni dosyalara kopyalayan toplu dosyaları kullanarak uygulama dosyalarını Terminal Sunucularına dağıtırız ve yedeklemeyi (önceki dosyalar) merkezi konuma yerleştirerek oldukça kolay bir şekilde geri alabiliriz ve komut dosyalarını yeniden çalıştırmak.

Proseslerinizin yazılımınızın kalitesini etkileyen sorunlar olduğunu bildiğinizi zaten belirlediniz ve bu soru bir dizi cevabı tetikleyecek olsa da, önerim yazılım mühendisliği konusuna bakmak ve neyi denemek ve öğrenmek olacaktır. ana geliştiriciler kendilerini bu alanda giderek daha fazla yapıyor buluyorlar. Başlamak için birkaç iyi kaynak okumaya başlamanızı öneririm. Akla gelen birkaç kişi:

• Mary ve Tom Poppendeick tarafından Yalın Yazılım Geliştirme "atık" tanımlamak ve daha zayıf ve daha verimli hale getirmek için değişen süreçler hakkında ne yapacağını öğrenmek isteyen insanlar için harika bir okuma sağlar.
• Dan Pilone ve Russ Miles tarafından Baş İlk Yazılım Geliştirme , ilk bakışta "aptallar için" kitaplardan birine benziyor, ancak kaotik sunum tarzının biraz ötesine bakarak, yazılım mühendisliğinin temelleri ile ilgili bilgilerin çoğunu içeriyor. ve Test Odaklı Geliştirme hakkında kısa bir yazı var.
• BDD'nin tanıtımı Dan North'un Davranış Odaklı Gelişime girme sayfasıdır, ya da belki bir BDD Wiki'yi tercih edersiniz . Bunlar BDD için başlangıç ​​referanslarıdır ve muhtemelen size yardımcı olacak araçlara ve çerçevelere bakmak isteyeceksiniz. Anlaşılması gereken önemli şey BDD'nin etkili bir şekilde TDD'nin daha yüksek bir kavramsal seviyeye alınmasıdır. Testleri, spesifikasyonlar hakkında düşündüğünüz gibi düşünmenizi ve spesifikasyonlar yazarken kullandığınız aynı dilde test etmenizi sağlar. Çerçeveler genellikle diğer birim test çerçeveleriyle bütünleşir, bu nedenle testinizin BDD sözdiziminden yararlanamayacağına karar verirseniz her iki dünyanın da en iyisini elde edersiniz.
• Wikipedia'nın Çevik Yazılım Geliştirme Makalesi , çevik yazılım geliştirme ile ilgili iyi bir ilkedir ve geliştirme topluluğunun daha saygın kişilerinin bazılarına yararlı referanslar ve makaleler için bağlantılar sağlar.

NASIL çalıştığınızı iyileştirmek için, tamamen açık fikirli olmanıza izin vermeniz ve bulabileceğiniz bazı kavramlara bağlı kalmadan yaptığınız şeyleri iyileştirmeyi öğrenmek için konfor bölgenizin dışına çıkmaya istekli olmanız gerekir. asmak için daha rahat. Kişisel deneyimlerden bahsetmişken, bu muhtemelen en zor şeydir veya başkalarında teşvik etmek.

Değişimi en iyi şekilde değiştirmek, aktif olarak değişim aradığınızı hissetseniz bile, bu yüzden size gerçekten verebileceğim en iyi tavsiye, yıllar boyunca kendinizi uygulamalara alıştırmak için geliştirilen çeşitli Çevik metodolojilere bakmaktır. en önemli olarak kabul edilen (örneğin: Birim Testi, Sürekli Entegrasyon, Yeniden Düzenleme vb.)) ve ardından sizin ve ekibinizin en rahat hissettikleri yöntemlere en yakın görünen yöntemi seçin. Kararınızı verdikten sonra, uygulamalarınızı ve geliştirme sürecinizi, ekibinizin bu yalın prensipleri ve nasıl çalışmak istediğinizi göz önünde bulundurarak ekibinizin, en az atık. En sonunda,

Süreçlerinizin sadece ince ayar yapmaya ihtiyacı olduğunu düşünüyorsanız, ancak takım zincirinizin ihtiyaçlarınızı tam olarak karşılamadığından endişe ediyorsanız, belki de orada iyileştirmelere bakın. En azından, sürekli bir entegrasyon entegrasyonu ürünü (Continuum, Cruise Control veya Hudson gibi) ve bir Sorun İzleme sistemi (Jira veya Redmine gibi), bazı oluşturma ve yayınlama işlemlerinizi otomatikleştirmenize yardımcı olacak bir öncelik olmalıdır. ve hatalarınızı ve özellik taleplerinizi kontrol altında tutmak için.

Gerçek şu ki, süreçleriniz ne kadar RAD olursa olsun, ekibiniz için "doğru" şeyler almak için zaman yatırımı yapmazsanız, sorunlarınız sadece zamanla büyümeye devam edecek ve mevcut zaman algınız buna göre küçültün. Ağır zaman baskısı altındayken büyük değişiklikler genellikle söz konusu değildir, ancak ekibinizin ideal bir metodoloji vizyonuna doğru bebek adımlarını atmanıza yardımcı olacak sistemleri yerleştirmek için kendinize küçük bir "kıpır kama odası" vermeye çalışın.

Kusurları her duyduğumda, ilk sorularım kusurların nereden kaynaklandığı ve nerede tespit edildikleri ve giderildikleri ile ilgilidir. Hata Giderme Verimliliği bunu ölçmenin ve izlemenin iyi bir yoludur. Kusurların nereden kaynaklandığını bilerek ve bu aşamalardaki süreçleri iyileştirmek için çalışarak, bir projenin zamanını ve maliyetini azaltabilirsiniz. Kusurları enjeksiyon noktalarına daha yakın düzeltmenin daha ucuz olduğu iyi bilinmektedir, bu nedenle kusurların nereden geldiğini öğrendikten sonra, bu aşamaları iyileştirmek için aktivite değişikliklerine bakabilirsiniz.

Kusurların nereden geldiği hakkında bilgi sahibi olduktan sonra, tam olarak hangi teknikleri ve teknolojileri uygulamak istediğinize bakabilirsiniz. Gereksinimlerin, tasarımın ve kodun, otomatik testlerin, statik analizlerin, sürekli entegrasyonun ve daha kapsamlı kullanıcı odaklı testlerin gözden geçirilmesi, hangi fazların hata ürettiğine bağlı olarak bakmanız gereken seçenekler olabilir.

Kod inceleme isteğinizi genişletmek için, bir modülün önceliğine ve riskine bağlı olarak farklı düzeylerde kod incelemeleri de düşünmelisiniz. Düşük riskli, düşük öncelikli modüller hiç bir kod incelemesine ihtiyaç duymayabilir veya belki de basit bir masa kontrolüne ihtiyaç duyabilir, burada başka bir geliştirici sadece kodu kendi başına okur ve yorum sağlar. Diğer kod inceleme teknikleri arasında çift programlama, izlenecek yol, eleştiriler ve çeşitli geliştiricilerle yapılan denetimler bulunmaktadır.

Geri alma amacıyla, bu işlemi daha hızlı ve daha az hataya eğilimli hale getirmek için bir tür komut dosyası kullanarak otomatikleştirmeye çalışacağım. Mükemmel bir dünyada, geri gönderilenlere gerek kalmayacak şekilde gönderilen ürünlerin kalitesini artırmak isterim ve bunu başarabilirsiniz. Bununla birlikte, yeteneğe sahip olmak iyi bir fikir olabilir, ancak mümkün olduğunca ağrısız hale getirin.

Diğerlerinin de belirttiği gibi, regresyon testinin eklenmesi gelecekte aynı kusurların ortaya çıkmasını önlemeye yardımcı olacaktır. Bununla birlikte, yeni kusurlarla karşılaşıyorsanız , sınıfların ve yöntemlerin ön koşullarını, son koşullarını ve değişmezlerini belirleyen koda iddialar (aka sözleşmeler) eklemenin zamanı gelmiş olabilir .

Örneğin, bir yöntemin yalnızca 10 ile 25 arasındaki sayıları kabul edebileceği bir sınıfınız varsa (buna ön koşul denir), yöntemin başına bir onay ifadesi eklersiniz. Bu iddia başarısız olduğunda, program hemen kilitlenir ve bu başarısızlığa yol açan yöntem zincirini takip edebilirsiniz.

Python, PHP ve diğer programlama dilleri dinamik olarak yazılmıştır ve yöntemlere birçok koşul eklemez. Bir şeyin çalışması için gereken tek şey, belirli bir yöntemi uygulamasıdır. Yöntemleriniz için daha fazla koşula ihtiyacınız olduğundan şüpheleniyorum. Bir yöntemin gerçekten ortamında çalışabilmesini sağlamak için tanımlamanız ve test etmeniz gerekir.

C / C ++ programları için, bellek tahsisini test etmek için iddialar eklemenin, programdaki bellek sızıntılarının sayısını azaltmada çok yararlı olduğunu buldum.