Dünün borcunu dünün teknik borcundan suçlamak


38

Şaşırtıcı sayıda kalite, ölçeklenebilirlik ve yük sorunları, başlangıçta yazmadığım bir uygulamada meydana geliyor. Neyse ki, akıl sağlığımın bir kısmını korumak için sıfırdan yaptığım yeni projelerim var.

Orijinal ekip 20 geliştiriciden (çoğu modası geçmiş becerilere sahip), iş gereksinimi belgesi veya kalite güvence testcisinden oluşmamış ve en başından beri bir şelale biçiminde kötü yönetilmiştir. Üretimin ilk günleri, daha da kırılgan düzeltmelerle gevrek prosedür benzeri kodların eklenmesini içeren utanç verici bir kabustu. Sonradan desteklenmesi amaçlanmayan bir veri modeline kızaklanan özellikler eklendi ve aynı kodun 10 kez çoğaltıldığını görmek ve güvenli bir şekilde kapatılmayan kaynakları görmek ve nadiren on binlerce kişiyi alan ORM sorguları bulmak nadir değildir. bir avuç hariç hepsini atmak için.

Şimdi sadece benim ve her zaman ortaya çıkan yeni bir problem ortaya çıkıyor, bir modülü daha iyi standartlara yeniden yazdım ve daha istikrarlı hale getirdim ancak Yönetim'in tüm bunların neden gerçekleştiğine dair doğru bir açıklama yapması gerekiyor.

Bu uygulamanın kalitesiz olduğu ve teknik borçlarda boğulduğu düşüncesi karşısında şok ve şaşkın görünüyorlar. Neyse ki, teknik borç kavramını anlıyorlar ve beni yok etme arayışımda beni destekliyorlar ve beni çok destekleyici ve takdir ediyorlar, ancak orijinal ekibi suçlamaya devam ediyormuş gibi hissediyorum (hepsi farklı bir projeyi mahvetmek için kalanlar gibi) bölünme).

Sonuç olarak, kendisinden önce projedeki geliştiricilerden daima şikayetçi olan "Bu Adam" olmak istemiyorum . Bu tutumu daha önce kariyerimdeki insanlardan, şahsen cahil olduklarını hissettim ve olayları olduğu gibi teşvik eden koşulları ve tasarım etkilerini göz önüne almadıklarını gördüm.

Genellikle, daha önce üst düzey üyelerin sahip olduğu ve fayda sağladığı yaşam deneyimlerini yaşamamış idealist genç geliştiricilerin zayıf tasarım ve uygulama için önceki takımı suçlama tutumunu görüyorum.

Sizden / ekibin itibarını önemsemeden bu tür sorunları yönetime rapor etmenin daha yumuşak, daha yumuşak bir yolu olduğunu düşünüyor musunuz?


17
Yaklaşık bir soruda ironik değil suçlama oyunu oynarken, önceki ekibi hakkında atıp Sorunuzun yaklaşık% 50'sini oluşturan 3 tam paragraflar geçirirler. Ve [bad-code] ve [bad-programmer] sorusunu etiketledi.
Aarona

8
@Aaronaught, Tamam, ısırırım, etiketli bad-codeçünkü kod gerçekten hatalara ve sorunlara neden oluyor. Bunu etiketledim bad-programmerçünkü korkarım ki, daha önce duyduğum her şeyden önce duyduğum yorgun ve klişeli bir bahaneyi suçlayarak önceki takımımı suçluyordum. İlk üç paragrafa bakılırsa belki de açıklayıcı olmaya ihtiyacım olmadı ama acil durumumun doğru bir resmini çizip şu ana kadar topladıklarımın tarihini anlatmak istedim.
maple_shaft

2
... Yani orada bir rant unsuru var mı? Evet, sanırım öyle ama DEHB gibi ölüm arzusuyla çalışan bir uygulamaya dadılık yapmaktan bıktım.
maple_shaft

2
Sana sempati duyuyorum Yaparım. Ama eğer buhar ya da buhar çıkarmak istemiyorsanız bir sohbet sistemimiz var. Yapıcı sorular nötr bir tonda olmalı ve bu kadar gereksiz detayları içermemelidir.
Aarona

Hayatımın Hikayesi
Iulian Onofrei

Yanıtlar:


46

Teknik borç, finansal borç gibidir. Gelecekte ödenmesi niyetiyle bir programın geliştirilmesinde stratejik olarak (umarım) alırsınız. Bazen insanlar kötü teknik borç kararları alır (örneğin kredi kartı çalıştırmak gibi), ancak bazen belirli miktarda teknik borç normaldir. Gelecekte değiştirilmesinin gerekli olacağı varsayımıyla bugün bir şeyi “doğru” yol haline getirmek için zaman ayırmamaya karar vermek tamamen normaldir ve tahmin edilmelidir. Elbette ince bir çizgi var, ancak doğru zamanda yapacağınızı düşünmek ilk kez kendi problemlerine neden olabilir (analiz felci).

Sonuç olarak, birkaç yıldan fazla süren önemsiz herhangi bir projenin, teknik borcu ödeyerek yeni bir geliştirme zamanı ayırması gerekecektir. Mesele şu ki, başvurunuzu doğru şekilde yazsanız bile bu doğrudur . Bunu yapmazsanız, borç borcunu ödüyorsunuz ve yönetim bu şekilde sunarsanız kesinlikle anlayabilir.

Bunu yönetime açıklayın ve önceki takımı her zaman "suçlamak" yerine, bunu "her zamanki iş" olarak sunabilirsiniz.


4
Bir projenin teknik borç almak için nasıl bir seçim yapabileceği (doğru!) Hakkında gerçekten iyi bir suçlayıcı olmayan açıklama için +1.
Joris Timmermans

1
@Nemi: Teknik borç ile finansal borç arasındaki önemli bir fark, ikincisini ölçmenin çok daha kolay olmasıdır. Ne kadar finansal borcunu ödediğinizi bilmek çok daha kolaydır (faiz birikiminde ve yinelenen finansal yükümlülüklerde bile etkilidir), o zaman bunu teknik borçlarla yapmak gerekir. Bunu sadece işaret ediyorum, çünkü bu maple_shaft'ın sorununu daha da şiddetlendiren bir şey.
Ben Hocking,

2
@Ben - kesinlikle haklısın. Tüm analojilerde olduğu gibi, bu bir mikroskopta bozuluyor. Ancak, karşılaştırma hala yüksek düzeyde sağlam. Esasen, detaylarla ilgilenir ve kendi seviyelerindeki yönetimle konuşur - teknik bir problem değil, bir ticari problem olarak. Temelde uzun süren herhangi bir proje belirli bir miktarda teknik borç biriktirir ve bu nedenle zaman geçtikçe gelişmeye ilave bir masraf olduğu anlamına gelir. Bu gizlendiğinden (hatta iyi anlaşılmadığından), hakkında konuşulduğundan emin olmak herkesin yararınadır.
Nemi

2
+1 ila "bu, başvurunuzu doğru şekilde yazsanız bile geçerlidir."
Mauricio Scheffer,

1
@radarbob Ben katılmıyorum - tıpkı finansal borç gibi, kötü şans ya da aptallık nedeniyle kasıtlı olarak yapılmasının önemi yok - birinin gelecekte ödemesi gerekiyor. Bu terim, nedene bağlı olarak doğal olarak nötrdür.
Hulk

23

IMO, çoğunlukla zaten bu konuda doğru şekilde gidiyorsunuz: "eski kod berbat" olduğu için bir yeniden yazma önerisinde bulunmuyorsunuz, ancak bir seferde bir şeyi düzeltirsiniz.

Eski takımı suçluyormuş gibi hissetmemek için, büyük olasılıkla bu kodu büyük zaman baskısı altında üretmek zorunda olduklarını hayal edin. O zamanki yönetim muhtemelen, “az ya da çok işe yarayan” kodunun, çok fazla acı ve tekrarlama olmadan herhangi bir bakımın mümkün olacağı anlamına gelmediğini anlamadı.

Eski ekibin, gerçekten de bir miktar iş değeri sunan bir ürün yapmayı başardığı için teşekkür ederiz - olmasa bile artık kullanılmayacaktı. Güzel yazılmış olsa bile, bir projenin ne sıklıkta iş değeri sağlayamadığına şaşırabilirsiniz.


3
+1: kaliteli bir ürün teslim etmekte başarısız olan eski yönetimi
suçla

15
@gbjbaanb - kimseyi suçlama! Kimseyi suçlamamak için kendi yolundan çık. Sadece mevcut durumu ve istenen durumu belirleyin ve oraya nasıl ve neden gitmeniz gerektiğine dair mantıklı bir tartışma yapın.
Joris Timmermans

Eh, yeni yönetim olduğundan emin olun. Aynı patron hala orada olabilir. İlerlemiş olsa bile, o dışarıda bir yerlerde. İnsanları otobüse atmadan önce dolaşmayı öğrendiğinizden emin olun.
Philip,

Keşke kimseyi suçlamamak kadar basit olsaydı. Yönetim, parmağını işaret edecek bir şey / bir konuda ısrar ediyor. Bir kişiye veya gruba işaret etmiyorsam, onu işaret ederim?
maple_shaft

4
@maple_shaft - yönetime cevabımda yaptığım tartışmayı yapın ve hala "suçlamak" konusunda ısrar ediyorlarsa, özgeçmişinizi bulabildiğiniz kadar siteye gönderin, çünkü işler sizin için çok kötü olacak parmağınızı işaret edecek kimsenin olmaması için sizi suçlamaya başlamaya karar verin .
Joris Timmermans

7

Bir sorunlu ürünün şu anki durumu hakkında yorum yapmam istendiğinde, her zaman “ne olduğu” düştüm ve daha sonra onu geliştirmek için planlar hakkında konuşmaya başladım.

Bu sorunu yaratan karara bağlanan tüm faktörleri bilmiyorsunuz - belki de o zamanlar makul. Yapabileceğin tek şey ileriye gitmek ve yarın daha iyi şeyler yapmak. Kulağa iyi bir iş çıkarıyor gibi geliyorsunuz - bu durum için doğru tutuma sahipsiniz.

Sorulduğunda sadece gerçekleri bildirmeye odaklanın. Anlatı veya yorum eklemek zorunda değilsiniz; sadece "X durumunda sistem başarısız" deyin ya da "Y durumu için raporlar yanlış" deyin. Ardından mevcut durumu nasıl iyileştirmeyi planladığınızı hemen ekleyin.

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.