Evet, gerçek dünya üniversitede öğretilenden çok farklı.

Bir işletme için çalıştığınızda iş, idealize edilmiş bir yazılıma göre yazılım sunmak değil, kâr etmektir. gelişme süreci. Bu şeyler çoğu zaman birbiriyle örtüşüyor, ancak her zaman değil.

Zaman zaman "köşeleri kesmek" tamamen meşru.

Patronunuzun bunu yapmadığına üzülseniz de ' Yazılım testinin önemini anlarsanız, işi etkileyen ticari baskıların farkında olmadığınızdan şikayet edebilirler. Bu, nesnelerin otomatik test olmadan gönderilmesi gerekebileceği anlamına gelir. Patronunuzu test etmenin önemini görmezden gelmek olarak sınıflandırmanın adil olduğunu sanmıyorum. Açıkçası, buna sizden farklı bir önem derecesi veriyorlar veya ne olduğunuza göre farklı faktörlerin farkında oluyorlar.

Bu durumda sizin rolünüz, yöneticinize otomatik test yapılmaması ile ilişkili riskleri vurgulamaktır. ve eldeki tüm bilgilerle bir karar vermelerine izin verin.

Yazılım geliştirme, sık sık yeni işler yaparken bilinmeyen veya belirsiz ortamlarda riski yönetmekle ilgilidir. Zaman, kapsam ve kalite konusunda ödün vermek her zaman olur. Yapılacak önemli şey, paydaşların kararlarının proje üzerindeki etkisini anlamalarına yardımcı olmaktır. Bana göre, "işi bırak" veya "düdük çal" yanıtları, proje için alınan kararların yaşam ve güvenlik, mahremiyet veya gizlilik, güvenlik veya başka bir 'kritik faktör' açısından ciddi sonuçlara yol açacağı durumlar için saklanacaktır. (Bu, ne oluşturduğunuza bağlı olarak değişir).

Maalesef, bu kararları vermek için en iyi uygulamalar veya algoritmalar yok. Öğrenme, zaman ve deneyimle gelir. Başkalarının deneyimlerini inceleyebilirsiniz, ancak en iyi deneyimler sizindir ve karar verme sürecinin gerekçesini anlamak için meslektaşlarınızla bu ödünleşmeler üzerinde çalışmak. Bunun gibi kararlar son derece bağlama duyarlıdır.

Evet, teknik borç çoğu durumda tamamen geçerli bir karardır; tıpkı gerçek borcun alınması gibi, birçok durumda iş hedeflerini ilerletmek için geçerli bir iş kararıdır. (İşletmeye yatırım yapacak sermayemiz olsaydı $ $ kazanırız, bu nedenle $ 'lık bir kredi almak ve $$'ı geri ödemek uzun vadede bizi yine de önde tutar.)

Ama bence otomatik testleri atlamak asla iyi bir borç değildir . Tasarruf edilen zaman genellikle yıllar veya aylar olarak değil haftalarca kullanılır. (Ve ödemesi katlanarak zorlaşıyor.) Son tarih bugün değilse, testleri atlamayın; buna değmeyecek.

Bu, TDD IMHO'yu takip etmek için bir nedendir. Çünkü o zaman asla bir özelliğin "bittiğini", ancak "yine de test edilmesi gerektiğini" söyleyebileceğimiz bir durumda değiliz. Teknik olmayan bir yönetici için testleri bırakıp bitti diye çağırmak çok cazip. Artık yalnızca kapsamı kısmak, teslimatı yeniden planlamak veya gerçekten gerektiğinde diğer teknik borç türlerini kullanmak (devlet yönetimini kötüye kullanmak, sağlam mimarileri atlamak vb.) İçin çok daha iyi seçeneklere sahipler.

"Kısayollar" dediğiniz şey, gerçekten değiş tokuşlardır ve bunlar, üstleneceğiniz herhangi bir disiplinde, her projenin doğasında vardır. Kaçınılmazdır. Mühendislik dünyasında bir deyim var (evet, bunu yukarıdaki bir yoruma ekledim): İyi yapabilirsin, hızlı yapabilirsin ya da ucuza yapabilirsin. En iyi durumda, 2'yi seçersiniz, bu nedenle belirli bir durumda hangi 2'nin en önemli olduğuna karar verilmesi gerekir.

Durumunuzu örnek olarak kullanmak için küçük bir ekibiniz var ( ucuz) ve sıkı bir son tarih (hızlı), bu nedenle oluşturduğunuz şeyde muhtemelen çok fazla hata olacaktır ve yapmak istediğiniz testi yapamayabilirsiniz. Bu, müdürünüzün verdiği karardır ve sonuçlarıyla ilgilenmesi gerekecektir. Daha iyi bir ürün oluşturmak için daha fazla test mi yapmak istiyorsunuz? Ya size daha fazla zaman vermeli ('hızlı' kaybetmeli) ya da testi yapmak için daha fazla kişi eklemeli ('ucuza' kaybetmelisiniz). Bunlar proje için seçenekler olmayabilir. Bu kaçınılmazdır.

Yani işinizden ayrılmak hiçbir şeyi çözmez, çünkü bu ilke nereye giderseniz gidin orada olacaktır. Yapabileceğiniz en fazla şey, üçlünün farklı bir kısmına vurgu yapan başka bir işveren bulmaktır, ancak bu bile projeden projeye değişecektir. Tıpkı şu anki yöneticiniz gibi kararlar alıyorlar.

Bu üçlü aleyhine verilecek herhangi bir kararın sonuçları olacak ve birinin bunların kabul edilebilir olup olmadığını çözmesi gerekecek. Daha iyi bir ürün oluşturmak için yavaşlamak, son teslim tarihini kaçırabileceğiniz anlamına gelir. Daha fazla insan eklemek, başka bir şey üzerinde çalışmayacakları anlamına gelir. Hızlı ve ucuza inşa etmek, onu daha sonra desteklemek için (veya kalitesiz bir ürünle yaşamak) daha fazla zaman harcamak anlamına gelir. Gereksinimlere bağlı olarak, bu kararlardan herhangi biri geçerli olabilir. Önemli olan, değiş tokuşları, bunların işletme için ne anlama geldiğini anlamak ve karar vericilerin bunları anladığından emin olmaktır. Sahip olabileceğiniz en önemli becerilerden biri bu.

"Değiş-tokuşlar" hemen hemen her zaman gereklidir, ancak saçmalık sunmak gerekmez. Kendinize çöp dağıtmanız istendiğini fark ederseniz, uzaklaşmayı düşünün. Veya yazılım finans, bilgi güvenliği veya sağlıkla ilgiliyse, bunu gözden kaçırmasını sağlayın. (Çünkü başarısız olduğunda, yönetim günah keçileri arayacak.)

Hangi önlemlerin alınması gerekir? Birincisi, yöneticinize bu kısayolun şirkete ne kadar bir maliyet getirebileceğini açıklamaktır. En kötü durumda kısayol, insanları tehlikeye atmak ve muhtemelen öldürmek anlamına gelir. En zararsız durum, sorunu önümüzdeki hafta çözmeniz ve herhangi bir zararın olmamasıdır. Yöneticinizin eğitimli bir karar vermenin ne olduğunu bilmesi gerekir.

Bir sonraki eylem, gerekirse kısayolu "düzelten" adımlar atmaktır. Bazen buna gerek yoktur. Bazen tek bir kullanım için yazılım yazarsınız ve çalışır ya da çalışmaz ve çalışıp çalışmadığını görebilirsiniz. Bu durumda, yazılım işe yaradıysa, hangi kısayolları kullandığınızın önemi yoktur.

Bazen kısayollar haklıdır. Tek geliştirici olduğunuzu ve yazılımın X tarihinde hazır olması gerektiğini varsayalım. X tarihinde hazırsanız, şirket iki geliştirici daha işe almaya yetecek kadar çok para kazanıyor. X tarihinde hazır değilseniz, şirket para kazanmaz ve işinizi kaybedersiniz. Açıkça kısayolu kullanıyorsun. Her şey yolunda giderse, iki ekstra geliştirici, hızlı olması için yaratılan tüm karışıklığı temizlemekten daha fazlasını yapabilir.

İyi olan, yöneticinize yazılımınız iyi durumda ise bazen kısayollar kullanabileceğiniz konusunda eğitim verebilmenizdir. Bir haftada dört hafta sürmesi gereken bir işi yapabilirsiniz (ama şimdi yazılım tamamen karıştı). Ancak bunu yalnızca bir kez yapabilirsiniz, o zaman temizlemek için üç hafta harcamanız gerekir. Temizlik yapmazsanız, sonraki dört haftalık iş ya temizlik dahil yedi hafta sürer ya da dört hafta daha da fazla karışıklık bırakır ve bundan sonra başınız belaya girer.

Sorunuzun temeline itiraz etmek istiyorum.

Yazılım geliştirme konusunda uzman kimdir? Sen mi patronun mu? Patronunuz sizi bir uzmansınız, profesyonel olduğunuz için işe aldı. Otomatik test, işinizin bir parçasıdır. Bu nedenle, bir profesyonel gibi hareket edin ve gerekli görürseniz otomatik test uygulayın. Patronunuz ayrıca bir sonraki satıra geçmek için tıklayıp tıklamanıza veya klavyenizi kullanıp kullanmayacağınıza da karar veriyor mu? Patronunuz sekme veya boşluk kullanıp kullanmayacağınıza karar veriyor mu? Bir programcı olmadığı sürece patronunuz bu konuda söz hakkına sahip değildir. Otomatik test için aynı. Onlar sizin işinizin bir parçası ve patronunuzun da bu konuda söz hakkı yok.

Elbette, bazen değiş tokuş yapmak istersiniz, ancak patronlar yalnızca özellikler üzerinde değiş tokuş yapabilirler. Ayrıca daha hızlı denemenizi ve programlamanızı da isteyebilirler. Ancak, yalnızca siz, geliştirmek için işe aldıkları profesyonel, kod kalitesi değiş tokuşlarına karar verebilirsiniz. Sizi neyin daha hızlı kodladığını bilmek sizin işiniz, onlarınki değil.