Yazılımı Hızlı Geliştirmek İçin Kendi Yöntemim
(evanhahn.com)- Mükemmellik ile hız arasında denge kurmak kolay değil, ancak duruma uygun yeterli kalite ve teslim tarihine uyum önemlidir
- Önce bir taslak (rough draft) geliştirip, ardından kod kalitesini iyileştirme yaklaşımı etkilidir
- Gereksinimleri gevşetmek veya aşırı talepleri azaltmak, hız ve verimliliği artırabilir
- Dikkat dağınıklığından kaçınıp küçük birimlerle sık commit atmak ve çekirdeğe odaklanmak gerekir
- Hızlı geliştirmeye yardımcı olan kod okuma, veri modelleme, scripting, debugging, saf fonksiyon odaklı yaklaşım gibi somut beceriler vardır
“Kod ne kadar iyi olmalı?” – kalite ölçütleri ve gerçekçi tercihler
- İlk zamanlarda tüm kodun mükemmel olmasını istemek doğaldır
- Her fonksiyonun titizlikle test edildiği, değişken adlarının zarif olduğu, soyutlamaların net olduğu ve hiç hata içermeyen bir kodu hayal ettim
- Ancak zamanla “tek bir doğru cevap yok” gerçeğini öğrendim
- Gerekli kod kalitesi duruma göre değişir
- 24 saatlik game jam: ortaya çıkan kodun mutlaka temiz veya hatasız olması gerekmez
- Sınırlı sürede çalışan bir çıktı üretmek daha önemlidir
- Kalp pili yazılımı: tek bir hata insan hayatını tehlikeye atabilir
- Bu yüzden en üst düzey güvenilirlik ve güvenlik şarttır
- Çoğu proje bu iki uç noktanın arasında yer alır
- Bazı şirketler hızlı teslimat ister ve ufak hataları tolere eder
- Bazı projeler yüksek kalite talep eder ama zaman çizelgesi rahattır
- Gerçek iş hayatında önemli olan, bu dengeyi anlayabilmektir
- Önce ekibin “yeterince iyi (good enough)” ölçütünün ne olduğunu anlamaya çalışırım
- Kabul edilebilir hata aralığı, kusursuz olmasa da sorun olmayan alanlar gibi pratik ölçütleri birlikte gözden geçiririz
- Kişisel kendi ölçütüm ise
- “10 üzerinden 8 kaliteyi, zamanında teslim etmek”
- Kod amacını iyi yerine getirir, kritik sorunlar yoktur ama küçük meseleler kalabilir
- En önemli şey zamanında teslim etmektir
- Ancak bu ölçüt de projenin bağlamına göre esnek biçimde ayarlanır
- Bazen mükemmelliği hedefleyip takvimin kayması kabul edilebilir
- Bazen de kusursuzluk düşük olsa bile hızlıca bitirmek daha değerlidir
- “10 üzerinden 8 kaliteyi, zamanında teslim etmek”
Rough drafts – rough draft ve prototiplemenin pratik kullanımı ve avantajları
- Yazılım geliştirmede de yazı yazmakta olduğu gibi taslak (rough draft, spike, walking skeleton) hazırlamak çok faydalıdır
- Mümkün olduğunca hızlı bir rough draft oluşturur, ardından bunu geliştirip tamamlanmış bir çözüme dönüştürürüm
- Benim rough draft kodlarım hata doludur; başarısız testler, bolca TODO yorumu, ele alınmamış istisnalar, aşırı print/log kullanımı,
performansın düşünülmemesi, WIP commit mesajları, gereksiz paket eklemeleri, tekrar eden kod, hardcode değerler, linter uyarıları gibi tam bir dağınıklık içerir - Bu süreç verimsiz görünebilir, ancak amaç “en azından problemin özünü anlayabilecek bir duruma” ulaşmaktır
- Elbette bu taslak durumdaki kodu nihai dağıtıma göndermezdim; gerçek deploy öncesinde mutlaka temizlerim
(Ekipte bazen taslak kodu olduğu gibi çıkarmaya yönelik baskı olur, ama mümkün olduğunca direnirim) -
Rough draft yaklaşımının başlıca avantajları
- “Bilinmeyen sorunları (unknown unknowns)” hızlıca ortaya çıkarır
- Bitince çöpe gidecek koddan ziyade, erken prototip aşamasında bilinmeyen engelleri bulmak çok daha avantajlıdır
- Prototip sırasında doğal olarak ortadan kalkan pek çok sorun vardır
- Yavaş bir fonksiyon veya yanlış bir yapı, sonradan tamamen gereksiz hale gelebilir; bu da zaman israfını önler
- Çok erken optimizasyon veya test için gereğinden fazla çaba harcamaya gerek yoktur
- Odaklanmayı artırır
- Gereksiz refactoring, isim bulma takıntısı, başka kod tabanlarını kurcalama gibi dikkat dağıtıcı şeyleri azaltır
ve sadece o anda çözülmesi gereken probleme yoğunlaşmayı sağlar
- Gereksiz refactoring, isim bulma takıntısı, başka kod tabanlarını kurcalama gibi dikkat dağıtıcı şeyleri azaltır
- Gereksiz erken soyutlamayı önler
- Önce çalışan bir çözümü hızlıca ortaya çıkarma sürecinde, gelecek için gereksiz soyutlamalara daha az yönelinir
- Sadece eldeki probleme odaklanarak gereksiz karmaşık tasarımdan kaçınılır
- İlerlemenin açık biçimde iletişimini sağlar
- Rough draft sayesinde ne kadar iş kaldığı daha doğru tahmin edilebilir
- Önce çalışan bir şeyi göstermek, paydaş geri bildirimlerinin ve yön değişikliklerinin hızlı gelmesini sağlar
- “Bilinmeyen sorunları (unknown unknowns)” hızlıca ortaya çıkarır
-
Rough draft’ı pratikte yürütme yöntemi
- Geri dönmesi zor kararlar (binding decision), taslak aşamasında mutlaka denenmelidir
- Örneğin dil, framework, DB şeması gibi büyük yön kararları erken doğrulanmalıdır
- Tüm geçici çözümler/hack’ler mutlaka TODO yorumu gibi işaretlerle kaydedilmelidir
- Polish (temizleme) aşamasında
git grep TODOgibi yöntemlerle hepsi taranıp düzeltilir
- Polish (temizleme) aşamasında
- Top-Down (üstten alta) sırayla geliştirin
- UI, API gibi kullanım biçimlerinden başlayarak scaffold (iskelet) yazılır; iç mantıkta hardcode/geçici uygulamalara izin verilebilir
- Pratikte UI/kullanıcı deneyimi netleştikçe alt mantığın değişmesi sık görüldüğünden, üst katmandan başlamak daha avantajlıdır
- Alt katmanları kusursuz inşa edip sonra üst katmana uydurmak verimsizdir
- Küçük değişiklikleri ayrı patch’lere bölün
- Rough draft sırasında kod tabanında iyileştirme veya bağımlılık güncelleme ihtiyacı fark edilirse,
o kısmı ayrı bir PR/commit olarak ayırıp hızlıca yansıtırım - Bu, toplam değişikliğin karmaşıklığını azaltır ve review/entegrasyon hızını artırır
> Not: “Kodun ilk taslağını çöpe at”, “Şu an için en iyi basit sistem”, “YAGNI(You Aren’t Gonna Need It)”
- Rough draft sırasında kod tabanında iyileştirme veya bağımlılık güncelleme ihtiyacı fark edilirse,
- Geri dönmesi zor kararlar (binding decision), taslak aşamasında mutlaka denenmelidir
Gereksinimleri değiştirmeyi denemek
- Daha az yapmak daha hızlı ve daha kolaydır ilkesini vurgularım
- Gerçek işte, verilen görevin gereksinimlerini gevşetmenin mümkün olup olmadığını her zaman düşünürüm
- Örnek sorular:
- Birden fazla ekranı tek ekranda birleştirebilir miyiz?
- Zor edge case’lerin hepsini gerçekten ele almak gerekiyor mu?
- 1000 girdi desteklenmesi isteniyorsa, 10 girdi yeterli olabilir mi?
- Tam sürüm yerine prototip kullanılabilir mi?
- Bu özelliği tamamen çıkarsak olur mu?
- Örnek sorular:
- Bu yaklaşım geliştirme hızını ve verimliliğini artırır
- Organizasyon kültürünü de azar azar daha yavaş ama daha makul bir tempoya yönlendirmeye çalışırım
- Ani ve büyük değişim talepleri pek işe yaramaz
- Kademeli öneriler ve tartışma biçimini değiştirme gibi yöntemlerle atmosfer yavaş yavaş değişir
Kodda dikkat dağınıklığından kaçınmak
- Sadece dış etkenler (bildirimler, toplantılar) değil, kod üzerinde çalışırken alakasız işlere kaymak da büyük bir engeldir
- Ben de sık sık bir bug düzeltirken tamamen ilgisiz bir yeri kurcalarken buluyorum kendimi; sonuçta asıl görev erteleniyor
- İki somut yöntem:
- Zamanlayıcı kurmak: Her iş için bir süre sınırı koyup alarm çaldığında mevcut durumu kontrol etmek
- İş beklenenden uzun sürdüğünde dikkat toplamak için faydalıdır
- Alarm çaldığında git commit atmak da küçük bir ilerleme hissi verir
- (Bu yöntem süre tahmini pratiği için de etkilidir)
- Pair programming: Birlikte çalışınca gereksiz yollara sapma azalır, odağı korumaya yardım eder
- Zamanlayıcı kurmak: Her iş için bir süre sınırı koyup alarm çaldığında mevcut durumu kontrol etmek
- Bazı geliştiriciler için bu tür dikkat dağınıklığından kaçınmak doğaldır, ama benim için bilinçli odaklanma ve alışkanlık haline getirme gerekir
Küçük ölçekli değişiklikler, küçük parçalara bölmek
- Eskiden büyük patch’leri ve geniş kapsamlı değişiklikleri teşvik eden bir yöneticim vardı
ama bunun gerçekte çok verimsiz olduğunu gördüm - Küçük ve odaklı diff’lerin neredeyse her zaman daha iyi olduğunu düşünüyorum
- Kod yazmanın zihinsel yükü daha düşüktür
- Kod review daha kolay ve hızlı olur; ekip arkadaşlarının yorgunluğu azalır ve benim hatalarımı bulmak da kolaylaşır
- Bir sorun çıktığında rollback daha kolay ve daha güvenlidir
- Tek seferde değişen alan küçük olduğu için yeni bug üretme riski de azalır
- Büyük özellikler veya feature eklemeleri de küçük değişikliklerin birikimiyle tamamlanır
- Örneğin yeni ekran eklemek gerekiyorsa, bug fix / bağımlılık yükseltme / feature ekleme işlerini ayrı patch’lere bölmek gerekir
- Küçük birimlerde değişim, daha hızlı ve daha yüksek kaliteli yazılım geliştirmeye yardımcı olur
Hızlı geliştirmede gerçekten işe yarayan somut beceriler
Yukarıdakiler biraz soyut kalabilir, ancak gerçekte hızlı geliştirme için etkili olan pratik beceriler de vardır
-
Kod okuma (Reading code): Bugüne kadar edindiğim en önemli geliştirici becerisi
- Mevcut kodu iyi yorumlayabiliyorsanız, debugging çok daha kolay hale gelir
- Open source/third-party kütüphanelerdeki bug’lar veya yetersiz dokümantasyon da çok daha az korkutucu gelir
- Başkalarının kodunu okuyarak öğrenilen şeylerin miktarı çok büyüktür ve bu, genel problem çözme becerisini doğrudan geliştirir
-
Veri modelleme (Data modeling): Zaman alsa bile veri modelini doğru tasarlamak önemlidir
- Kötü tasarlanmış bir veritabanı şeması, ileride çeşitli sorunlara ve karmaşık düzeltme maliyetlerine yol açar
- Geçersiz durumların en baştan ifade edilememesini sağlayacak tasarım, bug’ları kökten azaltır
- Veri saklanıyorsa veya dış sistemlerle alınıp veriliyorsa bu daha da kritik hale gelir
-
Scripting: Bash, Python gibi araçlarla kısa script’leri hızlı yazabilme becerisi, geliştirme verimliliğini çok yükseltir
- Bunu haftada defalarca; Markdown sıralama, veri temizleme, dosya tekrarlarını bulma gibi otomasyon işlerinde kullanırım
- Bash için Shellcheck gibi araçlar, sözdizimi hatalarını önceden yakalamaya yardımcı olur
- Çok robust olmasına gerek olmayan işlerde, LLM yardımıyla hızlıca tamamlamak da mümkündür
-
Debugger kullanımı: Debugger kullanmak, yalnızca print/log ile mümkün olmayan hızlı sorun teşhisi ve kod akışını anlamak için vazgeçilmezdir
- Karmaşık bug’ların kök nedenini bulmak çok daha hızlanır
-
Uygun zamanda mola vermek: Tıkandığınızda cesurca mola verme alışkanlığı
- Saatlerce çözülemeyen bir problemin, 5 dakikalık bir aradan sonra hemen çözüldüğü çok olur
- Odak verimliliği için de önemlidir
-
Saf fonksiyonlar ve immutable data odaklı yaklaşım: Fonksiyonel programlamada saf fonksiyonları ve immutable data’yı tercih etmek
- Daha az bug, daha az durum takibi yükü, daha yüksek açıklık/öngörülebilirlik sağlar
- Karmaşık sınıf hiyerarşileri tasarlamaktan daha basit ve etkili olduğu durumlar çoktur
- Her zaman mümkün olmayabilir, ama varsayılan olarak önce bu yaklaşımı düşünürüm
-
LLM (büyük dil modeli) kullanımı: LLM’ler (ör. ChatGPT vb.), dezavantajları olsa da tekrarlı veya otomasyona uygun geliştirme işlerinde büyük hız kazandırır
- Kendi kod akışıma LLM’i nasıl entegre edeceğimi ve sınırlarını yeterince anladıktan sonra aktif biçimde kullanıyorum
- Topluluktaki farklı deneyim, ipucu ve örneklerden de yararlanıyorum
Bu becerilerin hepsini uzun süre tekrar tekrar çalıştım ve gerçekten hızlı geliştirme için büyük bir sermaye haline geldiler
Özet
- Yazılımı hızlı geliştirirken edindiğim temel dersler şunlar
- Her iş için gereken kod kalitesi ölçütünü netleştirmek
- Rough draft’ı hızlıca yazarak genel çerçeveyi çıkarmak
- Gereksinimleri gevşetme alanlarını sürekli aramak
- Dikkat dağınıklığına kapılmadan odağı korumak
- Değişiklikleri küçük ve sık commit etmek, büyük patch’lerden kaçınmak
- Somut pratik becerileri (kod okuma, veri modelleme, debugging, scripting vb.) sürekli çalışmak
- Bunların hepsi çok bariz görünebilir, ama bu dersleri gerçekten öğrenmem uzun zaman aldı
2 yorum
Empati kurulacak çok şey var.
Yorumlar da güzel; ama biri bunları böyle derleyip anlattığında, yani bunun için bir zemin hazırladığında, buna yönelik karşı çıkışlar, destekler ve eklemelerle birlikte daha da olgunlaştığını düşünüyorum.
Not: Son zamanlarda "sıkıcı teknoloji" ifadesini sık görüyorum; İngilizcesi de boring technology imiş.
Hacker News görüşleri
Son birkaç yılda hızlı ve yeterince sağlam sistemler kurmanın yolunu öğrendim
Tek bir aracı derinlemesine öğrenmenin önemli olduğunu fark ettim. Yüzeyde daha uygun görünen bir araçtan ziyade, iyi bildiğim araç çok daha verimli oluyor. Hatta çoğu projede Django tam isabet bir seçim oluyor
Bazen Django fazla ağır mı diye endişelenerek bir projeye başladım ama sonuçta proje ilk niyetin çok ötesine geçti. Örneğin bir durum sayfası uygulaması yaptım ve Django’nun sınırlarından kaçınmaya çalışmanın verimsiz olduğunu hemen fark ettim
Django modeline uyan çoğu uygulamada veri modeli işin merkezinde yer alır. Prototip olsa bile veri modeli refaktörünü ertelerseniz, maliyet ve zorluk daha sonra katlanarak artar
Çoğu uygulamanın single-page app ya da ağır frontend framework’lerine ihtiyacı yok. Bazı bölümler için gerekebilir ama sayfaların %80’i için geleneksel Django view’ları yeterlidir. Geri kalanı için AlpineJS veya HTMX düşünülebilir
Çoğu durumda kendin geliştirmek daha kolaydır. Django ile CRM, durum sayfası, destek sistemi, satış süreçleri gibi birçok şeyi hızlıca yapabilirsiniz. Ticari bir CRM entegrasyonundan çok daha hızlıdır
Sıkıcı denecek kadar sıradan teknolojileri seçin. Python/Django/Postgres kombinasyonu çoğu iş için yeterlidir. Kubernetes, Redis, RabbitMQ, Celery gibi şeyleri unutabilirsiniz. Alpine/HTMX ise istisna, çünkü JS stack’inin büyük kısmından kaçınmanızı sağlar
Redis ve Kubernetes benim için 2025’in ‘sıkıcı teknolojileri’. İkisi de son derece stabil, kullanım alanları net ve dezavantajları da artık çok iyi biliniyor; bu yüzden güven veriyorlar. Ben şahsen ikisinin de hayranıyım. İhtiyacım olan işi tam olarak yaptıkları için güveniyorum
Ben de Django’yu gerçekten çok seviyorum. Bir projeyi inanılmaz hızlı başlatıp deploy edebiliyorsunuz
Gerçekten ‘sıkıcı teknolojiler’ seçilecekse Postgres bile bir kez daha düşünülmeli
Django projelerinde Celery’yi epey sık kullanıyorum. Getirdiği karmaşıklığı sevmiyorum ama PaaS ortamlarında yine de en az acı veren seçenek gibi duruyor
“Çoğu uygulamanın SPA veya ağır frontend framework’lerine ihtiyacı yok” iddiasıyla “bir aracı derinlemesine öğren” tavsiyesi çelişiyor gibi görünüyor
Kodu kaba bir taslak halinde bıraktığınızda, çoğu zaman yönetici o kodu olduğu gibi ‘nihai sürüm’ diye deploy eder
Bu yüzden ben en baştan robust kod yazarım. Hatta test harness’ini bile neredeyse deploy seviyesinde sağlam kurarım
Asıl mesele çok kaliteli modüller üretmektir. Değişme ihtimali çok düşük olan ya da değişirse çok büyük sorun çıkaracak bölümleri tamamen bağımsız modüller olarak izole eder, dependency şeklinde import ederim
Bu modüller sayesinde yeni uygulamaları çok hızlı geliştirebiliyor ve kaliteyi de sürekli yüksek tutabiliyorum
Kendi kullandığım örnekler arasında RVS_Checkbox, ambiamara, RVS_Generic_Swift_Toolbox var
Bir sorum var: Swift’te yorum işaretçisi olarak
* ##################################################################gibi kod kalıpları kullanmak standart mı?Yaklaşım, projenin ölçeğine göre çok değişiyor
Kişisel projelerde ya da küçük ekiplerde ‘hızlı ve kaba’ geliştirmek en iyi yaklaşım olabilir. Küçük ölçekli geliştirmenin gücü de burada
Küçük ekiplerde bug çıksa da hızlıca düzeltilir ve ekipteki herkes neredeyse tüm kodu eksiksiz bilir
Ölçek büyüdükçe mimari hataların ve bug düzeltmenin maliyeti patlar. Mimari kaçınılmaz olarak karmaşıklaşır ve büyük refaktörler fiilen imkânsız hale gelir. Böyle ortamlarda her adımda doğruluk en üst öncelik olmalı
Bağlam gerçekten çok önemli. ‘Büyük ölçek’in ne anlama geldiği değişebilir ama benim deneyimimde uygulamalar arası API’lerde erken uzlaşıp hem frontend hem backend için hızlı çalışma zemini kurmak her zaman doğruydu
Böyle durumlarda sistemi küçültmek gerekir. Herkes devasa bir sistem ister ama gerçekte çoğu zaman gerekmez
“24 saatlik game jam’de kod kalitesine takılmaya gerek yok” deniyor ama benim katıldığım hackathon’ların ve code review deneyimlerinin çoğunda, en iyi sonucu alan ekipler kod kalitesine ve temel test ortamına da dikkat ediyordu
Yukarıdaki iki iddia (hızlı olmak için kod kalitesinden vazgeçmek gerekir vs iyi sonuç alan ekiplerin kaliteyi yüksek tutması) aslında çelişmiyor. İyi ekipler kaliteye önem veriyor diye illa kodu estetik olarak kusursuz hale getirmeye saplanmış değillerdi
Game jam örneğinde, kodun temizliğine fazla takılmak tüm sonucun kötüleşmesine bile yol açabilir. UE blueprint gibi sistemler, neden ‘temizlikten’ çok ortaya çıkan sonucun öncelikli olması gerektiğini gösteriyor
Bazı insanlar kodun ‘temizliğini’ bütüncül olarak değerlendiriyor, bazıları ise gereksiz kod iyileştirmelerinin ayrıntılı maliyet/faydasına bakıyor
“Prototipleme yapınca öngörülemeyen unknown unknowns ortaya çıkar” deniyor ama ben yeni bir şeyle uğraşmaya başladığımda hep önce artıları görüyorum, eksileri pek göremiyorum
Gerçekte edge case’leri ele alma, kullanıcıya anlaşılır hata mesajları verme, yan etkileri temizleme gibi şeylerde; yani özelliği gerçekten tamamlama aşamasında asıl problemler, o unknown unknowns ortaya çıkıyor
Sanırım benim yaşadığım unknown unknowns daha çok araç/framework/kütüphane kaynaklı, yazarın bahsettiği ise problem alanının kendisinden doğan unknown unknowns
Kaba taslağın fazla kaba olmaması gerektiği de doğru. Üstünkörü geçilmemesi gereken yerleri geçerseniz asıl sorunlar orada patlar
Kendi kullanacağınız bir aracı yaparken kaba bir çözümle başlamak çoğu zaman yeterince iyi çalışabiliyor ve böyle hızlı yapılmış araçlar açıklarla dolu olsa da ciddi sorun yaratmayabiliyor
Bugünkü gibi sık sık yeniden yapılanmanın yaşandığı teknoloji sektörü, yazılım kalitesi ve mühendis üretkenliği için en büyük tehdit olabilir
İşten çıkarılma korkusu ve hızlı sonuç baskısı, yaratıcılığı ve deneme isteğini öldürüp tükenmişliğe yol açıyor
Herkes yapay zeka gibi moda konularda sürü psikolojisiyle hareket ediyor ve eleştiri de yapılamaz hale geliyor
Bu, LLM tabanlı otomatik kodlamadan bile daha acil bir sorun
Yazılım kalitesine yönelik en büyük tehdit her zaman tüketicinin kalite için para ödememesi olmuştur
Programlama düzeyindeki vendor lock-in, gerçekte SaaS lock-in’den çok daha yıkıcı
24 saatlik game jam gibi hızlı döngülerde kötü kodun aslında daha da ölümcül olduğunu hissediyorum
Kod ne kadar temizse hata da o kadar az oluyor, working memory üzerindeki yük düşüyor ve son anda istenen değişiklikleri, yeni özellikleri ya da düzeltmeleri yapmak çok daha kolaylaşıyor
24 saatlik projelerde işi en çok raydan çıkaran şey, yavaş kod yazmak değil; kişinin kendini köşeye sıkıştırması ya da öngörülemez sorunlara çarpması oluyor
Elbette tüm bug’ları kapatmak gerektiğini söylemiyorum. Ama temel kalite düşükse proje deneyimi genel olarak çok daha zor oluyor
Bu ilke daha uzun süreli projelerde de geçerli. Daha fazla zaman var diye baştan savma yazmak daha iyi olmuyor
İyi kod yazmayı alışkanlık haline getirirseniz ekstra maliyet olmadan kaliteyi koruyabilirsiniz. Üstelik daha uzun sürse bile sonunda buna değer
Ben de aynı fikirdeyim. Birçok kez game jam yaptım ama ‘dağınık kodu’ yalnızca son 1-2 saatte, başkasının dokunmayacağı dosyalarda kabul edebilirim
Hızlı ve iyi kod yazmanın yolu sonuçta çok yazmaktan geçiyor
İş acilken fancy bir asset loader ile uğraşmam, doğrudan statik dosyalar kullanırım
“İyi kod yazmak daha uzun sürer” fikrinin bir yanlış anlama olduğunu düşünüyorum. Belli bir kalite eşiğinin üstünde, iyi kod hızın önünde engel olmuyor
“Ne kadarının ‘good enough’ olduğu” standardı ekipten ekibe çok değişiyor ve kariyerimdeki en büyük çatışma kaynağı da bu oldu
Big Tech geçmişi olanlar test eksikliğinden şikâyet ediyor, startup kökenliler ise işlerin yavaş gitmesinden
‘Good enough’ standardını açıkça belgeleyip ekip içinde paylaşmak faydalı olur
İşte bu tam olarak team charter, yani ‘nasıl çalıştığımız’ belgesidir
Yazıda değinilmeyen önemli unsurlardan biri de zamanla geliştirme hızının düşmesidir
Proje ve ekip büyüdükçe geliştirme hızı doğal olarak yavaşlar
Anlık geliştirme hızından biraz feragat etmek gerekse bile, uzun vadede hızın daha az düşmesi için erken dönemde test, dokümantasyon, karar günlüğü, Agile toplantıları gibi hazırlıklar gerekir
Observability gibi kabiliyetleri veya test edilmesi kolay kod yapısını baştan kurmazsanız, sonradan çok büyük olumsuz etkiler bırakır
Ben tek başıma çalışan bir geliştirici olsam da karar günlüğü, test ve dokümantasyonun önemini çok net hissediyorum
Bu bana da tanıdık gelen bir örüntü. Kaba taslak ya da fikir doğrulama için başka bir script diliyle veya elle çalıştırılan küçük kod parçalarıyla başlıyorum