2024'te Ben Nasıl Programlıyorum

 (akkartik.name)
2 puan yazan GN⁺ 2024-08-06 | 1 yorum | WhatsApp'ta paylaş
  • İki yıldır doğrudan kullanıp geliştirerek düzelttiğim bir programın çekirdeğini yeniden yazma deneyimi, bir ay içinde test ve sürüm yönetimi hakkındaki eski inançlarımı sarstı
  • 2015'te kötü soyutlamalardan daha çok test ve sürümlerin uzun ömürlü yazılımın anahtarı olduğunu düşünüyordum; ancak Mu ve Freewheeling Apps sürecinden geçerken gerçek çalışma biçimim giderek değişti
  • Uzun ömürlü programların çok sayıda insana hitap etmektense, iyi bildiğiniz insanlar, bağlamlar ve işlevler içinde yapılması ve Dunbar sayısı gibi gerçekçi sınırların kabul edilmesi gerektiğini düşünüyorum
  • Türler, soyutlamalar, testler, sürümler, durum makineleri, değişmezlik ve biçimsel analiz; yabancı alanlarda faydalıdır, ancak fazlası gereksiz karmaşıklığı örten bir teknik borca dönüşür
  • Bağlam anlayışı istikrara kavuştuğunda büyük parçaları atıp yeniden yapmaya değer; gerekli senaryoları aynı anda zihinde tutup bütünü tek seferde kurmak gerekir

Test ve sürüm yönetimi hakkındaki düşüncelerimin değişimi

  • Uzun süre güvenle dayanabileceğim programları seçme ve bizzat yapma sorunuyla sürekli uğraştım, ama bu işi gerçekten iyi yaptığımı ben de düşünmüyorum
  • Son bir ay içinde, iki yıldır kullanıp kademeli olarak değiştirdiğim bir programın çekirdeğini yeniden yazdım
    • Sonrasında birkaç gün boyunca ne öğrendiğimi ve bir sonraki adımın ne olacağını toparlama zamanı geldi
    • Bu çalışma vesilesiyle daha geniş bir yaşam çizgisindeki değişim görünür olmaya başladı
  • 2015'te soyutlamalardan şüphe ediyor, test ve sürüm yönetimine önem veriyordum
    • Kodda kötü soyutlamaların çok olduğunu, test ve sürümlerin ise 2000'lerin temel ilerlemeleri olduğunu düşünüyordum
    • Sorunların nedenini kötü teşviklerde, aşırı soyutlamada, yetersiz testte ve sürüm yönetiminde arıyordum
    • Mu1, testleri ve layers yaklaşımını temel kısıt olarak alan bir platform tasarımı denemesiydi
  • 2017'de Mu1'i bugünkü Mu haline yeniden işlemeye başladım
    • Başlangıçta, testler ve katmanlarla ilgili tüm yeni fikirleri kullanıyordum
    • Zamanla bu fikirlere daha az başvurmaya başladım
    • Bugünkü Mu'da çok sayıda test var, ancak bunların çoğu genel testler ve katman altyapısını taşıyamadım
  • 2022'de Freewheeling Apps yapmaya başladım
    • Başta hiç test yoktu; daha sonra çekirdek parça olan metin düzenleyici için kapsamlı testler yazdım
    • Geri kalanı nasıl test edeceğimi bulmak zordu, ama testsiz de yeterince ilerleme sağlandı
  • 2024'te tüm testleri sildim
    • Metin düzenleyiciyi büyük ölçüde yeniden yapmaya başladım ve bu yaklaşım, diğer Freewheeling Apps ile birleşme çakışmaları konusunda kaygı yaratabilirdi
    • Sonuç olarak sürüm yönetimi üzerine düşünmeyi de bıraktım
    • Testleri ve sürümleri bıraktıktan sonra daha iyi bir program elde etmem, eski inançlarımla yaşadığım bilişsel uyumsuzluğu artık görmezden gelmeyi zorlaştırdı

Uzun ömürlü programlar için bugünkü çerçevem

  • Çok sayıda insan için uzun ömürlü bir şey yapmak fazla zor; bu yüzden en baştan böyle denememenin daha iyi olduğunu düşünüyorum
    • İyi bildiğiniz şeyler, iyi tanıdığınız insanlar ve Dunbar sayısı tarafından sınırlandırılmak gerekir
  • Dünyadaki yazılımların çoğunun, kısa vadede çok sayıda insana hizmet etmeye çalışan teşvikler tarafından enfekte edildiğini düşünüyorum
    • Mümkün olduğunca web sitesinde çok sayıda logo olmayan yazılımlara odaklanıyorum
    • Yapması kolay, bağımlılığı az ve otomatik güncelleme yapmayan yazılımları tercih ediyorum
    • Bu kısıtlarla süzünce, insanlığın bugüne kadar ürettiği uzun ömürlü yazılım miktarı çok küçük kalıyor
  • İnsanlar, yerler ve desteklenmek istenen işlevler gibi bağlamdaki küçük değişiklikler bile bir programın o bağlama ne kadar iyi uyduğunu büyük ölçüde değiştirebilir
    • Kısa vadeciliğin baskın olduğu bir ortamda buna hazırlanmak zor
  • Geçmiş çalışmaların hacmi küçük ve her programdaki uygulanma alanı da dar olduğu için, yeni yapmaya karar verilen programların bir şekilde bilinmeyen bir alana girme ihtimali yüksek
    • Metin düzenleyiciye özel “drawing lines” özelliği eklemeye çalışırken bile birçok soru ortaya çıkıyor
      • İmleç çizimin üzerinde olabilir mi
      • İmleç başka satırdayken bir satıra çizim yapılabilir mi
      • Çizim metin satırından daha yüksekse, ekranın üst kısmında yalnızca kısmen görünür olabilir mi
      • Kısmen görünen bir çizimin üstüne çizim yapılabilir mi
    • Bu soruların yanıtları uzun süre optimal değildi ve geçici çözümlerin üstüne yeni geçici çözümler eklendi

Araçlar gerekli ama fazlası teknik borç oluyor

  • Türler, soyutlamalar, testler, sürümler, durum makineleri, değişmezlik ve biçimsel analiz; bilinmeyen arazide kullanılabilecek araçlardır
    • Gerektiği kadar ve kişisel zevke göre kullanılabilirler
  • İnsanlar, çekildikleri araçları aşırı kullanmaya eğilimlidir
    • Bu araçların ideal kullanım miktarının çok küçük olduğunu düşünüyorum
    • Kısa vadeciliğin baskın olduğu ortamda edinilen sezgiden çok daha küçük olmalı
  • Araçlar fazla kullanıldığında teknik borca dönüşür
    • Programın gereksiz yere karmaşıklaştığını fark etmek zorlaşır
    • Program, daha uzun ömürlü olabileceği bir duruma göre daha kısa ömürlü hale gelir
    • Bağlam değiştiğinde programı değiştirmek daha zor olur

Yeniden yazmak ve “bütünü tek seferde yapmak”

  • Bağlam anlayışı istikrara kavuştuğunda, programın büyük bölümlerini atıp sıfırdan yeniden yapmanın değeri vardır
  • Yeniden yazmadan önce, programdan istenen her şeyi ve ele alınması gereken tüm senaryoları aynı anda zihinde tutmak gerekir
    • Bu süreç zordur, ama hedef her şeyi tek seferde inşa edebilecek duruma ulaşmaktır
  • Nihai yaklaşım her şeyi tek seferde yapmaktır
  • Bu deneyimde testler ve sürüm yönetimi, bu evrimin sonuna ulaşmayı tersine zorlaştırdı
    • Testler, endişelenilmesi gereken sorunları unutturuyor
    • Sürüm yönetimi insanı geçmişe bağlı tutuyor
    • İkisi de ters etki yaptı ve bunları bırakmak büyük bir yön değişikliği gerektirdi
  • Şimdiye kadar yaptığım tüm yazılımların ve Freewheeling Apps'in bu çizginin 6. aşamasında olduğunu düşünüyorum

Karmaşıklığın sınırı ve veri odaklı tasarım

  • Program çok karmaşık hale geldiğinde, 8. aşamada onu zihinde bütün olarak tutmak imkânsızlaşabilir
    • Şimdiye kadarki yazılımların çoğu, özellikle de ikiden fazla kişi tarafından yazılanlar, bence bu kategoriye giriyor
    • Küçük bir metin düzenleyici bile göz korkutucu olabiliyor; bu yüzden ayın büyük kısmını o korkuyla yüzleşmeye hazırlanarak geçirdim
  • Her yazılımın mutlaka 9. aşamaya gitmesi gerekmiyor
    • Birçok Freewheeling Apps yeterince basit ve yavaş evriliyor
    • Yalnızca az sayıda kişi tarafından kullanılması bile, ilk tasarım kararlarından bağımsız olarak hatasız bir duruma yerleşmesini sağlayabilir diye düşünüyorum
    • Özellikle artık çekirdekteki karmaşık bir parçayı nasıl sadeleştireceğimi biliyorum
  • Yine de değer oluştuğunda nasıl iyileştirilebileceğini bilmek faydalı
    1. aşamaya ulaşmakta kesinlikle yararlı görünen bir yöntem olarak data-oriented design'ı görüyorum
    • Bu, körü körüne uygulanabilecek bir araç değil; programın veriye nasıl eriştiğine büyük resimden bakan bir düşünme biçimi
    • ECS gibi araçlar, özündeki entelektüel faaliyeti perdelememeli
  • Bu aşama ayrımı tamamen doğru olmayabilir
    • Daha az deneyim sahibi olduğum araçları küçümsüyor olabilirim
    • Bu aşamaların ötesinde ne olduğu da hâlâ açık bir soru olarak duruyor
  • 2019'da yazdığım programlama biçimime dair yazıdan bu yana düşüncelerimin nasıl değiştiğinin izleri görülebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-08-06
Hacker News yorumları

  • Test yoksa test hatası da görünmez; sorun ortadan kalkmış gibi görünür sadece.
    Bir şeyi test edip de bug bulmadığım hiç olmadı; test ettiklerimin çoğu da zaten yayımlanmaya hazır olduğunu düşündüğüm şeylerdi.
    Testleri silerseniz, sonunda kandırdığınız kişi büyük olasılıkla yalnızca kendiniz olursunuz. Yazıyı okuyunca, testlerin kendisinden çok varyant/konfigürasyon yönetiminden yorulmuş gibi görünüyor; bunu tamamen anlayabiliyorum. Yine de para kazanmak için kullanıcı sayısı gerekir ve bu kolay bir sorun olsaydı, pazar çoktan her derde deva çözümlerle dolmuş olurdu.

    • Bence bu alana bağlı. Şu anda üzerinde çalıştığım kod tabanının bazı bölümlerinde testler refactoring için çok yardımcı oluyor; diğer bölümlerde ise UI davranışı çok olduğu için manuel test çok daha hızlı.
      UI veya workflow çok hızlı değişiyorsa, bir sonraki iterasyonda işe yaramaz hale geleceğini bildiğiniz için test yazmamaya başlıyorsunuz; tersine çok yavaş değişiyorsa, o kısma bir daha dokunma ihtimaliniz düşük olduğundan refactoring ile yeni bug girme olasılığı da az oluyor. Testler veya tipler her derde deva kutsal kâse değil, işe uygun araçlardır. İyi test coverage'ı olan ama manuel testte ya da gerçek kullanımda bug bulunmayan bir kod tabanı hiç görmedim. Biraz abartarak söylersem, kusursuz testler yazabilecek kadar iyiyseniz, doğrudan kusursuz kod da yazabilirsiniz. Testleri kusursuz yazamıyorsanız, o testlerin eksiksiz, bugsız ve gerçekten faydalı olduğunu nasıl biliyorsunuz diye düşünüyorum.
    • “Testler bug'ların varlığını gösterebilir, ama yokluğunu gösteremez” sözü benim deneyimime daha iyi uyuyor.
      Birkaç ayda bir yeni bug bulup özenle test ekledim, ama birkaç ay sonra ürünü ilk 10 dakika kullanan biri yine yeni bir bug buluyordu. Yeni sürümde de bulunacak bug'lar olacaktır; ancak seçilen veri yapısı sayesinde eski testlerin önemli bir kısmının yapısal olarak artık gerekli olmadığını düşünüyorum. En azından hafif kullanım için birkaç bug daha yakalanırsa epey kararlı olmasını bekliyorum. Testler, büyük ekipler kod tabanını sürekli değiştirdiğinde çok değerlidir; ama burada sabit bir özellik kümesine sahip bir şey yapılmaya çalışılıyor.
    • Yakın zamanda bir thread'de önerilen Russ Cox'un Go Testing By Example videosunu izledim: https://www.youtube.com/watch?v=X4rxi9jStLo
      Çok sayıda faydalı tavsiye var, ama özellikle değinmek istediğim nokta, daha basit bir implementasyona, örneğin brute-force bir implementasyona karşı test yazılabileceği. Burada daha derin bir bilgelik var. Bir testin faydası, test implementasyonunun test edilen implementasyondan ne kadar basit olduğuna bağlıdır. Daha güçlü söylemek gerekirse, testler ancak test ettikleri şeyden daha basit olduklarında faydalıdır. Ne kadar çok test yazarsanız yazın, sonunda kod üzerine akıl yürütmeniz gerekir; bir şeyin “test” olması onu kendiliğinden faydalı yapmaz. Bu yüzden birçok programcının, test yazmayı kolaylaştırmak için fonksiyonları faydalı arayüzler yerine parçalara bölmeye; sırf coverage için basit helper'ları veya küçük sorguları test etmeye; ya da yalnızca test uğruna soyutlama getiren dependency inversion ve mocking yaklaşımlarına temkinli baktığını düşünüyorum. Elbette her birinin gerekçesi olabilir, ama önemli olan özü kaybetmemek.
    • Benim durumumda unit test yazdığım her seferinde bug ortaya çıktı.
      Genelde önce başarısız testi yazdığınız test-driven development tarzını pek uygulamam, ama bazen yaparım. Bu yüzden bu testler çoğunlukla zaten çalıştığını düşündüğüm kodu hedef alır. Yine de genellikle unit test yerine test harness tercih ederim[0]. Hâlâ bug bulur, ama akış daha az doğrusal olur. Geliştirme sırasında daha fazla test yapmanızı sağlayarak bug'ları o anda düzeltmenize yardımcı olur.
      [0] https://littlegreenviper.com/testing-harness-vs-unit/
    • Otomatik unit/integration testlere odaklanmak nispeten modern bir akım; muhtemelen 90'ların sonlarından itibaren. Ondan önce de oldukça büyük ve çok kararlı yazılımlar yayımlandı.
      Örneğin Linux kernel eskiden çok fazla teste sahip değildi; bugünlerde daha fazla gibi görünüyor. Unix'te de muhtemelen çok “test” yoktu. Compiler'larda testler daha yaygındı, ama işletim sistemlerinde daha azdı; Doom gibi oyunlarda da çok test olma ihtimali düşüktü. Sonuçta bir denge noktası bulmak gerekiyor. Otomatik testlerin, yani unit, integration ve end-to-end testlerin kaliteli yazılım üretmeye yardımcı olduğunu biliyorum. Aynı zamanda iyi testler yazmak her zaman kolay değil; kötü testler refactoring'i zorlaştırıyor, flaky testler ise büyük projelerde çok zaman yiyor. Yine de özellikle tek başınıza geliştiriyorsanız, farklı yöntemleri deneyip size uygun olanı bulmak ilginç bir süreç.

  • “Testlerden ve sürümlerden vazgeçince çok daha iyi bir program oldu” kısmını anlamak zor. 2024’te kim gönüllü olarak kaynak kod yönetimi olmadan programlama yapmak ister, bilmiyorum.
    Tek kişilik bir projede bile birden fazla cihazda çalışmak, geçmişi görmek, geri almak ve branch kullanmak neredeyse sıfır maliyetle çok büyük değer sağlar. Belki de yazarın “sürüm” derken neyi kastettiğini yanlış anlamışımdır.

    • Küçük, hızlı ve özellik kümesi sabitlenen bir şey yapmaya çalışıyor. Sık değişmeyen bir temel üzerine inşa etmeye karar vermiş; arka planı https://akkartik.name/freewheeling adresinde daha fazla anlatılıyor.
      Bu yaklaşımın, bugün insanların yaptığı programların çoğuna, yani büyük ekipler ve sürekli değişen gereksinimlere uymadığı doğru. Yine de kaynak kontrolü hâlâ kullanılıyor. Orijinal metinde söylendiği gibi, sadece başka fork’larla merge conflict yaşama kaygısını bırakmış. Şu anda 24’ten fazla fork var; ayrıntılar yukarıdaki bağlantıda. Yedekleme, “az önce neyi değiştirdim?”, yazılımı yeni bir cihaza kurmak gibi temel amaçlar için sürüm kontrolü kullanıyor. Ancak bu program özelinde, sürüm kontrolünü neyin değiştiğini anlama ve izleme aracı olarak görmemeye başlamış. Ayrıntılar https://akkartik.name/post/wart-layers adresinde. Örneğin commit mesajı hijyenine daha az önem vermeye başlamış. Sürüm kontrolü var, ama özellik kümesi sabitlenmiş ve onlarca yıl dayanacak kalıcı bir çıktı üretmeyi amaçlayan bu dar bağlamda “iyi programlama pratiği” olarak önceliği düşmüş.
    • Yazar, profesyonel kullanıcıları ya da ücretli kullanıcıları desteklemek zorunda olduğu bir durumda değil gibi; bilinen iyi bir sürümü garanti etmekten çok deneme özgürlüğü istiyor gibi görünüyor.
      Büyük sistemlerle uğraştığı ya da kritik ekip işi yaptığı bir durum da yok gibi. Bu koşullarda araçlar çok büyük değer sağlamayabilir. Karmaşık bir senfoni çalan büyük bir orkestradaki flütçünün notaya ve şefe ihtiyacı vardır; ama bir drum machine’e eşlik ederek tek başına çalıyorsanız ya da free jazz yapıyorsanız nota pek gerekmez, hatta engel bile olabilir.
    • Yazarın programlamaya dair zihinsel yorgunluk ya da burnout yaşadığı izlenimi var. Sürüm kontrolü bu kadar rahatsız ediyorsa, bunun ara vermesi gerektiğine dair oldukça iyi bir işaret olduğunu düşünüyorum.
    • Programcılar sürekli seçenekler ve opsiyonlar altında eziliyor. Araçların ve zeitgeist’ın “en iyi araçlar” dediği şeyler genelde bir işi daha kolaylaştırma yönünde ilerliyor.
      Ama her zaman 1000 kolay seçenek varsa doğru seçimi yapmak büyük bir bilişsel yük yaratır. Sektörün her tür best practice’i kutsallaştırıp uymayanlara sosyal baskı uygulamasının nedenlerinden biri de bu. Kötü mimari ve berbat spaghetti code ile çalışmak çok zordur; ama apaçık doğru görünen şeyleri sorgulayan, seçenekleri ve araçları azaltan katı geliştirme ortamlarını keşfetmek, nihai probleme daha fazla odaklanmayı sağlayabilir. Sürüm kontrolü de branch’lerle programı “bağımsız özellikler”e bölmeye teşvik eder; geçmiş, eskimiş olabilecek işlev birimlerini körü körüne kullandırır; işbirliği ise çoğu zaman alakasız organizasyon sınırlarını kod mimarisine katı biçimde yerleştirir. Bu, Mel Conway’in söylediği şeyle de bağlantılı. Sürüm kontrolünün faydaları sağduyudur, ama “iş problemi X’i çözer” düzeyinde gerçek ödünleşimler vardır. Sektör genelinde bu ödünleşimlerin neredeyse görünmemesi düşündürücü.
    • Bu durumda yazarın kastettiği şey, uygulamanın içine sürüm mantığı kodlamak gibi görünüyor. Örneğin geriye dönük uyumluluk için sürüme göre API endpoint’leri gibi.

  • Başta yazarın tamamen haksız olduğunu düşündüm, ama yine de bazı iyi içgörüler var.
    Bu iş akışı yazar için çok iyi çalışıyor. Çoğumuz Git ya da otomatik testler yüzünden hayal kırıklığı yaşadığımız veya üretkenliğimizin düştüğü zamanları hatırlayabiliriz. Kodu Dropbox, FTP vb. ile yedeklemek gibi daha basit ve daha az dikkat dağıtan çözümler de var. Yukarıdaki yöntemin iyi çalışmasının nedeni, yazarın az sayıda kişiyle işbirliği yaptığı kişisel tutku projesinde kendi üretkenliğini optimize etmesi. Otomatik testler faydalıdır, ama yazar değerlerinin ortaya çıkmasını zorlaştıracak kadar küçük programlar yapmayı seviyor gibi. Bu bağlamda da otomatik testlerin değeri olduğunu düşünüyorum; yine de otomatik testlerin hızı düşürdüğü konusunda herkes hemfikir olabilir. Elbette birçok kişi bunun karşılığının sonra alınacağını savunacaktır. Sürüm kontrolü ve otomatik testler gerçek sorunları çözer. Bugün sürüm kontrolü olmadan proje başlatmak mantıklı değil; otomatik testlerin best practice olmasının da bir nedeni var. Ama yazarın özel kullanım senaryosunda makul geliyor. Tartışmalı sürüm kontrolü/test bölümlerini çıkarırsak, 7/8/9. maddeler büyük programlar yazarken ve refactor ederken düşünme biçimimi mükemmel yakalıyor. Yaz, at, yeniden yaz.

    • Sürüm kontrolü konusunda katılmıyorum. Tek kişilik proje olsa ve birden fazla sürüm branch’i olmasa bile.
      İnsan hata yapar; 100 bin satırdan büyük projelerde son 3 haftada neyi değiştirdiğini bilmek çok yardımcı olur. Sorunu bulup düzeltmek için işe yarar. Daha da iyi yanı, branch sayesinde önceki stabil hâle dönme yolunu korurken istediğin şeyi deneyebilirsin. Otomatik testler olmasa da olur diye düşünüyorum.
    • Tek başına yapılan bir projede bile .gitignore ayarlayıp git init, git add -A, git commit -a -m "before I changed the foo function to use bar" çalıştırarak önceki revizyona dönebilecek kadar Git öğrenmek kesinlikle buna değer.
      Git’te ustalaşmak gerekmez; ama commit mesajlarının ve dönebileceğin sürümlerin olması bile beni sayısız kez kurtardı. Daha gelişmiş özelliklerden bahsetmiyorum bile.

  • Oldukça kafa karıştırıcı bir yazı. Neden 1 numaraya kadar çıktığını gerçekten merak ediyorum.

    • Bir yandan, hayatını geliştirmek için farklı araç ve teknikleri deneyen bir geliştiricinin yazısı olabilir. Öte yandan insanları tartışmaya sürüklemeye çalışan bir tuzak yem de olabilir.

  • Makul bir test kümesine sahip olmanın başlıca motivasyonu hayal kırıklığını azaltmaktır. Test kümesi geliştiriciye sistemi evrimleştirme konusunda güven verir.
    Doğru yapıldığında, “geri kalanını test etmenin bir yolunu bulmak zordu ama yine de fena gitmedi” gibi düşünceler de sıkça ortaya çıkar. Özellik karmaşıklığı arttıkça bileşenleri ya da tüm sistemi test etmenin zorluğu başa çıkılamaz hâle gelebilir. Ancak testten ve sürüm kontrolünden vazgeçmenin daha iyi bir program ortaya çıkardığı felsefesi, tek bir kişinin ötesine ölçeklenmez. O da ancak o kişi kaynak koddaki güncel ve geçmiş tüm kararları yakın tarihli, aşina olduğu anılar olarak biliyorsa mümkündür. Üstelik uygulamayı derinlemesine biliyorsanız, her değişikliğin doğrulanması tanım gereği elle yapılmak zorundadır.

    • Bir zamanlar HN’de, o gün bizzat yazmadığı kodu asla merge etmeyen birinin hikâyesini gördüğümü hatırlıyorum.
      Günün sonunda merge edilebilir durumda değilse, bunun problemi bir gün içinde ifade edecek kadar iyi anlamadığı anlamına geldiğini ve ertesi sabah baştan denediğini anlatıyordu. Bunu hatırlayan var mı, yoksa başka bir siteyle ya da anekdotla mı karıştırıyorum bilmiyorum.
    • Tek kişilik bir programlama ekibi için bu doğru. Açıkçası tek başıma çalışırken bile test kümesi ya da sürüm kontrolü olmadan programlama fikri bile korkutucu geliyor.
      Dokümantasyon, testler ve sürüm kontrolü, kod bağlamı hakkında hatırlamam gereken miktarı azaltır. Gözümün önündeki kod ayrıntılarını hatırlamam gerekir; ama belgeleyip test ettikten ve neden/nasıl değiştirdiğimi iyi commit mesajlarıyla check-in yaptıktan sonra o kodu zihnimden çıkarıp bir sonraki işe geçebilirim.

  • “Desteklemeye çalıştığınız kişi/yer/özellik gibi bağlamdaki küçük bir değişiklik, programın o bağlama ne kadar iyi uyduğunu dramatik biçimde değiştirir” diyen 3. maddeye iyi bir örnek K9 Mail’dir. Artık Android için Thunderbird olmaya doğru gidiyor.
    K9 Mail, e-posta hesapları listesini ana ekranda gösteren ve her hesabın okunmamış ileti sayısını ve toplam ileti sayısını belirten alışılmadık bir UI ile başlamıştı. Birleşik gelen kutusu vardı ama kullanıcıya dayatılmıyordu. Bir kişisel hesabı, bir iş hesabını ve müşterilerin verdiği birkaç iş hesabını ayrı tutmak istediğim için bu uygulamayı özellikle seçtiğimi hatırlıyorum. Muhtemelen birçok K9 kullanıcısı da aynı nedenle bu uygulamayı seçmişti. Geliştirici, soldan hesap listesinin kaydığı ve hesaplar arasında geçiş için bir dokunuş daha gerektiren geleneksel Android UI’ye geçtiğinde çok şikâyet olmasının nedeni de buydu. Böyle bir UI’yi sevseydik en başta K9’u seçmemiş olmamız büyük olasılıktı. Böylece küçük bir değişiklik —ama muhtemelen çok kod gerektiren bir değişiklik— uygulamanın kullanıcıya uyan uygunluğunu bozdu. Ben eski UI’ye sahip son sürüm olan 5.600’ü kullanmaya devam ediyorum ve her yeni cihaz aldığımda sideload ediyorum. Daha da tuhafı, hesap erişimi için yalnızca POP3 kullanıyorum. Telefonda önizleme yapıyor, silinecekleri siliyor, gerekirse kendimi gizli kopyaya ekleyerek yanıtlıyor ve en sonunda dizüstü bilgisayarıma indiriyorum; K9 bu iş akışına mükemmel uyuyordu. Gösterişli bir şeye ihtiyacım yok; 90’ların uygulaması seviyesinde bir şey yeterli.

  • Bu yolun nereye varacağını ben de sürekli merak ediyorum. Kesin olan bir şey var: Tek başına yazılım yapmak, ekip içinde yazılım yapmaktan tamamen farklı bir faaliyet.
    Testler konusunda ise testler amaç değil, araçtır. Aradığımız şeyin güven olduğunu düşünüyorum. Uygulamaya güveniyorsak daha az test yazarız. Buna karşılık mutlaka çalışmaya devam etmesi gereken bir şey varsa, refactoring’in etkisinden daha az etkilenen ve hızı daha az kesen dış sınırlara birkaç entegrasyon testi ekleriz. İç kısımları test etmektense web backend’ini dışarıdan yoklamak gibi. Birim testleri yeni bir API tasarımını somutlaştırmak için iyidir; ama yön belli olduktan sonra o testler neredeyse işe yaramaz hâle gelir.

    • Tek kişilik projelerde de test bulundurmak için gerçekten çok iyi nedenler var.
      Üzerinde çalıştığınız özelliğe doğrudan gitmek için if ifadelerini true || gibi bir şeyle geçici olarak sabitlemek zaman alır ve sonra kaldırılması gerekir. Bunun yerine testi oluşturup çalıştırırsanız regresyon testi olarak kalabilir. Büyük ya da yavaş bir uygulama dağıtıyorsanız —bazen sırf Qt kullanmak bile derleme ya da çalıştırmayı uzun sürebilir hâle getirir— tek bir test daha hızlı yüklenir ve daha hızlı çalışır. Bir hatayı yeniden üretmek 45 saniye sürüyorsa test yazmak daha iyidir. İşin en sıkıcı kısmını otomatikleştirir, akışı korur, kontrol etmeye değer mi diye her seferinde düşünmeden hata durumunu istediğiniz sıklıkta kontrol edebilirsiniz ve o da regresyon testi olarak kalabilir.

  • Bu yazarı gerçekten seviyorum ve Mu en sevdiğim projelerden biri. Modern bir Lisp makinesine benzeyen, üstelik QEMU’da çalışan eğlenceli bir proje.

  • “Çoğu yazılım, kısa vadede çok sayıda insana hizmet etmeye yönelik teşviklerle onarılamaz biçimde enfekte olmuş durumda” cümlesini seviyorum. Yazılım yerine “işletme” koysanız da aynen geçerli.

  • Yazılım mühendisliği alanındaki karmaşıklık hepimizi bir ölçüde bunaltmış durumda. Bazen bu karmaşıklık rastlantısal da olabiliyor.
    Ama onlarca yıl boyunca üretilmiş tüm fikirleri reddetmenin çözüm olduğu görüşüne katılmıyorum. Öte yandan, her çözümü harfi harfine kabul etmemek ya da “fazla fazla” kullanmamak gerekir. Bunalmış olmak, tanımı gereği bir şeyi fazla kullandığınızda ortaya çıkar. Test yazın, sürüm kontrol sistemi kullanın, soyutlama kullanın; ama neden kullandığınızı bilin. O “neden” artık geçerli değilse yeniden değerlendirmek gerekir.

    • Sorunun büyük kaynaklarından birinin akademi olduğunu düşünüyorum. Danimarka’da CS öğrencileri için dış sınav değerlendirmenliği yapıyorum; hâlâ nesne yönelimli yaklaşımla ve onion architecture tarzında soyutlamaları en baştan yığmayı öğreniyorlar.
      Bu, yazılım geliştirmedeki en kötüye yakın ezberlerden biri. Daha da kötüsü, bunların neredeyse din düzeyinde öğretilmesi. Garip olan şu ki, son yıllarda uzmanların yazılım yazma biçimi epey gelişti. Dediğim gibi, soyutlama her şey için özünde kötü değildir. SQL veritabanına giren tipik verilerde updated, updated_by gibi alanları içeren bir temel sınıfın olmamasını hayal etmek bile zor olabilir. Ama genel olarak, gerçekten zorunlu olmadıkça soyutlamayı neredeyse hiç kullanmıyoruz. Buna rağmen akademide hâlâ 25 yıl önce öğrendiğim müfredatın aynısı öğretiliyor. Öğrencilerin şık UML ile devasa soyutlamalar oluşturup bunları koda dökme becerisini notlandırmak gerçekten tuhaf. O öğrencilerin %90’ı bir daha tek bir UML diyagramı bile görmeyecek; en azından benim bulunduğum küçük alanda durum böyle. Yine de gerçek bu.
    • Gerçekte Git kullanmaya başlamamın tek nedeni magit’ti.
      Keşke her şey için komut satırı düzeyinde bir “porcelain” olsa. Standart bir --help=ui çıktısı ve dialog tarzı bir arayüz olsa otomasyon yapılabilir gibi geliyor. Mesele karmaşıklıktan bunalmak değil de, aktif olarak kullanabileceğiniz kas hafızasının bir sınırı olması ve bir yerde kesip atmak zorunda kalmanız gibi.