Programcı, teknik borcunu ödedin mi?
"Bu tasarımı gerçekten geliştirmek istiyorum ama zamanım yok."
"Bunları gerçekten organize etmek istiyorum, ancak bu, bu görevin kapsamında değil."
"Bu modülün mimarisini yeniden düşünmek için şu anda zamanımız yok."
Bu sözler her geliştiricinin kulaklarını koza yaptı. Daha da çirkin olan şey, her geliştiricinin tüm gün boyunca bu kelimeler hakkında konuşmasıdır.
İnsanları kazanmaya ve kaybetmeye isteksiz hissettirir.Çoğu durumda, yapılması gerekenler bunlar.
Eskiden zarif ve güzel bir kod sağlamayı umuyordum, ancak gerçek şu ki patronum bana onlara ve müşterilerine faydalı özellikler, yani değer sağlamak için para ödedi.
Müşterilere değer sağlamaya odaklanmak, modern teknoloji işinin en büyük odak noktasıdır ve Eric Reis'in "Yalın Başlangıç" ın popülaritesi ve tüm "teknoloji ürün geliştirme" fikrine verdiği ilhamla bu odak daha belirgin hale geldi.
Bununla birlikte, hepimiz (Reis ve arkadaşları dahil), müşteri odaklı özellikleri gönülden sağlamanın bir hata olduğunun da farkındayız; bu, tanıdık "teknik borca" ve ardından "teknik iflas" a düşmemize neden olan suçludur Sonunda, korku içinde başarısızlığı kabul ediyoruz, tüm çalışmalar boşa gitti ve tüm kodun "tamamen yeniden yazılması" gerekiyor.
Bu nedenle, yazılım geliştiricileri olarak, genellikle bakımın (yani kod tabanını sağlıklı bir durumda tutmanın) işimizin önemli bir parçası olduğuna inanıyoruz.
Bununla birlikte, eğer hepimiz sağlıklı bir kod tabanı oluşturmanın işimizin önemli bir parçası olduğunun farkına varırsak, o zaman neden "bakıma" ayrılan zaman neredeyse sıfırken, çalışma zamanımızın% 100'ünü kaplayan "değer" buluyoruz?
Bakımın gerekli olduğunu biliyoruz. Teknik liderimiz biliyor. Baş teknoloji sorumlumuz sık sık bundan bahsediyor ve bazen CEO bile "teknik borç" kavramına ve teknisyenlerin bu konudaki korkusuna aşinadır.
Ancak gerçekte işimizin odak noktası değişmeden kalır. "Şu anda bu sorunla uğraşacak vaktim yok."
Bakım gerekçesi
Bu sorunun geçerli bir sebebi var mı?
En yaygın açıklama "ürün yöneticisi kötü adamdır" teorisidir: Teknik bakım yapamıyorum çünkü bu kötü iş adamı bana sürekli özellik geliştirmeyi veriyor.
Bu açıklamanın iki nedenden dolayı yeterli olmadığını buldum:
Öncelikle ürün yöneticileri anlattığımız imaja aykırı, aynı zamanda makul insanlar. Ayrıca teknik borcu biliyorlar ve endişeleniyorlar ve bundan kaçınmak istiyorlar.
Ve bunu yapmak istemeseler bile, yine de teknik kadromuz var Teknolojiyi sağlıklı tutmak teknik liderlik ekibinin görevidir.
İkinci olarak, yukarıdaki gözlemlerimize göre bakım, işinizin bir parçasıdır.
Ne zamandan beri çalışmanızın lideriniz tarafından onaylanması gerekiyor? Doktorlar sırf "Müşterilerimizi sezon sonunda sağlıklı tutmaya söz veriyoruz" dedikleri için kapsamlı muayene ve testler yapmayacaklar.
Profesyonel bir müteahhit, zeminin binanın yapısını desteklemek için yeterli olduğunu onaylamadan temeli atmaya başlamayacaktır.
Peki bunun yazılımdan farkı nedir? Pek çok neden, sektörümüzün aşırı olgunlaşmamış olmasıdır.
Tıpkı binalarda güvenlik denetimleri veya tıbbi hizmetlerde sıhhi işlemlerde olduğu gibi, kod sağlığını korumayı sürecin vazgeçilmez bir parçası haline getirmek için yeterli profesyonel standartlara sahip değiliz.
Bu da, böyle bir standardı kanıtlamak için yeterli profesyonel yeteneğe sahip olmadığımızı gösteriyor, bu da önceki projede "teknik borcu ödemek" için zaman harcadığımızı, ancak başarılı olamadığımızı gösteriyor. Öyleyse bir sonraki projede bunu yapmayı nasıl isteyebiliriz?
Tabii Bob Martin Amca'nın peşinden gidenler ve uzun yıllar aynı şeyi söyleyenler için bu sonuç yeni değil.
Ancak doğru bakımı yapacak kadar iyi olmadığımız için (yeterince profesyonel olmadığımız için) işlerin bitmediğine inanıyorum. Kısmen denemekte isteksiz olduğumuz için. Unutma, burada "Bunu ben yapmadım" diyorum, "Çok çalıştım ama yapamadım" değil.
Bakımı denemekte neden isteksiziz?
Tipik bir geliştirici olduğunuzu varsayalım. Bir gün değer yaratmayı veya bakım yapmayı seçebilirler. Onların (neredeyse herkes) ilkini seçeceklerini biliyorum.
Teknik liderleri, baş teknoloji yetkilileri ve meslektaşları her gün teknik borç endişelerini tartışmalarına rağmen. Bu neden? Müşterilere çok faydalı olan özellikleri sunduğunuz için siz (veya meslektaşlarınız) kaç kez övgü aldınız?
Şimdi, siz (veya meslektaşlarınız) kod yeniden düzenleme, bakım veya teknik dokümantasyon yazdığınız için kaç kez övüldüğünüzü karşılaştırın?
Veya başka bir bakış açısıyla, kişisel olarak sizin için, müşteriler için 100 özellik planlıyorsanız, ancak biri sunmayı başaramazsa, sonuçları ne olur?
Karşılaştırmak gerekirse, sizin için kod tabanını iyileştirmek veya sürdürmek için 100 fırsat varsa, ancak bunların hepsini 100 kez yapmadıysanız, sonuçları ne olur?
Çalışma ortamınız gördüğüm tüm çalışma ortamlarına benziyorsa, mükemmel bakım çalışması yapmanın meslektaşlarınız tarafından takdir edilebileceğini, ancak teslimat işlevi size bir terfi kazandırabilir.
Hangi seçerdiniz? Bu sonuç hiç de şaşırtıcı ya da yeni değil; Pazar ekonomisine dair çok az anlayışımla, herkesin faydalarını en üst düzeye çıkarmak için çaba göstereceğini de biliyorum.
Kod satır sayısına göre ödeme yaparsanız, aynı işlev için alacağınız kod miktarı 10 kat fazla olacaktır. Her hatayı düzelttiğinizde bir bonus alırsanız, uygulamanız gelecekte hatayı yavaşça değiştirebilmeleri için hatalarla dolu olacaktır.
Kodu korumanın somut bir ödülü yoksa, teknik borca girersiniz.
Geliştiricilerin enerjisinin% 100'ünü değere, bakım çalışmalarının% 0'ına nasıl aktarabiliriz? Basitçe söylemek gerekirse, yöneticiler sadece ağızlarını kullanamazlar; teknik borcun nasıl çözüleceği konusunda gevezelik etmeyi bırakabilirler. Bunun yerine, sorunu çözmek için birine ödeme yapmaya hazır olduğunuzu göstermelisiniz.
Bakımda dengenin önemi
Denge burada önemlidir. Geliştiricilerin değere ve bakıma 100'den 0'a yatırım yapmasını istemesek de 50'den 50'ye olmak istemiyoruz.
Yıllık değerlendirmenin bir parçası olarak bakımla ilgili çalışma nasıl yapılır? Veya geliştirme spesifikasyonunun bir parçası olarak?
Geliştiricilere her 10 defada bir "Bu işlevler nasıl yapılır?" Diye sorarken, "Son zamanlarda kod iyileştirmeleri nasıl?"
İnsanlar terfi, maaş artışları ve şirket içindeki pozisyonları da dahil olmak üzere kuralları sağlıklı tutmanın da ödüllendirileceğini anladıktan sonra, bunu tamamlamak için zaman, kapsam ve enerji bulacaklar.
Bununla birlikte, birisinin belirli bir hedefe ulaşıp ulaşmadığını etkili bir şekilde belirlemek için, onu ölçebilmeniz gerekir. Kod kalitesinin ölçülmesi veya kod kalitesinin iyileştirilmesi, kolayca çözülebilecek bir sorun değildir. Bu konunun nasıl ölçüleceği, açıklamak için bir blog yazısı açmayı, bir kitap yazmayı veya akademik araştırma yapmayı gerektirir.
Bu makaledeki açıklama deneyiminize uyuyor mu? Teknik borcu geri ödemek istemememizin makul bir nedeni var mı? Ya da belki bu hiç sorun değil? Lütfen aşağıya bir mesaj bırakın.
Orijinal bağlantı: https://uselessdevblog.wordpress.com/2018/06/24/why-we-all-choose-to-not-pay-back-tech-debt/
Yazar: Jhonny, Kıdemli Yazılım Geliştiricisi, C #, javascriptnode ve JS, ruby'nin yanı sıra bazı araçlar AnuglarJS, nHibernate, raylar, mongodb vb.
Çevirmen: Crescent Moon, Kurgu: Hu Weiwei
"Belgeler için çağrı"
CSDN halka açık hesabı, "on binlerce teknik insanla büyüme" kavramına bağlıdır. Teknik insanların ilk kez ilgilendikleri endüstri odak olaylarını teknik insanların benzersiz bakış açılarından tanımlamak için yalnızca "inek başlıkları" ve "konuşma" sütunlarını kullanmakla kalmaz, aynı zamanda "Teknoloji Başlıkları" sütunu, sektördeki popüler teknolojilerin ve uygulamaların derinlemesine bir yorumunu sunarak, tüm geliştiricilerin teknolojik trendlere ayak uydurmasına, uyanık bir teknolojik anlayışı sürdürmesine ve sektör eğilimleri ve teknolojileri hakkında daha kapsamlı bir anlayışa sahip olmasına olanak tanır.
Yüksek kaliteli makaleleriniz veya sektörün sıcak olayları, teknoloji trendleri hakkında içgörüler veya derinlemesine uygulama uygulamaları, senaryolar vb. Hakkında yeni içgörüleriniz varsa, gönderimler için lütfen CSDN ile iletişime geçin. İletişim: WeChat (guorui_1118, lütfen gönderim + ad + şirket pozisyonunu not edin), e-posta (guorui@csdn.net).
