Teknoloji borcu nedir?

Teknik borçlar, kişinin bilinçli olarak şu anda uygulamamayı seçmiş olabileceği bilinen mühendislik uygulama noktalarıdır. Teknoloji borçlarının alınması yaygındır, ancak makul bir şekilde düşünülmesi gerekir. Bunları ne zaman / nasıl değerlendireceğinize dair bazı yönergeler sunacağız.

İdeal olarak, herhangi bir kod parçası — ilk uygulaması sırasında bilinen tüm durumları ele almalıdır. Ancak, engelleyiciler olabilir:

1. Bazı durumlarda, umarız nadirdir - ürün işlevselliği veya mühendislik mantığı net olmayabilir. Bu aynı zamanda net olmayan ölçek veya trafik gereksinimleri olabilir ve trafik ve ölçek için yetersiz veya aşırı hazırlık riskine yol açabilir.
2. Yaygın olmayan kullanım durumları için uygulama açık olsa bile, uygulama karmaşık veya zaman alıcı olabilir.

Hepimiz ideal olarak teknoloji borçlarını en aza indirmek isteriz, ancak almanın mantıklı olduğu zamanlar vardır.

İlerleme ihtiyacı

Tüm ayrıntılara veya tam uygulamaya sahip olmamak zarar verici olabilirken, genellikle aşağıdaki nedenlerin bir kombinasyonundan dolayı ilerlemek gerekir:

1. Çoğu zaman, kullanımdan veya müşteriden gelen kısmi geri bildirimden yararlanarak, daha fazla soruyu yanıtlamak için bir şeyler oluşturmak veya uygulamak gerekir. Titreme, pahalı olan gecikmelere yol açabilir ve mükemmel olmayan bir uygulamayı riske atmak hiç olmamasındansa ihtiyatlı bir davranıştır.
2. Spesifik netlik eksikliği, oluşturulacak işlevselliğin daha geniş şemasında nispeten önemsiz olabilir, kolayca eklenebilir veya düzeltilebilir ve işlevselliği uygulamamak daha pahalı olabilir.

Nitelikler

Bir teknoloji borcu aldığımızda, bilinçli olarak belki de daha doğru bir uygulama ile kısmi bir uygulama arasında ticaret yapmaya karar verdik. Yine de iyi bir teknoloji borcu:

1. Teknoloji borcu ele alındığında, seçili olan uygulamanın kodunda daha az kod karışıklığına neden olur ve
2. İşlevselliğin nadir görülen bir kısmında zarif bir hataya yol açar. Tersine, sabitlendiğinde, özelliğin artımlı bir iyileştirmesidir.

Kişi yalnızca yukarıdaki nitelikleri karşılayan iyi teknoloji borçlarını almalıdır. Aşağıdaki sorular değerlendirmemize yardımcı olur.

Maliyet

Teknoloji borcunu almanın veya kaçırılan davanın maliyetini değerlendirirken sorulacak bazı sorular:

1. Kaçırılan işlevsellik nerede - örneğin veri görselleştirme/sunumunda veya veri oluşturmada? Daha spesifik olarak, kaçırılan işlevsellik kalıcı olarak hatalı verilere yol açar mı?
2. Kullanıcı deneyiminin dezavantajı nedir? Bu, kullanıcıların tökezleyip mutsuz olabileceği yaygın bir kullanım durumu mu, yoksa temel değer önermemizin sınırında yer alan alışılmadık bir durum mu?
3. Eksik veya atlanan işlevsellik tasarımı ve uygulamasının ayrıntılarından emin miyiz? Yoksa onu tanımlamak için kısmi uygulama hakkında geri bildirim almayı mı tercih ederiz?

Belirli avantajlar için teknoloji borçları alıyoruz:

1. Potansiyel olarak artan satışlara veya müşteri memnuniyetine yol açan daha hızlı sürüm.
2. Eksik işlevselliğin belki de daha iyi bir tasarımına yol açan benimseme verileri veya geri bildirim alma potansiyeli. Bazı belirsiz işlevler için bu gerekli olabilir.
3. Kısa vadede tasarruf edilen mühendislik çabasının fırsat maliyeti.

Sağlam tasarımın temel temel ilkelerini takip etmek, teknoloji borcunu ele almanın gerektirdiği yeniden çalışmayı en aza indirir.

modülerlik

İyi tanımlanmış arabirimlerle hizmetlerin ve nesnelerin iyi düşünüldüğünden emin olun. Modülerlik, kod yeniden işleme ayak izini en aza indirmeden değişikliklerin yerelleştirilmesine izin verir.

Hemen ötesinde düşünmeye çalışın, örneğin

1. Şu anda işlevselliğin bir uygulamasına sahipsek, ancak daha sonra uygulamayı bir arayüzün alt sınıfı olarak koyabiliriz. Bu, daha sonra daha fazla uygulama eklemeyi kolaylaştırır.
2. Bir varlık şu anda alan için bir olası değere sahipse, ancak daha sonra daha fazlasına sahip olabilirse, bunu bir sıralama yapın.

Temiz şema

Gerçek hayattaki kullanım durumunu yakından modelleyen iyi bir veritabanı şeması ve ORM modeli genellikle daha fazla değişiklik için sağlamdır.

İyi kodlama uygulamaları

1. İnce ayar yapılabilecek değerleri KURU tutun ve kodun derinliklerine değil. Çalışma zamanı giriş yapılandırma değişkenleri veya kod sabitleri olabilirler. Bu bilinçli bir karar olmalıdır.
2. Bazı işlevler, hızla yineleme veya müşteri başına özelleştirme becerisine ihtiyaç duyar. Düşük kodlu/kodsuz araçlar kullanın; mühendis olmayan biri tarafından bile yinelenmesi kolaydır. Ve daha az kod ve dolayısıyla daha az kayıp var.
3. Yukarıda belirtilen genel kodlama ve tasarım uygulamaları geçerlidir - yani kodu KURU tutun (tek bir yerde kodu değiştirmek kolaydır), basit tutun (dolayısıyla değiştirmeyi anlamak daha kolay), vb.
4. Mevcut tek düğümlü bir mongo veritabanı sunucusuna replika kümeleri eklemek veya bir mongo veritabanı sunucusuna sharding yapmak gibi bazı değişiklikler ek olacaktır - kelimenin tam anlamıyla statükonun üzerine inşa edilecektir. Bunların uygulanmasının pahalı olması durumunda, bu tür geliştirmelere duyulan ihtiyaç, herhangi bir ek çaba gerektirmeden ihtiyaç duyulana kadar zaman çizelgesinin daha aşağısına itilebilir.

Tüm vakaları ele almamak, kodu kontrol etmek için yeterince iyi bir neden değildir. Bunun yerine, ilerlemenin bir yolu aşağıdadır:

1. Bekleyen işlevsellik veya açıklama öğeleri hakkında çok sayıda YAPILACAKLAR yorumu ile şubenizde kod kaydetmeye devam edin.
2. İdeal olarak, çekme isteğini yükseltmeden önce tüm TODO'ları çözün.
3. Çözülmemiş herhangi bir sorun bir teknoloji borcu haline gelir - kod gözden geçirenin ve ilgili mühendislik yöneticisinin/yöneticinin etiketlendiğinden / bilgi, Jira'nın oluşturduğu teknoloji borcu ve yorumda Jira kimliğinin belirtildiğinden emin olun. PR incelemesi, teknoloji borcunun alınabileceğini umarız yeniden teyit eder.
4. Kodun işlenmeyen vakaları bile zarif bir şekilde ele aldığından emin olun; örneğin, ön uç, arka ucun çökmesine kıyasla henüz işlenmemiş API girişi hatasını göstermek için uygun bir API yanıtı alır.
5. Jira'nın teknik borcu için bir zaman çizelgesi tutun, muhtemelen bir sonraki sprint'te tutarak, ilk gözden geçirme için sprint planlama çağrısında ortaya çıkmasını sağlayın.