- Teknik zevk, teknik beceriden farklı bir kavramdır; kişi çok yetenekli olsa da zevki kötü olabilir, becerisi yetersiz olsa da zevki iyi olabilir
- Yazılım mühendisinin zevki, projeye uygun mühendislik değerlerini seçebilme yeteneği anlamına gelir
- Hangi kodun iyi/kötü göründüğü, hangi tasarım kararının tatmin edici olduğu, hangi problemlere takıntılı olunduğu gibi duyularda ortaya çıkar; bu da doğrudan kişinin önem verdiği mühendislik değerleri kümesini yansıtır
- Yazılım mühendisliğindeki tüm kararlar trade-off zinciridir; olgunlaşmamış mühendisler belirli bir yaklaşımı mutlak doğru sayarken, olgun mühendisler bağlama göre değerleri esnek biçimde ayarlar
- İyi zevk, belirli bir projeye uygun değer önceliklerini seçebilme yeteneğidir; kötü zevk ise "best practice" gibi mutlak ölçütlere saplanan bir katılık olarak ortaya çıkar
- Zevk, çeşitli proje deneyimleri ve açık fikirli düşünme ile gelişir; sonunda da bir projenin başarıya ulaşıp ulaşmaması üzerinden iyi zevkin varlığı görünür hale gelir
Teknik zevk ile beceri arasındaki fark
- Teknik zevk, üstün beceriyle mutlaka örtüşmez
- Herkes yemek yapma becerisinden bağımsız olarak iyi yemekle kötü yemeği ayırt edebildiği gibi, yazılımda da beceriden önce zevk oluşur
- Hangi kodun "iyi göründüğü" ya da "pek iyi görünmediği", mühendisin zevkini yansıtır
- Hangi tasarım kararlarının tatmin duygusu verdiği ve hangi problemlerin daha çok önemsendiği, zevkin bir parçası olarak işler
- Teknik yetenek tekrar ve öğrenmeyle geliştirilebilir, ancak zevk bundan daha muğlak ve sezgisel bir biçimde gelişir
-
Mühendislik zevkinin göstergeleri
- "Bu kod iyi/kötü görünüyor" diye hissetmek
- Bazı tasarım kararlarına karşı güçlü bir memnuniyet ya da kayıtsızlık duymak
- İşten çıktıktan sonra bile aklına takılan yazılım problemleri ile takılmayanlar
- Zevk, mevcut projeye uygun mühendislik değerlerini benimseyebilme yeteneği olarak düşünülebilir
Beceri ile zevkin ayrımı
- "İyi görünen kod" gerçekten daha iyi kod olmak zorunda mı sorusu vardır
- Örnek:
map/filter tercih eden biri kod okunabilirliğini ve saf fonksiyonları önemserken, for döngülerini tercih eden biri performansı ve basit genişletilebilirliği önemseyebilir
- Bu, doğru-yanlış meselesi değil, önem verilen değerlerin farkıdır
- Dil ve bağlama göre her seçimin artıları ve eksileri vardır; bu yüzden herhangi bir seçimin mutlaka daha iyi olduğu söylenemez
- Her mühendis farklı değerleri önemli görür ve buna göre tercihleri değişir
Mühendislik zevki nedir
- Yazılım mühendisliğindeki kararların neredeyse tamamı çatışan değerler arasında denge kurma (trade-off) meselesidir
- Toy mühendisler kendi zevklerinde aşırı ısrarcı olur
- Olgun mühendisler farklı bakış açılarından avantajları görür ve mevcut duruma uygun seçimi önemser
- Asıl önemli olan X teknolojisinin mi Y teknolojisinin mi daha iyi olduğu değil, mevcut projede X'in avantajlarına mı Y'den daha fazla ihtiyaç duyulduğunu değerlendirebilmektir
-
Mühendislik değerlerine örnekler
- Resiliency: Sistem arıza veya ağ sorunlarında da iyi çalışıyor mu
- Speed: Teorik sınırlara yakın performans gösteriyor mu, gereksiz iş yükü fazla mı
- Readability: Yeni bir mühendis sistemi hızlıca anlayıp adapte olabiliyor mu, fonksiyonlar kısa ve açık mı
- Correctness: Hatalı durumlar modellenebiliyor mu, testler, tipler,
assert vb. yeterli mi, hatta biçimsel doğrulama uygulanıyor mu
- Flexibility: Sistemi genişletmek kolay mı, değişiklikler basitçe uygulanabiliyor mu
- Portability: Belirli bir ortama bağımlı mı, dağıtım ortamındaki değişiklikler kolay mı
- Scalability: Trafik 10x, 100x arttığında sistem genişleyebiliyor veya otomatik ölçeklenebiliyor mu, darboğaz nerede
- Development speed: Sistem ne kadar hızlı genişletilebiliyor, mühendislerin çoğu üzerinde çalışabiliyor mu
- Bunların dışında elegance, modern-ness, açık kaynak kullanımı, bakım maliyeti gibi çeşitli değerler de vardır
- Tüm mühendisler her değere aynı düzeyde önem vermez
- Kişinin hangi değeri en üstte tuttuğuna göre kullandığı dil, framework ve tasarım desenleri değişir
Kötü zevkin özellikleri
- Kötü zevk, kişinin tercih ettiği değerler mevcut projeye uygun olmadığında ortaya çıkar
- Belirli bir teknoloji ya da metodolojinin avantajlarını kendi projesine sürekli dayatma şeklindeki esneklik eksikliği temel sorundur
- Her zaman yalnızca "best practice" öne süren yaklaşımlarda duruma özgü muhakeme eksikliği vardır
- Esnek olmayan mühendis, bazı projelerde çok uygun olabilir; ancak ortam ya da iş değiştiğinde ciddi sorunlara yol açabilir
İyi zevkin özellikleri
- İyi zevk, problem durumuna göre doğru mühendislik değerlerini iyi seçebilme yeteneğidir
- Basit teknik becerinin aksine, ancak karmaşık gerçek proje bağlamında doğrulanabilir
- Kişinin katıldığı bir tasarım kararı benimsenmiş ve proje iyi ilerlemişse, kendi zevkinin uygunluğunu kabaca ölçebilir
- Çeşitli proje deneyimleri ve doğru anda yeni değerlere açık olma hali, önemli öğrenme unsurlarıdır
- Esnekliği korumak ve belirli teknoloji ya da yöntemlere dair kalıplaşmış fikirlerden kaçınmak, iyi zevkin gelişmesine yardımcı olur
Sonuç
- İyi zevk, beceri kadar önemlidir ve gelişim sürecinde çeşitlilik, esneklik ve öz değerlendirme yoluyla geliştirilebilir
- Bazı insanlar deneyimlerinin ötesinde olağanüstü bir zevk sergileyebilir (programlama ve diğer alanlardaki dâhiler gibi)
Ek tartışma
- Hacker News yorumlarında "zevk" kavramının varlığına kuşkuyla yaklaşan görüşler de vardı
- Bazıları her problem için tek bir doğru çözüm olduğunu savundu; ancak yazar, gerçekte birden fazla çözümün mümkün olduğunu ve nihayetinde seçimi kişinin değerleri ile bağlamın belirlediğini söyleyerek buna karşı çıktı
- Başka bir görüş de müşteri ve iş bağlamının zevkin bir parçası olduğu yönündeydi
7 yorum
Buna kötü zevk demek yerine, ekip ve proje için zehirli olabilecek kötü bir eğilim gibi görünüyor.
Hacker News görüşü
Olgunlaşmamış mühendislerin kendi zevklerine fazla takılma eğiliminde olduğunu gördüm; üstelik bu tür bir olgunlaşmamışlık deneyimli mühendislerde de olabiliyor. Eskiden arkadaşlarımın bilgisayar ödevlerindeki koda yardım ederken, sırf ben sevmediğim için kodu baştan yazma dürtüsü duyuyordum. Ama sonunda bunun çok uzun süreceğini ve arkadaşlarımın ortaya çıkan işi anlayamayacağını fark ettim. Bu yüzden onların yaklaşımına sadece küçük düzeltmeler ekleyerek yardım ettim ve onlar bundan daha memnun kaldı. Bu deneyim sayesinde farklı bakış açılarını tanıdım ve kendi kodum da gelişti. Hatta asıl benim arkadaşlarıma teşekkür etmem gerektiğini düşündüm. Hâlâ önyargılarımı bırakmakta zorlanıyorum ama elimden geldiğince karşı tarafın bakış açısını ciddiyetle anlamaya çalışıyor, bazen de o yöntemin daha üstün olduğunu kabul etmeye uğraşıyorum. İlkeler aslında epey öznel şeylerdir; bu yüzden her zaman sadece ilkelere yaslanmak, durumu ciddiyetle düşünmeden tembelce yaklaşmak anlamına gelir
Junior bir mühendis bir şeyi verimsiz yapıyor olsa bile, onlara asla daha az optimize bir yöntem kullandıklarını söylemem. Bunun yerine her zaman neden böyle yaptıklarını sorarım. Her konuşmanın sonunda ikimizden biri mutlaka bir şey öğrenir. Ya ben yeni bir yöntem ya da onların gerekçesini öğrenirim, ya da onlar neden o yöntemin uzun vadede işlemediğini öğrenir. Hangisi olursa olsun, bu tür konuşmalar asla çatışmalı bitmez
“İyi zevk”in, harika API’ler ve iyi kodlar deneyimleyerek oluştuğunu düşünüyorum. İyi kodu görünce hemen tanıyabilirsin ve zamanla benim de öyle yazabiliyor olmam gerekir. Ama bu alana yeni girildiğinde iyi bir kodlama zevki geliştirmek zordur; deneyim sahibi olmak da mutlaka bu zevki kazandırmaz. Bu yüzden iyi zevki sürekli aramak, fark etmek ve taklit etmeye çalışmak gerekir
Önyargıdan, peşin hükümlerden ve katı düşünme biçimlerinden çıkış yolu eğitim ve kişinin kendi bakış açısının dışındaki çeşitli deneyimler biriktirmesidir. Başkalarının gözünden dünyayı anlamaya aktif olarak çalışmak gerekir ki insan ve profesyonel olarak gelişebilesin, bakış açın genişlesin. Benim gibi birçok alana ilgi duyan bir mühendis için, başka çözümler ya da bakış açıları olduğunu bilmek bile sorun çözme biçimimi değiştiriyor ve ilk içgüdüsel yaklaşımımdan daha iyi çözümler bulmamı sağlıyor
Bu yüzden farklı programlama dilleriyle denemeler yapmak iyidir. Şimdiye kadarki bakış açına sürekli meydan okuyan yeni dillere girince durmadan “hah!” diye aydınlanma anları yaşıyorsun. İlk başta tuhaf ya da yanlış görünebilir ama nedenini ve nasılını tam anlamadan önce bunun öyle olduğunu kabul etme süreci gerekir
Harika bir görüş. Bu düşünce biçimi, bizzat işe aldığım ya da birlikte çalıştığım ekip arkadaşlarına uyguladığım yaklaşım. Hedefe ya da sonuca ulaşılıyorsa, benim sürecimin ve ayrıntılarımın birebir uygulanması gerekmez. Farklı yollar olduğunu kabul ediyorum
Modadaki “iyi zevk”in, tek tek kıyafetlerden ziyade, özünde tek başına pek anlamı yokmuş gibi görünen parçaları bir araya getirip güçlü ve uyumlu bir his yaratmak olduğunu düşünüyorum. Yazının o yöne gideceğini ummuştum. Yazılım mühendislerinin zevkle verdiği kararların, gerçekten sadece teknik trade-off’lardan ibaret olmayıp “gerçek zevk alanı”na nasıl girdiğini daha çok irdelemek isterdim. Bu arada, yazının kendisi de kötü zevke bir örnek gibi geliyor. İçerik olarak her bölüm kendi başına gayet düzgün yazılmış, ama bütünüyle bir “görünüm” oluşturamadığı için yazı dağınık hissettiriyor. Bu yazara bir saldırı değil; konunun çok iyi olduğunu düşündüğüm için daha da geliştirilmesine dair fikrimi paylaşmak istedim
Tek bir kıyafetin kendi başına anlamsız olduğu fikrine katılmıyorum. Kıyafetler, bir kombin yapılmadan önce de kültürel, tarihsel ve sembolik anlam taşır. Moda, basit bir birleştirme işinden fazlasıdır. Ayrıca modada da üretim, giyim, eşleştirme gibi çeşitli trade-off’lar vardır
Merak ettiğin “güzelliği ve zarafeti nasıl algılıyoruz” sorusu antik çağlardan beri filozofların konusu ve tek bir yazıyla sonuçlandırılamayacak kadar büyük. Mimarlık alanından Christopher Alexander bunu derinlemesine incelemişti ve fikirleri yazılım mimarisini de büyük ölçüde etkiledi. Alexander nesnel güzellik diye bir şey olduğunu savunuyordu. Onun OOPSLA keynote konuşmasına ya da Roy Fielding’in doktora tezine bakmaya değer. Bu yazıda geçen “değerler”, Fielding’in tezinde “mimari özellikler” olarak daha sistematik biçimde ele alınıyor
İlginçtir ki ben bu yazının konuyu derinlikli ve sistematik biçimde ele alan, sık rastlanmayan derecede iyi bir metin olduğunu düşünüyorum
Mühendislikte bir karışım içinde gerçekten “zevk”in belirleyici olduğu anı, ve bunun yalnızca teknik trade-off’lardan ayrıldığı “zevk alanı”nı merak ediyorsun. Bana kalırsa birçok karar “teknik trade-off ama ya mutlak biçimde kanıtlanamaz ya da fark o kadar küçüktür ki pratikte önemsizdir” kategorisine giriyor. Yani kesin ayrım yapmak zorsa, bunu zevk meselesi olarak bırakıyoruz
Geliştiricilerin çoğunun genel olarak moda zevki zayıf ve bu yüzden iyi zevkin ne olduğunu da pek anlamıyorlar. Ayrıca teknoloji dünyasındaki şeylerin çoğu, teknoloji dışından insanlar için hiç de şık ya da havalı değil. Programlama dilleri havalı değil. Geliştirme dünyasında başlangıç noktası bile “havalı değil”den başlıyor ve oradan aşağı iniyor. Örneğin Rust, C++ gibi şeyler “havalı değil” kategorisinde; tuhaf fonksiyonel diller ya da Bash, Linux gibi şeyler ise “gerçekten hiç havalı değil” kategorisine giriyor
İyi zevk, sanki herkesin kolayca yazabileceği kadar güçlü bir sadelikte kod yazmaktır
Başka bir örnek paylaşayım. 72 model bir Dodge Challenger’ı söküp tekrar toplarken, bu arabanın ne kadar basit, doğrudan ve ucuz ama aynı zamanda ne kadar şaşırtıcı derecede iyi tasarlanmış olduğuna sürekli hayran kalıyorum. Mesela gösterge paneli gücü, arabanın genel voltajından (10~18V) ayrı olarak 5 volt gerektiriyor. Bunun için 5 voltun üstünde devreyi kesen, altında kapatan bir tür buzzer benzeri mekanizma (elektromıknatıs kullanıyor) var; hızlıca açılıp kapanarak ortalama 5 volt üretiyor. Çoğu kişi bunu elektronik voltaj regülatörüyle değiştiriyor ama sonra gösterge paneli çalışmıyor. Çünkü aslında gösterge paneli mekanik ve 5 volttaki küçük gürültü olmadan ibre sık sık takılıyor; tersine, bu “kaba” 5 volt takılmayı önlüyor. Elektronikle değiştirince bu kez bilinçli olarak biraz “gürültü” eklemek gerekiyor. Böyle basit bir mekanik düzeneğin hem etki hem sadelik açısından ne kadar üstün olduğuna hayranım
Bu tür basit kodun gerçek değeri, bakım yükünü azaltması ya da çalışanların zamanını kurtarması olsa da çoğu zaman gerektiği gibi takdir edilmiyor. KISS (Keep It Simple, Stupid) ilkesini uygulayan kod, değeri görünmüyor diye küçümsenebiliyor. Hatta bu yüzden, gerçekte gerekmeyen karmaşıklığı yönetmekten başka iş yapmayan ekipler ya da organizasyonlar bile var
Bazen mühendisin sıra dışı işler yapabilmesi güzeldir ama asıl önemli olan, başta zor görünse de sonunda sıradan ve basit çözümü sık sık bulabilen mühendistir
Bale izlerken hep “çok kolay görünüyor!” denir ama gerçekte bunu on binlerce kez çalıştıkları için gerçekten kolay yapıyorlardır
Karmaşık şeyleri gerçekten basit biçimde özetleyebilen insanlara her zaman en çok saygı duyarım. K&R C örnekleri kadar berrak olsun, ama keşke yorumlar biraz daha özenli bırakılsa
“Koda bir bakışta hakim olunabiliyor mu ve yeni bir mühendisi onboard etmek kolay mı?” sorusu düşünüldüğünden daha zor. “Yeni” denince 0 yıllık mı, 10 yıllık mı, 30 yıllık mı deneyim kastediliyor, belli değil. “Okunabilirlik” de birileri için net bir kavram gibi görünse de gerçekte 0’dan sonsuza uzanan bir spektrum. Maxwell denklemleri birine çok açık gelebilirken başkasına tamamen kapalıdır. Bu yüzden “kod okunması kolay olmalı” denince bunun tam olarak kim için söylendiğini hep sorguluyorum
Okunması kolay kod, okuyucuyu düşünerek bilişsel yükü en aza indiren koddur. Katmanlı soyutlamaların ve tasarım kalıplarının amacı da budur. Elbette hedef okuyucunun uzmanlığına ve kod tabanına aşinalığına göre değiştiği için özneldir. Ama öznel diye okunabilirliği bütünüyle reddetmek de fazla olur. Joyce’un Ulysses’i ile Seuss’un The Cat in the Hat’i eşit derecede kolay okunuyor denemez
“Okunabilirlik bir kavram değildir” iddiasına katılmıyorum. Okunamayan kod, ne yazarı (ya da AI) ne de başkası tarafından okunabilen koddur. Sadece yazarının okuyabildiği kod da yine kolay okunur sayılmaz
Maxwell denklemleri ortaya çıktığında gerçekten zordu ama bugün bildiğimiz biçim, Heaviside ve başkalarının bunu daha okunur hale getirmesiyle oluştu
Kodun bir kısmındaki “yerel okunabilirlik”in çok anlamlı olmadığını düşünüyorum. Kod tabanının genelinde kalıplar tutarlı biçimde uygulanıyorsa, bu kalıplar biraz karmaşık olsa bile bütün olarak oldukça okunabilir bir kod ortaya çıkabilir. Geçici karmaşıklık, genel kod kalitesini etkilemiyorsa sorun değil
Okunabilirlik çoğunlukla ‘accidental complexity’yi azaltmayı amaçlar. Film senaryosu gibi yazılmış bir formül de, karmaşık bir algoritma da, gösterimi kötüyse anlaşılması zor olur. Sonuçta “kod kimin için okunabilir olmalı?” sorusuna cevabım şu: İlgili alanda uzman bir mühendisin, probleme aşina olsa da kodu daha önce görmemişken okuyabilmesi gerekir. Bu biraz makaleler gibidir; ilgili araştırmacı grubu için okunabilir olmalıdır. No Silver Bullet özeti
“Kötü zevke sahip bir mühendis, sonunda yanlış yön gösteren bozuk bir pusula gibidir” benzetmesinin özü iyi anlattığını düşünüyorum. Böyle “öngörülebilir şekilde bozuk” insanları mülakatta ayıklayabilirsin. Asıl daha tehlikeli olan, “kısmen bozuk pusula”dır. Dışarıdan biraz sapıyor gibi görünür ama aslında hep tam 127 derece yanlış gösterir
Bu tür yazılar çoğu zaman iki meseleyi birbirine karıştırıyor. Birincisi, zevk ya da ilkelerden bağımsız olarak nesnel biçimde kötü kararlar vardır (örneğin bir listede O(n) arama yapmak yerine dictionary ile O(1) arama yapmak). Teknik olarak açıkça daha iyi ya da daha kötü olan durumlar vardır. İkincisi, geri kalan her şey trade-off’tur.
map-reducemü kullanacaksın yoksa sıradan bir döngü mü; burada performans durumu, okunabilirlik, uyumluluk gibi şeylere bakarsın. Bir seçeneğin mantıklı bir gerekçesi varsa, benim tercihimden farklı olsa da sorun etmem. Sorun, kararın yanlış olması ya da trade-off’un hiç düşünülmemiş olmasıdır. O zaman konu bakım alanına girer ve performans ya da kullanım sıklığı gibi bağlama göre bazen hiç dokunmamak da makul olabilir. Yeter ki o kararın arkasındaki “neden” net olsun. Bunun gerçekten “zevk” sayılıp sayılmadığından emin değilimBu yazının sorunu, “insanların önem verdiği değerler farklıdır” noktasını fazla bağlamsız ele alması. Oysa gerçekte bir mühendis, hangi değerlerin problem için en önemli olduğunu kabaca sezmeli; yani hangilerinin hard constraint olduğunu anlayabilmeli. Bu hard constraint’ler çıkarıldığında geriye kalan serbestlik alanına “zevk” demek daha doğru olur. Sanatçı benzetmesiyle, belirlenmiş malzeme ve ölçülerin dışında kişiye kalan ek kısıtlar ya da özgürlükler gibi. Yazılım mühendisinde iyi zevk, estetik olarak minimalizme ve öz disiplinde maksimuma yönelmekle benzeşiyor. Bana göre gerçekten “kötü zevk” dediğim durum, hiçbir gerekçe olmadan ilkeyi bozmak. Yani çoğu zaman sadeliği “alışkanlık”la karıştırmak söz konusu oluyor
Yazıdaki “değerler” bölümü, Roy Fielding’in doktora tezindeki yazılım mimarisi özellikleriyle bağlantılı. Fielding’in tezi daha çok REST ile tanınıyor ama aslında çok daha geniş ve sağlam bir yazılım mimarisi tartışması sunuyor. Birçok “mimari özellik” (ölçeklenebilirlik, okunabilirlik, bakım yapılabilirlik vb.) çerçevesinde düşünmeyi sağlıyor; ben de kişisel olarak bu özelliklerin yanı sıra ‘mimari kısıtlar’ın anlaşılmasının ne kadar önemli olduğunu vurgulamak isterim
Doğru dürüst mühendislik (Principled engineering) zaten olmazsa olmaz. Bunun üstünde hem iyi hem kötü zevk olabilir. Ama tersi geçerli değil. Mühendisliğin kendisi kötüyse zevkin bir anlamı kalmaz. Kötü zevk mühendisliğin verimini düşürebilir ama mühendisliğin kendisini imkânsız hale getirmez. Mühendislik temelde zevki destekleyen bir şeydir. Örneğin mükemmel mühendislikle yapılmış bir şey bile gereksiz ve istenmeyen bir şeyse anlamı yoktur
Kötü zevk sonunda kaçınmaya çalıştığımız belirsiz durumlara (X) sürükler. Bana göre iyi zevk, ileride gelecek belirsizliklere karşı kod tabanına sağlam temeller ve güvenlik korkulukları yerleştirmektir. Ancak böylece riske düşmeden ilerlenebilir
Gerçekten güzel
Orijinal metin de iyi ama yorumların içeriği de gerçekten çok iyi.
"Zevk" denince aklıma Torvalds’ın TED konuşması geliyor:
https://www.ted.com/talks/linus_torvalds_the_mind_behind_linux
14:20’den itibaren, linked list’te entry kaldırma kodunun uygulama biçimi üzerinden iyi zevk
Hacker News yorumunda bahsedilen “nesnel olarak kötü kararlar”ın (ör. listede
O(n)arama yerine sözlükteO(1)arama) bile bağlama göre farklı şekilde verilmesi gerekebilir.Arama yalnızca bir kez yapılacaksa, bir hash table oluşturmanın maliyeti listede
O(n)arama yapmaktan daha yüksek olabilir.Güzel bir yorum.