Yönetimi teknik borçlarla başa çıkmak için nasıl ikna edebilirim?


158

Bu, geliştiricilerle çalışırken sıklıkla kendime sorduğum bir soru. Şu ana kadar dört şirkette çalıştım ve bir yazılım uygulamasında gelecekteki ilerlemeyi engelleyen, kodun temiz tutulmasına ve teknik borçlarla ilgilenmeye dikkat edilmediğini fark ettim. Örneğin, çalıştığım ilk şirket MySQL gibi bir şey kullanmak yerine sıfırdan bir veritabanı yazmıştı ve uygulamayı yeniden yapılandırırken veya genişletirken ekip için cehennem yarattı. Projeksiyonları tartışırken menajerime her zaman dürüst ve açık olmaya çalıştım, ancak yönetim zaten orada olanı düzeltmekle ilgilenmiyor ve bunun takım moralindeki etkisini görmek korkunç.

Bu problemi çözmenin en iyi yolu hakkındaki düşünceleriniz nelerdir? Gördüğüm şey insanlar toplanıp gidiyorlar. Şirket daha sonra geliştiricilerin girip çıktığı ve kodu daha da kötüleştirdiği bir döner kapı haline geldi. Teknik borçları çözme ile ilgilenmeleri için bunu yönetime nasıl iletirsiniz ?


5
"geliştiricilerle çalışmak" "bunu yönetime iletin" Hangisini soruyorsunuz? Geliştiriciler veya yöneticiler? Kimin davranışını değiştirmek istiyorsun?
S.Lott,

45
Teknik borç finansal borç gibidir - uzun vadede başlamak için biriktirmemek çok daha kolaydır. Tüm teknik faturalarınızı haftada bir kez ödeyin.
Lawrence Dol

7
Mike> Son tarihler ve sınırlı bütçeler yaşadığım dünyaya hükmettiği için çok daha az kısıtlayıcı bir dünyada yaşadığınızı düşünüyorum. Yazılım gelecekteki ihtiyaçlara iyi adapte değilse ve düzeltmek için çok fazla çaba gerektiriyorsa, yönetim genellikle görmezden gelmekle daha fazla ilgilenir o ve özellikleri üzerine bolt tutmak. Şimdi çalıştığım pek çok arkadaş, zaman çizelgelerini uygulamaya koydu, bu nedenle geliştiricilerin çalışmalarını kaydetmeleri gerekiyor ve yönetimin olası işi gördüğü yere zaman harcanmıyorsa, zamanınızı boşa harcıyorsunuz demektir.
Planet Desolate

4
Sanırım bunun kısa vadeli faydalar ile uzun vadeli faydalar arasında bir sorun olduğunu söyleyebilirsin. Bir yazılım ekibi bir sistemi bir gün yerine uygulamak için yeni özelliklerin bir saatten az süreceği şekilde düzenlerse, bu hemen bir faydadır. Yönetim, kodu geliştirmeye çalıştığınızı ve istediklerini aleyhinize başladığını görüyorsa, gözlerinde biraz asi oluyorsunuz. Gerçekten en iyi çözümün ne olduğunu bilmiyorum, ama bu çok yaygın bir sorun gibi görünüyor ve ekiplere ne yaptığını gördüm.
Issız Gezegen

3
Scott> Soruyu cevaplamak için, değiştirmek istediğim yönetim tutumu. Geliştiriciler kodu bilir ve işleri kolaylaştırmak için hangi kodun geliştirileceği konusunda ilk elden deneyime sahiptir. Bir uygulamanın yeni bir versiyonunu piyasaya sürdüğümüzde önceki işlerde, böcek sayısı korkunç oranda artmaya devam etti. Test stratejileri uygulamak için çok çalıştım, ancak genellikle kayıp bir neden gibi geliyor.
Issız Gezegen,

Yanıtlar:


191

Bunu tartışmak için patronumla bir araya geldiğimde, tüm tahminlerime yeniden düzenlemeyi dahil etmem gerektiğini söyledi. Düşünmek istediği bir sorun olmadığını söyledi. Bunun yerine, ben halletmeliyim.

Bu, genel olarak yönetimin düşünmek istediği bir problem değildir. Onlar mühendis değiller. Bunu tüm tahminlerinizin söylenmemiş bir parçası haline getirin, teknik borcun azaldığını göreceksiniz.

Yine de asla mükemmel olmayacak. Teknik borç, kredi kartı borcu gibi, müşterilerin daha hızlı elde edilmesine ve rakiplerinizden daha hızlı pazar payı elde edilmesine yönelik bir yatırımdır. Kredi gibi, eğer uygun şekilde yönetilirse, sizi oldukça başarılı kılabilir.


30
Tecrübelerim genellikle bu çizgidedir. Yeni özellikler eklendikçe teknik borç temizlenir. Bazen belirli 'ilgili' düzeltmeler / özelliklerin tahminleri, bu şeylerin temizlenmesini içerecek şekilde doldurulur.
Ken Henderson,

4
+1 Duygularımı tam olarak paylaşıyorsunuz ... kendinizi daha diplomatik olarak ifade etmen dışında;)
Michael Brown

7
İyi cevap. Henüz müşteriye fayda sağlayamayacak bir 'yeniden düzenleme' projesini imzalamaktan mutlu olan bir işletme görmedim, sadece düzenli kod. Refactor-you-go şekilde kullanın.
JBRWilkinson

7
“Bunu tartışmak için patronumla tanıştığımda, tüm tahminlerime yeniden düzenlemeyi dahil etmem gerektiğini söyledi.” - Bu benim aldığım tutum ve çalıştığım ekiplerdeki birçok geliştiricinin tutumu. Ancak, bu 9 ila 5 geliştirici olarak adlandırdığımız geliştiricilerin yorumları ve ücret artışlarıyla ilgilenmeleri durumunda, kendileri için daha fazla iş yaratmayacaklar. Ne olursa olsun yönetimin ne düşündüğünü takip edecekler, sonuçta, onlara para ödüyorlar.
Issız Gezegen

8
@ jmort253: bu mükemmel politika ile ilgili bir (küçük) sorun var -> kapsamlı değişiklikler için mümkün değil (yani, OP'nin söylediği gibi veritabanını değiştirmek). Bunlar açıkça ele alınmalı.
Matthieu M.

48

Gandhi'nin taktiğinin Hitler gibi biriyle çalışıp çalışmayacağını sorduğunda söylediği gibi. "Zor olurdu" dedi. Ama bence cevabın gerçekten "Hayır" olduğuna dair adil bir argüman var. Ne yazık ki, yapmaya çalıştığınız şeyin yapılabileceğini sanmıyorum. Karamsar olmaya çalışıyorum değil, dürüst olmaya çalışıyorum.

Benim için sorun, yöneticilerin inandırıcı olması gerektiği değildir. Daha iyileri, borçların yönetilmezse katil olabileceğini zaten anlıyor. Fakat onlar anlayıp anlamadıkları, iyi yöneticileri veya kötü olmaları durumunda, hepsi de baskıya maruz kalıyorlar ve bu teslimat patronları tarafından bir tarihe karşı değerlendiriliyor. Kalite yalnızca son derece kötü olduğunda önemlidir, bu durumda geliştiricilerin hatası veya son derece iyi olan bu durumda bunun gerçekleşmesini sağlayan yönetim parlaklığıdır. Kalitenin sadece "yeterince iyi" olması gerekir.

Sanırım cevabında Renesis'in söylediklerini beğendim, çünkü yönetimin mühendislikten çok farklı düşündüğünü anlayan birkaç kişiden biri. Ve sanırım hepimiz firmaların, müşteri ve kalite odaklı olmalarının aksine, tarih odaklı ve proje yönetimli olmalarının ilerlemesini gördük. Bununla, tipik şirketleri kastediyorum, "Yapıldığı zaman yapılacak" (Apple Computer veya ID Software gibi -) ve bazen insanların özgür olmadıklarını anlıyorum. bu yaklaşımı almak için).

Ama işte sorun: birinci kalite yaklaşımını benimseyen şirketler ... onlar hakkında ne fark ediyorsunuz? Doğru, satıcılar, pazarlamacılar, proje yöneticileri veya muhasebeciler tarafından değil mühendisler tarafından yönetiliyorlar. HP, Apple, kimliği, Google, Microsoft ve IBM'i düşünün. Her şey satışçı değil mühendisler tarafından başlatılmış ve başarılı olmuştur, ancak satıcılar kesinlikle bir rol oynamışlardır ve eminim birçoğu Microsoft'un kaliteye bağlı olduğunu tartışacaktır :). Ve bunlardan, yokuş aşağı gidenlere mühendislik odaklı liderlikten kaçtı. Yine de, bu ifadede çok sayıda argüman var, çünkü değişen zamanlara uyum sağlayamamak ve kendi büyümelerini yönetmek konusunda başarısız olan birçok teknik şirket var. Mühendislik temelli liderliği bu başarısızlıkların nedeni olarak görmüyorum, bana göre ' Birinin geliştiricisi veya muhasebecisi olmasından bağımsız olan beceri ve iş zekası meselesi. Ancak, genel olarak konuşursak, mühendislikte, mühendisliğin bir bileşen olduğu şirketlere fayda sağlayan, hesap verebilirlik ve disiplinin zorluklarına bağlılık olduğunu düşünüyorum.

Cidden, etrafına bak. BT liderliği kesinlikle yoksundur. Odak her zaman maliyete ve zamana ve yeterince iyi olduğu sürece nadiren kaliteye odaklanır. BT liderleri artık CEO’ya nadiren rapor veriyor, şimdi her zaman CFO. BT, üretim desteği yaparken sıkışıp kaldı ve odağı daha küçük, daha sindirilebilir ve ölçülebilir parçalara odaklanan proje yöneticilerine giderek daha fazla önem veriyor; devrimci değerde önemli değişiklikler değil (bunun mutlaka yanlış olması değil; bölmek ve fethetmek iyi bir şey, ancak vizyon büyük resim için orada olması gerekiyor).

Bu yazı için çok uzun sürdüğüm için üzgünüm ama sonunda teknik borçla ilgili yönetimin nasıl bakım yapılacağına ilişkin sorunuzun, mevcut olanı değiştirmek yerine doğru lideri bulmakla daha iyi çözüldüğünü düşünüyorum. Teknik borcu standart düşünürlere açıklamak, Renesis’in dediği gibi odağı para ve maliyete çevirmek anlamına gelir ve bence çeviri konusunda çok şey kaybeder; Bu konuda başarılı olsanız bile, sadece şirketteki en iyi liderin satın alması önemli olacaktır. Orta yöneticinizi doğru şeyi yapmaya ikna etmek muhtemelen sadece kovulmasını sağlar.


43

Yapılacak ilk şey ifadeleri değiştirmek. “Teknik borç” olarak adlandırmak, yönetime, izin vermenin bir çeşit yatırım olduğu fikrini verir - gerçekten bir virüs gibi. (Ben teknik borç Dave Ramsey gibiyim .)

Ücretsiz gitmesine izin vermek, görülemeyen veya kolayca ölçülemeyen büyük bir maliyetle geliyor.

Yönetim için aşağıdakiler gibi sorunları listeleyin:

  • Yeni özellik tahminleri olması gerekenden çok daha yüksektir. Veya, tamamen imkansız.
  • Kötü kod daha fazla kötü kodu doğurur
  • Geliştiriciler her zaman tamir ediyor olsalar bile hata listesi büyüyor
  • Takım üyeleri ayrılıyor ( bu mükemmel cevapta açıklandığı gibi bir sorun olduğunu gösterebilir )

7
+1, son merminin "İyi / en iyi takım üyeleri ayrılıyor" olması gerektiğini düşündüğüm halde
Ken Henderson

12
Bit teknik borç olduğunu bazen bir yatırım. Başka bir şirketle yarışıyorsanız ve piyasaya sürülen ilk önce kendileri için pazar alırsa, daha hızlı başlatmak için koddaki kısayolları kullanmak mantıklı olacaktır. Sıfır ödeme yapan müşterileriniz varsa, hiç kimse mükemmel bir kodunuzun olmasını önemsemez.
quant_dev

3
@quant_dev bunu "hızlı" ve "mükemmel kod" arasında bir ikilik olarak görürseniz, o zaman elbette böyle düşüneceksiniz. Kısayolların teknik olarak sağlam olmasının bir nedeni yoktur, bu durumda teknik borç olarak kabul edilmezler.
Nicole,

2
@Renesis "Kısayolların teknik olarak sağlam olmasının bir nedeni yok" - bu doğru değil.
quant_dev

3
Ve bazen bu hiç bir teknik borç değil, sadece bir karmaşa: sites.google.com/site/unclebobconsultingllc/…
TrueWill

30

Benim yönetimim, orada çalışmaktan hoşlanmamın nedenlerinden biri olan teknik borcu ele almak için ciddi bir çaba sarf etmeye başladı, ancak uzun vadeli bir çaba ve onlara, bu çabanın neden değerli olduğunu hatırlatmaktan asla zarar gelmiyor.

Baskıya devam etmenin bir yolu, ne zaman bir tahmin istendiğinde ve belirli teknik borç sorunları ile uğraşmak zorunda kalmazsam zaman kazanılmış olabilir, bunu tahminime ekliyorum . Örneğin, " Bu hatanın izini bulmam 2-3 gün sürecek, ancak sırada sonsuza kadar sırada olan bu diğer 2 düşük öncelikli 'sorunu daha önce ele alsaydık, muhtemelen birden fazla zaman alabilirdi. " Yanıt devam etmek ve siz bu sırada diğerlerini düzeltmek olacaktır.

Ayrıca, işinizin bir parçası olan iyileştirmeleri göz önünde bulundurma ve çok rahatsız edici değilse, yaptığınız gibi yapma ile ilgili diğer cevapları kabul ediyorum. Şu anki görevim çok kötü tasarlanmış bazı kodlara eklemeler yapmak. Yeni kodumu eşleşecek şekilde yazarak karışıklığa eklemek yerine, genel işlevselliği pekiştirmek için biraz zaman harcıyorum, bu nedenle bir paket göndermek, 15 satır hafifçe değiştirilmiş kopyala ve tekrarlamak yerine sürekli tek satır işlev çağrısı olur. Kazan plakasını yapıştırın.

Yolun aşağısında bir bakıcının akıl sağlığını kurtaracağını biliyorum. Biliyorum çünkü bugün o korumacıyım. Bununla birlikte, şu anda bu özelliği kullanıp hata ayıklamak için kendi görevimi hızlandıracağına inanıyorum.

Geçmişte kullandığım ve tekrar yapmam gereken bir diğer teknik, yeniden derleyici bir DVCS dalını , derlerken, uzun bir test için beklerken ya da sadece bir adım değişime ihtiyaç duyduğunuzda, aşağı inen süre boyunca ayrı bir çalışma ağacında tutmaktır . bir böcek tükendiğinde biraz. Arada sırada yukarı akıştan birleştiğiniz ve çok uzaklaşamadığınız sürece, çok az marjinal çabayla değişikliklerin yeniden yapılandırılmasını istediğiniz süre alabilir. Burada ve orada günde 15 dakika gerçekten zamanla ekleyebilir.


20

Kredi kartı benzetmesini deneyebilirsiniz. Onlara "kredi kartı ekstrelerinizi uzun bir süre ücretsiz olarak bırakmaktan memnun musunuz?"

Yöneticiler maliyetleri ve faydaları anlar, ancak (genellikle) geliştiriciler tarafından kullanılan teknik terimleri değil. Bu teknik engelin üstesinden gelmek için "teknik borç" terimi zaten icat edildi, ancak bunu daha açık bir şekilde ifade etmeniz gerekebilir. Çoğu yöneticileri o kadar o gecikmiş kredi kartı ödemeleri korkunç bir faiz oranı ile büyümeye çok iyi (genellikle kendi deneyimlerinden) biliyor acıyor ödenmemiş bırakmak. Bu, yazılım entropisine ilişkin sorunun ciddiyetini anlamalarına yardımcı olabilir.

Ancak bu onları ikna etmiyorsa, gerçek kanıtları toplamaya ve bazı hesaplamalar yapmaya çalışın. Örn: ayrılan bir çalışanın yerine, şirketin hem nakit olarak hem de zaman kaybıyla - maliyeti ne kadardır.


12

İşe yarayan bir şeyi başka bir şeyle değiştirmek için hiç kimse para vermeyecek (şans ile de).

Yapabileceğiniz şey, daha fazlasını yapan bir şeyle değiştirmeyi teklif etmek, yani teknolojik borcun hizmetini, anında ve somut ticari faydalar sağlayan bir yükseltmeye dahil etmek.

Elbette bu konuda açık olmalısınız, burada yeni bir projeye "gizlice sokmaktan" bahsetmiyoruz.

Diğer tarafı, geliştiricilerin ele alması zor olanı buluyorum. Temel olarak buna bağlı olarak: bazı geliştiriciler için, kodunuzun mümkün olan en iyi kod olduğundan emin olmak profesyonel bir gurur meselesidir. Diğerleri için bu sadece başka bir iş ve amaç çabucak halletmek ve eve gitmek.

İkna edici hiçbir şey bu durumu değiştirmez ve zorunlu bir kod kalite standardı getirirseniz, dokuz ila beş geliştiriciniz sistemi çalıştırmanın bir yolunu bulurken, özel geliştiricileriniz kaçınılmaz olarak tüm prosedürle rahatsız olur (bu Onları hedeflemiyor, ancak geliştiricinin X kurallara uyması gerektiğini söyleyemezsiniz, Y istediğini yapabiliyorsa).

İşe yarayan, ama hala çok sinir bozucu olabilen, daha temel ve bilgili geliştiricilerinizin kod tabanını denetlemesini sağlamaktır, muhtemelen ileriye gidip orada ne olup bittiğini toplamak arasında iyi bir takas.


5
+1 Ancak, bu 9-5 geliştiricileri, sizin için döner kapının, ideal olarak bir tür hızlandırıcı formuyla olmasını istersiniz.
Orbling

3
@Orbling: +1. Yeterince umursamıyorlarsa, gerçekten başka bir yerde çalışıyor olmalılar. BÜYÜK dev'leri size "Sadece bu fikre sahip oldum ..." ile geldi.
hızla_

3
@Orbling Bazı gelişim alanlarında yararlı olabilirler. Ben hiç "geliştirici züppe" hayranı değilim, ama herhangi bir kullanım için herkesin niş bulmak zorunda. Yapabileceğin en kötü şey, herkesin senin gibi olduğunu varsaymak.
biziclop

Şahsen, endüstrinin fazlasıyla denetlendiğini düşünüyorum. Nerede bulunduğumu çoğu yazılım işleri bu gün başvuruda iyi bir 300 aday alır. Bu rekabet seviyesiyle, bir işveren, fazladan mil alan ve ortalamadan daha iyi olan işverenleri işe alabilir.
Orbling

"Maddi avantajlar (satış noktaları) sunmak için yenilemeler yapmak için yenilemeleri gerçekleştirin" "Baş Mimarımızdan haber almaya devam ediyorum.
Mario T. Lanza

12

Gerçek şu ki, pek çok şirkette, özellikle mevcut ekonomik durum göz önüne alındığında, her saat bir kişiye faturalandırılmalıdır.

Ya da hızlı inerler .

Mevcut müşteriler yeniden yapılanma için ödeme yapmaya istekli olmadıkça, önemli ölçüde iyileştirilmiş performans veya özelliklere sahip olmadıkça, bu olası değildir. Sonra eski kod tabanlarında olmayacak. Müşteriler derin ceplere sahipse, yeni projeler için bütçeye gizlice girebilirsiniz, ancak yeniden yapılanmadaki API'leri değiştirmeniz gerekmediği sürece, eski projeler için faydasız olacak ve Şirketin daha fazla baş ağrısı ve maliyete neden olan iki kod tabanını desteklediği durum.

Bir mühendis olarak, artık bir amaç için uygun olmayan eski kodu yeniden düzenlemeyi çok isterim, bir şey eskimez veya kullanımdan kaldırılırsa. Ama şimdiye kadar çalıştığım tüm şirketlerdeki MD'larım bana şöyle dedi: “Kim ödeyecek?”


12

Her zaman gittiğim gibi temizlemeye çalışırım. Kod temiz olana kadar işim bitmedi. Teknik borç sorunu, çoğu insanın bunu anlamadığıdır. Bununla baş etmenin en iyi yolu, hiçbirini birikmemek. Yöneticileriniz bir problemin nasıl çözüleceğine karar vermeleri konusunda geliştiricilere güvenirse, kodlama hijyenini her programlama görevinin bir parçası haline getirebilirsiniz. Hiç bir zaman hatalı kodları kontrol etmezseniz, borç biriktirmezsiniz. Ayrıca, İzci Kuralını izlerseniz (her zaman bulduğunuzdan daha temiz kod bırakın), mevcut borcunuz yavaşça ortadan kalkar.

Yeniden düzenlemeyi, özellikleri uygulamadan ayrı bir görev olarak görmüyorum. Bunun ayrılmaz bir parçası.


5
Daha fazlasını kabul edemezdim: "Teknik borç finansal borç gibidir - uzun vadede başlamak için biriktirmemek çok daha kolaydır. Tüm teknik faturalarınızı haftada bir kez ödeyin"
Lawrence Dol

7

Teknik olmayan yöneticilerle ilgileniyorsanız, tartışmanızı anladıkları terimlerle paylaşmanız yardımcı olacaktır. Teknik borcunuzu ödemek için harcadığınız işe olumlu bir yatırım getirisi için gerçekçi bir durum oluşturabilirseniz, bir yere gidebilirsiniz. Bu alıştırma sizin durumunuza bağlı olacaktır, ancak bir örnek şunun gibi olabilir:

Geliştiricilerin ne kadar zaman harcamak zorunda kaldıklarını analiz edin Üretim sorunlarıyla destekleyin, ardından eski kodun düzeltilmesinin A. destek sorunlarının sayısını azaltacağı durumunda olun, B. Geliştirmeye yükselmeden sorunların çözülmesini kolaylaştırın; C. Gelişmenin, ortaya çıktıklarında üretim konusunda harcadığı zamanı azaltma. Geliştiricilerin destek işleriyle bağlanmalarını sağlayarak kazandıkları dolar cinsinden koyun. Ayrıca, bir geliştiricinin destek yapmak için harcadığı her saatin "çifte" olduğuna dikkat edin, çünkü yalnızca bir geliştiriciye destek yapmak için ödeme yapmakla kalmazsınız, aynı zamanda geliştiricinin yapabilecekleri fırsat maliyetini de düşürürsünüz (yeni özellikler ekleyerek, vb. .)

... sorun değil, yönetimin kirli sırrı olmasıdır Evet, sayılar bazı voodoo / duman-and-aynalar olacak biliyorum onlara bir şey vermek onlar etrafında sapan sayılar çoğunluğu ettiği sürece toplam BS olduklarını çalışmak için görünüşte somut, bu yüzden başlarına alabilirler, bir mücadele şansınız var.


6

Bu teknik borcun açıklanmasından sonra, yönetiminiz borcunuzu ödemeye ikna edilmelidir:

Çok kirli bir mutfağınız olduğunu düşünün. Bir yemek hazırlamadan önce, ilk önce bir saat temizlik yapmanız gerekir. Ve her yemek yemek istediğinizde de öyle. Ayrıca, bir yemek hazırlarken, saçmalığın yemeğinize düşmediğinden emin olmak için ekstra dikkatli olmalısınız.

Mutfak sizin kodunuz, yemek sizin ürününüzdür ve yemek yemek ürününüzü satmaktadır.

Güvenli bir birim testleri olmadan, bir değişikliğin uygulanması için daha uzun süre bekleyebilirlerse, şirketinizde bir sorun var demektir.


4

Orijinal ürün ve iş durumu açısından, şu anda benim için daha önemli bir şey yapmak için bu parayı kullanamadığım konusunda çok inandırıcı bir argüman olmalı. Beğenin ya da beğenmeyin, yönetiminiz ya da müşterileriniz bunun için para ödüyorlar ve onları ikna etmek için satış yapabilmeniz gerekiyor.

Kendinizi müşteri olarak konumlandırmak için bunu tekrar yazalım. Eski güzel rol yapma.

Bir buzdolabı satın aldığınızı varsayalım. Ve Acme Corp.'dan iyi çalışan 1000 $ 'lık bir buzdolabı veya dışarıdan aynı görünen ve aynı teknik özelliklere sahip olan ancak daha temiz bir iç mimariden dolayı daha düşük bakım maliyetleri olan 2000 $' lık bir buzdolabı satın alabilirsiniz.

Bir müşteri olarak hangisini satın alırsınız?

Acme Deluxe mühendisleri, daha iyi bir cevap olduğunu düşünüyor?


3
Bu konudaki tutumunuzu belirlemek için zorlanıyorum. Bence cevabınız "müşterinin ne istediğine bağlı". Sorun, her müşterinin düşük maliyetli buzdolabının eritileceğini, derin dondurucu bölümünden pis pisliği kaçıracağını, yüksek sesler çıkardığını ve sonunda 5 yıl sonra çalışmayı bıraktığını, diğerinin 20 yıl boyunca sorunsuz ve sessiz kalacağını anlayamamasıdır. ve yeni bir model karşılığında onu satacak mülk sahipleri tarafından kabul edilmedikçe değiştirilmemelidir. Yine de, sorduğun soruyu beğendim. Provoke ettiği düşünülüyor. +1
jmort253

İlk satır - "Bu parayı şimdi benim için daha önemli bir şey yapmak için kullanamadığım [] inandırıcı bir argüman olmalı." Açıkça buzdolabı örneğini kullanıyorum, buzdolabımın içinde neler olup bittiği umrumda değil. Sadece bir sonuç istiyorum. (makul bir fiyata soğuk yiyecekler). Açıkçası, buzdolabı mühendislerinin şirket içinde daha iyi bir ürün olduğunu düşünmeleri umrumda değil. Onlara danışabilirim ama bu onların kararı değil.
jasonk

3

" Teknik borç ”, ihtiyaç duymayacağı için yönetime sunmak için zor bir konu olabilir. Soru, şirkette "Bak, teknik borç üzerinde çalışmak için% X zaman harcıyoruz. Bize bunun iyi çalıştığını göstermemiz için 3 ay verin" ya da başka bir şey olup olmadığını belirten bir şampiyon olup olmadığı şeklinde anlaşılabilir. benzer. Orada özerkliğe dair bir iddia var, ancak aksi takdirde yönetim, tehlikeli bölgeler olan bazı sonuçları görene kadar ne kadar süre alabileceklerini merak ettiği için bir zaman çerçevesi de var.

İlk mesele olsa da, bunu bir problem olarak görüp görmedikleri. Görme bozukluğu olan kişi gözlük hakkında hiçbir şey bilmiyorsa ve ne gibi değişiklikler sağlayabiliyorsa, göz testinin neden değerli olabileceğini nasıl anlayabilirler? Konunun oldukça teknik olduğu ve maalesef kolayca ölçülemediği durumlarda da aynı fikir.


Buna tamamen katılıyorum ve gittikçe daha fazlasını buluyorum. Son zamanlarda, uygun bir düzeltmenin yapılmaması ya da benzer nitelikteki kusurların bulunmaması nedeniyle yeniden açılan hataların bir listesini topluyorum. Umarım geliştiriciler zaman harcadı. Bazen yaparlar, bazen yaparlar, ama bu tür veriler sağlıksız bir ürünün işlerini nasıl etkilediğini göstermek için faydalı bir temeldir.
Issız Gezegen,

2
Şu andaki işyerimde fazla mesai yanlış nedenlerle tahsis edildi. Yangınla mücadele sorunları yerine uygulamanın sağlıklı kalması için zaman harcanması halinde, zamanla para tasarrufu sağlanacak ve geliştiriciler yönetimde yanmaktan ve sinirlenmekten daha güçlenecektir.
Issız Gezegen,

Ancak yönetim (çoğu durumda doğru!) Böyle görür. Hala çalışan bir 1980'lerin magimix'i var ve eski ve renk modası olmadığı için değiştirmemi söylüyorsunuz!
James Anderson

2

Sadece şikayet etmekten vazgeçmelisin.

İşte nedeni:

  1. Yazılımı bir yıldan daha uzun süre kullanmayı asla planlamazlar
  2. Planları daha sonra atmak ise, sadece tweaking zaman kaybı
  3. Şimdi düzeltilmesi gereken bazı gerçek sorunlar var
  4. programcıların her zaman eğlenceli olmasa da, bakımla başa çıkmayı öğrenmeleri gerekir
  5. yapılması gerekenleri daha iyi bildiğinizden şikayetçi olmak kibirlidir - başkası kararı verir ve bundan mutlu olmalısınız
  6. Yine de iyi kod yazman için sana güveniyorlar.

Yani ileri doğru en iyi yol:

  1. Size yeni görev verdiklerinde, verilen sürede mümkün olan en iyi şekilde uygulamaya çalışın
  2. İlk seferinde mükemmel yaz. Daha sonra değiştirmeniz gerekirse, ilk defa bir hata yaptınız ve herhangi bir değişiklik her zaman yanlış yöne gidiyor - ve bu program yaptığınız zaman hata yapmanız programcılar için bir öğrenme fırsatı.
  3. Bunun için fazladan zaman istemeyin, alamayacaksın, bildiğin son tarihler var.

3
Berbat yazılımların bile, yaratıcılarının beklediğinden daha uzun süre hayatta kalma eğiliminde olduğu bilinmesi dışında çoğunlukla katılıyorum. Ama haklısın, şikayet etmemek daha iyi. Bunun yerine, kodun anlaşılabilirliğine yardımcı olacak bazı sınırlı ölçeklendirme faktörlerini görürseniz, devam etmeniz ve bakım / hata düzeltmeleriniz sırasında İZİN OLMADAN değişiklikleri yapmak (ve bunu yapmak için bir riske maruz kalmak) değerinde olabilir.
Angelo,

@Angelo - Endişelerini dile getirmek, ekibin sessizce acı çekmesine izin vermek yerine daha iyi olmaz mı? Bu sorunun takım moraline ne yaptığını ve fazla mesai için harcanan zaman / para miktarını gördüm. Ben böyle "inleme" olarak görmüyorum. Siz sadece proje risklerine dikkat çekiyorsunuz ve fikirleriniz teslim sürelerini hızlandırabilir ve süreçleri düzene sokabiliyorsa neden endişelerinizi dile getirmiyorsunuz? Bu sağır kulaklara düşerse, en azından nerede durduğunuzu bilirsiniz.
ıssız gezegen

2
Sen gerekir bundan şikayet yüksek sesle aksi takdirde var, senin hatan eğer diğer insanların kod sonu ( "Bu bir karışıklık olduğunu biliyordu ve kimseye söylemedim?"). Ayağa kalkın ve devam edin "Hey patron, bu bok er ya da geç vantilatöre çarpacak" geliştirici bir ekibi işlevsel tutmak için çok önemlidir .
Alex,

1

Anladığım kadarıyla mevcut bir sistemi yeniden yazma / değiştirme, hatta yükseltme için bir projeye hiç katılmadınız.

Bunlar başarıyla tamamlanması en zor projelerden bazıları. Karşılaşacağınız sorunlardan bazıları şunlardır:

  1. İş kuralları zamanla kaybolur.
  2. Belgeleme ve uygulama tamamen senkronize değildir.
  3. Bir hata olarak gördüğünüz, kullanıcıların bir özellik olarak gördüğü.
  4. Tersine, birçok "özellik" kullanıcıların kusurları olarak görülecektir.
  5. Kullanıcının içeri girmesini sağlamayacaksınız - "gerçek bulma" nı "aptal sorular soran inekler" olarak görecekler, test etme çabalarını zaman kaybı olarak görecekler, yeni özellikler eklemek konusunda ısrar edecekler, böylece bir proje uzatacak. zaten programın gerisinde kaldım.
  6. Muhtemelen kaynak kod çalışan çalıştırılabilir% 100 ile eşleşmiyor.
  7. Departmanınız gelişmekte olan yeniden yapılanma ile uğraşırken, aslında iş yapmak istemiyor.
  8. Muhtemelen yeniden faktörlendirmenizin "daha temiz gelişmiş arayüzler" içereceği ve böylece diğer projeleri geç teslim ve başarısız testler batağınıza sürükleyeceğidir.
  9. Proje konserve edildikten sonra (bu çabaların% 50'sinden fazlası tamamen başarısız oluyor), tüm güvenilirliğini yitirmiş olacaksınız - sizi dinlemeye hazırlanan birini bulmak için başka bir şehirdeki başka bir şirkete taşınmanız gerekecek.
  10. Eğer proje "başarılı olursa" herkes ne kadar kabus göreceğini hatırlayacaktır - sen .......

Veba gibi herhangi bir yeniden yazma / yeniden düzenleme projesinden kaçınmanızı öneriyorum, herhangi bir profesyonel kariyeri içinde en çok üzülen deneyimlerden bazıları olabilir.

"Kırılmazsa düzeltmeyin" ifadesinde çok fazla bilgelik var.


1
“Anladığım kadarıyla yeniden yazma / değiştirme ya da hatta mevcut sistemi yükseltme projesine hiç katılmadınız” - Yanlış, 7 yıl.
Issız Gezegen,

1
Tam bir yeniden yazmanın genellikle bir felaket olduğuna tamamen katılıyorum. Ancak kariyerimin son 8 yılında üç örneğim var. Bunlardan biri, ürünü daha iyi tutabilmemizi sağlayan ancak hiçbir iş değeri sağlamayan sonuçta uzun bir slogandı; bir diğeri ise toplam başarı olan kısa bir yazıydı; Üçüncüsü, şirketi nihayetinde öldüren, yeniden yazmaya karar vermedi. Zehirini seç.
Tom Harrison Jr

1

Hayatım boyunca, bazı insanların neden değişimden bu kadar korktuklarını anlayamıyorum - kendi yeteneklerinize güven duymuyorsunuz.

Dün gece Yosemite Ulusal Parkı'nda bir gösteri izledim ve 1940’lardan 1990’ların sonlarına doğru yeni bir Sequoia ağacının filizlenmemiş olduğu dikkat çekti. Orman yangınlarının yanmasına izin verilmesine karşı katı bir politika olduğu ve Sequoia çam kozalaklarının tohumlarını açmak ve tohumlarını salıvermek için ateşten gelen ısıya ihtiyaç duyduklarının nedeni ortaya çıktı.

Görüyorsun ya, her on yılda bir ateş sağlıklıydı. Mevcut ağaçların (işlemlerin) sağlıklı kalması ve yenilerinin (özelliklerin) yer tutması için biriken tüm odunları temizleyin.

Şu anda yeniden yapılanma için net bir durumda olan bir projedeyim: Eski yazılım tamamen .NET web formları kullanılarak yazılmıştır. Neredeyse tüm işletme mantığı, HTML / sunucu etiketi görünüm mantığı ile birleştirilir ve artık işletme büyüdüğü için diğer uygulamalara genişletilemez.

Yönetim görevin gerisindedir, çünkü geliştiricilerinde ender görülen bir lüks olduğunun farkına varacakları bir güvene sahipler.

Evet, gerçekten bir yeniden inşa gerekip gerekmediğini kendinize sorun. Mümkün olan yerlerde çalışan mevcut kodu tekrar kullanmak için elinizden geleni yapın. Gerekirse bu kodu yeniden oluşturmaya entegre edin. Sadece kimsenin sizi cesur değişiklikler yapmaktan korkmanın yazılım geliştirici olarak var olmanın tek yolu olduğuna ikna etmesine izin vermeyin.

İyi şanslar!


1
Bu soruyu nasıl cevaplıyor, "Teknik borçları ayırmalarını sağlamak için bunu yönetime nasıl iletirsiniz?"
gnat

1
@gnat: "Cevapların" çoğu bu soruyu doğrudan nasıl cevaplıyor? Örneğin, James Anderson, tp1 veya en çok oy alan tepedeki cevaplara bakınız. Ancak sorunuzu yanıtlamak için OP'nin kullanabileceği alternatif bir benzetme sağladım. Bana göre bu konuda fikrime katılmıyorum. Sorun değil, ancak oy kullanmamak için sebep yok.
Matt Cashatt

1
okuduğumda, bahsettiğiniz en iyi cevap , ilgili deneyime dayanarak doğrudan sorulan cevabı doğrudan ele alıyor gibi görünüyor. "Bunu tartışmak için patronumla buluştuğumda ..." Fikrinize gelince, buna katılıyorum, ancak içerik kalitesi hakkında, belirli bir görüşü destekleyip desteklemediğime değil. Stack Exchange Soru-Cevap oylama modeli, kamuoyu yoklamaları
gnat

1
O zaman tekrar okumanızı tavsiye ederim. Gelecekteki işler için tahminleri doldurarak teknik borcu kapatacak bir yöntemle ilgili bir patronu ile yapılan bir sohbeti anlatmak, "Teknik borcu ayırmakla ilgilenmelerini sağlamak için bunu yönetime nasıl iletirsiniz?" Sorusuna cevap vermez. Ya. Bununla birlikte, sohbete eklediği için cevabı aşağı oylamadım. Bu yüzden, başardığınız tek şey, önemli bir sebep olmaksızın, hemfikir olduğunuz konuyla ilgili bir görüşü susturmaktır. "Programcılar" konuşabileceğimiz bir yer olmalı. Her şey ikili değildir.
Matt Cashatt

1

Teknik borçla başa çıkmak için yönetiminize finansal bir neden ve bu teknik borcu azaltmayı yönetmek için bir çerçeve vermeniz gerekir.

Teknolojik bir yol haritasının sürdürülmesi böyle bir çerçevedir. Bir yol haritasına başlamak, sizi teknik borca ​​yatırmaktan kurtarmanıza yardımcı olacak ve mevcut borcu azaltmanıza da yardımcı olabilir.

Birçok başarılı uzun vadeli proje, kalkınmayı yönlendirmek için yönlendirme komiteleri ve yol haritalarını ilişkilendirmiştir. Bunlar, özellikle birden fazla geliştirme ekibi ve ilgili paydaş olduğunda faydalıdır.

Benim önerim, bu stratejiyi yöneticilerinizle tartışmanız (ve mümkünse paranın nerede harcandığı konusunda karar verenler).

Bir yol haritası oluşturmak ve yönetmek için genel yaklaşım oldukça basittir, ancak yönetim ekibinizin desteğini gerektirir. İlk önce bir hedef tanımlayın. Teknik borcun unsurlarını tanımlayın ve teknik borcun unsurlarını azaltan bir hedef sistem mimarisi geliştirin. Unutmayın, mükemmel olmak zorunda değil, sadece çalışılabilir ve şu anda olduğunuzdan daha iyi olması gerekiyor. Yazılım, geliştirme araçları, donanım platformları, sisteme eklenebilecek önemli yeni özellikleri göz önünde bulundurun. Maliyet analizi yapın. İstenilen mimariye sahipseniz, yeniden düzenlemeyi gerçekleştirmenin somut faydaları nelerdir? (Avantajlar, azaltılmış test süresi, daha güvenilir yazılım ürünleri, daha fazla tahmin edilebilir geliştirme döngüsü vb. İçerir). Yeniden yapılanmanın gerçekleştirilmesinde yeterince fayda gösterebilirseniz, yönetim desteği alabilirsiniz.

Bir yol haritasına ve yönetim desteğine sahip olduğunuzda, bu istenen duruma ulaşmak için atmanız gereken bir dizi adım (plan olarak da bilinir) geliştirin. Yol haritasını tutan, geliştirme ekiplerini yol haritası üzerinde eğiten ve eğiten ve periyodik olarak mimari bütünlük değişikliklerini gözden geçiren bir yönlendirme komitesi oluşturmak iyi bir fikir olabilir.

Yol haritaları gerçekten yararlıdır ve belki de Joel Testinin 13. sorusu “Bir yol haritanız var mı?” Olmalıdır.

İşte son Red Hat Linux yol haritası oturumunun ilk saatinin bir videosu .


1

Zaten büyük bir yeniden yazma işine dahil olmuş (sadece refactor değil), finansal adamları projeye kabul etmenin en büyük engellerden biri olduğu konusunda hemfikir olabilirim. Bu zorluğun üstesinden gelmek, şirketler işinin suda orta vadede ölmüş olacağı anlamına gelen bir dizi sorunu gösteren bir rapor yazmamı, sunmamı ve savunmamı gerektiriyordu.

Anlaşmanın ilerlemesinde kilit faktörler:

  • Mevcut kod artık yalnızca desteklenmeyen bir geliştirme platformunda çalışan PDP11-23 destekli bir araç zincirinde (MicroPower Pascal) bulunuyordu.
  • Araçlar ve hedefler üzerinde çalışabilecek geliştiriciler bulmak neredeyse imkansız hale geldi.
  • Yedek donanımlar gerektiğinde hedef donanım artık mevcut değildi ve üretici bir tamir hizmeti vermek için isteksiz hale geldi.
  • Koddaki sorunlar kolayca tespit edilebilir müşteri memnuniyetsizliği ve doğrudan servis maliyetleri ile sonuçlandı.
  • Yeni donanım eklemek ve hatta hata düzeltmeleri, hedef donanımın sınırlandırılması nedeniyle neredeyse imkansız hale geliyordu, bu sayede sorunları ele alırken yer sağlamak için diğer alanların yeniden yapılandırılması gerekiyordu.
  • 8 saatlik bir inşa süresi ile herhangi bir değişikliğin geliştirilmesi ve test edilmesi pahalıydı.

Raporda, devam etmekte olan maliyetlerin tahminleri ile ilgili sorunlar ayrıntılandırılmış ve 3 seçenek sunulmuştur:

  1. Yakın gelecekte muhtemelen hata düzeltmeleri yapmadığımız yerlerde dondurun.
  2. Kodu yalnızca alan için optimize edin, bakımdan bağımsız olarak , optimize edilmiş kodu korumaya çalışan herhangi birinin, optimizasyonu yapan kişiden daha akıllı olması gerektiğine dikkat çekerek.
  3. Endüstri standardı, yaygın olarak öğretilen bir dilde (ANSI C), yeni, düşük maliyetli, COTS donanımında (PC-104), piyasada mevcut olan birden fazla satıcıyla, yüksek faktörler olarak test edilebilirlik ve bakım kolaylığı ile yeniden uygulama Kalan mevcut donanımla çalışabilmesi için arayüz kartı tasarladı. Böyle uçucu olmayan depolama, hatalı durumda otomatik olarak yeniden başlatmayı sağlamak için bir gözcü saati olarak gelişimin bir parçası olarak yeni özellikler sınırlı sayıda ekleme bazı birimler günde birden çok kez çökmesini ve sıfırlamak için bir £ 40 servis çağrısı dışarı gerektiren , süreçte daha iyi tanılama.

3. seçenek için ileriye dönük olan 3 aylık sözleşmem, hem yeni yazılım hem de donanım geliştiren, ancak çok iyi bir sonuç veren 3 yıllık zorlu çalışmaya dönüştü.

Daha az aşırı teknik borcu olan durumlarda, gerilla refactoring olarak adlandırdığım şeyi kabul ediyorum:

Belirli bir modülle ilgili bir sorun olduğunda:

  1. Yeniden yönlendirme yapmadan da başarısız olması muhtemel olan sorunu gösteren bir dizi test yazın.
  2. Gelişimin bir parçası olarak refactor testlerin hala başarısız olduğunu gösteriyor.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.