it-swarm.asia

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

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

Bu sorunu çözmenin en iyi yolu hakkındaki düşünceleriniz nelerdir? Gördüğüm insanlar paketleme ve ayrılma. Şirket daha sonra geliştiricilerin içeri girip çıkıp kodu daha da kötüleştirdiği döner bir kapı olur. Bunları sıralama ile ilgilenmelerini sağlamak için yönetime nasıl iletirsiniz teknik borç ?

164
Desolate Planet

Bunu tartışmak için patronumla görüştüğümde, tüm tahminlerime yeniden düzenleme yapmam gerektiğini söyledi. Bunun düşünmek istediği bir sorun olmadığını söyledi. Bunun yerine, ben halletmeliyim.

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

Yine de asla mükemmel olmayacak. Kredi kartı borcu gibi teknik borç, müşterileri daha hızlı hale getirmek ve rakipleriniz üzerinde daha hızlı pazar payı kazanmak için yapılan bir yatırımdır. Kredi gibi, düzgün yönetilirse, sizi oldukça başarılı yapabilir.

194
jmort253

Gandi'nin taktiğinin Hitler gibi biriyle çalışıp çalışmayacağı sorulduğunda söylediği gibi. "Zor olurdu" dedi. Ama bence cevabın gerçekten "Hayır" olduğu konusunda adil bir argüman var. Ne yazık ki, yapmaya çalıştığın şeyin yapılabileceğini sanmıyorum. Kötümser olmaya çalışmıyorum, daha doğrusu dürüst olmaya çalışıyorum.

Benim için sorun yöneticilerin ikna edici olması değil. Daha iyisi, borcun yönetilmediği takdirde katil olabileceğini zaten anlıyor. Ancak bunu anlasalar ya da anlamazlarsa, iyi yöneticiler ya da kötü olmaları, hepsi teslimat baskısı ile karşı karşıyadır ve bu teslimat, patronlar tarafından bir tarihe karşı değerlendirilir. Kalite sadece son derece kötü olduğunda önemlidir, bu durumda geliştiricilerin hatası veya son derece iyi, bu durumda bunu gerçekleştiren yönetim parlaklığı. Kalite sadece "yeterince iyi" olmalıdır.

Sanırım Renesis'in cevabında söylediklerini seviyorum, çünkü yönetimin mühendislikten çok farklı düşündüğünü anlayan az sayıda kişiden biri. Ve sanırım hepimiz şirketlerin müşteri odaklı ve kalite odaklı olarak tarihe dayalı ve daha proje yönetimli olma yolunda ilerlediklerini gördük. Bununla, tipik işlerden bahsediyorum, "İş bittiğinde yapılacaktır" gibi cesaret sahibi olan gerçek şirketler değil (Apple Bilgisayar veya kimlik Yazılımı - ve evet, ben bazen insanların bu yaklaşımı benimseme özgürlüğü olmadığını anlayın).

Ama işte şu: önce kalite yaklaşımını benimseyen şirketler ... onlar hakkında ne fark ediyorsunuz? Doğru, satıcılar, pazarlamacılar, proje yöneticileri veya muhasebeciler değil, mühendisler tarafından yönetiliyorlar. HP, Apple, id, Google, Microsoft ve IBM'i düşünün. Her şey satıcılar tarafından değil mühendisler tarafından başlatıldı ve başarılı oldu, ancak satıcılar kesinlikle bir rol oynadı ve eminim ki birçok kişi Microsoft'un kaliteye bağlı olduğunu tartışacaktı :). Bunlardan yokuş aşağı gidenler mühendislik odaklı liderlikten uzaklaştılar. Yine de bu açıklamada bir dizi tartışma var, çünkü değişen zamanlara uyum sağlayamama ve kendi büyümelerini yönetememe nedeniyle sonuçta 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 bu bir geliştirici veya muhasebeci olmaktan bağımsız bir beceri ve iş zekası meselesidir. Bununla birlikte genel olarak konuşursak, mühendislikte, mühendisliğin bir bileşen olduğu şirketlere fayda sağlayan hesap verebilirlik ve disiplinin zorluklarına adanmışlık olduğunu düşünüyorum.

Cidden, etrafına bak. BT liderliği oldukça eksik. Odaklanma her zaman maliyet ve zamana ve yeterince iyi olduğu sürece nadiren kaliteye odaklanır. BT liderleri artık nadiren CEO'ya rapor veriyor, şimdi her zaman CFO. BT, üretim desteği yapmaya sıkışmış ve odağı daha küçük, daha sindirilebilir ve ölçülebilir parçalara odaklanmış, devrimci değerin önemli değişiklikleri değil (bunun mutlaka yanlış olması değil; böl ve fethet iyi bir şey, ama vizyon) büyük resim için orada olması gerekir).

Bu gönderiyi bu kadar uzun sürdüğümüz için özür dilerim, ama sonunda, teknik borç konusunda yönetim bakımının nasıl yapılacağı ile ilgili sorunuzun, var olanı değiştirmek yerine doğru lideri bularak daha iyi çözüldüğünü düşünüyorum. Teknik borcu standart düşünürlere açıklamak, Renesis'in dediği gibi, odağı paraya ve maliyete dönüştürmek anlamına geliyor ve bence bu çeviride çok şey kaybediyor; 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 onu kovacaktır.

48
Bernard Dy

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 olduğunda. (Ben teknik borcun Dave Ramsey gibiyim.)

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

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

  • Yeni özellik tahminleri olması gerekenden çok daha yüksek. Ya da, tamamen imkansız.
  • Kötü kod daha kötü kodu doğurur
  • Geliştiriciler bunları her zaman düzeltse bile hata listesi büyüyor
  • Takım üyeleri gidiyorlar (bunun kendisi açıklandığı gibi bir sorun olduğunu gösterebilir bu mükemmel cevap )
43
Nicole

Yönetimim aslında orada çalışmayı sevmemin nedenlerinden biri olan teknik borcu ele almak için ciddi bir çaba göstermeye başladı, ancak bu uzun vadeli bir çaba ve bu çabaya neden değdiğini hatırlatmak asla acıyor.

Baskıyı korumamın bir yolu, ne zaman bir tahmin istendiğinde ve belirli teknik borç sorunları ile uğraşmak zorunda kalmazsam zamandan tasarruf edilebilirdi, Bunu tahminime dahil ediyorum =. Örneğin, " Bu hatanın izini sürmesi 2-3 gün sürecek, ancak sonsuza kadar kuyrukta olan bu diğer 2 düşük öncelikli hatayı daha önce ele almış olsaydık, muhtemelen bir taneden daha azını alırsınız. "Genellikle yanıt, siz devam ederken diğerlerini düzeltmek olacaktır.

Ayrıca, işinizin bir bölümünü iyileştirmeyi düşünmek ve çok rahatsız edici değilse bunları ilerletmekle ilgili diğer cevaplara da katılıyorum. Şu anki görevim, çok kötü tasarlanmış bazı kodlara eklemeler yapmak. Eşleştirmek için yeni kodumu yazarak karmaşaya eklemek yerine, ortak işlevselliği birleştirmek için biraz zaman harcıyorum, bu yüzden bir paket göndermek, 15 satır hafifçe değiştirilmiş kopyala ve tekrarla yerine sürekli bir satır işlevi çağrısı haline geliyor kazan plakasını yapıştırın.

Bir gerçeği biliyorum ki, bazı akıl sağlığını koruyacak. Biliyorum çünkü bugün o bakıcıyım. Ancak, bu özelliğin şu anda devreye girip hata ayıklanması konusundaki mevcut görevimi de hızlandıracağına inanıyorum.

Geçmişte kullandığım ve tekrar yapmam gereken başka bir teknik ayrı bir çalışma ağacında yeniden düzenleyen bir DVCS dalını saklamak derlerken, uzun bir test beklerken ya da bir hataya yakalandığınızda biraz değişiklik yapmanız yeterlidir. Ara sıra yukarı akıştan birleştiğiniz sürece çok fazla sapmamanız durumunda, değişiklikleri çok az marjinal çaba ile yeniden düzenlemeyi istediğiniz kadar sürebilirsiniz. Günde 15 dakika orada gerçekten zamanla toplanabilir.

30
Karl Bielefeldt

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

Yöneticiler maliyetleri ve faydaları anlar, ancak (genellikle) geliştiriciler tarafından kullanılan teknik terimleri anlamaz. "Teknik borç" terimi, bu iletişim engelinin üstesinden gelmek için zaten icat edildi, ancak daha açık bir şekilde ifade etmeniz gerekebilir. Çoğu yönetici, gecikmiş kredi kartı ödemelerinin korkunç bir faiz oranı ile büyüdüğünü (genellikle kendi deneyimlerinden) çok iyi bilir, bu yüzden onları ücretsiz olarak bırakmak acıyor. Bu, yazılım entropisi ile ilgili sorunun ciddiyetini kazanmalarına yardımcı olabilir.

Fakat bu onları ikna etmiyorsa, gerçek kanıtlar toplamaya ve bazı hesaplamalar yapmaya çalışın. Örneğin. İşten ayrılan bir çalışanın yerini almanın hem sabit nakit hem de kaybedilen sürede - maliyeti nedir?.

20
Péter Török

Hiç kimse, (herhangi bir şansla) çalışan başka bir şeyle çalışan bir şeyi değiştirmek için para vermeyecektir.

Yapabileceğiniz şey, daha fazlasını yapan bir şeyle değiştirmeyi teklif etmektir, yani teknolojik borcun servisini anlık ve somut iş faydaları getiren bir yükseltmeyle birleştirin.

Tabii ki bu konuda açık olmalısınız, burada yeni bir projeye "gizlice girmekten" bahsetmiyoruz.

Diğer tarafı, geliştiricilerin üstesinden gelmenin daha zor olduğunu düşünüyorum. Temel olarak bu kaygılar: bazı geliştiriciler için, kodunuzun gelebilecek en iyi kod olduğundan emin olmak profesyonel bir gurur meselesidir. Diğerleri için, bu sadece başka bir iştir ve amaç çabuk halletmek ve eve gitmek.

Hiçbir durum bu durumu değiştirmeyecektir ve zorunlu bir kod kalite standardı uygularsanız, dokuzdan beşe kadar geliştiriciniz sistemi çalıştırmanın bir yolunu bulurken, özel geliştiricileriniz kaçınılmaz olarak tüm prosedür ( onları hedeflemedi, ancak geliştirici X'in kurallara uyması gerektiğini söyleyemezsiniz, Y ise istediği her şeyi yapabilir).

Ne işe yarıyor, ama yine de çok sinir bozucu olabilir, kod tabanını denetleyen daha özel ve bilgili geliştiricilere sahip olmak, muhtemelen ilerlemek ve orada alrady olanı düzenlemek arasında iyi bir ödünleşmek.

12
biziclop

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

Ya da aşağı inerler, hızlı.

Mevcut müşteriler yeniden düzenleme için ödeme yapmak istemiyorsa, önemli ölçüde yükseltilmiş performans veya özelliklerle gelmedikçe, bu pek olası değildir. O zaman eski kod tabanlarında gerçekleşmez. Müşterilerin derin cepleri varsa, daha yeni projeler için bütçeye gizlice girebilirsiniz, ancak yeniden düzenleme işleminde API'ları değiştirmeniz gerekmedikçe, eski projelere faydası olmayacak ve şirketin daha fazla baş ağrısına ve maliyete neden olan iki kod tabanını desteklediği durum.

Bir mühendis olarak, artık amaç için gerçekten uygun olmayan eski kodları yeniden düzenlemeyi çok isterim, her şey eski veya kullanımdan kaldırıldığında. Ama şimdiye kadar çalıştığım tüm şirketlerdeki MD'lerin bana söylediği gibi: "Kim ödeyecek?"

12
Orbling

Ben giderken her zaman temizlemeye çalışırım. Kod temiz olana kadar ben yapılmadı. Teknik borçla ilgili sorun, çoğu insanın bunu anlamamasıdır. Bununla başa çıkmanın en iyi yolu hiçbirini biriktirmemek. Yöneticileriniz bir sorunun nasıl çözüleceğine karar vermek için geliştiricilerinize güvenirse, kod hijyenini her programlama görevinin bir parçası haline getirebilirsiniz. Hiçbir zaman kötü kod girmezseniz borç birikmezsiniz. Ayrıca İzci Kuralı (kodu her zaman bulduğunuzdan daha temiz bırakın) uygularsanız, mevcut borcunuz yavaşça yok olur.

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

12
EricSchaefer

Teknik olmayan yöneticilerle uğraşıyorsanız, tartışmanızı anladıkları terimlere çevirebilmeniz yardımcı olacaktır. Teknik borcu ödemek için harcanan iş üzerinde pozitif bir YG için gerçekçi bir dava oluşturabilirseniz, bir yere gidebilirsiniz. Bu alıştırma koşullarınıza bağlı olacaktır, ancak bir örnek şöyle olabilir:

Geliştiricilerin ne kadar zaman harcamak zorunda kaldıklarını analiz edin. C. Geliştirme, ortaya çıktıklarında üretim konularına harcadıkları zamanı azaltır. Destek işlerine bağlı geliştiricilerin bağlı kalmamasıyla tasarruf edilen dolar cinsinden ifade edin. Ayrıca, bir geliştiricinin destek vermek için harcadığı her saatin "çift yönlü" olduğunu belirtin, çünkü yalnızca bir geliştiriciye destek vermek için ödeme yapmakla kalmaz, aynı zamanda geliştiricinin neler yapabileceğinin fırsat maliyetini (yeni özellikler, vb. .)

Evet, bazı rakamlar voodoo/duman ve aynalar olacak ... sorun değil, yönetimin kirli sırrı, biliyorum etrafta sling ettikleri sayıların çoğunluğunun toplam B.S. Onlara çalışmak için somut görünen bir şey verdiğiniz sürece, başlarına sokmaları için bir savaş şansınız var.

7
mindcrime

Bu teknik borç açıklamasından sonra, yönetiminiz bunu ödemeye ikna edilmelidir:

Bok dolu çok kirli bir mutfağınız olduğunu hayal edin. Bir yemek hazırlamadan önce, bir saat temizlik yapmalısınız. Ve her yemek istediğinde böyledir. Ayrıca, bir yemek hazırlarken, bokun yemeğinize düşmediğinden emin olmak için ekstra dikkatli olmalısınız.

Mutfak sizin kodunuz, yemek sizin ürününüz ve yemek ise ürününüzü satıyor.

Bir birim testi güvenli bir ağ olmadan bir değişikliğin uygulanması için daha uzun süre bekleyebiliyorlarsa, şirketinizde bir sorun var demektir.

6
BЈовић

Orijinal ürün ve iş durumu açısından, bu parayı benim için daha önemli bir şey yapmak için kullanamadığımın çok inandırıcı bir argüman olması gerekiyor. İster beğenin ister beğenmeyin, yönetiminiz veya müşterileriniz bunun bedelini ödüyor ve onları ikna etmek için satış yapabilmeniz gerekiyor.

Kendinizi müşteri olarak konumlandırmak için bunu tekrar yazalım. Eski rol oynamak iyi.

Bir buzdolabı satın aldığınızı varsayalım. Ve Acme Corp.'dan sorunsuz çalışan 1000 dolarlık bir buzdolabı veya dışarıdan aynı görünen ve aynı teknik özelliklere sahip, ancak daha temiz bir iç mimari nedeniyle daha düşük bakım maliyetleri olan Acme Deluxe Buzdolapları'ndan 2000 dolarlık bir buzdolabı satın alabilirsiniz.

Müşteri olarak hangisini kendiniz satın alırsınız?

Ve Acme Deluxe mühendisleri daha iyi cevap ne düşünüyor?

4
jasonk

" Teknik borç " yönetime sunulması zor bir konu olabilir, çünkü buna ihtiyaç duymayabilirler. Soru, şirkette "Bak, burada teknik borç üzerinde çalışmak için% X zaman alıyoruz. Bunun size iyi çalıştığını göstermek için bize 3 ay verin" veya başka bir şey olduğunu belirtmek isteyip istemediğinizi belirtebiliriz. benzer. Orada özerklik iddiası var, fakat aynı zamanda bir zaman çerçevesi var, aksi takdirde yönetim oldukça tehlikeli bölgeler olan bazı sonuçları görene kadar ne kadar sürebileceğini merak ediyor.

İlk nokta, bunu bir sorun olarak görüp görmedikleri. Görme güçlüğü çeken kişi hiçbir gözlük ve ne tür değişiklikler sağlayabileceğini bilmiyorsa, bir göz testinin neden değerli olabileceğini nasıl anlayabilirler? Burada da konunun oldukça teknik olduğu ve maalesef kolayca ölçülemediği fikir.

3
JB King

Sadece şikayet etmeyi bırakmalısın.

İşte nedeni:

  1. Yazılımı bir yıldan uzun süre kullanmayı asla düşünmüyorlar
  2. eğer planları daha sonra dökmekse, bu sadece ince ayar yapmaktır
  3. şimdi düzeltilmesi gereken bazı gerçek sorunlar var
  4. programcılar, her zaman eğlenceli olmasa bile, bakımla baş etmeyi öğrenmelidir
  5. ne yapılması gerektiğini daha iyi bildiğinizden şikayet etmek kibirli - başka biri karar verir ve bundan memnun olmalısınız
  6. Zaten iyi kod yazmanıza güveniyorlar

Bu yüzden en iyi yol:

  1. Size yeni bir görev verdiklerinde, verilen zamanda mümkün olduğunca uygulamayı deneyin.
  2. İlk seferinde mükemmel yaz. Daha sonra değiştirmeniz gerekiyorsa, ilk kez bir hata yaptınız ve herhangi bir değişiklik her zaman yanlış yöne gidiyor - ve hata yaptığınızda programcılar için bir öğrenme fırsatı.
  3. Bunun için fazladan zaman sorma, anlamayacaksın, bildiğin son tarihler var.
2
tp1

Mevcut sistemi yeniden yazmak/değiştirmek veya hatta yükseltmek için bir projeye hiç katılmadınız.

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

  1. İş kuralları zaman içinde kaybolur.
  2. Dokümantasyon ve uygulama tamamen senkronize değil.
  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 tarafından kusur olarak görülecektir.
  5. Eğer kullanıcı satın almak olmaz - onlar "gerçek bulma" aptalca sorular soran nerds "olarak kabul edecek, onlar test çaba zaman kaybı olarak kabul edecek, böylece bir proje uzatmak olacak yeni özellikler eklemek ısrar edecek zaten programın gerisinde.
  6. Büyük olasılıkla kaynak kodu% 100 çalışan yürütülebilir dosya ile eşleşmez.
  7. Departmanınız gelişmeyi yeniden yapılandırmakla uğraşırken, iş gerçekten istiyor.
  8. Muhtemelen, yeniden faktoring işleminiz "daha temiz geliştirilmiş arayüzler" içerecek ve böylece diğer projeleri geç teslim ve başarısız testler bataklığınıza sürükleyecektir.
  9. Proje konserve edildikten sonra (bu çabaların% 50'den fazlası tamamen başarısız olur) tüm kredibiliteyi kaybetmiş olacaksınız - sizi dinlemeye hazır birini bulmak için başka bir kasabadaki başka bir şirkete taşınmanız gerekecek.
  10. Eğer proje "başarılı olursa" herkes ne bir kabus olduğunu hatırlayacak - siz yapacaksınız .......

Veba gibi yeniden yazma/yeniden düzenleme projelerinden kaçınmanızı tavsiye ediyorum, bunlar herhangi bir profesyonel kariyerindeki en tatmin edici deneyimlerden bazıları olabilir.

"Eğer kırılmazsa düzeltmeyin" deyiminde çok bilgelik vardır.

2
James Anderson

Zaten büyük bir yeniden yazımda yer alan (sadece refactor değil), finans adamlarının projeyi kabul etmelerini sağlamanın en büyük engellerden biri olduğunu kabul edebilirim. Bu engelin üstesinden gelmek, şirketlerin işinin orta ila yakın vadede suda öleceği anlamına gelen bir dizi sorunu yazmamızı, sunmamızı ve savunmamı gerektiriyordu.

Anlaşmanın devam etmesini sağlayan temel faktörler:

  • Mevcut kod, yalnızca neredeyse desteklenmeyen geliştirme platformunda (PDP11-23) çalışan artık desteklenmeyen bir araç zincirinde (MicroPower Pascal) idi.
  • Araçlar ve hedefler üzerinde çalışabilecek geliştiriciler bulmak neredeyse imkansız hale geliyordu.
  • Yedek parçalara ihtiyaç duyulduysa ve hedeflenen donanım artık mevcut değildi ve üretici bir onarım hizmeti sunmak için giderek daha isteksiz hale geliyordu.
  • Koddaki sorunlar, kolayca tanımlanabilir müşteri memnuniyetsizliğine ve doğrudan servis maliyetlerine yol açmıştır.
  • Hedef donanımın sınırlamaları nedeniyle yeni özellikler ve hatta hata düzeltmeleri eklemek, sorunları giderirken alan sağlamak için diğer alanları yeniden düzenleme gereği ile neredeyse imkansız hale geliyordu.
  • 8 saatlik bir inşa süresi ile herhangi bir değişikliği geliştirmek ve test etmek maliyetliydi.

Rapor, devam eden maliyet tahminleriyle sorunları ayrıntılı olarak açıkladı ve 3 seçenek sundu:

  1. Biz yakın gelecekte muhtemelen bile düzeltmeleri ile nerede olduğumuzu dondur.
  2. Kodu yalnızca alan için optimize edin, sürdürülebilirlik göz önüne alınmaksızın optimize edilmiş kodu korumaya çalışan herkesin optimizasyonu yapandan daha akıllı olması gerektiğini belirtir.
  3. Test edilebilirliği ve sürdürülebilirliği yüksek faktörler olarak, bir endüstri standardında, yaygın olarak öğretilen bir dilde (ANSI C), yeni, düşük maliyetli, COTS donanımında (PC-104), bir şirkette bulunan birden fazla satıcıyla yeniden uygulayın kalan mevcut donanım ile çalışmasını sağlamak için tasarlanmış arayüz kartı. Geliştirmenin bir parçası olarak, geçici olmayan depolama, bir arıza durumunda otomatik olarak yeniden başlatma sağlamak için bir zamanlayıcı gibi sınırlı bir dizi yeni özellik eklenmesi bazı birimler günde birkaç kez kilitleniyor ve 40 £ servis çağrısı gerektiriyordu) sıfırlamak için, süreçte daha iyi teşhis.

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

Daha az aşırı teknik borcu olan durumlarda, gerilla yeniden düzenleme dediğim şeyi benimseme eğilimindeyim:

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

  1. Sorunu gösteren bir dizi test yazın ayrıca yeniden düzenleme yapmadan da başarısız olabilir
  2. Testlerin hala başarısız olduğunu gösteren gelişimin bir parçası olarak refactor.
2
Steve Barnes

Hayatım boyunca, bazı insanların neden körü körüne değişimden korktuğunu anlayamıyorum - kendi yeteneklerinize güvenmekten korkuyor.

Dün gece Yosemite Ulusal Parkı'nda bir gösteri izledim ve 1940'tan 1990'ların sonuna kadar yeni bir Sequoia ağacının filizlenmediği belirtildi. Bunun nedeninin orman yangınlarının yanmasına izin vermesine karşı katı bir politika olması ve Sequoia çam kozalaklarının tohumlarını açmak ve serbest bırakmak için ateşten ısıya ihtiyaç duydukları keşfedildi.

Görüyorsunuz, her on yılda bir yangın sağlıklıydı. Mevcut ağaçların (süreçlerin) sağlıklı kalması ve yenilerine (özellikler) yer açması için biriken tüm deadwood ve bramble'ı temizledi.

Şu anda yeniden oluşturma için açık bir davaya sahip bir projedeyim: Eski yazılım tamamen .NET web formları kullanılarak yazılmıştır. Hemen hemen tüm iş mantığı, HTML/sunucu etiketi görünüm mantığı ile birleştirilmiştir ve iş büyüdükçe diğer uygulamalara genişletilemez.

Yönetim görevin arkasındadır, çünkü geliştiricilerine nadiren lüks olan uygun bir güven duymaktadırlar.

Evet, kendinize bir yeniden yapılandırmanın gerçekten gerekli olup olmadığını sorun. Mümkün olan yerlerde çalışan mevcut kodu yeniden kullanmak için elinizden geleni yapın. Gerekirse bu kodu yeniden oluşturmaya entegre edin. Kimsenin sizi cesur değişiklikler yapmaktan korkmanın bir yazılım geliştiricisi olarak var olmanın tek yolu olduğuna ikna etmesine izin vermeyin.

İyi şanslar!

1
Matt Cashatt

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

Bir teknolojik yol haritası korumak böyle bir çerçevedir. Bir yol haritasından başlamak, teknik borç biriktirmenize engel olmanıza yardımcı olur ve ayrıca mevcut borcunuzu 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ı ile ilişkilendirilmiştir. Bunlar, özellikle birden fazla geliştirme ekibi ve paydaş olduğunda faydalıdır.

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

Bir yol haritası oluşturma ve yönetme konusundaki genel yaklaşım basittir, ancak yönetim ekibinizin desteğini gerektirir. İlk olarak, bir hedef belirleyin. Teknik borcun unsurlarını tanımlayın ve teknik borcunuzun unsurlarını azaltan bir hedef sistem mimarisi geliştirin. Unutmayın, mükemmel, sadece uygulanabilir ve şu anda olduğunuzdan daha iyi olması gerekmez. Sisteme eklenebilecek yazılım, geliştirme araçları, donanım platformları, önemli yeni özellikleri göz önünde bulundurun. Bir maliyet analizi yapın. İstediğiniz mimariye sahipseniz, yeniden düzenleme yapmanın somut faydaları nelerdir? (Avantajlar, daha kısa test süresi, daha güvenilir yazılım ürünleri, daha öngörülebilir geliştirme döngüleri vb. İçerir.) Yeniden düzenleme yapmak için yeterli fayda gösterebilirseniz, yönetim desteği alabilirsiniz.

Bir yol haritanız ve yönetim desteğiniz olduğunda, istenen bu duruma ulaşmak için atmanız gereken bir dizi adım (plan da denir) geliştirin. Yol haritasını koruyan, geliştirme ekiplerini yol haritasında eğiten ve eğiten ve mimari bütünlük için değişiklikleri periyodik olarak 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 Testindeki 13. soru "Yol haritanız var mı?" Olmalıdır.

İşte yakın zamanda yapılan bir Red Hat Linux yol haritası oturumunun ilk saatinin videos .

1
Jay Elston