Düzeltilemez sonsuz bir proje ile başa çıkmak

Çok fazla teknik borcu olan büyük (1200+ saat) bir web sitemiz var . Bunun başlıca nedeni aşağıdaki (olağan) nedenlerdir.

1. Geliştirme sırasında gelen ve giden çoklu programcılar.
2. Geliştirme sırasında özelliklerin değiştirilmesi.
3. Çok sayıda ilave işlevsellik eklendi (kısa sürede).

Müşteri çok sayıda yeni işlevsellik istiyor ve bu temelde bu proje üzerinde haftada 10 saatten fazla çalışmaya geliyor .

Nedeniyle teknik borca biz geçirmek ÇOK genellikle aşağıdakilerden biri kendi kaynağını bulmak, sabitleme veya sorunları araştıran saat:

1. İnsanları ağlatan utanmaz, aptalca bir böcek.
2. Yeni bir özellik yukarıdakilerle sonuçlanır, çünkü yeni özelliğin etkili olacağı tüm yerleri önceden tahmin etmemiştik.
3. Karşılaştığımız diğer bazı sorunlar (sunucu geçişi, yükseltme)

Her gün sorun yaşıyoruz ve bunu durdurmak için aşağıdaki şeyleri denemeye çalıştık:

1. Web sitesinin ithalatı, ödenmesi ve genel çalışması ile ilgili teknik belgeler hazırlanmıştır.
2. Haftanın başında toplantı yapın - mevcut sorunları veya gelişmeleri ve bunların nasıl ele alınması gerektiğini tartışmak.
3. Bir test planınız olsun. Programcı A testi B, B C ve C testleri A'yı test eder. Ardından Proje Yöneticimiz bazı testleri yapacaktır. Özelliğin etkisi ile ilgili olarak, bir hazırlama ortamına atıyoruz ve müşterinin kendisini kontrol etmesini sağlıyoruz.

Sorun şu ki, problemler devam ediyor ... ve bir şekilde bunun üstesinden gelemiyoruz. Yeni özellikler hala hatalara neden oluyor ve eski hatalar merhaba diyor. Bir şekilde - belki de projenin büyüklüğü nedeniyle - bu projeyi ele alamıyoruz.

Daha büyük projeler üzerinde çalışan bir sürü programcı olduğunu varsayıyorum. Bu yüzden soruma geliyorum:

Biz ne yapabiliriz, ya da ne yapmak sen büyük projelerde bu sorunları önlemek için ne?

Küçük düzenleme, ekstra bilgi:

1. Sürüm kontrolü (SVN) kullanıyoruz.
2. DTAP geliştirme sürecimiz var.

Bunun nasıl ortaya çıktığını çok sık gördükten sonra şeytanın avukatını oynayacağım: Onunla baş edemezsin. Sistemle gerçek bir problemi olduğu gibi gören tek kişi olduğunuzu garanti ederim, yoksa şirketle nasıl başa çıkacağınızı sormak zorunda kalmazsınız çünkü şirket kültürü hataları damgalamak ve kodu düzeltmek için bir tane olurdu Mümkün olan her yerde, yani gerçek profesyonellerin nasıl çalıştığı.

Bahse girerim, birim testleri yazmaya başlamak için çok büyük, çünkü senden önce test yapmayı bilen kimseye sahip değildi (ve ekibinizdeki diğer insanlarla şans) ve nereden başlayacağınızı bilmek imkansız ve hatta belki de imkansız test çünkü kesin uygulamalara ve somut verilere dayanır, bu yüzden ilk etapta test edebilmek için bunların hepsini arayüzlere, alaylara, taslaklara ve benzerlerine ayırmak çok uzun sürecektir. Ayrıca, çok sıkı bir şekilde bağlandığından ve yeniden kodlanması gerekenleri yeniden düzenleyemeyeceğinize ve kötü kodları düzelterek neyin kırılacağını bilmeyen hiçbir test olmadığından eminim. Kısacası, ciddi bir şekilde düzeltmek için çok kanserli hale gelir, ancak elbette sadece kesilip yeni başlayamaz.

Kaybeden bir savaşta savaşıyorsun dostum. Ya hayal kırıklığından yanacak ve sonunda bırakacak ya da delireceksiniz ya da başkalarının sorunları fark etmesini sağlamak için yeterince uzun süre şikayet ederseniz, tek sorunun siz olduğunuzu düşünecek ve size kapı gösterilecek.

Herhangi bir şey yapmıyorsanız, birim testleri iyi bir başlangıç ​​noktasıdır. En azından eski hataları düzeltirken sizi yeni hatalar eklemekten koruyacaklardır.

Kaynak kontrolü de kullanmadığınız sürece yardımcı olur. Suçlama ve kütük özellikleri, özellikle buggy kod parçasının nasıl / neden işlendiğini ortaya çıkarmak için harika.

Müşterinin sonunda, değişiklik / ek özellikler talep edilir edilmez fiyat ve (uzun) gecikmelerin tartışılmasının, bunları tartışmak / tasarlamak için harcadığınız zaman için ücretlendirme gibi makul bir şekilde işe yaradığını buldum. Müşteriler sık ​​sık ikinci düşüncede bekleyebileceklerine karar vereceklerdir.

(Aksine, hemen onunla birlikte teknik özelliklere ve uygulama fikirlerine girerseniz, sizi genellikle "oh, yine de bunu yapmayı kabul ettiğimizi düşündük" veya daha da kötüsü, birkaç gün sonra ve "ancak bakın, zaten tasarlandı ve tartıştığımız şey kulağa zor gelmiyor!".)

Son olarak, e-postaları günde sadece bir kez okuduğumda (işe geldikten sonra) ve daha acil bir şey için bir telefon aldığımın, üretkenlikte büyük bir artışa yol açtığını gördüm.

Öncelikle en sık kırılan alanlara bazı CI tabanlı testler eklemenizi öneririm. Bu, proje üzerinde çalışma yapılırken kaliteyi artırmanıza yardımcı olacaktır.

Ayrıca, hangi alanların / işlevselliklerin daha sık kırıldığı daha açık hale gelir ve bu nedenle hangi parçaların yeniden düzenlenmesi veya en azından testlerin artırılması gerektiğine karar vermek daha kolaydır.

Eklenen özellik başına $$$ ve gereken süre açısından projenin yanlış gitmesi için daha fazla manuel test riski eklemek.

Bazı kod incelemeleri iyidir, ancak bu A-> B-> C-> A test şemasının bir parçasıdır. (Belki diğer yönde kod incelemesi?)

Sana bir masal atmama izin ver. Günün erken saatlerinde caddeden aşağı biriyle yürüyüş yapıyordunuz ve gideceğiniz yere ulaşıyorsunuz. Birlikte yürüdüğünüz kişi, yol boyunca bir yerde yüzüğünü kaybettiğini öğrenir, böylece ikiniz de geri dönüp onu aramaya karar verirsiniz. Birlikte yürüdüğünüz kişi hızlı bir şekilde bir sokak lambası durur ve çılgınca bakmaya başlar. "Sokaktan geçerken kaybetmiş olabileceğinizi düşündüğümde neden lamba direğine bakıyorsunuz?" Diyorsunuz. "Biliyorum ama ışık burada daha iyi."

Bu durumda birkaç kereden fazla bulundum ve bazı ortaklıklar gördüm. Bu tür bakım kabusu projeleri, genellikle yönetimin getirdiği ağır gözetim ve süreç iyileştirmeleri ile ağır bir süreç ortamında yürütülür. Süreç iyileştirmelerinin kötü bir şey olduğunu söylemiyorum ama daha sık olarak Yönetimin genellikle yürürlüğe girmesini isteyeceği süreç iyileştirme türlerinden iki önemli nokta daha söz etmiyorum.

1) Genellikle ofis politikalarını ve güç dengesini bozmazlar. 2) Konunun merkezinde grev yapmaktan ziyade yönetim tarafından kontrol yanılsaması yaratmada başarılılar.

"Işık burada daha iyidir" yönetimi genellikle "Her yeni özelliğin ayrıntılı bir teknik özelliğe sahip olması gerekir" veya "Sorunları ve bunların üstesinden gelmek için her gün saatlik bir durum toplantısı yapalım" diyerek devam ettiğini düşünür.

Bunların hiçbiri meselelerin merkezine gerçekten çarpmıyor ve üretkenliği düşürebilirler, ancak kesinlikle yönetim tarafından kontrol yanılsamasını doğrularlar.

Zorlamaya yardımcı olabileceğiniz tek gerçek değişiklik, işleri sarsan değişiklikler olacaktır. Bir web sitesinin canavarlığınızın muhtemelen bu noktada onarılamayacağından şüpheleniyorum ve yeniden mimarlık ve yeniden yazma için ileride olacaksınız. Bununla birlikte, gelecek için, program ayarlamaları yapmadan kapsamdaki sürünmeyi en aza indirmeye yardımcı olmak için sıkı Değişim Kontrolü prosedürleri altında düzenlenen Çevik metodoloji, Sürekli Entegrasyon, Test Odaklı Geliştirme, Kod İncelemeleri ve iş gereksinimi spesifikasyonlarının önemini aklınızda tutabilirsiniz.

Bu tür değişiklikler gerçekten yönetim düzeyinde düşünme biçiminde bir değişiklik gerektirir ve tüm mesleki deneyimimde, bunun bir tür orta yönetim seviyesi sarsıntısı olmadan gerçekleşmesi ile hiç karşılaşmadım. Umarım bu, yokuş yukarı bir savaşta savaşıyorsanız, doğru olanı denemeniz için cesaret kırıcı değildir, çünkü statükoyu seven insanların şiddetli direnişiyle karşılaşacaksınız.

Bir süre önce aynı yerde bulundum. Artık iki basit kural sayesinde değilim:

• Her hafta, uygulamanın en tüylü kısımlarını düzeltmek / yeniden yazmak için bir veya iki gün geçirilir. Hata avlama yok, yeni özellik geliştirme yok.
• Yeni özellikler uygularken, müşterinin beklediğinden daha fazla zaman harcadığımızda bile doğru olanı elde etmeye çalışıyoruz.

Tek sorun diğer insanların onlara saygı duymasını sağlamaktır. Kolay kısmı şaşırtıcı bir şekilde müşteri oldu. Nedenini açıklayamıyorum, ama bir şekilde onu ikna ettik, bir özellik üzerinde biraz daha uzun çalıştığımızda herkes için daha iyi. İlk kurala saygı duymak daha sorunlu görünüyor, ama aynı zamanda bize çok yardımcı olduğunu düşünüyoruz. Uygulamanın farklı bölümleri iyileştikçe sürekli ilerlemeyi garanti eder.

Kod incelemeleri. Birim testleri. Gerçek KG Testi. Şartname toplama süreci ve artımlı geliştirme - bunlar sorunlarınızın çoğunu çözmesi gereken şeylerdir.

Ayrıca müşterilerin doğrudan geliştiricilerinize ping atmasına izin vermeyin - Bu genellikle sorunları çözmenin en verimsiz yoludur. Müşterileriniz ve geliştiriciler arasında arayüz oluşturacak iyi bir Program yöneticisi işe alın. İşi, ürünün uçtan uca, mevcut durum, gelecekteki yönler ve benzeri şeyleri bilmek olacaktır. Müşteri başka bir yeni özellik istediğinde, mevcut öğe listesini verebilmeli ve bu yeni istek alınacaksa müşterilere neyin çarpılacağını gösterebilmelidir.

İşlem çok az veya çok fazla kullanıldığında kötüdür. Sanırım eski eyalettesin.

Deni'nin de belirttiği gibi, projeye birim testi ekleyebiliyorsanız, bu size yardımcı olacaktır. Sistemin bir kısmını değiştirmek / düzeltmek üzere olan bir teste sahip olun ve bu nedenle yeniden düzenleme kodunuzda, hiçbir şeyi kırmadığınızdan emin olmak için bu testi bir kılavuz olarak kullanın.

Ayrıca, kodun en kırık kısımlarını tetikleyin. En kötü etkilenenleri bir risk listesine koymaya ve bu riskleri bağımsız olarak yönetmeye çalışın. Hataların en çok nerede olduğunu sorgulayarak kod tabanında ne kadar kırık kod olduğu hakkında bir fikir edinmeye çalışın. Daha sonra, etkilenen alanı hata sayısına (veya sizin için neyin işe yaradığını bildiren sorunlara) göre listeleyebilirsiniz.

Kodun eklenmesi ve temizlenmesi zaman alacaktır, ancak takımdaki her geliştirici kodu biraz daha temiz bırakabilirse, kodlamadan önce olmuştu, zamanla kod tabanı artacaktır. Eğer hızlı, ordu tarzı arıyorsanız, şimdi çözülmüş olsun çözümü, yardımcı olacak pratik (veya önerilen) bir şey olduğundan şüpheliyim.

Şerefe. Jas.

Net fonksiyonel özellikler yazın; Bilginize dayanabilir ve düzenli olarak bu özelliklere göre işlevselliği gözden geçirebilirsiniz. Bir geliştiricinin ne geliştirmesi gerektiği hakkında ne kadar az fikri varsa, onun gelişmesi gerektiği gibi olma ihtimali de o kadar az olur.

Kod yazmaya başlamadan önce bazı ön tasarım çalışmaları yapın; bunun mükemmel veya büyük olması veya UML içermesi gerekmez, ancak çözülmesi gereken soruna oldukça sağlam bir çözüm getirmelidir. Daha az yazılımın planlandığını söyleyebildiğim kadarıyla daha kötü. Üzerinde çalışmaya başlamadan önce tasarımı tartışın.

Kodun açıkça kötü olan ve ilerlemenizi gerçekten engelleyen bir alan üzerinde çalışmaya başladığınızda; eklemeyi bırakın, sorundan geri adım atın, mimariyi nasıl yeniden tasarlayabileceğinizi öğrenin, böylece engeller orada değildi ve gelecekte daha uyarlanabilir olacaktı. Teknik borcu ele almadan önce ne kadar uzun süre bırakırsanız, tam bir yeniden yazma olmadan onu ele almak o kadar zor olacaktır. Üstel bir şey olduğunu söyleyebilirim.

Davranışı test eden ve mimarinize sıkı sıkıya bağlı olmayan testler tasarlayın . Çok moda değil, ama kodunuzun gerçek amacı net olana kadar teste başlama. Özellikle neyi test etmek istediğinizi bilinceye kadar teste başlamayın; IMO kötü düşünülmüş bir testin testten daha kötü olduğunu. Ve ne kadar çok teste sahip olursanız, kodunuzu dahili olarak değiştirmek o kadar zor olur. Test kodunuzu üretim kodunda olduğu gibi değerlendirin; planlanmalı ve iyi yazılmalıdır.

Düzenli / günlük kod incelemeleri yapın: bu, geliştiricinin kurstan çok uzaklara gitmediğinden emin olmak için daha fazla akıl sağlığı kontrolü ile ilgilidir. Sonraki günlerde çalışmayı planlamak için bu oturumları kullanın. Bunların 5 dakika veya 1 saat sürdüğü günler olabilir; mesele, bir diyaloğu açık tutmak ve geliştiricilere çalışmalarını diğer geliştiricilerle tartışma ve tavsiye alma şansı vermektir. Kodun zor kısımlarında veya fikirleri prototiplemek için bazı eşleştirme oturumları yapın, ancak insanların çalışmak için kendi zamanları olsun.

Kodunuzu oluşturmayı ve dağıtmayı kolaylaştırın. İnşa sürelerini kısa tutmaya çalışın. Ne kadar kolay inşa edilirse, o kadar çok inşa edilir, o kadar hızlı inşa edilir.

Kodlama standartlarını benimseyin ve katı bir şekilde uygulayın. Bu, bir projenin dosya sisteminde yaşadığı yerden özel bir sabitin kasasına kadar her şeyi kapsamalıdır. Bu anlamsız ve sinir bozucu görünebilir, ancak iyi alışkanlıklar bir geliştirme sürecinin temel taşıdır.

Temel olarak, kullandığınız sürecin çok önemli olduğunu düşünmüyorum, modalar gelir ve gider. Asıl önemli olan, yazılımı nasıl geliştirdiğiniz konusunda profesyonel olmanız ve uygulamanızda disiplinli olmanızdır.

Duman testleri tasarlayıp otomatikleştirerek ve onları CI ortamına atarak başlardım. Bunlar işlevsel olmalı. Müşteri size bir şeyin böyle çalışması gerektiğini söylediğinde, daha sonra başvurabilmeniz için bir yere yazmanızı isteyin. Yazılımda belirli bir çözüm gördüğünüzde, sorular sorun ve yanıt alır almaz bunları bilgi tabanına dahil edin ve izlenebilir hale getirin.

Olumlu durumlar için temel işlevselliğin çalıştığından emin olun. Daha sonra hatalı veri işleme için artımlı testler oluşturmaya başlayın ve gerekli olduğu durumlarda kusurları yerleştirin. Öncelikler hakkında uzun ve derin bir tartışma yapın ve test yöneticisinin farkında olmasını sağlayın, böylece test süresini buna göre atayabilir. Her şeyi otomatikleştirmeye çalışmayın, ancak bazı test vakaları otomatikleştirilmeye mantıklı olduğu için tereddüt etmeyin.

Genel olarak, kaliteyi anında artıracak araç olarak değil, ürüne olan güveni artırmak için testi kullanın. Sakin ol, ama iddialı ol :). Belki çevik olmaya çalışın, ancak sadece kesinlikle olumlu bir şekilde PM sertifikalı olabilir. Agile'ı Agile bilmeyen bir kişi ile tanıştırmak, büyük olasılıkla projeyi öldürecektir.