Mümkün Olan En Basit Şeyi Yapın
(seangoedecke.com)- Yazılım tasarımında, her zaman “mümkün olan en basit şeyi” seçmek etkili bir tavsiyedir
- İyi bir sistem tasarımı gösterişli görünmez; aslında sorunu çözmek için yalnızca en az sayıda bileşen kullanır
- Basit çözümler ararken, yeni gereksinimler yalnızca gerçekten ortaya çıktığında kademeli olarak genişlemeyi öngören YAGNI (You Aren't Gonna Need It) ilkesi temel tasarım felsefesi olabilir
- “Basitlik” tanımı tartışmalı olsa da, bileşen sayısı az, iç bağlantıları gevşek ve istikrarlı sistemler basitliğe en çok yaklaşan sistemlerdir
- Aşırı ölçeklenebilirlik takıntısı kod tabanını daha az esnek hale getirdiğinden, gerçek gereksinimlere sadık kalan basit tasarım uzun vadede daha avantajlıdır
Mümkün Olan En Basit Şeyin Peşinde
Yazılım sistemleri tasarlarken “mümkün olan en basit şeyi” yapmak önemlidir. Bu yaklaşım, hata düzeltme, mevcut sistemlerin bakımı, yeni mimari tasarımı gibi neredeyse her duruma uygulanabilir. Birçok mühendis iyi organize edilmiş, neredeyse sonsuz ölçekte büyüyebilen ve temiz biçimde dağıtılmış “ideal” sistemi hayal eder; ancak pratikte mevcut sistemi derinlemesine anladıktan sonra en kolay çözümü seçmek daha etkilidir.
Basitliğin Hafife Alınması
- Sistem tasarımı; uygulama sunucusu, proxy, veritabanı, önbellek, kuyruk gibi çeşitli araçları kullanabilme becerisi gerektirir
- Özellikle junior mühendisler birden çok teknolojiyi kullanarak karmaşık yapılar kurmak isteyebilir, ancak gerçek ustalık gereksiz olanı azaltabilmektedir
- İyi yazılım tasarımı sıradan görünür; hatta sorunun beklenenden daha kolay çözülebildiği izlenimini verir
- Örneğin Unicorn ve Rails REST API, Unix’in temel işlevlerini kullanarak asgari bir yapı ile temel garantileri (izolasyon, ölçekleme, kurtarma vb.) sağlar; bu açıdan tasarım olarak çok başarılıdır
Basit Uygulama Düşünce Biçimi
- Örneğin bir Golang uygulamasına rate limiting özelliği eklerken Redis gibi harici bir depolama kullanılabilir; ancak gerçekten gerekmedikçe önce bellek içi sayaçlar gibi daha basit yöntemler denenebilir
- Basit yöntem yeterliyse ağır bir altyapı eklemeyi ertelemek mümkündür
- Sistem, ancak yeni gereksinimler gerçekten ortaya çıktığında genişletilen kademeli geliştirme anlayışıyla ilerleyebilir
- Bu, YAGNI ilkesini tasarımın en üst önceliği yapan bir yaklaşımdır
Basitliğin Tuzakları ve Gerçekçi Sınırlar
1. Big Ball of Mud olgusu
- Her gereksinimi anında çözmeye çalışmak, karmaşık ve bakımı zor bir “big ball of mud” kod tabanına dönüşme riski taşır
- Ancak anlık yamalar (hack), basitlik değil; aksine anlama ve bakım açısından daha fazla karmaşıklık üretir
- Gerçekten basit bir çözüm bulmak için pek çok yöntemi karşılaştırmak ve fiilen sistematik mühendislik yapmak gerekir
2. Basitliğin tanımı
- “Basitlik” konusunda uzlaşmak kolay değildir
- Genel olarak basit sistemlerde hareketli parça (çalışan unsur) sayısı azdır, bileşenler arası bağlantılar gevşektir ve arayüzler nettir
- Somut örnek: Unix süreçleri ve Unicorn bellek paylaşmadığı için daha basittir; Puma veya Redis ile karşılaştırıldığında iç bağlantılılıkları daha düşüktür
- Seçim belirsiz olduğunda, daha az bakım gerektiren tarafın daha basit olduğu kabul edilebilir
3. Ölçeklenebilirlik takıntısına eleştiri
- “Basit yöntem” büyük ölçekli trafik için uygun olmayabilir
- Ancak gelecekteki ani büyümeye göre sistemi önceden karmaşık tasarlamak çoğu zaman boşa harcanmış emektir
- Kodların büyük bölümü için gerçekte yalnızca yaklaşık 2–5 kat trafik artışına hazırlıklı olmak yeterlidir; daha fazlası olduğunda soruna o anda müdahale etmek daha mantıklıdır
- Aşırı ölçeklenebilirlik odaklı tasarım, kodun esnekliğine zarar verir; gereğinden fazla yapısal ayrım belirli özelliklerin uygulanmasını zorlaştırabilir ve hatta karmaşık işlem yönetimi gerektirebilir
Sonuç
- Zaman geçtikçe, sistemin gelecekteki gereksinimlerini tahmin etme becerisine dair daha karamsar bir bakış oluşur
- Pratikte mevcut sistemin durumunu doğru anlamak bile yeterince zordur ve iyi tasarımın önündeki temel engellerden biri de budur
- Yazılım geliştirmede genel olarak iki yaklaşım vardır
- Gelecekteki gereksinimleri öngörerek tasarlama yaklaşımı
- Mevcut gereksinimlere sadık kalıp mümkün olan en basit şeyi tekrar tekrar yapma yaklaşımı
- İkinci yaklaşım pratikte daha etkilidir; YAGNI ve basitlik merkezli düşünce uzun vadede daha iyi tasarımlar üretir
Ek: Hacker News tartışması ve terimin kaynağı
- Mimari basitliğin ölçek büyüdükçe anlamını yitirdiği yönündeki görüşe karşı yazar, tam tersine büyük ölçeklerde basit yapının daha da önemli olduğunu savunur (özellikler arası etkileşim karmaşıklığına karşı)
- “Do the simplest thing that could possibly work” ifadesi Ward Cunningham ve Kent Beck tarafından ortaya atılmıştır
1 yorum
Hacker News görüşü
Bence bu yaklaşım basit alanlarda işe yarayabilir. Ama büyük teknoloji şirketlerinde uzun süre çalıştıktan sonra bile gereken karmaşıklığa hep şaşırıyorum. En basit iş problemleri bile çözülmesi bir yılı aşabiliyor ya da sayısız edge case ve ölçek sorunu yüzünden sık sık bozuluyor. Sürekli sadeliği savunan kişiler, muhtemelen büyük ölçek deneyimine sahip değildir. 10 yıllık bir kod tabanına baksanız bile dikkate alınması gereken o kadar çok şey vardır ki yeniden yazımlar da sık sık başarısız olur. Chesterton's Fence benzetmesinde olduğu gibi, bir şeyin neden var olduğunu bilmiyorsanız onu gelişigüzel kaldırmamak gibi bir bilgelik gerekir
Bunun, yazılım mühendislerinin birbirleriyle iyi iletişim kuramamasından doğan klasik bir yanlış anlama olduğunu düşünüyorum. Söylenen şey, başlıktaki gibi, "mümkün olan en basit şeyi" yapmaktır. Karmaşık problemlerde karmaşıklık kaçınılmazdır, ama burada kastedilen gereksiz yere daha da karmaşık hale getirme hatasına dikkat etmektir. Amaç karmaşıklığı tamamen ortadan kaldırmak değil, işi gereğinden fazla karmaşıklaştırma alışkanlığına karşı uyanık olmaktır
İşaret edildiği gibi, karmaşıklık alanın kendisinden kaynaklanmıyor da olabilir. Sorun kötü yazılım tasarımından doğmuş olabilir. Eğer sistem bağımlılıklar ve yan etkilerle doluysa, bunun nedeni sorumlulukların ayrılmasının ve bağımlılık derecesinin iyi yönetilmemesidir. Bu durumda refactoring neredeyse imkânsız hale gelir ve kurum kültürü düzelmezse refactor sırasında sadece yeni sorunlar üst üste eklenir. Yine de sorumlulukların ayrılması ve basit bileşimlerle karmaşık problemler çözülebilir. Zor olsa da kıdemli geliştiricilerin bu bakış açısını sağlam biçimde benimsemesi başarı ihtimalini artırır
Yazarın GitHub'da staff engineer olduğundan bahsedilince, bu kişinin de büyük ölçekli sistemlerde yeterince deneyimi olduğunu düşünüyorum
Legacy sistemler kenarlarda yaşar. Gerçek sistemlerde de, çok boyutlu uzayda boyut sayısı arttıkça noktaların sınır yüzeylerinde toplanması gibi, gerçek kullanıcılar da çoğu işi sistemin sınırlarına yakın yerlerde yapar. Tüm bu edge durumlarını en iyi şekilde karşılayan şey de sonuçta mevcut eski sistemdir
Önceki işimde karmaşıklığın önemli bir kısmı, başarısız olmuş, yarıda bırakılmış ya da tamamlanmamış refactoring ve iyileştirme girişimlerinden geliyordu. Bunlar erken aşamada engellenseydi bize daha basit bir sistem mi kalırdı diye sık sık merak ettim. Demek istediğim hiç refactor veya iyileştirme yapılmasın değil; ama bunların kesin biçimde kullanım senaryolarının %100'ünü kapsayacak şekilde planlanması, bütçe ve kilometre taşları güvenceye alındıktan sonra da kademeli olarak iyileşeceğinin garanti edilmesi gerektiğini düşünüyorum
Keşke "mümkün olan en basit şey" ifadesinin kökeni mutlaka belirtilseymiş. Bu ifade, wiki'nin mucidi Ward Cunningham ile Kent Beck'in birlikte çalışırken 80'lerin sonunda sıkça kullandığı bir ilkedir. İkisi kod yazarken birbirlerine sürekli bu ilkeyi hatırlatırdı ve sonrasında sunumlarında ya da yazılarında bu önemli bir tema haline geldi. Kapalı kapı örneğinde olduğu gibi, basit görünen bir şeyde bile duruma göre o "basitlik" farklı olabilir; makale de buna değiniyor. Yani basit çözümü bulmak her zaman basit değildir. Bu yaklaşımın teknik borç bırakabileceği de biliniyordu, ama öncelik önce kodu çalıştırmaktı. Kişisel olarak bu yazıda da teknik borç boyutunun biraz daha fazla ele alınmasını isterdim
Kent Beck daha sonra Extreme Programming'i resmileştirdi. Bu metodoloji, gereksinimler değiştikçe basit sistemlerin doğal biçimde evrilmesine yardımcı olan pratikler toplamıdır
Bu ifadeyi bir iş arkadaşımdan duyup onu hayat mottosu gibi kullandığını biliyordum ama kökeninin Ward Cunningham'a dayandığını bilmiyordum. İfade o kadar yaygınlaşmış ki artık kimsenin asıl sahibini bilmemesi herhalde en büyük onur sayılır
Wiki'den bahsedilmesi ilgimi çekti. Eski işyerimde projeleri Lotus Notes ile yönetiyorduk ve hangi belgenin ne zaman değiştiğini varsayılan olarak vurgulaması çok kullanışlıydı. Sonraki projede sadece Wiki kullandık ama hangi belgelerin değiştiğini tek bakışta anlayamadığımız için pratikte işe yaramaz hale geldi. Basitti ama fazla basitti; bu yüzden kullanışlılığı düştü
"Çalışıyor" tanımı kariyerim boyunca en çok tartışma yaratan konulardan biri oldu. "Çalışıyor olması bozuk olmadığı anlamına gelmez" sözü, bir şeyi gerçekten tamir etmiş insanlar için sezgisel olarak çok anlamlıdır. Tamirciler bozuk bir aletle idare ede ede sonunda değiştirmeye karar verirken, geliştiriciler sanki "bunu gerçekten düzeltmemiz gerekiyor" ihtiyacını aynı ölçüde hissetmiyor gibi
Kariyerimde en zorlandığım dönem, prototip yapmayı seven bir ekibin olduğu şirketteydi. O ekip çok hızlı şekilde sadece concept proof üretip yöneticilere demo gösteriyor ve hemen dağıtıma zorluyordu. Sonra yöneticiler de "bu kadar hızlı bittiğine göre hemen production'a alınabilir" diye yanılıyordu. Sonrasında sorumlu ekip kodu açıp baktığında uçtan uca güvenlik, doğrulama, hata işleme gibi zorunlu şeylerin tamamen eksik olduğunu görüyordu. Sonuçta her şeyin baştan yapılması gerekiyordu ve yöneticiler de dağıtım ekibinin işi gereksiz yere karmaşıklaştırdığını sanıyordu
Bir yerde şu etkileyici alıntıyı görmüştüm: "Bir programın çalışması yeterli değildir. Doğru nedenlerle çalışması gerekir." Özünde aynı mesaj
Bu tür konuşmalar mesleki açıdan önemli. Bir sistemin istenen çıktıyı üretebilmesi anlamında "çalışıyor" denebilir, ama güvenilirlik ya da maliyet açısından yine de başarısız sayılabilir
Yaptığım işte "çalışıyor" tanımı, işverenimin kaynaklarıma yani zamanıma nereye yatırım yapmak istediğine göre değişiyor. Kaliteyi artırmaya zaman ayırmama izin veriliyorsa elimden gelenin en iyisini yaparım. Tersine sadece hedef tutturmamı ya da bir kontrol listesini tamamlamamı istiyorlarsa ona göre çalışırım. Bana göre neyi ölçersen sonuç da ona göre gelir; ben tavsiye verebilirim ama karar bende değil
Bu tür tavsiyelerin ironisi şu ki, bunları gerçekten iyi uygulayabilen kişiler zaten deneyimli uzmanlar oluyor. Örneğin "en basit şey"in ne olduğunu nasıl bileceksiniz, bunun gerçekten işe yarayıp yaramayacağını nasıl anlayacaksınız? Yakın zamanda kendi yaptığım bir XLSX importer'da XML namespace işlemede hata yaşadım; çünkü Excel'in her zaman varsayılan namespace kullandığını varsaymıştım. Sonra farklı namespace kullanan bir dosya gelince anında bozuldu. Sadece prefix'leri söküp öyle işlemek basit olurdu, ama gelecekteki kendim için 4 saat harcayıp tüm parser'ı namespace dostu olacak şekilde yeniden kurdum. "En basit şeyi" yapmak pratikte o kadar kolay değil; deneyim arttıkça daha iyi karar verilebiliyor. Ama o kadar deneyim kazandığınızda da bu tavsiyeye zaten daha az ihtiyaç duyuyorsunuz
Bence makalede de bu tavsiyenin neden uygulanmasının zor olduğuna değiniliyordu. Ana fikir şu: "En basit çözümü bulmak için birden çok yaklaşımı değerlendirmek gerekir ve bu da mühendislik düşüncesi gerektirir"
Şirkette bizim bir ilkemiz var: "Kodu yanlış yöne doğru büyütme." Kısmi bir uygulama olsa bile, kodu ancak ileride doğru şekilde geliştirilebilecek bir doğrultuda yazarız. KISS yaklaşımını benimsiyoruz ama kestirme çözümlere asla izin vermiyoruz
Ben sadeliği "devir teslimi en kolay olan şey" üzerinden değerlendiriyorum. Karmaşık soyutlamalara ya da altyapıya bağlı olmayan tek bir servis, sonunda devretmesi en kolay olan şeydir. Okuyan kişi hemen anlayabilir; onboarding ve debugging de daha kolay olur. Ama soyutlama gerektiğinde mutlaka eklerim, altyapı gerçekten gerektiğinde de onu koyarım. Önemli olan, kodu devrederken açıklaması en kolay yapı mı diye sürekli düşünmek. Eskiden mümkün olduğunca her şeyi soyutlayıp servislere ayırıp konfigürasyon tabanlı yapıp neredeyse hiç kod bırakmamayı hedeflerdim ama pratikte devir ve teslim süreçleri tamamen başarısız oldu. Artık yapıyı sadece gerçekten gerektiğinde karmaşıklaştırıyor, varsayılan olarak sezgisel sadeliği koruyorum. Sonuçta bu yaklaşım yeni çalışanların onboarding'ine, hata düzeltmeye ve gerçek devir teslime fayda sağlıyor
AI vibecoding de benzer. Deneyim ve birikim arttıkça uygun görev seçimi ve agent yönetimi daha kolay hale geliyor
Bence birçok kişi "en basit şey"in kestirme ya da acele bir yama olmadığını gözden kaçırıyor. Basit yöntem çoğu zaman daha fazla düşünme ve sistem anlayışı gerektirir; yazının girişinde söylenen de buydu. Birçok kişi başlığı görüp kendi şikâyetlerini dökmüş gibi duruyor
Genelde bu tür ilkeleri ya da çok güçlü iddiaları duyar duymaz temkinli olurum. Yazılım geliştirme hakkında sanki evrensel bir doğru varmış gibi konuşuluyorsa, çoğu zaman aslında pek bir şey bilinmiyordur. Gerçekten deneyimli geliştiricilerin vardığı sonuç, yazılımın zor olduğu ve dikkat gerektirdiğidir. Mutlak bir sihirli cevap yoktur. Açık fikir ve özen gerekir
Sadelik yani karmaşıklığın tersi, yazılım tasarımı alternatiflerini karşılaştırırken neredeyse en öncelikli ölçüttür. Çünkü sonuçta planlayan, uzlaşan, uygulayan ve bakımını yapan insanlardır. Ama sadeliği değerlendirmek çok zordur ve sektördeki ortalama mühendisin bu konuda verdiği karara güvenilemez. Üstelik "sadelik" iddiası da içi boş bir moda sözcük gibi yayılıp, sağlam bir argümana karşı sadece "bu daha basit" diye itiraz etmek için kullanılır hale geldi. Bu tür şeyleri iyi bir ekip liderinin yakalaması gerekir ama ekip liderliği yetkinliği de giderek daha az güvenilir hale geliyor; bu yüzden iş daha da zorlaşıyor
Makalede etkileyici bir ifade daha vardı. Gerçek usta "eklemeyi" değil, "eksiltmeyi" bilir; aceminin hareketleri çok ve gösterişlidir, ustanınki ise az ama belirleyicidir
Yazıyı okurken başlarda biraz sinirlenmiştim ama "kestirme çözümler"in sadece başka bir karmaşıklık türü eklediğini söyleyerek deneme-yanılmanın özünü iyi yakaladığını düşünüyorum. Sorun, böyle ilkelerin yönetim buyruğu gibi aşırı uygulanması; o zaman karmaşık problemlere aşırı basit cevaplar verilmeye çalışılıyor, bilgi aktarımı zorlaşıyor ve geriye sadece daha da karmaşık bir toparlama işi kalıyor. Tersine, gereğinden fazla karmaşıklığın bir nedeni de sürekli günü kurtaran yamalara maruz kaldıktan sonra bu kez her şeyi tek seferde düzeltmeye çalışıp aşırıya kaçmak. Sonuçta geliştiricilerin toplantılara aktif biçimde katılıp baştan daha akıllı kararlar alınmasını sağlaması gerekiyor
Ben bunun alarm zili sayılacak kadar kötü olduğunu düşünmüyorum. Gereksiz karmaşıklık her gün biraz daha arttığı için sadeliği korumayı savunmak gerçekten gerekiyor. Tasarımcılar, ürün yöneticileri, hatta müşteriler ve mimarlar bile içgüdüsel olarak karmaşıklık eklemeye meyilli
Söylediğine katılıyorum ama sonuçta her şeyin "trade-off" ya da "there is no free lunch" noktasına vardığını da not etmek gerekir. Her genel ilke, sahadaki deneyimin damıtılmış hali olduğu için tamamen yok sayılamaz. Sorun, kullanışlı bir kavramın bir noktada aşırı söylentiye ya da dine dönüşüp geriye sadece klasör adı tartışmalarının kalmasıdır
Startup'larda (Seed~Series C) birkaç tane 0'dan 1'e sistem kurarken içselleştirdiğim bir ilke var: "Sadelik, dayanıklılıktır." İlk tasarımda ya da mevcut bir sistemi iyileştirirken aşırı tasarım yapmak çok kolay. Müşteri ihtiyaçları sürekli evriliyor ve gelecekteki ihtiyaçları öngörmeye çalışsanız bile sonunda yine yanılmanız çok olası. Bence sadelik sadece hata sayısını azaltmakla kalmıyor, yapıyı kolayca değiştirebilmenin de temelini oluşturuyor. Olası X, Y, Z durumlarına hazırlık yaparken bile, gelecekte genişleyebilmek ve hareket alanı bırakmak için yönü "mümkün olan en basit şey"i yapmaya çeviriyorum. Karmaşıklık kaçınılmaz olarak kısıtları artırır ve zamanla biriktikçe tüm yığını daha kırılgan hale getirir
Bence ancak bir ölçüde "ideal sistemi" tasarlamaya çalıştıktan sonra sonunda "en basit şey"e ulaşabiliyorsunuz. Okuması kolay, değişimi kolay bir sistem kurmak da ciddi bir ustalık gerektiriyor. Gerçek anlamda "basit" bir iyileştirme de deneyim ve derin anlayıştan doğuyor
Gall's law ile aynı bağlamda. Bu görüşe göre düzgün çalışan karmaşık bir sistem her zaman basit bir sistemden başlayıp üzerine kademeli olarak karmaşıklık eklenerek oluşur. Baştan karmaşık kurulan sistemler genelde iyi işlemez. Bu yüzden önce en basit sistemi kurup, sonra gereksinimlere göre yavaş yavaş karmaşıklık eklemek gerekir
Yazının ana fikrine katılıyorum ama cloud altyapısının ortaya çıkmasıyla "sadelik" tanımının değiştiğini düşünüyorum. Eskiden mesele "basit ama ölçeklenmeyen şey" ile "karmaşık ama ölçeklenen şey" arasındaydı; artık o kadar net değil. In-memory bir rate-limiting çözümü tek sunucuda basit olabilir ama iki sunucu olunca hemen dağıtık durum problemi doğar. Buna karşılık DynamoDB veya ElastiCache gibi managed service'ler, ister tek düğüm ister 1000 sunucu olsun, tek bir truth source sağlayarak karmaşıklığı ciddi biçimde azaltır. "Basit sistem daha sağlamdır" açısından bakarsanız managed service kullanmak aslında daha temel düzeyde daha basittir. Çünkü veri kaybı, dağıtık durum yönetimi gibi tekrar eden sorunları ortadan kaldırır. Artık "en basit şey"in tanımı, elde yönetim gerektirmeyen managed service'leri iyi değerlendirmek yönünde değişmiş gibi. Günümüzde dış bağımlılıklardan kaçınmaktan ziyade, izole biçimde doğrulanmış sistemleri etkili şekilde leverage ederek karmaşıklığı azaltmanın zaman ve maliyet tasarrufu sağladığını düşünüyorum
"Mümkün olduğunca basit yap, ama daha da basitleştirme" sözüne katılıyorum. Bu ilkeye her zaman uymaya çalışıyorum ama bir yandan da modern teknolojileri yeterince bilmediğim için gereksiz karmaşıklıkları kaçırıyor muyum, yoksa herkes gerçekten gereksiz karmaşıklığın peşinde mi diye hep düşünüyorum. Bir şeyin gerçekten işe yarayıp yaramadığını öğrenmek için onu gerçek projelerde kullanmak gerekiyor; ama sırf kişisel öğrenme uğruna en yeni aracı projeye zorla sokmanın ekibe zarar verdiğini de gördüm
Ben de benzer bir kâbus yaşıyorum. Hep en yeni yazılıma meraklı bir üst düzey kişi yüzünden, anlamlı olup olmayacağı belirsiz araçları gerçek işte değerlendirmek zorunda kalıyoruz. Sonuçlarla ilgisi olmasa da her hafta bu tür keşifleri sürdürmem bekleniyor; bu da ciddi bir yük
Aslında bence en doğrusu, en basit yöntemle çalışır hale getirmekten başlamak ve gerekirse bunu elle yapmak; tam işlevi de ancak gerçekten ihtiyaç doğduğunda eklemek. Başta her şeyi otomatikleştirmeye ya da araçlaştırmaya zaman harcamış olsanız bile, sonradan neden gerekli olduğunu açıkça öğrenmiş olmak daha değerli
Bu his bana çok tanıdık geliyor. Ben de bu tür yazılara hep katılıyor ve sadeliği uygulamaya çalışıyorum ama bunun gerçekten bilgelik ve pragmatizm mi, yoksa sadece deneyim ya da beceri eksikliğim mi olduğunu sürekli sorguluyorum
Bu yüzden "CV odaklı geliştirme" tuzağına düşmemek için gerçekten dikkat etmeye çalışıyorum