https://buraksenyurt.com/Burak Selim Şenyurt - Deneyimler2022-11-06T19:50:52+00:00Matematik Mühendisi Bir Bilgisayar Programcısının NotlarıBurak Selim SenyurtBlogEngine.Net Syndication Generatorhttps://buraksenyurt.com/opml.axdBurak Selim SenyurtMatematik Mühendisi Bir Bilgisayar Programcısının Notlarıtr-TRBurak Selim Şenyurt0.0000000.000000https://buraksenyurt.com/post/monolitik-uygulamalarda-teknik-borclanma-ile-mucadele-teoriMonolitik Uygulamalarda Teknik Borçlanma ile Mücadele (Teori)2021-10-23T07:00:00+00:00bsenyurt<p class="graf graf--p">İş hayatına adım attığımda tarihler 1999 yılını gösteriyordu. Bilgi İşlem Sorumlusu unvanı ile yarı zamanlı başladığım şirkette bir çağrı merkezi uygulamasının geliştirilmesinden, bilgisayarların kurulumlarından ve kullanıcı destek işlemlerinden sorumluydum. O zamanlar sahip olduğum bilgiler çok kıt ve tamamen programlama üzerindeydi. Ne katmanlı mimarilerden ne de tasarım kalıplarından bihaberdim. Hal böyle olunca yazdığım uygulama buton arkası kodlamanın ötesine geçemiyordu. Üstelik web tabanlı değil Windows tabanlı bir programdı ve dağıtımı çağrı merkezi bilgisayarlarına kopyala yapıştır usulüne göre yapılıyordu <em class="markup--em markup--p-em">(Neyse ki şirkette sadece on iki çağrı personeli vardı)</em> ancak bir sonraki işimde dengeler tamamen değişti. Bu sefer yazılım dünyasının milenyum başındaki yükselen yıldızlarından olan .Net platformu üstünde yeni yetme bir yazılımcı olarak işe başlamıştım. Bana Junior Software Developer unvanı vermişlerdi ve bu kez web tabanlı bir uygulama ile bol miktarda katman söz konusuydu. Tipik olarak katmanlı mimariye göre geliştirilmiş ve müşterisi olan bir ürün üstünde çalışan birkaç yazılımcıdan birisiydim.</p>
<p class="graf graf--p">Aradan yıllar geçti ve ben yazıyı yazdığım tarih itibariyle yedinci şirkette olduğumu fark ettim. Halen daha görev aldığım Doğuş Teknoloji’de dördüncü yılımı doldurmak üzereyim. İlginç olan şu ki hem burası hem de öncesinde altı yıla yakın çalıştığım ING Bank, ciddi anlamda dönüşüm geçiren iki kurum. Her ikisi de var olan legacy sistemlerini yenilemek veya baştan yazmak için hem kültürel hem de teknolojik altyapı değişimi geçirdiler, geçiriyorlar. Bende geliştirici olarak bu dönüşüm çalışmalarında ipin bir ucundan da olsa tutma fırsatı buluyorum. Şüphesiz ki değişim yazılım dünyasının olmazsa olmaz bir parçası. Diğer yandan son on yılda içinde yer aldığım işlerden gözlemlediğim kadarıyla monolitik yaklaşıma uygun olarak geliştirilmiş katmanlı sistemlerde var olanı yeniden yazmak da modernize etmek de hiç kolay değil. Çok planlı olunması ve iyi bir strateji ile hareket edilmesi gerektiği ortada. Her şeyi en ince ayrıntısına kadar düşünmek gerekiyor. Seçilecek mimari, bu konuda çalışacak insan gücünün sahip olması gereken yetkinlikler, revize edilecek süreçler, yük olan lisanslamalar ve alternatifleri, kullanılacak açık kaynak ürünler, nelerin <em class="markup--em markup--p-em">SaaS (Software as a Services)</em> haline geleceği vb.</p>
<p class="graf graf--p">Tüm bu gelişmelere ek olarak bir süredir şirketin iç girişim programına dahil edilen bir ürün fikri için kıymetli bir meslektaşıma destek olmaya çalışıyorum. Özellikle fizibilite safhasında yirmiden fazla firmanın önemli pozisyonlardaki çalışanları ile karşılıklı görüşme fırsatımız oldu. Konumuz ürünle alakalı olsa da benim dikkatimi çeken nokta özellikle beş yaş üstü şirketlerin neredeyse tamamında birçok uygulamanın yenilenmesinin söz konusu oluşu. İster kırk yıllık mainframe sistemler etrafında koşan uygulamalar olsun ister iki yaşında bir ürün mutlak suretle bir değişimden <em class="markup--em markup--p-em">(yenilemeden, modernizasyondan…Artık nasıl düşünürseniz)</em> bahsediliyor. Son on yıldır görev aldığım iki kurumun uygulama modernizasyonlarına tanıklık etmiş birisi olarak sektörü dinlediğimde ortaya çıkan sonuçların örtüşmesi dikkatimi monolitik sistemin katmanlı uygulamalarına çekti. Onlardan her yerde bolca bulmak mümkün.</p>
<p class="graf graf--p">Yazılımcı olmanın kaçınılmaz bir gerçeği üretim ortamından gelen problemler ile uğraşmaktır belki de. Çalışmakta olduğumuz sistemlerin giderek büyümesi, iş kurallarının zamanla karmaşıklaşması, nasıl yapılır nereye bakılır bilgisinin ayrılan iş gücü nedeniyle eksilmesi, entegrasyon noktalarının çoğalması ve daha birçok sebepten ötürü bu kaçınılmazdır. Her birimiz yazılım yaşam süresi boyunca farklı tipte mimariler üzerinde çalışırız. Örneğin 2021 yılının ilk çeyreğinde hazırladığım ve yedi yüzden fazla <a class="markup--anchor markup--p-anchor" href="https://docs.google.com/forms/d/1O_EwxGI22cADNVa2PIW5yOxGKHRECGvIp7JRWSMLw4w/edit#responses" target="_blank" rel="noopener" data-href="https://docs.google.com/forms/d/1O_EwxGI22cADNVa2PIW5yOxGKHRECGvIp7JRWSMLw4w/edit#responses">kişinin katıldığı “Teknik Borç Farkındalık Anketi” isimli çalışmanın sonuçlarına göre</a> beşimizden dördünün katmanlı mimari olarak adlandırdığımız monolitik sistemlerde görev aldığını söyleyebiliriz. Hele ki sektörde yirmi yılı deviren bir yazılım geliştirici iseniz <em class="markup--em markup--p-em">(ki yine anket sonuçlarına göre neredeyse %40ımız 10 yaşından büyük ürünlerle çalışmış)</em> böyle bir sistemle yolunuzun kesişmemiş olması pek mümkün değildir.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_01.png" alt="" /></p>
<p class="graf graf--p">Sonuçların bilimselliği bir kenara dursun katmanlı sistemlerin en büyük dertlerinden birisi kolayca modernize edilemeyişleridir. Bunun en büyük sebeplerinden birisi de kontrolsüz büyümenin ve birçok <a class="markup--anchor markup--p-anchor" href="https://buraksenyurt.com/post/AntiPatterns-Ders-Notlarc4b1m" target="_blank" rel="noopener" data-href="https://www.buraksenyurt.com/post/AntiPatterns-Ders-Notlarc4b1m"><strong class="markup--strong markup--p-strong">Anti Pattern</strong></a> ihlalinin teknik borç yükünü artırmış olmasıdır. <strong class="markup--strong markup--p-strong">Ward Cunningham</strong>’ın bu terimi programcı olmayan insanlara neden kodu refactor etmeleri gerektiğini anlatmak için metafor olarak kullanmasının üstünden çok süre geçmiş olsa da pek çok sistemin baş etmek zorunda kaldığı bir gerçektir teknik borç. Bu baş belası için bazı kaynaklarda ürkütücü <strong class="markup--strong markup--p-strong">The Silent Company Killer</strong> terimi kullanılır ve bence bu son derece isabetli bir ifade.</p>
<blockquote>
<p class="graf graf--p">Neden legacy kabul edilen bir sistemi modernize etmeye çalışıyoruz da onu sıfırdan yazmıyoruz sorusu aklınıza gelebilir. Ancak ölçekçe büyük, müşteri nezdinde fonksiyonel olarak yüksek memnuniyet sağlayan sistemlerde veya mainframe gibi kolayca kopartılamayacak bağımlılığı bulunan yapılarda Big Bang olarak da ifade edilen sistemi komple değiştirmek kurumun hareket etme kabiliyetini olumsuz yönde etkileyebilir ve hatta bir noktada işleyen operasyonun yürütülmesini engelleyebilir. </p>
<p class="graf graf--p">Bir üst seviyeye geçmeden önce<em>(örneğin yeni bir mimari modele)</em> domain olarak var olan süreçleri hem veri hem işleyiş bazında ayrıştırmak daha iyi bir yaklaşım olacaktır. Nitekim büyük resmi görmek ve sonrasında detaylara inebilmek böylesine büyük yapılarda çok zordur. Bu da bir stratejidir ve bunu gerçekleştirme noktasında var olan yüklerden kurtulmak yani teknik borcu hafifletmek önemlidir. Hatta var olanın yenisini paralelde yazmayı seçtiğimiz durumda da sistemi anlamak ve iyileştirmek için önemlidir.</p>
</blockquote>
<p class="graf graf--p">Teknik borç yazılım tarafındakiler için anlamlı bir terim <em class="markup--em markup--p-em">(bazen)</em> olmasına karşın bazen IT personeli ve daha da önemlisi iş birimi ile paydaşlar için pek önemli bir kavrammış gibi görünmez. Sonuçta ölçülebilir değerler sunmadığımız ve bunların maliyet tablosundaki etkilerini göstermediğimiz sürece paydaşlar için anlamlı olmaz. Oysaki Gartner, McKinsey, Price Waterhouse Coopers, CAST ve CISQ <em class="markup--em markup--p-em">(Consortium for Information & Software Quality)</em> gibi kurumların zaman içerisinde yaptığı çeşitli çalışma sonuçları ve raporlar durumun ne kadar ciddi olduğunu gözler önüne sermektedir. İşte konu ile ilgili dikkat çekici bazı istatistikler;</p>
<ul class="postList">
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">CISQ</strong>’ in 2020 yılı bazlı <a class="markup--anchor markup--li-anchor" href="https://www.it-cisq.org/pdf/CPSQ-2020-report.pdf" target="_blank" rel="noopener" data-href="https://www.it-cisq.org/pdf/CPSQ-2020-report.pdf">The Cost of Poor Software Quality in the US</a> raporuna göre Birleşik Devletler’ de ciddi sorunlara yol açan teknik borç düzeltme maliyeti 1.13 Trilyon dolar civarındadır.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Gartner</strong>’ a göre ciddi sorunlara yol açabilecek teknik borç düzeltme maliyeti sadece 2020 için 2.84 Trilyon dolar civarındadır ki aynı danışmanlık firmasının 2011’de yayınladığı raporda 2015 için bu borcun 1 Trilyon dolar civarında olacağı ön görülmüştür.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">NYSE</strong> borsasında tahtası olan ve devlet tarafından belirlenen bir regülasyonu hatalı uygulayan bir firma, uygulamanın eksik dağıtımı sebebiyle 45 dakika içinde 462 milyon dolar zarar etmiştir.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">McKinsey</strong>’ nin değeri 1 milyar doların üstünde olan şirketlerin CIO’ ları ile yapığı çalışma sonuçlarına göre CIO’ ların %60’ı son üç yıllık dönemde teknik borçların gözle görülür şekilde arttığını belirtmektedir.</li>
<li class="graf graf--li">Yine aynı rapora göre yeni ürünlere ayrılan bütçenin %10 ile %20 kadarı teknik borçların giderilmesi için harcanmaktadır. Üstelik teknik borçların tüm teknoloji mülkiyeti içerisindeki payının %20 ile %40 arasında değiştiği belirtilmiştir.</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.castsoftware.com/research-labs/technical-debt-estimation" target="_blank" rel="noopener" data-href="https://www.castsoftware.com/research-labs/technical-debt-estimation"><strong class="markup--strong markup--li-strong">CAST</strong></a>’in 160 farklı organizasyondan 550 milyon satır koda sahip 1400 uygulamayı inceleyen raporuna göre kod satırı başına ortalama teknik borç maliyeti tahmini 3.61 dolar seviyesindedir.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Tricentis Software Fail Watch</strong> 2017 yılında 606 ölümcül yazılım hatası raporlamış ve bunların 304 firmaya 1.7 trilyon dolar civarında zarar yol açtığı sonucuna varmıştır.</li>
</ul>
<p class="graf graf--p">Bazı rakamlar ütopik değerler gibi görünse de çalıştığım şirketlerdeki gözlemlerim bu bulguların oldukça gerçekçi olduğu hissiyatını uyandırmakta. Diğer yandan dünya çapında bilinen kod tabanının evrenimiz gibi genişlediği de söylenebilir. Yine CISQ raporlarına göre 2005’te yıllık ortalama 35 milyar satır kod üretildiği öne sürülmüştür. Bu değer 2020'de ortalama 100 milyar satır kod olarak revize edilmiştir. Rapordaki tahmin projeksiyonuna göre 2020 yılında dünya üstünde yaklaşık 1.655 trilyon satır kod olduğu öngörülmüştür. Yakın zamanda karşılaştığım Tanrı Parçacığından bozma kod dosyasındaki bir sınıfın 600 kitap sayfasına eş değer satırı olduğunu hesaplayınca bu rakamlarda gerçeklik payı olduğunu ve kayıt dışı olanlarla birlikte çok daha büyük bir havuzda yaşadığımızı söyleyebilirim.</p>
<blockquote class="graf graf--blockquote">Teknik borç yönetiminde ustalaşmış firmalar teknoloji borcunu finansal sermaye yapılarını yönetirken kullandıklarına benzer stratejik bir süreçle idare ederler.</blockquote>
<p class="graf graf--p">Her ne kadar belirtilen rakamlar oldukça karamsar bir tablo çizse de teknik borcu iyi yöneten firmaların çeşitli kazanımlar elde ettiği de ortadadır. Sadece teknik borç ödeme yönetiminin bilinçli olarak kabulü ve buna göre hareket edilmesi bile fark yaratır. İsmini vermek istemeyen bulut tabanlı bir bilişim firmasının CIO’ suna göre teknik borçla mücadele yöntemlerinde yapılan değişiklik sonrası yazılımcıların bu işler için normal mesailerinden ayırdıkları zaman %75’ten %25’e kadar düşmüştür — McKinsey. Hatta aynı rapora göre teknik borcu aktif olarak yönetebilen firmalarda mühendisler zamanlarının %50 kadar fazlasını olması gerektiği gibi iş hedeflerine harcayabilmektedir.</p>
<p class="graf graf--p">Teknik borçlanma yazılımın kalitesine de doğrudan etki eder. Hangi metrik olursa olsun belli standartların üzerinde koşan kaliteli ürünlerde bile kusurlara rastlanabilir. Bu kusurlara çevresel faktörler de eklenince ortaya korkutucu sonuçlar çıkar. 2019–2020 aralığı büyük yazılım hatalarının tarihe geçtiği yıllar olarak hafızlara kazınmıştır. Fidye programları, siber saldırılar, beklenmedik IT kesintileri ve veri sızıntıları gibi nedenler havacılıktan bankacılığa, devlet kurumlarından savunma sanayine kadar birçok sektörde zarara sebep olmuştur. Örneğin NASA’nın Boeing Startliner mekiği iki büyük yazılım sorunu yüzünden insansız görevi sırasında Uluslararası Uzay İstasyonuna kenetlenememiş ve kargosunu bırakamadığı gibi dünyaya geri dönmek zorunda kalmıştır. Bu hatalar sebebiyle yeni bir uçuş planlanmış ve bunun maliyeti dört yüz milyon doları geçmiştir. İngilizce ders kitaplarına da konu olan Britanya’nın ünlü Heathrow havalimanı, Check-In sistemindeki kusurlar yüzünden aynı gün içinde yüzden fazla uçuş planının bozulmasına şahit olmuş, yaşanan sorun ancak sonraki gün düzeltilebilmiştir. Yoğun geçen bir yaz dönemi sonrasında belki de yorgun düşen yazılım sisteminin çökmesi sonrasında British Airways’in yüzden fazla uçuşu iptal edilmiş, üç yüzden fazlası da gecikmeli olarak sefer yapmıştır. </p>
<p class="graf graf--p">Şirketler bu ve benzeri olaylar neticesinde sadece para değil itibar da kaybederler. Ne yazık ki hepsinden kötüsü yazılım sorunlarının ölümcül sonuçlara sebep verdiği gerçeğidir. Dünyanın ünlü şirketlerinden birisinin göz bebeği olup Titanik misali övülen hava taşıtı yazılımındaki hata sebebiyle başka bir uçakla çarpışmış ve bu hazin olay sonucu 346 insan yaşamını yitirmiştir. Sonuç olarak program sonlandırılmış, şirket sonradan yine kazansa da hatırı sayılır derece hisse değeri kaybetmiştir. Peki ölenler geri gelebilmiş midir?</p>
<blockquote class="graf graf--blockquote">Görüldüğü gibi üzerinde çalıştığımız ve bizzat geliştirmesine doğrudan etki ettiğimiz yazılımlar aynı zamanda bizlere farklı sorumluluklar yüklerler. Sonraki yazılımcılara temiz bir ortam bırakmak gibi sade bir mesuliyetten insan hayatını korumaya kadar uzanan önemli bir etik çizgi söz konusudur. </blockquote>
<h3 class="graf graf--h3">Tanım</h3>
<p class="graf graf--p">Raporlar ve rakamlar bu işin ciddiyetini ortaya koymaktadır ancak her şeyden önce bir tanım yapılması gerekir. Üstelik bu tanım bilişim personeli, iş sahipleri ve tüm paydaşlarca anlaşılır olmalıdır. Nitekim farkında olunması gereken bir mevzu söz konusudur. Big Commerce firmasından Shawn McCormick’e göre bir proje olgunlaştıkça çevikliği azaltan her kod teknik borçtur ve gerçek teknik borç tesadüfi değil kasıtlı olarak ortaya çıkmaktadır. Forbes’tan Brad Sousa’ya göre bir işletmenin doğru çözüm için gereken zaman ve parayı harcamak yerine mevcut kodu yeni kodlarla yükseltmeyi seçtiğinde maruz kaldığı gerçek maliyet teknik borcun ta kendisidir. Git Connected’ tan Trey Huffine’ e göre teknik borç, hızlı kazançlar elde etmek için yazılıma eklenen ve ileride düzeltilmesi için daha fazla çaba gerektiren herhangi bir koddur. Hackernoon’ dan fpgaminer kod adlı kişi ise onu şöyle yorumlamıştır; hedefe daha hızlı ulaşmak için koda kestirme yollar eklediğinizde bugün normalden daha fazlasını yapabilirsiniz ama sonra daha yüksek bir maliyet ödersiniz. Konu ile ilgili daha akademik bir tanım da mevcuttur. ScienceDirect teknik borcu şöyle ifade eder; Teknik borç kasti veya değil müşteri isteklerine veya uygulama kısıtlarına<em class="markup--em markup--p-em"> (deadline gibi)</em> öncelik veren yazılım geliştirme eylemlerinin bir sonucudur.</p>
<blockquote class="graf graf--blockquote">Ben ise teknik borcu şöyle tanımlamak isterim; Belirli sebeplerle yeni bir özelliğin geliştirilmesi ya da bir sorunun çözümü sırasında kullanılan ancak tam olarak doğru olmayan yaklaşımların çoğalmasıyla oluşan ve ivmesi sürekli yükselen faizli kredi borcudur.</blockquote>
<h3 class="graf graf--h3">Teknik Borç Türleri</h3>
<p class="graf graf--p">Teknik borcun bu bahsi geçen türlü tanımları onun farklı kategorilerde ele alınmasını da gerektirmiş ve buna göre bazı farklar ortaya konmuştur.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_02.png" alt="" /></p>
<p class="graf graf--p">Örneğin Steve McConnel 2007 yılında teknik borçları kasıtlı olarak yapılan ve yapılmayanlar şeklinde iki ana kategoriye ayrıştırmıştır. Gerçekten de bazı durumlarda oluşacak teknik borçlanma stratejik bir karar sebebiyle sineye çekilebilir. Buna karşın ilerde borcun ödenmesi gerekir. Software Engineering Institute tarafından 2014 yılında yapılan bir çalışmaya göre teknik borç birçok kategoride değerlendirilir. Mimari yaklaşımlardaki anomaliler de teknik borca sebebiyet verebilir, personelin sahip olduğu yeteneklerdeki eksiklik de teknik borca sebebiyet verebilir gibi. Bana göre bu sınıflandırmalar teknik borcun domain bazlı ayrılabilmesine ve buna göre ekiplerin kontrolüne verilmesine de olanak sağlamaktadır. </p>
<p class="graf graf--p">Çok doğal olarak hepimizin seveceği ve dikkat kesileceği çeşitlendirme Martin Fowler tarafından yapılmıştır. <a class="markup--anchor markup--p-anchor" href="https://martinfowler.com/bliki/TechnicalDebtQuadrant.html" target="_blank" rel="noopener" data-href="https://martinfowler.com/bliki/TechnicalDebtQuadrant.html">Martin’in Quadrant’ına göre</a> durum öncelikle kasıtlı veya kazara mı meydana geliyor ona bakılmalıdır. Buna göre umursamaz ve pervasız bir şekilde hareket etmekle tedbirli ve ihtiyatlı bir şekilde hareket etmek arasında farklılıklar oluşacaktır. “Tasarım için zamanımız yoktu” sözü genellikle kasten ve umursamaz olduğumuz bir durumu ifade etmek için idealdir. Bazen bilerek teknik borca girmemiz kaçınılmaz olur. Hemen çıkmamız gereken bir özellik için bu sonucun oluşacağının bilincindeysek durumu tedbirli bir borçlanma gibi yorumlayabilir ve riski göze alabiliriz. Tabii alınan riskin etkin bir şekilde yönetilmesi de gerekir.</p>
<h3 class="graf graf--h3">Sebepler</h3>
<p class="graf graf--p">Neden teknik borç oluşur sorusunun farklı cevapları vardır. Örneğin McKinsey bunları dört ana başlık altında toplamış ve aşağıdaki gibi kategorize etmiştir.</p>
<p class="graf graf--p"><strong class="markup--strong markup--p-strong">Stratejik Sorunlar</strong></p>
<ul class="postList">
<li class="graf graf--li">IT girişimlerinin şirket stratejisi üzerindeki etkilerini ölçememek.</li>
<li class="graf graf--li">Portföy yönetimindeki sorunlar sebebiyle senkronize olmayan kaynak tahsisi ve toplam maliyet tahmini yapılamaması yüzünden finansman ile yaşanan uyum sorunları.</li>
<li class="graf graf--li">Birleşme ve satın almalardan sonra teknoloji entegrasyonunun yetersiz kalması — <em class="markup--em markup--li-em">Birkaç şirketi satın alan bir firmanın kendi ürünleri ile gelen eski ürünler arasındaki iletişimde yaşayacağı her türlü teknik, kültürel zorluk olarak düşünebiliriz.</em></li>
<li class="graf graf--li">Ürünlerdeki aşırı karmaşıklık.</li>
</ul>
<p class="graf graf--p"><strong class="markup--strong markup--p-strong">Süreçsel Sorunlar</strong></p>
<ul class="postList">
<li class="graf graf--li">Proje Backlog maddelerine doğru öncelik verilememesi veya bu maddeler listesinin etkin bir şekilde kullanılmaması.</li>
<li class="graf graf--li">Geliştirme ve bakım sürecinin zayıf yönetimi.</li>
<li class="graf graf--li">Nadiren yapılan kod kalite ölçümleri.</li>
<li class="graf graf--li">Zayıf olağanüstü durum <em class="markup--em markup--li-em">(Disaster Recovery diyelim)</em> yöntemlerinin kullanılması sebebiyle IT operasyonlarındaki düzensizlik ve tutarsızlık.</li>
</ul>
<p class="graf graf--p"><strong class="markup--strong markup--p-strong">Yetenek Bazlı Sorunlar</strong></p>
<ul class="postList">
<li class="graf graf--li">Ürünlerin kullanıcılara teslimini geciktiren, kaynak riski oluşturan beceri eksiklikleri.</li>
<li class="graf graf--li">Ekip kapasitesinin nadiren teknik borcu azaltmak için tahsis edilmesi.</li>
<li class="graf graf--li">Karar vermede teknoloji borcunun göz ardı edilmesi.</li>
<li class="graf graf--li">Ekiplerin sadece kısa vadede özellik <em class="markup--em markup--li-em">(feature)</em> sağlamaya odaklanması.</li>
</ul>
<p class="graf graf--p"><strong class="markup--strong markup--p-strong">Mimari Bazlı Sorunlar</strong></p>
<ul class="postList">
<li class="graf graf--li">Uygulama sunucuları, veri tabanları, alt yapı platformlarındaki güncelleme hataları.</li>
<li class="graf graf--li">Legacy sistemlerden kalan düzeltilmemiş sorunlar.</li>
<li class="graf graf--li">Yeniden kullanılabilirliği sınırlayan zayıf arabirime sahip monolitik bloklar.</li>
<li class="graf graf--li">Özelleştirilmiş paketlere sahip esnek olmayan yazılımlar.</li>
<li class="graf graf--li">PoC <em class="markup--em markup--li-em">(Proof of Concept)</em> formatında başlanıp ürün haline getirilmiş yazılımlar ki en sevdiğimiz günahlardan birisidir.</li>
<li class="graf graf--li">Yazılım içerisine sıkıştırılmış, değiştirilmesi zor yerleşik iş kuralları. Hatta bazen yazılım kodundan çıkıp veri tabanı içinde hayat bulan iş kuralları.</li>
<li class="graf graf--li">Tutarlı bir veri modeli üzerinde anlaşamama ve düşük veri kalitesi.</li>
<li class="graf graf--li">Standard sistem entegrasyonu yaklaşımlarının doğru kullanılmaması sebebiyle çoğalan uygulamadan uygulamaya entegrasyon noktaları <em class="markup--em markup--li-em">(Point-to-Point entegrasyon noktalarının çoğalması olarak düşünülebilir ki bazıları zamanla atıl hale gelip unutulur ve hayalet bağımlılıklar oluşur)</em></li>
</ul>
<h3 class="graf graf--h3">Teknik Borç Nasıl Yönetilir?</h3>
<p class="graf graf--p">Büyük resme bakıldığında teknik borç sadece kodun kötü parçalarından ayıklanması ya da iyileştirilmesiyle alakalı değildir. Şirketin genelini ilgilendiren bir sorundur ve herkes tarafından kabul edilmelidir. Ayrıca teknik borcun rakamsal olarak ifadesi ve denk düştüğü eksi maliyetler şeffaf bir şekilde sunulmalıdır. Teknik borç, yönetim kademesinden yazılımcısına kadar herkesin bilinçli şekilde baş etmesi gereken bir sorundur. Buna göre bazı çözüm yöntemleri önerilir. Yine sıkılıkla referans olarak kullandığım McKinsey raporlarına göre bu mücadele aşağıdaki sıralama ile yapılabilir.</p>
<p class="graf graf--p">1. <strong class="markup--strong markup--p-strong">Ortak Tanım Yap:</strong> İş birimleri ve bilişim personeli liderleri teknik borcun ne anlama geldiğinin ortak tanımını yapmalıdır.</p>
<p class="graf graf--p">2. <strong class="markup--strong markup--p-strong">İşle İlgili Bir Sorun Olduğunu Kabul Et:</strong> Teknik borcun sadece teknolojik değil aynı zamanda işle ilgili olduğunu kabul edin.</p>
<p class="graf graf--p">3. <strong class="markup--strong markup--p-strong">Şeffaf Ol:</strong> Teknik borçları rakamsal olarak açıkça ifade edin.</p>
<p class="graf graf--p">4. <strong class="markup--strong markup--p-strong">Karar Verme Sürecini Resmileştir:</strong> Belli kurallar üzerinde anlaşılmış bir portföy yönetimini takip edin.</p>
<p class="graf graf--p">5. <strong class="markup--strong markup--p-strong">Kaynak Ayır:</strong> Sadece teknik borca adanmış bir görev gücü oluşturabilirsiniz.</p>
<p class="graf graf--p">6. <strong class="markup--strong markup--p-strong">Büyük Patlamaya Dikkat Et:</strong> Mega projelerde teknik borcu tutarlı, tahmin edilebilir ve stratejik yol haritasına bağlı olarak ayırın ki rekabet etme yeteneğinizi kaybetmeyin. Yani topyekün değiştirmek yerine parçalayarak mücadele edin. <em class="markup--em markup--p-em">Nitekim bir teknik borcu düzelteceğiz derken çalışan ve sahanın göz bebeği olan ürünü işlemez ve geliştirilemez hale de getirebilirsiniz.</em></p>
<p class="graf graf--p">7. <strong class="markup--strong markup--p-strong">İflas Noktalarını Belirle:</strong> Teknolojik varlıklar değerinin %50’ sini aşan borçlarda yeni bir Stack oluşturmayı düşünün. Maraton projeler için “IT Platform in a Box” şeklindeki yaklaşımları da tercih edebilirsiniz —<em class="markup--em markup--p-em"> ya da ürünler için bir raf ömrü belirleyebilirsiniz. Beş yılı geçen ürünleri yeni nesil teknolojilere dönüştürüyoruz gibi bir politika pekala belirlenebilir.</em></p>
<p class="graf graf--p">Teknik borcu yönetmek için çeşitli yöntemler olduğu aşikardır. Diğer yandan bu işin önemli bir parçası olan yazılım mühendislerinin işi pek de kolay değil. Yazılımların giderek büyümesi ve daha da karmaşıklaşması, artan ve ciddi boyutlarda zarar veren siber saldırılar, kirli bilgi dezenformasyonu sebebiyle yanlış öğrenilenler, sonu gelmeyen kullanıcı ihtiyaçları, teknoloji geliştirme hatlarının<em class="markup--em markup--p-em">(tech stack diyelim) </em>sürekli evrimleşmesi, gerekli teknik becerilerin çabucak eskimesi, hangi çevik metodoloji olursa olsun BT üzerinden kalkmayan zaman baskısı, işletme modellerinin değişen müşteri ihtiyaçları ve teknolojilere ayak uydurmak için devamlı değişmesi, veri güvenliği ve siber güvenlik ile ilgili regülasyonlar, yazılan her kod satırının potansiyel bir hata noktası olma ihtimali ve daha bir çok nedenden ötürü teknik borçla mücadele noktasında yazılım geliştirenleri bekleyen pek çok zorluk bulunmaktadır.</p>
<p class="graf graf--p">Bu arada teknik borcu yönetme noktasın teşhis koymak, acı noktalarını belirlemek, devam kararı alıp almamak için skor kartlarına başvurulabilir. Bu konu ile ilişkili olarak The Art of Service tarafından yayınlanan Technical Debt — A Complete Guide (Practical Tools for Self-Assessment) kitabını tavsiye edebilirim. Kitabın genel amacı aşağıdaki skor kartlarının çeşitli kategorideki sorulara verilen cevaplara göre puanlanarak doldurulmasıdır. </p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_03.png" alt="" /></p>
<h3 class="graf graf--h3">Mimari</h3>
<p class="graf graf--p">Ben ve benim gibi yazılımcılar açısından bakıldığında mimari seçim ve uygulanış biçiminin teknik borçlanma üzerinde etkisi olduğu söylemek kaçınılmazdır. Yazılım mimarileri oldukça geniş ve kapsamlı bir konudur ancak çok yüksek irtifadan meseleye bakıldığında işimize yarayacak bir özet üzerinde durabiliriz.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_04.png" alt="" /></p>
<p class="graf graf--p">Yazılım mimarileri temel olarak ikiye ayrılır. Monolitik sistemler ve dağıtık olanlar. Pek çoğumuzun yakinen tanıdığı katmanlı tarz monolitik tarafta yer alırken pek çoğumuzun da çalışmak istediği hatta bazen kurtarıcı olarak gördüğü mikro servis yaklaşımı dağıtık mimari kategorisinde bulunur.</p>
<blockquote class="graf graf--blockquote">Sıfırdan bir uygulama tasarlarken genellikle katmanlı modelde başlanması ve ihtiyaç olması halinde mikro servis mimarisine geçilmesi tavsiye edilir ama belki de bu bir şehir efsanesidir. Bu mit bir kenara Clean Architecture diye de güzide bir yaklaşım vardır ve mutlak suretle incelenmelidir.</blockquote>
<p class="graf graf--p">Tipik olarak katmanlı çözümler aşağıdakine benzer bir kurguya sahiptir ve pek çok kitapta bu şekilde resmedilir.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_05.png" alt="" /></p>
<p class="graf graf--p">Hatta bu yapının aktörleri zaman zaman dağıtılabilir farklı parçalara da bölünebilir. Bu daha çok ölçeklenebilirliği mümkün mertebe etkin kullanmak amacıyla yapılır. Aynen aşağıdaki şekilde görüldüğü gibi.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_06.png" alt="" /></p>
<p class="graf graf--p">Veri tabanı katmanı ve diğer kısımlar ayrı bir şekilde dağıtılabilirken uygulamanın tamamı tek parça halinde de üretim ortamına uğurlanabilir arkasından bir bardak su dökülerekten. Bizim üzerinde durduğumuz katmanlı yapı ile diğerlerini kıyasladığımızda ele alınması gereken birçok kriter de vardır. Pek çok kriter zaman içerisinde ortaya çıkan ihtiyaçlar doğrultusunda önem kazanmıştır. Netflix, Amazon, Google, Spotify ve benzeri öncülerin sürüklediği sistemler mimarilerin değişmesine neden olmakla kalmaz hata toleransından sistemin ayakta kalabilir olmasına kolay dağıtımdan esnekçe genişleyebilmeye kadar birçok faktörün de dikkate alınmasına sebep olur. Aşağıdaki tabloda söz konusu mimari yaklaşımlar arasındaki avantaj ve dezavantajları görebilirsiniz. Bir yıldız çok zayıf, beş yıldız çok güçlü anlamındadır.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_07.png" alt="" /></p>
<p class="graf graf--p">Katmanlı mimari küçük çaplı, basit uygulamalar ile web siteleri gibi çözümler için son derece idealdir. Ayrıca başlangıç bütçesi düşüktür. Bu nedenle kurumsal çapta düşünüldüğünde fikirleri hayata geçirme noktasında sıklıkla tercih edilir. Nitekim çabuk sonuç verir. Dağıtık sistemlere geçildikçe düşünülmesi, yönetilmesi gereken ayrık bileşenler çoğalır ve daha iyi bir teknik yönetim gerekir. Hata yönetimi bile dağıtık sistemler düşünüldüğünde katmanlı yapılara göre çok daha zordur. Anlamlı loglar atmanız, bunları yorumlamanız, yorumlarınıza uygun alarm sistemleri kurmanız, çakılan servisler kendine geldiğinde ne yapmalıyı planlamanız, versiyonlamaları nasıl yöneteceğinizi düşünmeniz, ağ trafiğini gözlemleyip iyileştirmeniz, kara cumalara aylar öncesinden hazır olmanız vs gerekir.</p>
<blockquote class="graf graf--blockquote">Hoş bugün kullanmakta olduğumuz izleme, performans ölçücü ve alarm mekanizmaları zaman içerisinde teknik borcun keşfi için bir belirteç de olabilir. Bir yıl öncesinde çok fazla bellek sorunu yaşamayan, sıklıkla çökmeyen, taleplere cevap verme süreleri düşük olmayan uygulamaları keşfettiğinizde “şuna bir bakalım” diyerek herhangi bir araca<em class="markup--em markup--blockquote-em">(sonarqube, cast vb)</em> bağımlı kalmadan teknik borçla mücadeleye başlayabilirsiniz.</blockquote>
<h3 class="graf graf--h3">Semptomlar</h3>
<p class="graf graf--p">Monolitik yapılar iyidir hoştur ama zaman her şeyin ilacı olduğu kadar bazen de çaresi olmayan bir virüstür. Kontrolü kaybettiğimiz noktadan itibaren teknik borç sistemin tüm damarlarına sirayet etmeye başlar. Esasında bazı semptomlar teknik borcun artmış olduğunun iyi birer göstergesidir. Bunları aşağıdaki gibi özetleyebiliriz.</p>
<ul class="postList">
<li class="graf graf--li">Loglar sorun tespitinde yetersiz kalır ve üretim ortamında sıklıkla debug yapılır.</li>
<li class="graf graf--li">Anti Pattern pratikleri çoğalır.</li>
<li class="graf graf--li">Yerleşik iş kurallarını dışarıya almak sadece zor değil neredeyse imkansız hale gelmiştir.</li>
<li class="graf graf--li">Test yazmak zordur ve hatta test yazılmaz.</li>
<li class="graf graf--li">Yazılım tek paket olarak üretime çıkar ve bu sırada kesintiler olup diğer paydaşlar bundan etkilenir.</li>
<li class="graf graf--li">Bir katmandaki hata diğerlerini de etkiler.</li>
<li class="graf graf--li">Basit bir sınıf değişikliği yeniden dağıtım gerektirir.</li>
<li class="graf graf--li">Mean Time to Recovery süreleri dakikalar mertebesinde artar.</li>
<li class="graf graf--li">Benzer hatalar sürekli olarak karşımıza gelir.</li>
</ul>
<p class="graf graf--p">Monolitik yapılar büyüyüp karmaşıklaştıkça dağıtık mimarilere nazaran sahip oldukları kolay anlaşılırlık, düşük inşa ve bakım maliyeti gibi avantajlarını kaybederler. Yukarıdaki semptomlar çok doğal olarak bir şeyler yapılmasını gerektirir. Bu noktada bazen ilk akla gelen monolitik mimariyi terk edip dağıtık sistemlerin göz bebeği olan mikro servis yaklaşımına geçmektir. </p>
<blockquote class="graf graf--blockquote">Monolitik yapılardan mikro servislere geçmeden önce teknik borcu azaltmak, maliyetleri düşürmek adına iyi bir yaklaşımdır.</blockquote>
<p class="graf graf--p">Büyük resme Legacy sistem terimi üstünden de bakmak gerekiyor. Günümüzde monolitik yapıları görünce genellikle Legacy sistemler olarak anıyoruz. Onlar eski çağdan kalmış, yeni neslin çalışmak istemediği, korkunç teknolojiler içeren ürünler! Değil mi? Adı her ne olursa olsun bu tip yazılımların kalitesini artırmanın ve daha da önemlisi ömrünü uzatmanın bilinen belli başlı yolları da mevcut <em class="markup--em markup--p-em">(Çalışan sisteme dokunma derler ya. Az biraz dokununca güzel sonuçlar da çıkabiliyor aslında.)</em> </p>
<ul class="postList">
<li class="graf graf--li">Tüm sistem detaylarını izole edecek şekilde API’lere ve Container’lara geçmek—<em class="markup--em markup--li-em"> Encapsulate</em>, </li>
<li class="graf graf--li">Sadece bug’lar ile uğraşıp bakım yapmak — <em class="markup--em markup--li-em">Repair</em>, </li>
<li class="graf graf--li">Yeni donanımlara geçerek sistemi hızlandırmak — <em class="markup--em markup--li-em">Replatform</em>, </li>
<li class="graf graf--li">İnce ayar çekmek — <em class="markup--em markup--li-em">Rebuild</em>, yeni bir teknolojik platforma adapte etmeye çalışmak — <em class="markup--em markup--li-em">Rearchitect</em>,</li>
<li class="graf graf--li">Mainframe gibi parçaları bulut servis sağlayıcılarına taşımak —<em class="markup--em markup--li-em"> Rehost</em>,</li>
<li class="graf graf--li">Çözümü Software as a Service ile değiştirmek — <em class="markup--em markup--li-em">Replace</em>, </li>
<li class="graf graf--li">Teknik borçları azaltıp olası hataların önüne geçmek — <em class="markup--em markup--li-em">Refactor </em></li>
<li class="graf graf--li">ve en nihayetinde üstteki maddelerin birçoğunu bir arada yapmaya çalışmak. </li>
</ul>
<p class="graf graf--p">Fakat bu iyi bir organizasyonu ve çözüm metodolojisini gerektirir.</p>
<h3 class="graf graf--h3">TDML (Technical Debt Management Lifecycle)</h3>
<p class="graf graf--p">Yaklaşık olarak dört yıldır çalıştığım Doğuş Teknoloji ve öncesinde görev aldığım bankada teknik borçlanma ile mücadele cephesinde savaştım, savaşıyorum. En azından üstüme düşen görevleri yapmaya çalıştığımı ifade edebilirim. Statik ve dinamik kod analiz araçları bu mücadelenin önemli birer parçasıdır ancak teknik borcun sadece kodla ilgili olmadığını düşündüğümüzde yeterli değildir. Dolayısıyla diğer konular için yönetsel seviyede destek almak bu mücadele açısından hayatidir. </p>
<blockquote class="graf graf--blockquote">Teknik borç yükü ile mücadelede başarılı olan ve bunun bir etkisi olarak kaliteli ürünler geliştiren firmaların belli karakteristik özellikleri vardır; Proje yönetimi konusunda iyilerdir, yetenek yönünden yeterli seviyede istihdamları vardır, iyi tanımlanmış geliştirme süreçlerine sahiplerdir, süre tahmini konusunda mükemmel metotlar kullanırlar, müşteri memnuniyetine önem verirler, toplam kalite yönetimi konusunda bir kültür benimserler ve kusurları önleme konusunda beceriklidirler.</blockquote>
<p class="graf graf--p">Edindiğim tecrübelere göre monolitik bir sistemde teknik borçlanma ile mücadele için aşağıdaki gibi bir yaşam döngüsünün kullanılması gerekir. Buna <strong class="markup--strong markup--p-strong">TDML<em class="markup--em markup--p-em">(Technical Debt Management Life Cycle)</em></strong> adını verebiliriz ve farklı türden sistemlere de uyarlanabilir.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_08.png" alt="" /></p>
<p class="graf graf--p">Döngüye girebilmek için ön gereksinimlerin tamamlanması gerekir. Her şeyden önce teknik borcu kabul etmek, ortak bir tanımını yapmak, yarattığı yükü hesaplayıp genel maliyetini ölçmek ve bunu şeffaf bir şekilde paylaşmak gerekir. Ön gereksinimler için aşağıdaki gibi genel bir kontrol formu kullanılabilir ve Dashboard benzeri bir arabirim ile sistem içerisinde her an görünür olması sağlanabilir. Görünürlük de bu mücadelenin olmazsa olmazlarındandır.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_09_new.png" alt="" /></p>
<p class="graf graf--p">Teknik borç yönetimi yaşam döngüsü belli periyotlarda tekrar eden bir düzenektir. Gereksinimlerin karşılanmasını takiben sırasıyla aşağıdaki adımlara göre işletilir.</p>
<ul class="postList">
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Keşfet:</strong> Keşif aşamasında var olan kodun çarpık yanları ortaya konur. Bir başka deyişle teknik borç keşfi yapılır. Bu amaçla çeşitli araçlardan yararlanılabilir. Statik Kod analiz araçlarından birisi olan SonarQube bunlardan birisidir — a<em class="markup--em markup--li-em">ncak tek değildir. Aşağıdaki tabloda diğer araçları ve genel özelliklerini görebilirsiniz</em>. Buna ilaveten IT4IT anlamında yapılması düşünülen yenilikler de keşif aşamasında değerlendirilebilir. Bu, bizim de şirket bünyesinde sıklıkla uyguladığımız bir pratiktir. Örneğin Business Layer içerisindeki fonksiyonların servis olarak dışarı çıkartılması, Session kullanımından vazgeçilip Redis’e dönülmesi, konfigürasyon değerlerinin Secret Vault üstüne alınması, karmaşıklık değeri yüksek fonksiyonların<em class="markup--em markup--li-em">(cognitive complexity)</em> hafifletilmesi, tekrarlı kod bloklarının tekilleştirilmesi, Transaction kullanımından vaz geçilmesi, bağımlılıkların Dependency Injection mekanizmaları ile dışarıya alınması, veri tabanı tarafına yayılmış iş kurallarının otomatik araçlarla kod tarafına çekilmesi vb. Bu noktada yazılımcıları dinlemek oldukça önemlidir. Onlardan toplanan fikirlerin TDML sürecine sokulması noktasında yine bir komite desteğini almakta yarar vardır.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Öncelik Ver:</strong> Araçlardan elde edilen bulgular ya da hissedilen düzensizlikler sonrası teknik borcun azaltılması için toplanan ve yapılması düşünülen fikirler çoğalacaktır. Bu nedenle bir komite eşliğinde hangilerinin öncelikli olarak yapılacağını belirlemek önemlidir. Nispeten SonarQube gibi bir aracın bulgularını takım bazında parçalamak kolay olsa da genel mimariyi etkileyen önemli değişikliklerin planlanması için bir komite desteği ve görüşü almak gerekir. Burada önceliklerin belirlenmesi, kayıt altına alınması, planlanması ve takibi gibi konularda çevik metodolojiler uygulanmalı ve bir komite eşliğinde ilerlenmelidir. Bazı firmalarda <em class="markup--em markup--li-em">(örneğin bizde)</em> bu amaçla açılmış özerk mangalar <em class="markup--em markup--li-em">(chapter)</em> görebilirsiniz.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Dağıt:</strong> Öncelik durumlarına göre sıralanan bulgular bu işle uğraşacak bireylere veya takımlara dağıtılır. Bu dağıtım sırasında TDLM Kimlik Kartında belirtilen kişi başına ne kadarlık bir eforun bu işe ayrılacağı mutlak suretle göz önüne alınmalıdır.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Refactor Yap:</strong> Dağıtımı yapılan işlerin oluşturduğu teknik borçlanma gözden geçirilir ve gerekli müdahaleler yapılarak ortadan kaldırılması için çalışılır.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Raporla:</strong> Yapılan değişikliklere ait sonuçlar raporlanır ve güncel durum analiz edilir. Bu aşama görev panosunun da güncellenmesi gereken dilimdir. Yapılan son çalışmalara istinaden borçlanmanın genel durumu şeffaf bir şekilde yenilenmeli ve tüm paydaşlara sunulmalıdır. Üstte belirttiğimiz skor kartının bu aşamada yeniden hesaplanması yerinde bir ölçüm olacaktır.</li>
<li class="graf graf--li"><strong class="markup--strong markup--li-strong">Kontrol Et:</strong> Burası geri dönülmez kontrol noktası olarak düşünülebilir. Devam etmekte olan geliştirmeler ve önceden var olan kodların yarattığı teknik borçlar törpülense de terk ediş noktası olarak belirlenen hedefin uzağında kalmış olabiliriz. Dolayısıyla döngünün bu safhasında var olan uygulamanın artık yenisi ile değiştirilmesi gerekliliği kararı verilebilir. Diğer yandan göstergeler pozitif anlamda belirlenen bir noktanın üzerindeyse köklü mimari dönüşümler için hazırlıklara başlanması düşünülebilir. Örneğin mikro servis mimari için domain bazlı parçalamalar için gerekli alt yapı hazırlıkları IT4IT işleri kapsamında bitmiş olabilir…</li>
</ul>
<p><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_10.png" alt="" /></p>
<p class="graf graf--p">Burada bahsi geçen sistem genel konsept olarak teknik borç yükü altındaki birçok uygulamaya uyarlanabilir. Hatta siz bile kendi TDLM sürecinizi tasarlayıp çeşitli araçlarla donatabilirsiniz. Önemli olan teknik borçla mücadelenin iş birimi, bilişim personeli ve paydaşlar tarafından anlaşılmış, kabul edilmiş olması ve bu çerçevede karar verilen bir strateji ile belli bir metodoloji altında icra edilmesidir. TDLM gibi bir yaşam döngüsü sürekli tekrar eden bir kültür sağlar. Bu kültürün devamlılığının sağlanması da başlı başına bir konudur.</p>
<h4 class="graf graf--h4">EK — İleriyi Görerek Modernizasyonu Yapmak</h4>
<p class="graf graf--p">Daha önceden de belirttiğim üzere bazı legacy sistemleri bir sonraki seviyeye geçirmeden önce modernize etmek ya da anlamaya çalışmak önemlidir. Bu amaçla yapılan IT4IT işlerinde genellikle neler yapılacağı maddeler halinde ortaya konur ve bir komite eşliğinde veya farklı bir strateji ile ilgililere dağıtılarak icra edilmeye çalışılır. Ancak gözden kaçan bir nokta vardır; Bir IT4IT işinin ne işe yaradığı çoğu zaman açık ve anlaşılır olsa da ürünün sonraki kademesinde hangi alanın ihtiyacını karşılayacağı ya da devam eden dönemlerdeki hangi IT4IT işini tetikleyeceği bilinmez. Bu yüzden modernizasyon için de bir yol haritası oluşturmak yararlı olabilir. Kabaca aşağıdaki haritanın çok daha büyük ve kapsamlı bir versiyonunu kullanabiliriz.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2021/Ekim/techdebt_11.png" alt="" /></p>
<p class="graf graf--p">Bu sayede yapılan işin neyi tetikleyeceği ve hedef seviyede hangi alana işaret edeceği net bir şekilde modernizasyona dahil olan tüm paydaşlar tarafından anlaşılır hale gelecektir.</p>
<p><iframe title="YouTube video player" src="https://www.youtube.com/embed/vmTVVl5rOU4" width="560" height="315" frameborder="0" allowfullscreen="allowfullscreen"></iframe></p>
<p class="graf graf--p"><strong class="markup--strong markup--p-strong"><em class="markup--em markup--p-em">Sunuma </em></strong><a class="markup--anchor markup--p-anchor" href="https://www.slideshare.net/BurakSelimSenyurt1/monolitik-uygulamalarda-teknik-borlanma-ile-mcadele-teori" target="_blank" rel="noopener" data-href="https://www.slideshare.net/BurakSelimSenyurt1/monolitik-uygulamalarda-teknik-borlanma-ile-mcadele-teori"><strong class="markup--strong markup--p-strong"><em class="markup--em markup--p-em">bu adresten</em></strong></a><strong class="markup--strong markup--p-strong"><em class="markup--em markup--p-em"> erişebilirsiniz.</em></strong></p>
<p class="graf graf--p"> </p>
<h3 class="graf graf--h3">Kaynaklar</h3>
<ul class="postList">
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.sciencedirect.com/science/article/pii/S0950584917305098#:~:text=Technical%20debt%20describes%20the%20consequences,technical%20implementation%20and%20design%20considerations." target="_blank" rel="noopener" data-href="https://www.sciencedirect.com/science/article/pii/S0950584917305098#:~:text=Technical%20debt%20describes%20the%20consequences,technical%20implementation%20and%20design%20considerations.">Technical debt and agile software development practices and processes: An industry practitioner survey</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.it-cisq.org/pdf/CPSQ-2020-report.pdf" target="_blank" rel="noopener" data-href="https://www.it-cisq.org/pdf/CPSQ-2020-report.pdf">The Cost of Poor Software Quality in the US: A 2020 Report</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.productplan.com/glossary/technical-debt/" target="_blank" rel="noopener" data-href="https://www.productplan.com/glossary/technical-debt/">What is Technical Debt</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.castsoftware.com/research-labs/technical-debt-estimation" target="_blank" rel="noopener" data-href="https://www.castsoftware.com/research-labs/technical-debt-estimation">CAST Technical Debt Estimation</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://pdf.sciencedirectassets.com/271539/1-s2.0-S0950584915X00115/1-s2.0-S0950584915001743/Nicolli_S_R_Alves_Technical_Debt_2015.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEKj%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIQCP37P1LrIXgSHRN%2FjW2tUniDkeMKXvPcgPdDC8A9DOpgIgWCoIxS4aWl4C63BcrlhF5d%2BTpHGXWt3J%2BVRdd2HyCekqgwQIwf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARAEGgwwNTkwMDM1NDY4NjUiDIrPuHMmb5VbUE4f%2FirXA3YpbV4M0ZU79eov3dUWwRzZ4qF1BG%2FJQk%2BBa1nSP1ywyNVqUPk%2BUyuNsb80mqRt7PVMMAulItYWOc9E3caZ6ql%2B12aFzMx6Xcf566bv1HW59IbHprXUI4NT%2BNE4HgZURIalOa7ak%2FK1XoY0BXjMERfgtyPLTRstJDGJXtOj5%2FVhv8bJMXSexpx7mrapqP5YmOkRq7unz9eqT4UMiiF4lq535lYMhb20N0aZosfwtZNE05vNh%2B8YOmB2Lv5%2FlXddKQqvcLGNZsWOKzH58z5TM2lBlFPA1EjQ1zy32BMruGowcMSqYd6XPH7yudKjKkuAgBsbpysBiM5J3GIsRwq%2FLUxKngsY4m7uSaEBNKV3Y0cne214tVcQTyOkzk54kVo4q11RYCLanrLUM2ZDC0yA01YByDpUyUSeSPQe99QJ%2BOzgLMO7nmYFed699sjHoJEy4duLAzKXi0gsVlDuuX3PrPdxuWm1RNujlnESHIWyvBFUHqPsQyOOk5u085wB3wlIVqWQnMs2QtqMvkf%2F7jkAzt0Ky6Dxyd3%2FWMljH489nfqP%2FfflFAx69aaHXyfTLpW3osnXbWLY0m3cvYCZhxHCElSjHJQ4UabGCcgKKcjOC6AYGAOfEjOjuzCqvMqIBjqlAYrfaRr6pmDrWMsBOD2c7iYLqjid%2FzmczBzC%2FsOxQxcMm5YgwFzHga5r9DlqIDeZFnnc%2BNTxOQ9LQti6WP%2BoMHrIAGlf3dK43sPgdTmYWLiEbCYHfdYAX%2Bn6W6JDeJAcsF3Pnw3vXM1MPzM5xBD6LQDixDZh0MzhHHQ4ACQqGw3mxZpiWMVQ2iMsJGl2n20fbiVK4r37Z1H8S%2Bu2mOy0vqk6cAnlpQ%3D%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210810T160818Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIAQ3PHCVTYQHS5BDBD%2F20210810%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=73c39a99e3a29eff3a4955674161afe67e53c09f5beca39c08437515839ebf9c&hash=af1a40704bfc93396cb420d58c61c9dd3214787d4a0ecd55e0e0d0e005d5c452&host=68042c943591013ac2b2430a89b270f6af2c76d8dfd086a07176afe7c76c2c61&pii=S0950584915001743&tid=pdf-1b40ad4e-73cb-462b-a66b-9741505b548e&sid=950738e73dd014440359d5f259870579643bgxrqb&type=client" target="_blank" rel="noopener" data-href="https://pdf.sciencedirectassets.com/271539/1-s2.0-S0950584915X00115/1-s2.0-S0950584915001743/Nicolli_S_R_Alves_Technical_Debt_2015.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEKj%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJHMEUCIQCP37P1LrIXgSHRN%2FjW2tUniDkeMKXvPcgPdDC8A9DOpgIgWCoIxS4aWl4C63BcrlhF5d%2BTpHGXWt3J%2BVRdd2HyCekqgwQIwf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARAEGgwwNTkwMDM1NDY4NjUiDIrPuHMmb5VbUE4f%2FirXA3YpbV4M0ZU79eov3dUWwRzZ4qF1BG%2FJQk%2BBa1nSP1ywyNVqUPk%2BUyuNsb80mqRt7PVMMAulItYWOc9E3caZ6ql%2B12aFzMx6Xcf566bv1HW59IbHprXUI4NT%2BNE4HgZURIalOa7ak%2FK1XoY0BXjMERfgtyPLTRstJDGJXtOj5%2FVhv8bJMXSexpx7mrapqP5YmOkRq7unz9eqT4UMiiF4lq535lYMhb20N0aZosfwtZNE05vNh%2B8YOmB2Lv5%2FlXddKQqvcLGNZsWOKzH58z5TM2lBlFPA1EjQ1zy32BMruGowcMSqYd6XPH7yudKjKkuAgBsbpysBiM5J3GIsRwq%2FLUxKngsY4m7uSaEBNKV3Y0cne214tVcQTyOkzk54kVo4q11RYCLanrLUM2ZDC0yA01YByDpUyUSeSPQe99QJ%2BOzgLMO7nmYFed699sjHoJEy4duLAzKXi0gsVlDuuX3PrPdxuWm1RNujlnESHIWyvBFUHqPsQyOOk5u085wB3wlIVqWQnMs2QtqMvkf%2F7jkAzt0Ky6Dxyd3%2FWMljH489nfqP%2FfflFAx69aaHXyfTLpW3osnXbWLY0m3cvYCZhxHCElSjHJQ4UabGCcgKKcjOC6AYGAOfEjOjuzCqvMqIBjqlAYrfaRr6pmDrWMsBOD2c7iYLqjid%2FzmczBzC%2FsOxQxcMm5YgwFzHga5r9DlqIDeZFnnc%2BNTxOQ9LQti6WP%2BoMHrIAGlf3dK43sPgdTmYWLiEbCYHfdYAX%2Bn6W6JDeJAcsF3Pnw3vXM1MPzM5xBD6LQDixDZh0MzhHHQ4ACQqGw3mxZpiWMVQ2iMsJGl2n20fbiVK4r37Z1H8S%2Bu2mOy0vqk6cAnlpQ%3D%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20210810T160818Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIAQ3PHCVTYQHS5BDBD%2F20210810%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=73c39a99e3a29eff3a4955674161afe67e53c09f5beca39c08437515839ebf9c&hash=af1a40704bfc93396cb420d58c61c9dd3214787d4a0ecd55e0e0d0e005d5c452&host=68042c943591013ac2b2430a89b270f6af2c76d8dfd086a07176afe7c76c2c61&pii=S0950584915001743&tid=pdf-1b40ad4e-73cb-462b-a66b-9741505b548e&sid=950738e73dd014440359d5f259870579643bgxrqb&type=client">Identification and Management of Technical Debt: A Systematic Mapping Study</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity" target="_blank" rel="noopener" data-href="https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/tech-debt-reclaiming-tech-equity">Tech debt: Reclaiming tech equity</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://apps.dtic.mil/sti/pdfs/AD1123234.pdf" target="_blank" rel="noopener" data-href="https://apps.dtic.mil/sti/pdfs/AD1123234.pdf">Managing Technical Debt</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://insights.sei.cmu.edu/blog/a-field-study-of-technical-debt/" target="_blank" rel="noopener" data-href="https://insights.sei.cmu.edu/blog/a-field-study-of-technical-debt/">A Field Study of Technical Debt</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.sciencedirect.com/science/article/pii/S016412122030220X" target="_blank" rel="noopener" data-href="https://www.sciencedirect.com/science/article/pii/S016412122030220X">A systematic literature review on Technical Debt prioritization: Strategies, processes, factors, and tools</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://martinfowler.com/bliki/TechnicalDebt.html" target="_blank" rel="noopener" data-href="https://martinfowler.com/bliki/TechnicalDebt.html">TechnicalDebt, Martin Fowler</a>,</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451" target="_blank" rel="noopener" data-href="https://www.amazon.com/Fundamentals-Software-Architecture-Comprehensive-Characteristics/dp/1492043451">Fundamentals of Software Architecture</a>, Richards & Ford, O’Reilly</li>
<li class="graf graf--li"><a class="markup--anchor markup--li-anchor" href="https://www.amazon.com.tr/gp/product/1867433923/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1" target="_blank" rel="noopener" data-href="https://www.amazon.com.tr/gp/product/1867433923/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1">Technical Debt A Complete Guide — 2021 Edition</a>, The Art of Service</li>
</ul>2021-10-23T07:00:00+00:00teknik borçmonolitik mimariyazılım mimarilerimodernizasyonsonarqubestatik kod analizidijital dönüşümçevik olmakyazılım geliştirme yaşamdöngüsüstratejibsenyurtYazılımcı olmanın bir gerçeği de üretim ortamından gelen problemler ile uğraşmaktır belki de. Çalışmakta olduğumuz sistemlerin giderek büyümesi, iş kurallarının zamanla karmaşıklaşması, nasıl yapılır nereye bakılır bilgisinin ayrılan iş gücü nedeniyle eksilmesi, entegrasyon noktalarının çoğalması ve daha birçok sebepten ötürü bu kaçınılmazdır. Her birimiz yazılım yaşam süresi boyunca farklı tipte mimariler üzerinde çalışırız. Örneğin 2021 yılının ilk çeyreğinde hazırladığım ve yedi yüzden fazla kişinin katıldığı “Teknik Borç Farkındalık Anketi” isimli çalışmanın sonuçlarına göre beşimizden dördünün katmanlı mimari olarak adlandırdığımız monolitik sistemlerde görev aldığını söyleyebiliriz. Hele ki sektörde yirmi yılı deviren bir yazılım geliştirici iseniz (ki yine anket sonuçlarına göre neredeyse %40ımız 10 yaşından büyük ürünlerle çalışmış) böyle bir sistemle yolunuzun kesişmemiş olması pek mümkün değildir.https://buraksenyurt.com/pingback.axdhttps://buraksenyurt.com/post.aspx?id=d3e19703-1d67-473d-a330-8813c60172462https://buraksenyurt.com/trackback.axd?id=d3e19703-1d67-473d-a330-8813c6017246https://buraksenyurt.com/post/monolitik-uygulamalarda-teknik-borclanma-ile-mucadele-teori#commenthttps://buraksenyurt.com/syndication.axd?post=d3e19703-1d67-473d-a330-8813c6017246https://buraksenyurt.com/post/sekiz-saatlik-sonsuz-donguSekiz Saatlik Sonsuz Döngü2019-12-27T07:00:00+00:00bsenyurt<p class="graf graf--p"><img style="float: right;" src="https://buraksenyurt.com/image.axd?picture=/2019/12/shellby_mini.png" alt="" />Uygulama geliştirme yaşam döngümüzün henüz otuzuncu Sprint başındaydı. İki haftalık koşu görevlerini Sprint Planning toplantısında zaten belirlemiştik. Takım olarak 13 Story Point’e sahip Production Support Buffer mecburen her sprint içerisine dahil ettiğimiz bir maliyet. 17 yaşındaki Microsoft .Net tabanlı devasa ERP<em class="markup--em markup--p-em">(Enterprise Resource Planning)</em> ürünümüz ek geliştirmeler veya önceki yıllardan kalan teknik borçlar sebebiyle bazen üretim ortamı sorunları ile karşımıza gelmekte. Büyüklüğüne nazaran Code Coverage oranının düşük olması yeni ilavelerin var olan yapılara olan etkisini anlamamızı zorlaştırıyor. Ben, Mali İşler ve Ortak Modüller<em class="markup--em markup--p-em">(Kimsenin bilmediği bir modül varsa böyle gelin)</em> ekibindeyim. Lakin ERP’nin diğer modüllerinde de benzer sorunlar olabiliyor. </p>
<blockquote class="graf graf--pullquote">Bazen kod kalite standartlarını korumak, bakım maliyetlerini düşürmek, minimum sorunla sürümleştirmek, hızla ölçekleyebilmek ve çabuk adaptasyon için geliştirilmiş yeni kültür, ilke, mimari model veya araçları gözden kaçırırız<em class="markup--em markup--pullquote-em">(farkına varmayız)</em> Bu, uzun ömürlü ürünlerin ilerleyen zamanlarda ki modernizasyonunu oldukça güçleştirebilir. Tabii her şeyi de sorgusuz sualsiz benimsememeliyiz. Değişime açık ama sakin davranmalıyız.</blockquote>
<p class="graf graf--p">O gün her zaman ki gibi Madelein yanıma oturdu ve acil çözüm bekleyen müşteri sorunlarının en önemli olanlarından birisinden bahsetmeye başladı. Tüm öncelikleri bir kenara bırakıp bu üretim problemine yoğunlaşmam ve en kısa sürede çözüme ulaştırmam gerekiyordu. Bu, bazı stand-up meeting toplantıları sonrası yaşadığımız standart bir durum. Gün geçtikçe azalan ama bir süre daha hayatımızın parçası olacak bir gerilim hatta. Her ne kadar müşterinin de dahil olduğu kurumsal çaptaki Dijital Board ile işler önceliklendirilse de, bayilerden ve ana yüklenici firmadan gelen üretim ortamı sorunları göz ardı edilemiyor.</p>
<p class="graf graf--p">Bir bayinin kısa süreliğine de olsa fatura kesememesi ya da stok sahasındaki mobil cihaz süreçlerinde meydana gelen yavaşlık nedeniyle durma noktasına gelen sevkiyat, elbette ortaya çıkan zararlar düşünülünce kriz ortamının bir mantar bulutu gibi geliştiricinin masasında patlamasına neden olmakta<em class="markup--em markup--p-em">(Ve kimse radyoaktif maddeyle kaplanmış bir geliştiricinin yakınlarında olmayı tercih etmez)</em></p>
<p class="graf graf--p">Bu nedenle müşteri isteklerinin doğru şekilde parçalanması, ortak paydaşlarda el sıkışılması, önceliklendirmelerin ve iş değerlerinin üst kademeden itibaren şeffaf bir şekilde görülebilmesi elzem derecede önemli. Bunu aşmak için modüllerdeki iş sahipleri ve scrum master’lar belirli aralıklarda müşteri ve üst yönetim ile bir araya gelerek kabul kriterleri üzerinde müzakerelerde bulunup vaziyet hakkında bilgi paylaşımında bulunuyorlar. Bu sayede her şeyin şeffaklıkla tüm birimlere akması sağlanıyor.</p>
<h3 class="graf graf--h3">Shelby’nin Monolitik Dünyası</h3>
<p class="graf graf--p">Tamamiyle monolitik karakteristikte bir yazılım olarak niteleyebileceğimiz ERP ürünü gerçek bir Legacy sistem. 2002 yılında .Net Framework’ün ilk sürümüyle birlikte geliştirilmeye başlanmış, N-Tier mimariye göre yazılmış, zaman içerisinde SOA<em class="markup--em markup--p-em">(Service Oriented Architecture)</em> evrimini gerçekleştirmiş, tek Microsoft SQL Server örneği ile çalışan, 8500 ekran, 4500 tablo, 27binden fazla Stored Procedure’den oluşan ve sahada 10bin personel tarafından kullanılan bir Asp.Net Web Forms uygulaması<em class="markup--em markup--p-em">(Şimdi pek çoğunuz “ne kadar da demode bir teknoloji kullanıyorlar” diyebilirsiniz ama unutmayın; Bu monolitik mimari yıllardır ve halen müşteri için olan görevini başarıyla yerine getiriyor)</em></p>
<p class="graf graf--p">Shelby, çevresel olarak entegre olduğu çeşitli tipte sayısız servise de sahip. Eski nesil SSIS<em class="markup--em markup--p-em">(Sql Server Integration Services)</em> paketlerinden yeni nesil REST servislerine, kurum dışı WCF uç noktalarından SOAP bazlı Web hizmetlerine kadar oldukça geniş bir dal budak yığını söz konusu. Sektörün bir gereği olarak yurt dışı firmalarla yapılan bir çok entegrasyon noktası bulunuyor. Bazılarıyla TCP gibi protokollerle iletişim kuruluyor. Regülasyonlar sebebiyle devlet kurumları ile entegre olunan noktalar da mevcut. Kocaman bir ekosistem işte :)</p>
<blockquote class="graf graf--pullquote">Monolitik bir sistem her zaman kötü çocuk değildir. Shelby sahip olduğu dezavantajlara nazaran tek bir paket olması nedeniyle üretime alma, performans ve hata izleme ile bağımlılık yönetimi gibi konularda dağıtık mimariye göre daha avantajlı durumda. </blockquote>
<blockquote class="graf graf--pullquote">Nitekim dağıtık sistemlerin yönetilmesi ve yaşatılması zordur. Öyle ki dağıtık sistemlerde üretime alma sürecinin otomatikleştirilmesi, test süreçlerine ait otomasyonun her aşamasında uygulanması(Unit Test, Functional Test, Regression Test, User Acceptance Test), yazılım ve operasyon ekiplerinin daha yakın çalışması(DevOps), her servisin çalışma zamanı performansının izlenebilmesi, takibinin yapılması, versiyonunun yönetilmesi vb bir çok şey gereklidir.</blockquote>
<p class="graf graf--p">Güncel .Net Framework sürümüne evrilmiş olsa da SonarQube ile başlanan teknik borç azaltma çalışmaları öncesi yaklaşık 2 milyon satır koda sahip olan bir üründen söz ediyoruz. Big Bang öncesi %17 kadarı tekrarlı koddan oluşuyordu <em class="markup--em markup--p-em">(Doğruyu söylemek gerekirse turuncu bankada çalışırken gördüğüm C ile yazılmış devasa muhasebe paketinden sonra Tanrı Nesneler-God Object içeren bir uygulama daha görmek şaşırtıcı değil) </em>SonarQube, çeşitli seviyelerden gelen toplam teknik borcun temizlenmesi için 786 adam günlük bir tahminlemede bulundu.</p>
<p class="graf graf--p">Teknik borçların azaltılması şarttı çünkü bir sene öncesinde başlanmış olan dönüşüm süreci kapsamında yeni araç ve kültürlere adapte olunurken Shelby’nin modernize edilmesi gerekiyordu. Terk edilemeyecek kadar önemli bir role sahip olan ürünün baştan yazılması maliyeti ciddi anlamda yüksekti. Bu nedenle hedeflerden birisi sonraki yıl onun teknik borcunun sıfırlanması olarak belirlenmişti. Bunu yapmazsak CI/CD hattındaki Quality Gate noktasına takılacağımız ve Gandalf’ın o meşhur ‘you shall not pass’ sözüyle karşılaşacağımız aşikar.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_1.png" alt="" /></p>
<p class="graf graf--p"><em>İşin başında ve sonrasında,</em></p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_2.png" alt="" /></p>
<blockquote class="graf graf--pullquote"><a class="markup--anchor markup--pullquote-anchor" href="https://www.thoughtworks.com/" target="_blank" rel="noopener" data-href="https://www.thoughtworks.com/">ThoughtWorks</a> firmasının zamanında verdiği danışmanlık sonrası sunduğu 171 sayfalık rapor, dev monolitik ERP uygulamasının mikro servis dönüşümüne tabii olmasının zorunlu olduğunu belirtmişti. Bunun için bir çok <a class="markup--anchor markup--pullquote-anchor" href="https://medium.com/@burakselyum/y%C4%B1llar-ge%C3%A7sede-de%C4%9Fi%C5%9Fmeyen-%C5%9Feyler-var-121ddf9c0476" target="_blank" data-href="https://medium.com/@burakselyum/y%C4%B1llar-ge%C3%A7sede-de%C4%9Fi%C5%9Fmeyen-%C5%9Feyler-var-121ddf9c0476">Anti-Pattern</a>’i bünyesinde barındıran ürünün öncelikle teknik borçlarından arındırılması önemli.</blockquote>
<p class="graf graf--p">SonarQube’nin pek çok çıktısı benzer kural ihlallerini verdiğinden genç arkadaşlarımızdan oluşan bir ekip<em class="markup--em markup--p-em">(deneyimli yazılımcıların yanına eklenen stajyerlerden oluşan bir grup parlak beyin)</em> Roslyn ile kokan kısımları hızlıca bertaraf etti. İşin başında teknik borcun farkında olup ürünleşme yolundaki engelleri de bilen ve CEO’ya doğrudan raporlama yapan yazılım grup müdürü dahi vardı. Bizzat kodlamaya katıldığını ve teknik borcun temizlenmesi için elinden geleni yaptığını gözlerimle gördüm. Kısa sürede teknik borcun akıllı kod parçaları ile 133 güne kadar indiği görülmüştü. Asıl sorun Complexity değerleri yüksek olan God Object damgalı sınıfların nasıl ayıklanacağıydı. İşte bu noktada daha önceden öğrenip de ne zaman kullanırız dediğimiz bazı kavramlar değer kazanıyor<em class="markup--em markup--p-em"> (Çok fazla if bloğu veya switch koşulu barındıran ve bu nedenle Complexity değeri yüksek çıkan bir fonksiyonda hangi tasarım kalıbını kullanarak çözüm üretirsiniz?)</em></p>
<blockquote class="graf graf--pullquote">Burası konfor alanınız dışına çıkmanızı gerektiren, iletişimin ön plana çıktığı, mücadelesi yüksek bir yer. Bu bence iyi bir şey. Çünkü daha fazlasını kaldırabileceğinizi görüyorsunuz.</blockquote>
<h3 class="graf graf--h3">Dönüşmeye Çalışmak ve Sıkıntılar <em class="markup--em markup--h3-em">(Dijital Dönüşüm)</em></h3>
<p class="graf graf--p">Çeşitli ürün gruplarından farklı teknolojilerle geliştirilmiş bir çok sistemin bir arada yer aldığı kaotikleşmiş, bakım maliyetlerinin yüksek olduğu, sirkülasyon nedeniyle bilgi kaybının yaşandığı, basit bir kod düzeltmesinin<em class="markup--em markup--p-em">(hotfix gibi)</em> çıkılması için dahi rutin geçiş gününün beklendiği bir ortam söz konusuydu. ERP bir yana yeni nesil ürünler ile de haşır neşir olunuyor, kaçınılmaz modernizasyon çalışmaları pek çok ekipçe planlamalara dahil ediliyordu. </p>
<p class="graf graf--p">Kabaca bir yanda yeni nesil savaş uçağının geliştirilmesi, diğer yanda kırk yıllık tankların modernize edilmesi öteki tarafta amfibik yetenekleri ile diğer unsurları taşıyacak uçak gemisinin yapımı noktasında çalışan bir çok insan olduğunu hayal edin. Akıllı ve dikkatlice hareket edilmediği takdirde 135mm tank topu taşıyan ve uçacağına kesin gözüyle bakılan bir mühendislik harikası icat etmeniz içten bile değil.</p>
<blockquote class="graf graf--pullquote">Uzun yıllarını şirket bünyesinde geçirirken pek çok konuda bilgi sahibi olan bir geliştirici, özellikle o şirket kültürünün şartları düşünüldüğünde değerlidir. Bu tip çalışanların kaybı ister istemez bazı kritik müdahale bilgilerinin de uçmasına sebebiyet verebilir. <br /><br />Çalışanlar arası bilgi transferinin daha iyi yapılabileceği çevik iletişim teknikleri ve farklı modüllerdeki kişilerin çapraz yetkinlikler kazanabileceği Tribe usülü yapılar bu kayıplara belki çözüm olabilir. <br /><br />Yine de işin can alıcı kısmı insanların buna ne kadar istekli olduğuyla da alakalıdır. </blockquote>
<p class="graf graf--p">Bu bağlamda çevik metodolojilere adapte olunup Scrum ile yürünmesine, DevOps kültürünün benimsenmesine, ürün taşıma sisteminin yani CI/CD<em class="markup--em markup--p-em">(Continuous Integration/Continuous Delivery-Deployment)</em> hattının kurgulanıp TFS yerine git bazlı Azure DevOps platformuna geçilmesine karar verildi. Feature bazlı geliştirmeyi desteklemek adına Git Flow stratejisi tercih edildi. Artık develop isimli branch tabanlı olarak açılan Feature setleri üzerinde yapılan geliştirmelerin test sonuçlarından gelen bilgilere göre tekrar develop hattına, oradan master’a merge edilmesi söz konusu. Hatta kod yamaları için de Git Flow stratejisi tercih ediliyor. Üretim ortamında aldığımız bir hata için rutin geçiş gününü beklememiz şart değil. Acil geçiş mi? Hiç sorun değil!</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_3.png" alt="" /></p>
<p class="graf graf--p"><em>git extension tarafından bir görüntü</em></p>
<p class="graf graf--p">Her feature, Scrum Board üzerinde açılmış bir User Story veya Work Item ile ilişkili. Derlenmesi neredeyse bir saati bulan<em class="markup--em markup--p-em">(şimdilik)</em> ERP her öğle vakti teste, iki haftada bir her pazartesi dondurularak<em class="markup--em markup--p-em">(freeze) </em>pre-prod ortamına ve o haftanın çarşamba gecesi üretim ortamına çıkıyor<em class="markup--em markup--p-em">(Şu vakitler haftada bir üretim ortamına çıkılması da gündemde)</em> Benim için heyecan uyandıran tüm bu otomatikleştirilmiş etkileşim Azure DevOps üzerinden yönetiliyor. Hedef bu periyotların dışına çıkıp istenildiği zaman üretim ortamına özellik eklenebilmesi. Lakin bunun için biraz daha yolumuz var.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_4.png" alt="" /></p>
<p class="graf graf--p"><em class="markup--em markup--p-em">Araya renk katacak bir ekran görüntüsü de koyalım. Fotoğrafta buradaki belki de en renkli takımlardan olan </em><a class="markup--anchor markup--p-anchor" href="https://medium.com/ltunes" target="_blank" data-href="https://medium.com/ltunes"><em class="markup--em markup--p-em">lTunes klanı</em></a><em class="markup--em markup--p-em">nın board’u yer alıyor. Bu renkli oluşumda onları motive eden yöneticileri </em><a class="markup--user markup--p-user" href="https://medium.com/u/89dabd262e97" target="_blank" data-href="https://medium.com/u/89dabd262e97" data-anchor-type="2" data-user-id="89dabd262e97" data-action-value="89dabd262e97" data-action="show-user-card" data-action-type="hover"><em class="markup--em markup--p-em">Ismail KIRTILLI</em></a><em class="markup--em markup--p-em"> nın rolü çok büyük(Şekerpınar’daki bu board hiç bozulmadan Maslak’taki yeni ofise de taşındı)</em></p>
<p class="graf graf--p">Her ne kadar süreç otomatik hale getirilmiş olsa da üretim geçişleri çoğunlukla CAB<em class="markup--em markup--p-em">(change advisory board)</em> süreci üzerinden ilerletiliyor. Acil geçiş ihtiyaçları mutlaka direktör onayından geçiriliyor. Geçişin etkisi, kritikliği ve geri alma planları sürece dahil edilmeye çalışılıp sorun olduğunda bir önceki doğrulanmış versiyona dönebilmek için ne gerekirse yapılıyor.</p>
<p class="graf graf--p">Tüm bu çetrefilli işlerin yanında şirketin kültür dönüşümünün sancıları da olmadı değil. Bizi en çok zor anlayan her zaman olduğu gibi müşteri tarafıydı. ERP, onların göbekten bağlı olduğu bir sistemdi ve şimdi isteklerini sprint’ler başlamadan önce ürün sahipliği rolünü üstlenerek ilk kez temas ettikleri yazılım ekipleri ile birlikte belirlemeye çalışmak başlarda onlara da zor gelmişti. Binalar arası bir otoban olmasıydı belki de bizi birbirimizden uzaklaştıran ama sonunda alıştılar…</p>
<blockquote class="graf graf--pullquote">Aslında biz yazılım ekipleri çoğunlukla SCRUM, KANBAN gibi metodolojiler ile uğraşıyoruz. Ancak üst yönetim kademisine baktığımızda benzer stratejilerin dijital board gibi terimlerle uygulandığını da görmekteyiz. <a class="markup--anchor markup--pullquote-anchor" href="https://www.scaledagileframework.com/" target="_blank" rel="noopener" data-href="https://www.scaledagileframework.com/">SAFE</a><em class="markup--em markup--pullquote-em">(Scaled Agile Framework)</em> aslında tam da bu kademenin uygulayacağı türden bir pratik.</blockquote>
<h3 class="graf graf--h3">Yeni Nesil Ürünler ve Gelecek Vizyonu</h3>
<p class="graf graf--p">İlk başladığım zamanlarda bu yeni nesil ürünlere biraz temkinli yaklaştığımı ifade etmek isterim. Henüz deneysel sürümlerde olan platformların ürünleştirilip müşteriye sunulmasına her zaman karşıyım. Deneyimlemek daima tavsiye ettiğim heyecanlı bir çalışma ama müşterinin bakış açısı çok daha farklı oluyor. Onlar sorunsuz ürünlere yeni isteklerini ekletmek istiyorlar.</p>
<blockquote class="graf graf--pullquote graf--startsWithDoubleQuote">“Ayıkla pirincin taşını” dememek yerine gerçekten emin olup ürünleştirmek bu tip kurumsal firmalar için çok daha iyi. Sonuçta Start-Up kültüründen oldukça farklı dinamikler söz konusu. Bu nedenle hype teknolojileri ürünleştirmeden önce belki de <a class="markup--anchor markup--pullquote-anchor" href="https://www.thoughtworks.com/radar" target="_blank" rel="noopener" data-href="https://www.thoughtworks.com/radar">Technology Radar</a> gibi bir kaynağa bakarak ilerlemekte yarar var. <br /><br />Neler geliyor, kimi mercek altına alalım, ne için hazırlık yapalım, hangisine adapte olalım ve benzeri soruların cevapları stratejik olarak önemli. Pek tabii yazılımcıları da bu noktada teşvik etmek, cesaretlendirmek ve hata yapmaktan korkmamalarını sağlamak lazım. Elbette hata yapma toleransının kabul edilebilir sınırlarını da iyi belirlemek gerekiyor.</blockquote>
<p class="graf graf--pullquote graf--startsWithDoubleQuote"><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_5.png" alt="" /></p>
<p class="graf graf--p">Yeni nesil ürünler çok daha şanslı. Microsoft’un açık kaynak ve platform bağımsız .Net Core tabanlı Web API servisleri ile konuşan Vue/Angular tabanlı önyüz sistemlerinden oluşan bu çözümlerde deneyselliğe de izin veriliyor. </p>
<blockquote class="graf graf--pullquote">Yazılımcıların hata yapmalarına müsaade etmek gelişimi destekleyen en önemli unsurdur. Bu hatalardan ders çıkartıldığı müddetçe.</blockquote>
<p class="graf graf--p">Javascript yerine daha çok Typescript tercih ediliyor, <a class="markup--anchor markup--p-anchor" href="https://webpack.js.org/" target="_blank" rel="noopener" data-href="https://webpack.js.org/">webpack</a> gibi modern paketleyiciler, Node.js gibi sunucular kullanılıyor. Tamamen Dockerize edilerek ölçeklenebilirliği kolaylaşan uygulamalar, Azure üzerindeki CI/CD <em class="markup--em markup--p-em">(Continuous Integration/Delivery-Deployment)</em> hattında Test standartlarına uyulmaya çalışılarak yaşıyor. Yaygınlaştırılmaya başlanan Selenium entegrasyonları ile fonksiyonelliklerin davranış odaklı test senaryoları üzerinden kontrolü yapılıyor. Günün herhangi bir anında kolayca sürüm çıkılması ve container çoklaması ile performans iyileştirilmesi mümkün.</p>
<p class="graf graf--p"><a class="markup--anchor markup--p-anchor" href="https://buraksenyurt.com/post/Peki-ya-Kong-Kim" target="_blank" rel="noopener" data-href="https://www.buraksenyurt.com/post/Peki-ya-Kong-Kim">KONG</a> arkasında yönetilen bu ürünler çoğunlukla kendi veritabanları ile çalışırken pek çoğunda PostgreSQL gibi farklı alternatifler de değerlendiriliyor<em class="markup--em markup--p-em">(Hatta Shelby’nin veritabanının domain bazlı olarak parçalanmasından önce PostgreSQL’e geçişi ile ilgili deneysel çalışmalar yapılmakta. Üzgünüm Microsoft ama topyekün bakıldığında lisanslama maliyetlerin çok pahalıya gelebiliyor)</em> Yeni nesil ürünler kendi Bounded Context’leri içinde konumlandırıldıklarından mikro servis yapısına daha uygunlar. Henüz mezun olmuş ya da birkaç yıllık iş tecrübesi bulunan geliştiricilerin aşina olduğu ve kolayca adapte olabileceği ortamlar.</p>
<blockquote class="graf graf--pullquote">Son zamanlarda geniş bir stajyer programı uygulanıyor. Özellikle uzun dönem stajyer arkadaşlar doğrudan okyanusa bırakılıyor ve aktif olarak müşteri isteklerinin karşılanması ile ilgili görevlerde çalışıyor. <br /><br />İnsan Kaynakları ekibinin üniversitelere bizzat giderek iyi bir eleme programı uyguladığına inanmaya başladım gördüklerimden sonra. Şirket, çekirdekten yetiştirmenin meyvelerini günden güne alıyor. </blockquote>
<h3 class="graf graf--h3">Her Şeyin Farkında Olmalıyız <em class="markup--em markup--h3-em">(İzleme, Erken Tedbir ve Otomatikleştirme)</em></h3>
<p class="graf graf--p">İster onyedi yaşındaki ERP ürünü olsun ister yeni doğmuş, emekleyen, yürümeye henüz başlamış yeni nesil ürünler, izleme<em class="markup--em markup--p-em">(monitoring)</em> her şeydir.</p>
<p class="graf graf--p">Her ne kadar erken uyarı sistemlerini tam olarak robotlaştıramasak da çalışma zamanında oluşan sıkışmaları görmek, hataları koda girmeden yakalayabilmek adına çeşitli araçlardan yararlanıyoruz. Shelby’nin dünyasını genellikle Riverbed üzerinden izliyoruz<em class="markup--em markup--p-em">(Open APM ve HP Diagnostics kullanan ekipler de var)</em> Yavaşlayan bir ekran varsa, ön yüz sayfa taleplerinden Data Access Layer metotlarına ve arka plandaki SQL çağrılarına giderek sorunu tespit etmemiz ve çözmemiz kolaylaşıyor. Yavaşlamaya başlayanlar genellikle yoğun iş kuralı içeren stored procedure’ler veya indeksleri bozulan tablolar oluyor<em class="markup--em markup--p-em">(Veritabanı ekibiyle yapılan koordineli çalışma ile sorunlar bertaraf edilebiliyor ama kalıcı çözümler için bazı bazı kaynak sıkıntısı da yaşanıyor)</em></p>
<blockquote class="graf graf--pullquote">Rutin olarak yapılan işlerden birisi de sistemin yavaşladığı noktaları Riverbed veya muadili bir araç üzerinden yakalayıp nasıl çözebiliriz sorusuna cevap bulmaya çalışmak. Böylece uygulamanın gizli saklı tüm sırlarını görüyor, MSMQ yerine Apache Kafka veya RabbitMQ’ya geçmeliyiz gibi yorumlarda bulunabiliyoruz.</blockquote>
<p><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_6.png" alt="" /></p>
<p><em>RiverBed ürününden bir ekran görüntüsü. Temsili.</em></p>
<p class="graf graf--p">Vakit ve belki de yeterli kaynak olsa bu ve benzer sorunları problem olarak sınıflayıp <a class="markup--anchor markup--p-anchor" href="https://buraksenyurt.com/post/itil-in-farkina-vardim" target="_blank" rel="noopener" data-href="https://www.buraksenyurt.com/post/itil-in-farkina-vardim">ITIL</a><em class="markup--em markup--p-em">(Information Technology Infrastructure Library)</em> felsefesinde geçen ilkelere göre kalıcı olarak çözmek çok da güzel olur. </p>
<p class="graf graf--p">Yeni nesil ürünlerin Elasticsearch tarafına atılan sayısız log verisini Kibana üstünden takip ediyoruz. Şu meşhur ELK üçlemesini ele aldığımızı ifade edebilirim. Bu log gerçekten çok büyük önem arz ediyor. Üretim ortamına ait sıkıntılı durumlarda kayıtlardaki izlere bakarak yazılıma müdahale bile etmeden çözümler üretebiliyoruz.</p>
<p class="graf graf--p"><img src="https://buraksenyurt.com/image.axd?picture=/2019/12/last_7.png" alt="" /></p>
<p class="graf graf--p"><em>ElasticSearch içeriği daha güzel bir şekilde izlediğimiz Kibana'dan bir görüntü</em></p>
<p class="graf graf--p">Yeni şeyler ekledikçe ürünlerin kalitesini korumamız da lazım. Bunun için <a class="markup--anchor markup--p-anchor" href="https://www.sonarqube.org/" target="_blank" rel="noopener" data-href="https://www.sonarqube.org/">SonarQube</a>’ye, güvenlik noktasındaki açıkların tespiti için <a class="markup--anchor markup--p-anchor" href="https://www.microfocus.com/en-us/products/static-code-analysis-sast/overview" target="_blank" rel="noopener" data-href="https://www.joinfortify.com/">Fortify</a>’a başvuruyor, <a class="markup--anchor markup--p-anchor" href="https://www.owasp.org/index.php/Main_Page" target="_blank" rel="noopener" data-href="https://www.owasp.org/index.php/Main_Page">OWASP</a><em class="markup--em markup--p-em">(Open Web Application Security Project)</em> gibi standartlara bağlı kalmaya çalışıyoruz. </p>
<p class="graf graf--p">Yeni nesil ürünlerdeki en yakın dostumuz ise Chrome’un F12 tuşu. Ön yüzün arka taraftaki REST servislerine hangi tip çağrı ve payload bilgisi ile eriştiğini görmek, problem yaşanan durumlar için ilgili senaryoları local geliştirme ortamında kolayca tatbik edip çözüm bulmamızı kolaylaştırıyor. Senaryoları gerçekleştirirken ağırlıklı olarak Postman ve SOAP UI gibi araçlardan yararlanıyoruz. </p>
<blockquote class="graf graf--pullquote">REST Api tipindeki servisler her ne kadar popüler olarak kullanılsa da bazı ürünlerde yeni nesil gRPC protokollü versiyonları kullanmak ve hatta Event-Driven yaklaşımlara geçmek çok daha iyi olabilir. </blockquote>
<p class="graf graf--p">Bazı işleri otomatik hale getirebiliyoruz. Kullanıcıların sıklıkla tekrarladığı aynı şeyleri RPA<em class="markup--em markup--p-em">(Robotic Process Automation)</em> süreçleri ile kontrol altına alıyoruz. Bu da şirket bünyesinde yaygınlaştırılmaya çalışan bir alan. Sonuçta önemli bir zaman ve maliyet kazancı olacağı ortada.</p>
<h3 class="graf graf--h3">Vizyon</h3>
<p class="graf graf--p">Kurumsal boyuttaki uygulamaların yenilenmek üzere tekrardan masaya yatırılması sıklıkla gündeme gelir. Sadece yeni isteklerin karşılanması değil baş ağrılarının giderilmesi ve modern çağa uymak için bu gereklidir. Bu nedenle somut ve cesaret isteyen adımlar atılmalıdır. Bu kararlılığı bir veya iki kişinin ya da bir takımın göstermesi yetmez. Konunun müşteri ile tartışılabilecek ve sayısal veriler ile desteklenebilecek şekilde en üst yönetim kadrosu tarafından da benimsenmiş olması beklenir. İnsiyatif alma isteği uyandıracak iç motivasyon unsurları önemlidir. Ancak hepsi bir yana bir teknoloji vizyonunun olması şarttır. Hangi durumdayız, nereye gitmek istiyoruz, bu yolda ilerlemek için hangi teknolojileri mercek altına almalıyız, kısa vadede hangi kararları uygulamalı uzun vadeye ne şekilde yaymalıyız…</p>
<blockquote class="graf graf--pullquote">Şahsen bulunduğum mavi teknoloji firmasının gerek bir önceki gerek şu anki yazılım grup müdürleri bir eylem planı oluşturmak, radikal kararlar almak ve korkmadan bunları sahiplenmek konusunda oldukça cesaretliler. Karar verici mecradakilerin sahip olduğu vizyon ile değişimi desteklemeleri önemli bir mesele.</blockquote>
<p class="graf graf--p">Geçtiğimiz yaz ayında yapılan bir toplantıda Shelby’nin modernizasyonu kapsamında aşağıdaki maddelerdekine benzer işlerin planlandığını ifade edebilirim.</p>
<ul class="postList">
<li class="graf graf--li">Web Site’ların ilk etapta Web Application’a çevrilmesi ve ilerleyen dönemlerde Blazor çatısına taşınması<em class="markup--em markup--li-em">(Sıcak bir noktada)</em></li>
<li class="graf graf--li">En kısa sürede DevOps ekibinin hazırız dediği Blue/Green dağıtım stratejisine geçilmesi.</li>
<li class="graf graf--li">MSSQL veritabanının PostgreSQL dönüşümüne başlanması. Kısa vadede yoğun iş kuralları içeren SP’lerin EF tarafında karşılıklarının oluşturulma maliyetlerinin çıkartılması.</li>
<li class="graf graf--li">Orta vadede bir ORM<em class="markup--em markup--li-em">(Object Relational Mapping)</em> kullanımına geçilmesi.</li>
<li class="graf graf--li">Teknik borç hedeflerinin yerine getirilmesi hususunda devam eden Fortify, Sonarqube, Testinium çalışmalarının tamamlanması <em class="markup--em markup--li-em">(Testinium üzerinde modül bazlı olarak given-when-then senaryoları yazılmaya başlandı)</em></li>
<li class="graf graf--li">Platformda .Net Framework 4.8 versiyonuna geçilmesi ve kod içerisinde C# 8.0 destekli yeni kalite standartlarının adaptasyonu<em class="markup--em markup--li-em">(Yazıyı tamamladığım tarih itibariyle bitmişti)</em></li>
<li class="graf graf--li">N-Tier yapının 3-Tier formuna indirgenmesi.</li>
<li class="graf graf--li">Performans ölçümlemede OpenAPM ürününe geçilmesi için gerekli çalışmalarının yapılması<em class="markup--em markup--li-em">(ki geçildi)</em></li>
<li class="graf graf--li">Servis bağımlılıkları sebebiyle duran WS-* transaction yapılarının terk edilerek farklı bir stratejinin kullanılmasına başlanması.</li>
</ul>
<p class="graf graf--p">Buradaki bazı kararları değil almak düşünmenin bile çok zor olduğu kurumsal dünyalar olduğu aşikar.</p>
<h3 class="graf graf--h3">Sonuç</h3>
<p class="graf graf--p">Şüphesiz ki pek çok büyük oyuncunun dönüşmeye çalıştığı/dönüştürdüğü platformlar ile haşır neşir olduğumuz bir zaman dilimindeyiz. Yirmi yıl önceki dönüşümler tekrarlanıyor ve ileride de tekrarlanacak. Hatta daha kısa periyotlarla değişime adapte kalmamız gerekecek. Eğer şirketiniz aşağıdakileri yapıyorsa ciddi anlamda değişimi düşünmek gerekebilir.</p>
<ul class="postList">
<li class="graf graf--li">Programa eklenen ve müşteri testi yapılmış yeni bir özellik için üretime çıkış gününü bekliyoruz.</li>
<li class="graf graf--li">Geliştirdiğimiz ve üretime aldığımız özelliklerin müşteri için oluşturduğu katma değeri bilmiyor/ölçümleyemiyoruz.</li>
<li class="graf graf--li">Az zamanımız olduğu için bazı testleri atlamak zorunda kalıyoruz.</li>
<li class="graf graf--li">Üretim ortamında oluşan bir sorunu çözmek için kullandığımız tekniğe onu düzeltmek için tekrar dönme fırsatı bulamıyoruz.</li>
<li class="graf graf--li">Temel kod metriklerini aşan devasa sınıflar ve veritabanı nesneleri üzerinde hata ayıklama işlemleri yapıyoruz.</li>
<li class="graf graf--li">Sahip olduğumuz ürünün ne kadar büyük bir teknik borcu olduğunu bilmiyoruz.</li>
</ul>
<p class="graf graf--p">Bu dünyada birbirinden farklı eski-yeni bir çok teknolojiyi bir arada görüyoruz. Yeni nesil araçlar sayesinde önceden önlemlerimizi almak, teknik borçlanma gibi konuları bertaraf etmek, her noktasını test ettiğimizden emin olduğumuz ürünleri sürümlemek artık çok daha kolay. Hazırlıklarımızı buna göre yapmalı ve kendimizi sürekli geliştirmeliyiz.</p>
<p class="graf graf--p">Yazıda bahsettiğim ne kadar şey varsa sadece bulunduğum ERP uygulaması ve çevresindeki gelişmelerden ibaret. Robotik süreç otomasyonu<em class="markup--em markup--p-em">(RPA-Robotic Process Automation)</em>, yapay zeka, makine öğrenimi, IoT<em class="markup--em markup--p-em">(Eşyanın Interneti)</em>, finansman, sigorta, filo, raporlama vb işlerle uğraşan daha pek çok ekip var ve hepsi bu büyük ekosistemin bir parçası olarak gelişimini sürdürüyor.</p>
<h3 class="graf graf--h3">Bahsedilen Terimler</h3>
<p class="graf graf--p">Yazı boyunca aşağıdaki listede yer alan terimlerden bahsettim. Eminim ki bir çoğuna aşinasınız ama çoğunu da bilmiyorsunuz. Bildiklerinizi de iyi bilip bilmediğiniz konusunda tereddütleriniz var. Bu yüzden bilmedikleriniz dahil var olanları da araştırıp pekiştirmenizi, üzerlerine eklenecek yeni daha neler olduğunu sürekli araştırmaya devam ederek canlı kalmanızı tavsiye ederim. Benim sekiz saatlik sonsuz döngüm neredeyse her gün bu şekilde işliyor. Zamansal paradox yaratarak oturduğum yerde kara delik açan bu cümle ile yazıma son veriyorum. Hepinize mutlu günler dilerim.</p>
<p class="graf graf--p">#agile #scrum #sprint #storyPoint #safe #workItem #dotNet #dotNetCore #nodeJs #typescript #vue #angular #erp #monolithic #legacySystem #nTier #SOA #SOAP #REST #WCF #sonarQube #codeCoverage #technichalDepth #qualityAssurance #mssqlServer #postgreSql #gitFlow #vsts #tfs #azureDevOps #branch #fortify #owasp #roslyn #CI/CD #continuousIntegration #continuousDelivery #continuousDeployment #dockerize #container #microService #kong #riverBed #ITIL #CAB #antiPattern #godObject #boundedContext #dataAccessLayer #chromeDevTools #thoughtWorks #microService #hypeTech #techRadar #SSIS #IoT #yapayZeka #robotik #postman #soapUI #rpa</p>2019-12-27T07:00:00+00:00teknolojiagilescurmsprintstoryPointsafeworkitemstoredotnetdotnetcorenodejstypescriptvueangularerpmonolithiclegacysystemnTiersoasoaprestwcfsonarqubecodecoveragetechnicalDepthquality assurancemssql-serverpostgresqlgitflowvsts 2008tfsazuredevopsbranchfortifyowasproslynci/cdcontinuous integrationcontinuous deliverycontinuous deploymentdockerizecontainermicroservicekongriverbeditilcabanti patterngodObjectboundedContextdataAccessLayerchrome developer toolsthoughtworkshype techtechRadarssisIoTyapayzekarobotikpostmansoapuirpabsenyurtUygulama geliştirme yaşam döngümüzün otuzuncu sprintinin ilk günlerinden birisiydi. İki haftalık koşu görevlerini Sprint Planning toplantısında zaten belirlemiştik. Takım olarak 13 Story Point’e sahip Production Support Buffer mecburen her sprint içerisine dahil ettiğimiz bir maliyet. 17 yaşındaki Microsoft .Net tabanlı devasa ERP(Enterprise Resource Planning) ürünümüz ek geliştirmeler veya önceki yıllardan kalan teknik borçlar sebebiyle bazen üretim ortamı sorunları ile karşımıza gelmekte. Büyüklüğüne nazaran Code Coverage oranının düşük olması yeni ilavelerin var olan yapılara olan etkisini anlamamızı zorlaştırıyor. Ben, Mali İşler ve Ortak Modüller(Kimsenin bilmediği bir modül varsa böyle gelin) ekibindeyim. Lakin ERP’nin diğer modüllerinde de benzer sorunlar olabiliyor.https://buraksenyurt.com/pingback.axdhttps://buraksenyurt.com/post.aspx?id=c38945f1-72de-45d4-82df-4a3f8d675f475https://buraksenyurt.com/trackback.axd?id=c38945f1-72de-45d4-82df-4a3f8d675f47https://buraksenyurt.com/post/sekiz-saatlik-sonsuz-dongu#commenthttps://buraksenyurt.com/syndication.axd?post=c38945f1-72de-45d4-82df-4a3f8d675f47