Teknik Borç Nedir ve Bundan Kaçınabilir Misiniz?

Yazılım geliştirmedeyseniz, bir noktada teknik borçla uğraşmak zorunda kalacaksınız. Yani başlıktaki soruyu cevaplamak için… hayır, bundan kaçınamazsınız. Ancak, etkilerini en aza indirmek ve kontrolden çıkmamasını sağlamak için atabileceğiniz adımlar vardır. En azından çok kötü.

Teknik Borç Nedir?

Bazen adlandırıldığı gibi teknik borç, esasen kusurlu koda sahip olduğunuz için zaman içinde maruz kaldığınız maliyettir. Kaynak kodundaki değişiklik ve güncellemelerin, geliştirme ekibine yeni bir üye eklemenin, yeni bir özellik eklemenin veya hataları düzeltmenin ve açıkları yamalamanın bir maliyeti vardır.

Projeniz büyüdükçe, kod tabanı genişler ve daha fazla insan bu kod üzerinde çalışır, sesleri ve stilleri burada ve orada çatışır. Belki bir son teslim tarihiniz vardır ve zamanında bitirmek için kaynak koduna ideal olmayan bir çözüm eklenir. Belki de bir özelliği kendiniz kodlamak yerine ele almak için tam olarak anlamadığınız bir açık kaynaklı bileşen eklersiniz. Veya kitaplıkları sürümler arasında değiştirebilirsiniz (örneğin, Backbone'dan React'e), ancak yine de projeleri için eski kod tabanını kullanan kişileri desteklemeniz gerekir.

Kesinlikle bunların hiçbiri kötü değil . Kendi başlarına değil. Belki de hiç değil. Ancak bir araya getirildiğinde, üstlendikleri teknik borcun gelecekte bir noktada geri ödenmesi gerekecek.

Bir noktada, bu açık kaynaklı bileşenin değiştirilmesi (veya çatallanması) gerekebilir. Bu zaman ve paraya mal olacak. Uzak bir gelecekte, projenizden tüm Backbone kodunu kaldırmanız ve eski kullanıcıları desteklemeyi bırakmanız gerekecek. Yine, zaman ve para. Son teslim tarihini karşılamak için yaptığın yama? Eh, sonunda çözülecek ve daha kalıcı bir düzeltmeye ihtiyacı olacak. Zaman ve para. Ve tüm bunları yapmak için eski koda geri dönen ve önceki geliştiricilerin kodunu ve mantığını anlaması gereken ekibinizin yeni üyelerine sahip olacaksınız. Zaman. Para.

Anlarsın.

Teknik borç soyut ve genellikle mecazi bir terim olsa da, teknoloji borcunun maliyeti oldukça gerçektir. Geri ödemenin parasal bir değeri vardır ve ödediğiniz faizi mesai saatleri ve maaş bordroları üzerinden takip edebilirsiniz. Bunu tüm yazılım geliştirmenin alt satırında görebilirsiniz.

Teknoloji Borçlarından Kaçınabilir misiniz?

Daha önce de söylediğim gibi… pek değil, hayır. Yayınlandıktan sonra koda geri dönerseniz, yazdığınız her projede teknik borç tahakkuk ettireceksiniz. Ancak, teknik borç türlerini parçalara ayırırsanız, projelerinizde bunu en aza indirebilir ve hatta hesaplayabilirsiniz. Borcu önceden düşünürseniz, araba kredisi veya ipotek almaktan farkı yoktur. Maliyete, faize ve faydaya bakarsınız ve sonra bunu ödeyip ödeyemeyeceğinize/istemeyeceğinize karar verirsiniz.

Yukarıda tartıştığımız bazı örneklere bir göz atalım ve maliyeti önlemenin, en aza indirmenin veya absorbe etmenin bir yolu olup olmadığını görelim.

Amaca Yönelik Teknik Borcu Düşünmek

Amaca yönelik teknik borç dediğimizde, ekibinizin üzerinde çalıştığınız projenin dili veya türü için sözde en iyi uygulamalar kapsamında olmadığını bildiğiniz kararlar aldığını kastediyoruz. Daha önce buluşmak için bir son tarihiniz olabileceğinden bahsetmiştik. Ve belki de bu son teslim tarihi zor ve hızlıdır. Belki de değiştirilme veya kaydırılma şansı %0'dır.

Bu, bir kredi almayı ve teknik borca ​​girmeyi düşünmeniz gereken zamandır.

Burada gerçekten üç seçeneğiniz var:

• Bitmemiş ve sorunlu yazılımları söndürün, ancak kod netliği ve mantığından taviz vermezsiniz
• Mükemmelleştirmeyi başaramayacağınız özellikleri çekin, ancak elinizdekileri olabildiğince iyi yazılmış olarak yayınlayın
• Her şeyin çalışmasını sağlamak için "yeterince iyi" kod ortaya koyan, ancak muhtemelen daha sonra yeniden ele alınması gerekecek geliştirme kararları alın

Buradaki üçüncü seçenek, genellikle insanların seçtiği seçenektir. Bu teknik borca ​​giriyor. Ve bunda yanlış bir şey yok. Çünkü bunu yapmaya karar verdin .

Maksatlı Borç Kredisini Geri Ödemek

Bu rotaya gitme seçiminin arkasındaki kararları kodunuzda belgelediğinizden emin olun. Ne yaptığınıza karşı ideal çözümün ne olacağına dair notlar tutun. Ve bu borç alma çözümünün nerede uygulandığını (ve biliyorsanız, projenin diğer alanlarındaki sistemleri etkilediğini) belirtmek için kaynak koduna en azından bir tür yorum eklediğinizden emin olun. Bu adımı atmazsanız, projeye ekleme yapmak (hata düzeltmeleri ve yamalarda bile, yeni özelliklerden veya genişletilmiş bir kod tabanından bahsetmiyorum bile), tam bir çözüm beklediğiniz bir patchwork çözümü bularak korkunç bir şekilde gecikebilir.

Yine, bu patchwork çözümü tamamen iyi olabilir ve size asla gerçek problemler vermez. Ancak teknik borç hala orada ve hesaba katılması gerekiyor.

Eski Kod Teknik Borcunu Düşünme

Bir başka yaygın teknik borç türü, WordPress'in şu anda çok fazla biriktiği borçtur. WordPress, PHP 5.x üzerinde çalışabilir. Ancak en yeni güncelleme, kullanıcılara en az PHP 5.6 olması gerektiğini söyleyecektir. 2019'un sonunda, WP Core PHP 7.x gerektirecektir. Ancak, gereksinimleri artırarak birçok eski kodun güncellenmesi gerekiyor. Çünkü eklentilerde, temalarda ve Core'un kendisinde hala PHP 5.x kodu var.

Yeni Blok Düzenleyiciden bahsetmiyorum bile. JavaScript ile yazılmıştır. Özellikle tepki verin. Bu PHP'ye yakın bir şey değil. Aslında, WordPress Çekirdeğinin çoğu yavaş yavaş JavaScript'e yeniden yazılıyor. Ancak tüm bu JS, PHP ile de iltifat etmeli ve iyi geçinmelidir. Yeni teknolojiyi benimsemek harikadır ve yeni sürüm oluşturma gereksinimlerinin benimsenmesi gereklidir. Ancak bunu yaparken, bir süredir var olan bu yazılımdan kaynaklanan kaçınılmaz teknik borcun faizini ödüyorsunuz.

Eski Kodun Borcunu Geri Ödemek

Bu biraz zor çünkü bunu yapmanın harika bir yolu yok. Nükleer seçeneği alabilir ve yeni dilde/çerçevede/sürümde sıfırdan tam bir yeniden yazma yapabilirsiniz (Divi 2 ve Divi 3.0 arasında, Backbone.js'den React'e geçerken ne yaptığımıza bakın). Yine de bu, borç sorununu tamamen çözmez, ancak hala eski kütüphaneyi kullananlarınız var. Bir noktada, eski kod tabanı desteğini bırakmanız gerekecek. Bu bir nevi krediyi geri ödemek gibi bir şey. Bir sonrakini çıkarmak zorunda kalana kadar.

Bu bir seçenek değilse (veya sizin için en iyi fikir), dile veya sürüme özgü özelliklere güvenmediğinizden emin olabilirsiniz. Bazı tarayıcılar yepyeni özellikleri hızlı bir şekilde desteklerken, diğerleri (Microsoft Edge/IE, öksürük öksürüğü) asla benimsemeyebileceğinden, ön uç geliştiriciler her zaman bununla uğraşmak zorundadır. Temellere bağlı kalarak projelerinizi geleceğe hazırlayabilirsiniz; bu da, yükseltme veya yeniden düzenleme sırasında ele alınması gereken değişiklik sayısını normalde olduğundan daha az yapacaktır.

Zaman İçinde Birden Fazla Geliştiriciyi Düşünmek

Bu, büyük ekiplerin zamanla küçük geliştirme ekiplerinden daha kötü bir şekilde tahakkuk etme eğiliminde olduğu bir tür teknik borçtur. Küçük olanlar bile bunun için endişelenmeli. Görüyorsunuz, her yazılım mühendisi farklı kod yazar. Çok nadiren aynı sorunu aynı kodla çözen iki geliştiriciniz olacak. Aynı işlevi yerine getirebilirler ve sonuç aynı olabilir, ancak kod yazarın sesiyle yazılacaktır (tıpkı burada yazıları kimin yazdığını anlayabileceğiniz gibi, örneğin Jason, Nathan, Donjete ve Hepsinin farklı stilleri var). Kod farklı değil.

Bunu akılda tutarak, mantığın bazen farklı sesleri de olabilir. Bir geliştiricinin düşündüğü şey tamamen açıktır, başka bir geliştirici bakacak ve kodun neden yaptığını anlamayacaktır. Orijinal yazar artık danışmak için uygun olmadığında bu sorun gerçekten sorunlu hale gelir. Bunun tahakkuk ettirdiği teknik borç felaket olabilir. Ama bununla başa çıkmanın yolları var.

Eski Geliştiricilerin Teknik Borcunu Geri Ödemek

En kolay yol, mümkün olan en iyi geliştiricileri işe almak ve onların şirketinizden ayrılmalarına asla izin vermektir. Durmadan.

Bu, zamanın %100'ünde olmayacağından, bu borcu geri ödemek düşündüğünüzden biraz daha kolay bir şekilde hafifletilebilir. Her şeyden önce, geliştirici ekibinizi kodlarını yorumlamak için eğittiğinizden emin olun. Ve bunu iyi yorumlamak için. Bir başkası tarafından uzaktan bile belirsiz görülebilecek bir karar verdiklerinde, bunu neden yaptıklarını ve işlevin nasıl çalıştığını not etmelerini sağlayın.

Ek olarak, ekibinizdeki her geliştiricinin bir stil kılavuzuna veya bir dizi standartlara bağlı kaldığından emin olun. WordPress Çekirdeği, eklentileri, temaları ve Çekirdek katkılarını satır içi tutacak bir dizi kodlama standardına sahiptir, böylece daha sonra başka birinin onunla sorun yaşamaması sağlanır. Airbnb, endüstri çapında resmi olmayan bir standart olarak benimsenen React için bir stil kılavuzuna sahiptir. Dahili stil kılavuzları ve standartları bile, geliştiricilerinizi kendi başlarına çok ileri gitmekten alıkoyuyor çünkü bu tür taahhütler, sona ermedikçe birleştirilmeyecek.

Toplama

Teknik borç çok gerçek bir sorundur. Nasıl yönetileceğini biliyorsanız, aynı zamanda çok gerçek bir kaynaktır. Teknoloji borcunu ne zaman üstleneceğinize ve bunu nasıl geri ödeyeceğinize karar verebildiğinizde, gelişiminiz mümkün olandan daha hızlı ve sorunsuz ilerleyebilir. Ve bu yükü üstlenmenin kaçınılmaz olduğu zamanlarda, size aksi takdirde olabileceğinden daha az etkili hale getirmek için uygulayabileceğiniz bazı strateji fikirleri verdiğimizi umuyoruz.

Projelerinizde ve geliştirme ekiplerinizde teknik borçla nasıl başa çıkıyorsunuz?

Makalede öne çıkan görsel Andrey Suslov/ Shutterstock.com