Değişiklik başına çok fazla sürüm kontrolü ve hata izleme ek yükü var mı?

CVS delisi ve Bugzilla delisi olan bir yerde çalışıyorum.

1. Her sürümde o kadar çok dal var ki bunlardan biri sayılmaz. Herkes sürekli otomatik olarak birleşiyor.

2. Bu işte akıcılık yok . Her şey kilit adım atıyor . Basit bir şey için bile 25 adım atıyor. Bir fabrika üretim hattında olmak gibi değil: her gün kendime bir fabrika kurmak gibi.

Örnek durum:

Tek bir hatayı düzeltmek için önce temiz, yeni bir sanal makine elde ediyorum. Daha sonra Bugzilla raporunda açıklanan başka bir şubeye dayanarak bu tek hata düzeltmesi için bir dal oluşturuyorum. Şube makineye kurar, kurarım. Ben hatayı düzeltirim. Kontrol ediyorum, makineyi ve makineyi başkalarının test etmesi için bırakıyorum. Sonra hata kontrol yazılımına girip ne yaptığımı ve tüm adımları izleyerek bir test davası yazmam gerektiğini açıklamam gerekiyor. Sonunda bir başkası bunu bir sürümle birleştirir.

Böcek ne kadar küçük olursa olsun, bütün bunları yapmak zorundayım. Bazen insanlar işleri çoklu böcekler üzerinde birleştiriyorlar, ancak dediğim gibi, bunun pek mümkün olmadığı kadar çok dal var.

Başka bir işte, içeri girip hatayı düzeltirdim. Ben yaşadım her iş bunu kullandığına rağmen zar zor hatta, SCM kullanarak hatırlayın: işte her işte, onlar nasılsa tuttu çünkü yolumdan .

Sürecin içine girip kendine son vermesi gereken bir nokta var mı? Bu bile mühendislik mi?

Sürecin içine girip kendine son vermesi gereken bir nokta var mı?

Ağır işlemler maalesef yaygındır. Bazı insanlar - özellikle yönetim - dini olarak süreçlerin ürün ürettiğini hayal ediyorlar . Böylece süreçleri aşırıya ve gerçekten çalışkan, akıllı bir avuç insan olduğunu unutma aslında ürünler yaratmak. Üst yönetim için, işlerinin birkaç ineğin elinde olduğunu düşünmek bile korkutucu ve bu yüzden gözlerini gerçeklikten kapatıp onların yerine “süreç” i düşünen, onları kontrol yanılsaması veren korkutucu.

Bu nedenle, bir avuç iyi mühendisle çevik bir girişim başlatmak, çalışanlarının enerjisinin% 95'ini süreç ve raporlamaya harcayan büyük, yerleşik şirketleri yenebilir. Bir zamanlar rakiplerini yenen ve / veya tamamen yeni pazarlar yaratan küçük başlangıçlara dair bazı örnekler:

• Elma (Elma 1 mühendis tarafından yaratılmış ; o zamanlar şirkette 3 kişi vardı).
• Google (başlangıçta 2 programcı tarafından oluşturuldu ).
• Facebook ( başlangıçta 1- adam çaba).
• Microsoft ( 1975 yılında 2 kişilik bir şirket).

Kolayca bunların yalnızca aykırı değerler, aşırı istisnalar olduğunu ve ciddi bir şey yapmak için kolayca kurulabilir bir şirket olmanız gerektiğini söyleyebilirim. Ancak liste devam ediyor. Ve üzerinde. Utanç verici bir şekilde uzun. Hemen hemen her gün büyük şirket sıra dışı bir şey yapan bir garaj dükkanı olarak başladı. Garip bir şey. Yanlış yapıyorlardı. Sence sürece göre yaptıklarını mı düşünüyorsun ?

Şirketler genellikle Kontrol-Esneklik ikilemi olarak adlandırmak istediklerimden acı çekiyorlar. Genel kurallar, yapılar ve bürokratik genel giderler, işleri başarmaktan daha kolay ve hızlı olur (aynı zamanda daha eğlencelidir). Ancak, "kötü" şeyleri "iyi" şey olarak yapmak da aynı derecede kolaydır. Bu, yalnızca kritik olmayan birkaç hata yapan yetenekli çalışanlarınız olduğunda iyi olduğunuz anlamına gelir.

Öte yandan, düşük veya yarı vasıflı çalışanlarınız çok varsa ve / veya hata yapma maliyeti çok yüksekse (kuzey yarımkürede uzay mekiği birikintisi riski gibi) şirketler giderek daha fazla kurallara uyma eğilimindedirler. "ve" süreçleri "denemek ve en aza indirmek için.

Tek sorun, bu süreçlerin kümülatif ek yükünün şirketten ayrılan daha yetenekli çalışanlarla sonuçlanacak bir şeyi başarmayı zorlaştırmasıdır. Bu, ortalama becerinin daha da düşmesine ve daha fazla işlem ve bürokrasiye ihtiyaç duymasına neden olur. Öyleyse ölüm spirali, radikal bir şey olana ya da şirket göbeklenene kadar devam eder.

Kendinizi, bu yönden geri dönüşü olmayan noktadan geçmiş gibi görünen bir şirkette bulursanız, ya işinizi umursamayarak (kalan çoğu kişinin yaptığı şeydir) ya da cehennemi geri almak için kendiniz çözebilirsiniz. Ruhun bozulmadan orada ...

Eğer şirket fazla ileri gitmediyse ve imkanlara sahipseniz, dersi saf kararlılık ve irade ile tersine çevirmeyi deneyebilirsiniz. Başarı garantisi olmadan muazzam miktarda iş ve kişisel enerji alabileceğine dikkat edin, buna değer olduğundan emin olun. Bazen birisinin kaybını kesmek ve kendini daha zengin bir deneyim yaşamak daha iyidir.

Bu tarz bir geliştirme tarzının geçerli tek bir nedeni vardır: geliştirilen yazılım kesinlikle kritik önem taşır ve hiçbir koşulda herhangi bir hata içermemelidir. Jet motoru yakıt enjeksiyon donanımını yolcu uçaklarında veya kalp pilinin donanım yazılımında veya nükleer füze fırlatma sisteminde düşünün.

Diğer tüm durumlarda, genel masraflar işi öldürür. Harekete geçme zamanı.

Bu soru gerçekten ayrı ayrı ele alınması gereken iki soru içermektedir:

Bazı ekiplerin neden katı bir gelişim süreci var?

Basit cevap, eğer yapmazlarsa hatalar olur. Pahalı hatalar. Bu gelişme için geçerlidir ve BT alanının geri kalanı için de geçerlidir (sistem yöneticileri, DBA'lar, vs.).

Bu, pek çok geliştirici ve BT çalışanının anlaması için çok zordur, çünkü çoğumuz "uç noktalarda" sadece birinde - en azından bir düzine geliştiriciye sahip büyük Fortune tarzı şirketler ve takip edecek sıkı süreçler için çalıştık. Küçük, mikro-ISV'ler ve hatta serbest çalışan, insanların kötü bir şekilde batırmadığı ya da vidalamanın maliyeti düşük olduğu yerlerde çalışır.

Ancak, bu aşamalar arasında bir şirket - parlak, yetenekli BT personeline sahip bir şirket bile - hiç işlem yapmadıysanız, herhangi bir işlem yapmamanın veya yarı-aşamalı bir sürecin tehlikelerini anlayacaksınız. Görüyorsunuz, personel arasındaki iletişim bir Kombinatoryal Patlama probleminden muzdariptir ; Tek bir ekipte yaklaşık 6-10 geliştirici seviyesine ulaştığınızda, ana veya kritik hataların ana nedeni yetenek veya teknik bilgi değil, iletişim eksikliğidir.

Alice pazartesi sabahı etrafta sorar ve bagajda rekonstrüktif cerrahi yapılması uygun olduğuna karar verir, çünkü o kısımda başka kimse çalışmaz. Bob, bir saat sonra, tatilinden ve enerji dolu bir zamanda geri dönüyor ve aynı alanda yeni bir ana özellik uygulayacağına karar veriyor ve neden hiç kimse bu koda değmediği için bir dalla uğraşıyor? Böylece Alice, bu "teknik borcu" öder, Bob 6 ay boyunca arka brülörde olan katil özelliğini uygular ve nihayet her ikisi de kodunu kontrol ettiklerinde (tabii ki cuma günü kapanmadan hemen önce!) Takımın geride kalması ve önümüzdeki birkaç hafta boyunca böcek ve gerileme olarak yaşamaya devam eden kabus cehennemi cehennemi üzerinde çalışmaya çalışması gerekiyor.

Alice ve Bob Her ikisi de kodlama görevlerinde harika bir iş çıkardılar, ancak ikisi de kötü bir kararla başladı ("olabilecek en kötü şey ne?"). Takım lideri veya proje yöneticisi onları bir ölüm sonrası alır ve tekrar olmasını önlemek için bir kontrol listesi çıkarır:

• Çatışmaların etkisini en aza indirmek için girişler günlük olmalıdır;
• Dallarda 1 günden fazla sürecek değişiklikler yapılması gerekir;
• Tüm önemli görevler (yeniden düzenleme gibi özellik dışı çalışmalar dahil), hata izleyicide uygun şekilde izlenmeli ve atanmalıdır.

Bahse girerim, çoğumuz için, bu "süreç" sağduyulu gibi gözüküyor. Bu eski bir şapka. Fakat birçok küçük takımın bunu yapmadığını biliyor muydunuz? İki kişilik bir ekip, kaynak kontrolü ile hiç uğraşmıyor bile. Kimin umrunda? Gerçekten gerekli değil. Sorunlar sadece takım büyüdüğü zaman başlıyor, fakat süreç yok.

Tabii ki, süreç optimizasyonu performans optimizasyonu gibidir; ters üstel bir eğri izler. Kontrol listesi yukarıdaki kusurların% 80'ini ortadan kaldırabilir, ama bunu uygulamak sonra, bazı başka şey için hesaplar bulmak kalan kusurların% 80. Hayali ama tanıdık bir örneğimizde, farklı donanım ortamları nedeniyle oluşan hatalar olabilir, bu da standart bir donanım olmadığı ve geliştiricilerin her 2 haftada bir güncellenen açık kaynaklı kitaplıklar kullandıkları gerçeğinden kaynaklanmaktadır.

Bu nedenle, üç seçeneğiniz vardır: (a) donanımı standart hale getirin ve maliyeti yüksek olan ve verimliliği önemli derecede azaltabilecek olan 3. taraf kitaplık kullanımını ciddi şekilde kısıtlayın ya da (b) sysadmin grubundan ve korumak için tam zamanlı geliştirici, veya (c) standart bir sanal makine dağıtarak ve geliştiricilere bu konuda geliştirme yapmalarını söyleyerek geliştiricilere bunu yapmalarını sağlayın. Açıkça (b) en iyi uzun vadeli çözümdür, ancak (c) daha iyi bir kısa vadeli güvenilirlik ve uygunluk dengesine sahiptir.

Döngü uzayıp gidiyor. Gördüğünüz her "politika" genel olarak gerçek bir sorunu çözmek için kurulmuştur. Joel Spolsky'nin 2000 yılında tüm yolunu yazdığı gibi (tamamen farklı bir konuda, ama yine de alakalı):

Bir restorana girdiğinizde ve "Köpeklere İzin Yok" yazan bir işaret gördüğünüzde, bu işaretin tamamen gizleyici olduğunu düşünebilirsiniz: Bay Restaurant, köpekleri sevmez, bu yüzden restoranı inşa ettiğinde o işareti koydu.

Olanların hepsi bu olsaydı, "Yılan Yok" işareti de olurdu; sonuçta, kimse yılanları sevmez. Ve "Fil Yok" işareti, çünkü oturdukları zaman sandalyeleri kırarlar.

Bu işaretin asıl nedeni tarihseldir: insanların köpeklerini restorana getirmeye çalıştıklarını gösteren tarihi bir işarettir.

Çoğu (aynısını söylemeyeceğim) yazılım ekiplerinde aynıdır: “Her hata düzeltmesi için bir test vakası eklemeniz gerekir” gibi politikalar neredeyse her zaman ekibin tarihsel olarak gerilemeyle ilgili sorunları olduğunu gösterir . Regresyonlar, yetersizlikten ziyade iletişimin bozulmasından dolayı ortaya çıkan sorunlardan bir diğeridir. Politikayı anladığınız sürece, meşru kısayollar alabilirsiniz (örneğin, 6 küçük hatayı düzeltmek zorunda kaldım ama hepsi aynı özellikteydi, bu yüzden aslında 9 tanesi için bir test davası yazabilirim).

Bu, süreçlerin neden orada olduğunu açıklar, ancak bütün hikaye bu değildir. Diğer yarısı:

Süreci takip etmek neden bu kadar zor?

Aslında cevaplanması gereken en basit soru şudur: Çünkü takım (veya yönetimi) tekrarlanabilir sonuçlara odaklanır ve hataları en aza indirir (yukarıdaki gibi) ancak bu sürecin optimizasyonuna ve otomasyonuna yeterince önem vermedi .

Örneğin, asıl soruda, birkaç sorun görüyorum:

• Revizyon kontrol sistemi (CVS) bugünün standartlarına göre eski. İçin yeni projeler hızla böyle Mercurial (Hg) olarak dağıtılmış sistemler gölgesinde hale gelmektedir kendisi yıkılma (SVN), neredeyse tamamen almıştır. Hg'ye geçmek, dallanmayı ve birleşmeyi çok daha basit hale getirecek ve yukarıdaki varsayım örneğime rağmen, günlük taahhüt gereksinimi çok daha az acı verici hale gelecekti. Kodun derlenmesi gerekmez, çünkü havuz yereldir; - aslında, lazier geliştiricileri, isterlerse otomatik olarak yerel depoda değişiklikler yapmak için bir oturum açma komut dosyası ayarlayarak bu adımı otomatikleştirebilirler.

• Sanal Makine işlemini otomatikleştirmek için zaman harcanmadı. Bir sanal makineye kaynak / kitaplık edinme, yapılandırma ve indirme işlemi% 100 otomatikleştirilebilir. Yerel makinenizdeki hata düzeltmeleri üzerinde çalışırken merkezi bir sunucuda çalıştırdığınız katılımsız bir işlem olabilir (ve temiz bir yapı oluşturmak için VM'yi kullanın).

• Öte yandan, belirli bir ölçekte geliştirici başına VM çözümü aptallaşmaya başlar ve yalnızca Sürekli Entegrasyon sunucusuna sahip olmanız gerekir. Gerçek verimlilik avantajlarının geldiği yer burasıdır, çünkü (çoğunlukla) bireysel geliştiricileri binalar hakkında endişelenmek zorunda kalmaz. Derleme sunucusu her zaman temiz olduğu için temiz sanal makineler kurma konusunda endişelenmenize gerek yok .

• Sorunun ifadesi ("tüm adımlarla test davası"), bazı manuel testlerin yapıldığına işaret eder . Bu, yine nispeten düşük bir iş yüküne sahip küçük takımlar için çalışabilir, ancak daha büyük ölçekte hiçbir anlam ifade etmiyor. Regresyon testleri otomatikleştirilebilir ve yapılmalıdır; "basamak" yoktur, sadece ünite / entegrasyon test odasına eklenmiş bir sınıf veya yöntem vardır.

• Söylemeye gerek yok, Bugzilla'dan daha yeni (daha iyi) bir hata izleme sistemine geçmek, deneyimin bu kısmını daha az acı verici hale getirecektir.

Şirketler sadece bu sorunları çözmedikleri için ucuz ya da aptal değildirler. Tek bildikleri şu anki sürecin işe yaradığı ve bazı durumlarda bu konuda bir şeyleri değiştirmeye riskli ve isteksiz oldukları. Fakat gerçekten de faydalarından ikna olmaları gerekiyor .

Geliştiriciler kodlama yapmayan tüm görevlerde zamanlarını izleyerek bir hafta geçirdilerse, kolayca ekleyebilir, mesela yönetime Mercurial’a geçişte sıfır sermayeli, 100 kişilik bir yatırım olacağını (örneğin) birleştirme çatışmalarını çözmek için haftada 10 adam-saati ortadan kaldırır, o zaman bu 10 haftalık bir ödemedir ve neredeyse kesinlikle buna katılırlar. Yapı sunucuları (CI) veya daha iyi hata izleme ile aynı fikir.

Özetlemek için: Takımlar henüz böyle bir şey yapmadı, çünkü kimse yönetimi bugün yapmanın yeterince önemli olduğuna ikna etmedi . Öyleyse inisiyatif al ve bir fayda-maliyet denklemine dönüştür; Asgari riskle basitleştirilebilecek / otomatik hale getirilebilecek görevlere ne kadar zaman harcandığını öğrenin ve yeni bir araç veya tekniğin başlangıç ​​noktası ve nihayetinde getirisini hesaplayın. Onlar ise hâlâ dinlemiyorsun, o zaman zaten kalan seçenekler ne olduğunu biliyoruz.

Eğer geliştiriciler bir hafta boyunca kodlama yapmayan tüm görevlerde zamanlarını takip ederek geçirdilerse, kolayca ekleyebilir, yönetimi gösterebilir ve maliyet-fayda denklemine çevirebilirdiniz ...

Yukarıdaki bölüm daha da genişlemeye değer.

İşe yaradığını onaylayabilirim. Programcılar, üzerinde çalıştığım projelerden birinde birkaç kez kullandılar ve her seferinde istenen değişikliklere yol açtı.

Genel izlenim, doğru yapıldığında, bu numara oldukça ağır miktarda yönetim cehaletini ve ataleti geçersiz kılabilir .

Kendimizi (geliştiricilerin) bu türden bir yaklaşımla ele almak zorunda kaldıklarını söyleyen bu DIY yaklaşımının çok olgunlaşmamış olduğunu belirtmek isterim . Daha fazla deneyimli yazılım satıcısında bunun gibi şeylerin çoğunlukla yöneticiler tarafından yapıldığını gördüm. Kural olarak, bizde programcılardan daha üretkenlerdi. Çok daha üretken.

Eğer sıkı bir şekilde düzenlenmiş bir sektörde çalışıyorsanız, bu hantal sürecin bazı sebepleri olabilir: bir gün denetlenebilir ve bu hatayı kimin düzelttiğini, nasıl, kimin incelemesini, kimin test ettiğini açıklamak için tüm kayıtlarınızı göstermeniz gerekir. o, vb ...

Bu yüzden gerekli bir kötülük olabilir.

Öte yandan, bu süreç için gerekçenin bulunmaması durumunda, yönetimden duyulan güvensizlikten başka, yöneticinizle konuşmaya çalışmalı ve ona şirket için nasıl zaman ve paradan tasarruf edebileceğinizi anlatmalısınız.

Doğru şekilde açıklandığı takdirde, daha hızlı ve daha iyi bir süreci reddeden, aklında hiç kimse yoktur.

Ancak değişikliği haklı çıkarmak için savınızı savunmaya hazır olun.

Sorunun yarısı, bir süreçte kullanılmayan araçları, sizin tasarlanmadıkları yerlerde kullanıyor olmanızdır. Tanımladığınız şey, hata başına dal oluşturma sıkıntısı çekmeden modern DVCS'lerde olması çok kolaydır.

Başka bir sorun açıkça sizin zevk aldığınız iş doğrultusunda değilsiniz. Gelişim yapmak isterken, bakımda çalışıyorsunuz. İşi değiştirmenin yanı sıra bu konuda yapılabilecek çok az şey var.

Yazılım mühendisliği disiplini, doğası gereği "süreç hakkında" dır, bu yüzden "böyle" olup olmadığını merak etmek, bu noktayı kaçırmaktır.

Çoğu programcı, asgari süreçten ziyadesiyle rahatsız edilmek yerine, bazılarının çevik metodolojileri için örgütlenmelerin karşılaştığı sorunları çözmedikleri zaman savunuculuk yapacak olsa da, bir şirketin kullanmaya karar vermesi tamamen mümkündür ” ağır " iş taleplerinden dolayı" müşteri talep ediyor "gibi süreçler . Müşterileriniz Fortune 500 şirketleri, üniversiteleri veya devlet kurumları ise bu yaygındır. Bu müşterilere satış yapmanın getirdiği kazançlar, eklenen ek yükü haklı çıkarmak için yeterince büyük olabilir.

Şirketiniz bir veri noktasıdır ve deneyiminizi daha ağır süreçlere doğru ya da uzağından endüstri çapında bir eğilim içinde genelleştirmek imkansızdır. Asıl soru, şirketiniz, ürünleriniz, müşterileriniz ve kişisel olarak bir programcı olarak sizin için en iyi hangi dengenin işe yaradığıdır? Bu şirkette çalışmaktan hoşlanmıyorsanız, değişimi başlatın veya başka bir iş bulun.

Gönderen diğer soruya Bugün senden gördüğüm, işinde oldukça mutsuz görünüyor. Uzun süredir orada bulunmadınız, amirinize sadece bir hata yaptığınızı düşündüğünüzü söyleyebilirsiniz ve artık beklenenden daha erken bir şekilde ayrılma zamanınız geldi.

İşinizde iyiyseniz, yeni bir tane bulmakta gerçekten çok zorlanmayacaksınız ve dürüst olmak gerekirse, bu sürecin gerçekleşmesi için iyi bir neden yoksa, muhtemelen de hareket etmeyi düşünürdüm. CVS'yi kullanmak benim için gerçekten çok önemli bir şey olurdu, ancak görüşme sırasında her zaman kaynak kontrol sorusunu soruyorum. Açıkçası, durumunuzu bilemiyorum ve başka zorunluluklarınız varsa iş bırakmak mümkün olmayabilir.

Çok kötü programcılar ile yazılım mühendisliğinin nasıl sular altında kaldığını konuşacaktım, ama anlattığınız durum korkunç.

Benim kişisel deneyimime göre, tarif ettiğiniz bu "işlem" den bazıları, programcılara dayattığı sistemlerin verimsizliklerinin tamamen farkında olmayan yönetim ve sistem yönetimine eşlik ediyor. Örnekler arasında işletim sistemi seçimini kısıtlama, kullanılan yazılımı kısıtlama, internet erişimi, kişisel masaüstü yönetim ayrıcalıkları; Bütün bunlar iyi gelişme için çok önemlidir .

Ayrıca, farklı şirketler tarafından kullanılan "sihirli çözümler" arasındaki uyumluluk gereksinimleri. Örnekler arasında merkezileştirilmiş kaynak kontrolü uygulayan merkez ofisleri, saha dışı Outlook sunucuları ve her sorun için uygun olmayabilecek kodlama yönergeleri veya diller sayılabilir.

Kurumsal juggernaut'ların tekerleklerini yuvarlamak çok eğlenceli değil, ancak bazı firmalarda çok az yenilik, yaratıcılık ve parlaklık kabarcıkları olduğunu gördüm.

Muhtemelen süreç odaklı bir şirkette çalışıyorsunuzdur. Bunun yerine sonuç odaklı bir şirket bulmaya çalışacağım , nerede yaptığınızla değil, sizin için önemli olan şey.

Şirketimde de bir "süreç" var (ama çok basit). Kısayol alarak hiçbir şeyi kırmadığım sürece hiç kimse bana bir şey söylemeyecek çünkü sonuçları alıyorum.

Sürecin içine girip kendine son vermesi gereken bir nokta var mı? Bu bile mühendislik mi?

Kelimenin tam anlamıyla, çoğu mühendislik belirli bir soruna cevaben iyi kurulmuş parçaları belirli bir düzende bir araya getiriyor. Bir ME'ye bütün gün ne yaptıklarını sorarsanız, bu çok açık. Mühendisliği mimarlıkla veya erken aşamadaki ürün geliştirme (herhangi bir alanda) ile karıştırıyorsunuz. Sorunuz hakkında iki gözlemim var.

1. Mimari veya tasarım çalışmalarına değil, hata onarım çalışmalarına atanmış gibisiniz.
2. İş arkadaşlarınız, onları daha verimli hale getirmek için sınırlı geçici çözümler (bug fix VM'leri birleştirerek) ile gelmiş gibi görünüyorlar, onların mantıklı örneklerini takip ediyor gibi görünmüyorsunuz.

Basitçe, çok sayıda insanı alan herhangi bir yapıcı çabada, bazı insanların tasarımı yapması ve daha büyük bir grubun uygulamayı yapması için bir 'gerçekleşme' olduğu bir gerçektir. Üzgünüm, ama ikinci gruptasınız.

Diğer yorumcuların da belirttiği gibi, CVS yüksek branşlı bir geliştirme modeli için iş için en iyi araç değildir, ama aynı zamanda birleşmeden sorumlu olmadığınızı da unutmayın, bu yüzden endişelenmeyin.

Şikayetlerin çoğu aslında "Gelişmeden önce, sırasında veya sonrasında test etmek istemiyorum!" Gibi görünüyor. Adımlarınızı kıracağız, nokta nokta.

• Tek bir hatayı düzeltmek için önce temiz, yeni bir sanal makine elde ediyorum. Bir test ortamı
• Daha sonra Bugzilla raporunda açıklanan başka bir şubeye dayanarak bu tek hata düzeltmesi için bir dal oluşturuyorum. - Böceğin bulunduğu çevreyi kopyaladınız ... bu mantıksız mı?
• Şube makineye kurar, kurarım. Ben hatayı düzeltirim. Ben kontrol - Temel dev süreci
• ... onu ve makineyi başkalarının test etmesi için bırakarak. - Birleştirme ekibiniz muhtemelen birleşme güneye giderse düzeltmeyi doğrulayabilmeyi ister.
• O zaman hata kontrol yazılımına girip ne yaptığımı açıklamam gerekiyor - Bunu yapmayan bir mağazadaysanız ... neden hataları izliyorsunuz?
• ve tüm adımlarla bir test davası yazın. - Yanılıyor olabilirim, ama bu, tüm 'havalı çocukların' nasıl gideceği yönünde görünüyor.
• Sonunda bir başkası bunu bir sürümle birleştirir. - Yukarıdaki adımların bazıları işlerini kolaylaştırmak için.

Önünüzdeki bir başkası, bulunan bir hatanın başka bir sürümde yeniden düzeltilmediğinden veya daha sonraki bir sürümde bozulmadığından emin olmak için hata denemesi yapar (test durumları bunun için geçerlidir).

Uzaktan bile olağandışı ya da bu süreç hakkında çok kısık olan tek şey, VM olayıdır. Hangi alanda çalıştığınızı bilseydik, makul sayılabilecek bir ihtimal var.

İlginç. Test cihazın var mı? Bunların bir kısmını yapıyor olmalılar. Ben birim ve çalıştığım yerde iyi bir çözümümüz var.

İşlevsel bir kusur için, açıkladığınız gibi, işlemimiz şöyle devam eder:

1. Bir VM'deki kusurları test ederim (ya bir müşteri tarafından rapor edildi, ya da keşif testim sırasında, veya e)
2. Hata bulundu / yeniden düzenlendi.
3. Böceği ben yaratıyorum. Hatalar şunları içerir:
   • Tam repro, kurulum noktasından hatayı görme noktasına kadar.
   • Sanal Makinenin anlık görüntüsüne bir bağlantı (eğer geliştiricinin buna ihtiyaç duyacağını düşünüyorsanız ... her nasılsa, isterlerse sordum).
   • Sistem bilgisi, yapmam gereken özel ayarlar.
4. Bu hata deve atanır. Bir düzeltme üzerinde çalışırken ben:
   • Bir test durumu oluşturun
   • Manuel testi otomatik bir teste yazın (veya dönüştürün)

Sonra bir çözüm bekliyorum ve ihtiyaç duydukları her şekilde deve yardım ediyorum. Çözüldüğü gibi geri geldiğinde, ben:

1. Düzeltmeyi onaylamak için otomatik test senaryosunu ve manuel versiyonu (bazen) çalıştırın.
2. Böceği kapat.

TL; DR: Test cihazınız yoksa, o zaman bazılarına ihtiyacınız var. Eğer bazılarınız varsa, o zaman 'rollerini yapmıyorlar'.

Tom DeMarco:

... İlk ölçüm kitabım ... en çok alıntı yapılan satır ilk cümlesidir: "Ölçemediğiniz şeyi kontrol edemezsiniz." Bu çizgi gerçek bir gerçeği içeriyor, ama onu kullanmamdan giderek daha rahatsız oluyorum. Alıntıdaki örtük (ve aslında kitabın başlığında), kontrolün herhangi bir yazılım projesinin önemli bir yönü, belki de en önemlisi olduğu yönündedir. Ama öyle değil.

... kontrole ne kadar çok odaklanırsanız, göreceli olarak düşük değerli bir şey sunmak için çabalayan bir proje üzerinde çalışıyor olabilirsiniz.

Aklıma göre, bir yazılım projesini kontrol etmekten çok daha önemli olan soru şudur, neden dünyada böyle bir marjinal değer sağlayan bu kadar çok proje yapıyoruz? ...

Yazılım Mühendisliği: Kimin Zamanı Gelip Gitti?

"Sonra o tek hata düzeltmesi için bir dal oluşturuyorum"

Tek hata düzeltmesi için dal oluşturmaya gerek yoktur. İlk önce bugzilla'da hatayı yaratın. Serbest bırakma şubesini kontrol et. Düzeltmeyi yap. Taahhüt mesajında ​​yazılan metin anahtar kelimelere bağlı olarak, hatayı güncelleyen ve "sabit, teste ihtiyacı var" veya "sabit, test edilmiş, birleştirme ihtiyacı" olarak işaretleyen hata numarasını içeren onaylama mesajıyla işlemi gerçekleştirin. Hata veritabanı yapılan tüm değişiklikler ve neden yapıldıkları için mükemmel bir takip mekanizmasıdır; Bu bilgiyi çıkarmak için raporları bug veritabanından çalıştırılabilir.

Sürecin çoğunun otomatik olabileceğini düşünüyorum , böylelikle hata üzerinde çalışmaya başlamadan önce sanal makine ve şube oluşturma (derleme kodu, hata ayıklayıcıları ayarlama vb. Dahil) tamamen sizin için yapıldı.

Yaptıklarınızı ve nasıl test edileceğini açıklamak tüm hata düzeltmeleri için buna değer. Sadece metni yazarken sorunları yakalayabileceğimi gördüm , çünkü risk hakkında düşünmemi sağlıyor.

Bu yüzden, sürecin biraz “üstte” olabileceğini düşünüyorum, ancak asıl mesele, süreci destekleyen özel otomatik araçların eksikliği.

Hey dostum, düşünce sürecin, tarif ettiğin şeyin tamamen berbat olduğu ve yazılımda ne kadar yanlış olabileceğinin gerçek bir gösterimi olduğu konusunda haklı. İşte iyi haber olsa da, gerçek ruhlarda Agile'yi uygulayan pek çok şirket var. Çalıştığım şirket böyle bir şey. Bugünlerde birçok ve bu gerçekten iyi bir haber var.

İş yerinizde işlerin gerçekten doğru olmadığını hissettiğiniz zaman, yapabileceğiniz iki şey var - ya pozitif değişimi etkileyebilir ya da o yeri terk edip daha iyi birine katılabilirsiniz.

CVS veya herhangi bir konfigürasyon yönetim sistemi fena değil. Ne yazık ki, kullanım şekli, amacını gerçekten bilmeden, tüm organizasyon için! @ # $ 'De bu tür acıya neden olmaktadır.

Agile'nin gerçekte neyle ilgili olduğunu hızlı bir şekilde anlamak için, Venkata Subramaniam'ın "Çevik bir geliştiricinin Uygulamaları" kitabını inceleyin. Kolayca anlaşılabilir bir dille yazılmış.

Size iyi şanslar diliyorum!