Google’ın Design Docs belge yazma kültürü (2020)
(industrialempathy.com)- Google’da Design Doc, kodlamadan önce problemin bağlamını, üst düzey uygulama stratejisini ve temel tasarım kararlarını derleyerek tasarım maliyeti düşükken riskleri azaltan bir belgedir
- Belgenin değeri, tamamlanmış kodu açıklamaktan çok trade-off’ları ve alternatifleri görünür kılarak organizasyonun aynı karar gerekçesini paylaşmasını sağlamasındadır
- İyi bir Design Doc; bağlam ve kapsamı, hedefleri ve hedef dışı kalanları, gerçek tasarımı, değerlendirilen alternatifleri, güvenlik·gizlilik·gözlemlenebilirlik gibi çapraz kesen konuları projeye uygun biçimde içerir
- Tasarım zaten açıksa veya belge yalnızca uygulama adımlarını sıralıyorsa, Design Doc yazma ve inceleme yükü sağlayacağı faydadan daha büyük olabilir
- Belge; yazım, inceleme, uygulama sırasında güncelleme, bakım ve öğrenme aşamalarına uzanır; yayın öncesinde tasarım değişirse belgenin de birlikte güncellenmesi iyi olur
Design Doc’un üstlendiği rol
- Google’da Design Doc, bir yazılım sistemi ya da uygulamasının başlıca yazarlarının kodlama projesine başlamadan önce hazırladığı nispeten gayriresmî bir belgedir
- Üst düzey uygulama stratejisini ve temel tasarım kararlarını içerir; ancak basit bir karar listesinden ziyade bu seçimlerin neden yapıldığını gösteren trade-off’lar önemlidir
- Yazılım mühendisliğinin amacı kod üretmek değil problem çözmek olduğundan, projenin başlarında serbest biçimli metin koddan daha kısa ve anlaşılır olabilir
- Design Doc, geliştirme yaşam döngüsünde çeşitli roller üstlenir
- Değişiklik maliyeti düşükken tasarım sorunlarını erkenden yakalar
- Organizasyon içinde tasarım mutabakatı oluşturur
- Güvenlik, gizlilik ve gözlemlenebilirlik gibi çapraz kesen konuların gözden kaçmamasını sağlar
- Kıdemli mühendislerin bilgisini organizasyon içinde yayar
- Tasarım kararlarına ilişkin kurumsal hafıza bırakır
- Tasarımcının teknik portföyünü özetleyen bir çıktı olur
Design Doc’un temel yapısı
- Design Doc için katı bir şablon yoktur; ilk ilke, belirli proje için en uygun formatı seçmektir
- Bununla birlikte sıkça yararlı olan yapı bağlam ve kapsam, hedefler ve hedef dışı kalanlar, gerçek tasarım, değerlendirilen alternatifler, çapraz kesen konular ve uygun uzunluk şeklinde özetlenebilir
-
Bağlam ve kapsam
- Yeni sistemin içinde yer alacağı ortam ve gerçekten ne inşa edileceğine dair kabaca bir genel bakış sağlar
- Bir gereksinim dokümanı olmadığından kısa tutulmalı, okuyucunun arka planı hızla yakalamasına odaklanmalıdır
- Bazı ön bilgiler varsayılabilir, ayrıntılar bağlantılarla verilebilir
- Bu bölüm nesnel arka plan gerçeklerine odaklanmalıdır
-
Hedefler ve hedef dışı kalanlar
- Sistemin hedeflerini ve bazen daha da önemli olan hedef dışı kalanları kısa madde işaretleriyle özetler
- Hedef dışı kalanlar, “sistem çökmemeli” gibi hedefin basit bir olumsuzu değil; hedef olabilecek ama açıkça kapsam dışında bırakılmış öğelerdir
- Veritabanı tasarımında ACID uyumluluğunun hedef mi yoksa hedef dışı mı olduğunu bilmek iyi bir örnektir
- Bir özellik hedef dışı olsa bile, hedeflere ulaşmayı engelleyen bir trade-off yaratmıyorsa o özelliği sunan bir çözüm seçilebilir
Gerçek tasarımı yazma biçimi
- Gerçek tasarım bölümü genel bakışla başlamalı ve ayrıntılara doğru ilerlemelidir
- Design Doc, yazılım tasarımında ortaya çıkan trade-off’ların kaydedildiği yerdir
- Bağlam olarak verilen gerçeklere, hedefler ve hedef dışı kalanlar olarak ifade edilen gereksinimlere dayanarak bir çözüm önermeli ve belirli çözümün hedefleri neden en iyi karşıladığını göstermelidir
- Belge formatının avantajı, problem kümesine uygun ifade biçimini esnek şekilde seçebilmesidir
-
Sistem bağlam diyagramı
- Birçok belgede system-context-diagram yararlı olabilir
- Bu diyagram sistemi daha büyük teknik ortamın bir parçası olarak gösterir ve okuyucunun yeni tasarımı zaten bildiği ortam içinde anlamasını sağlar
-
API ve veri depolama
- Tasarlanan sistem bir API sunuyorsa API’yi taslak olarak çizmek genellikle iyidir
- Biçimsel arayüzleri veya veri tanımlarını olduğu gibi kopyalayıp yapıştırmaktan kaçınılmalıdır
- Bu tür tanımlar kolayca uzar, gereksiz ayrıntılar içerir ve hızla eskime riski taşır
- Tasarım ve trade-off’larla ilgili kısımlara odaklanılmalıdır
- Veri depolayan sistemler, verinin nasıl ve yaklaşık hangi biçimde saklanacağını ele almalıdır
- Tüm şema tanımını yapıştırmak yerine tasarım kararlarıyla ilgili bölümleri açıklamak daha iyidir
-
Kod ve sözde kod
- Design Doc’a mümkün olduğunca az kod koymak iyi olur
- Yeni bir algoritmayı açıklama durumları dışında sözde kod da nadiren kullanılmalıdır
- Tasarımın uygulanabilir olduğunu gösteren bir prototip varsa uygun şekilde bağlantı verilebilir
Kısıt düzeyi belge biçimini değiştirir
- Yazılım tasarımını ve Design Doc’un biçimini etkileyen başlıca etkenlerden biri çözüm alanının kısıtlanma düzeyidir
- Bir uçta yalnızca hedeflerin olduğu ve çözümün herhangi bir şey olabildiği greenfield yazılım projeleri vardır
- Bu tür belgeler geniş bir kapsamı ele alabilir, ancak yönetilebilir bir çözüm kümesine daralmak için kuralları hızlıca tanımlamalıdır
- Diğer uçta olası çözümlerin iyi tanımlandığı, ancak bu çözümlerin hedefe ulaşmak için nasıl birleştirileceğinin net olmadığı sistemler vardır
- Değiştirilmesi zor bir legacy sistem olabilir
- Ana programlama dilinin kısıtları içinde çalışması gereken bir kütüphane tasarımı olabilir
- Bu durumlarda görece kolay yapılabilecek işleri listelemek mümkündür; ancak hedefe ulaşmak için bunları yaratıcı biçimde birleştirmek gerekir
- Birden fazla çözümün hiçbiri kusursuz değilse, belge tanımlanan trade-off’lara dayanarak en iyi yaklaşımı seçmeye odaklanmalıdır
Alternatifler ve çapraz kesen konular
-
Değerlendirilen alternatifler
- Bu bölüm, benzer sonucu makul biçimde sağlayabilecek alternatif tasarımları listeler
- Her tasarımın yarattığı trade-off’lara ve bu trade-off’ların nihai seçime nasıl götürdüğüne odaklanılmalıdır
- Seçilmeyen çözümler kısa ele alınabilir, ancak bu bölüm belgede çok önemlidir
- Okuyucuların merak edebileceği diğer çözümlerin proje hedefleri ışığında neden daha az tercih edilir olduğunu göstermelidir
-
Çapraz kesen konular
- Organizasyonlar bu bölüm sayesinde güvenlik, gizlilik ve gözlemlenebilirlik gibi çapraz kesen konuların her zaman dikkate alınmasını sağlayabilir
- Genellikle her konunun tasarımı nasıl etkilediğini ve nasıl ele alındığını açıklayan kısa bir bölüm olur
- Ekipler kendi durumlarında hangi konuları standart kabul edeceklerini belirlemelidir
- Google projeleri, önemi nedeniyle ayrı bir gizlilik Design Doc’u gerektirir ve gizlilik ile güvenlik için özel incelemeler vardır
- İncelemelerin tamamlanması projenin yayın zamanına kadar gerekir
- Tasarımın bunları baştan yansıtması için gizlilik ve güvenlik ekipleriyle mümkün olduğunca erken iş birliği yapmak en iyi uygulamadır
- Bu konular için özel belgeler varsa merkezi Design Doc ayrıntıları tekrarlamak yerine onlara referans verebilir
Uzunluk ve yazmanın gerekmeyebileceği durumlar
-
Uygun uzunluk
- Design Doc yeterince ayrıntılı olmalı, ancak meşgul insanların gerçekten okuyabileceği kadar kısa kalmalıdır
- Büyük projeler için yaklaşık 10~20 sayfa uygun nokta gibi görünür
- Bundan çok daha uzarsa problemi daha yönetilebilir alt problemlere bölmek daha iyi olabilir
- 1~3 sayfalık mini Design Doc’lar da mümkündür
- Kademeli iyileştirmeler veya çevik projelerin alt işleri için özellikle yararlıdır
- Uzun belgelerle aynı adımlar izlenir, ancak daha kısa tutulur ve sınırlı bir problem kümesine odaklanılır
-
Yazmanın gerekmeyebileceği durumlar
- Design Doc yazmanın bir yükü vardır
- Yazılıp yazılmaması; tasarım mutabakatı, dokümantasyon ve kıdemli incelemesi gibi faydaların belge oluşturma maliyetini aşıp aşmadığına bağlıdır
- Temel karar ölçütü tasarım probleminin belirsiz olup olmadığıdır
- Problem karmaşıklığı, çözüm karmaşıklığı veya her ikisi nedeniyle belirsiz olabilir
- Belirsizlik yoksa belge yazma sürecinin değeri düşüktür
- Belge fiilen bir uygulama kılavuzu ise Design Doc gerekli olmayabilir
- Yalnızca “bunu böyle uygulayacağım” deyip trade-off’ları, alternatifleri ve karar açıklamasını içermiyorsa doğrudan programı yazmak daha iyi olabilirdi
- Çözüm trade-off bırakmayacak kadar açıksa belgenin değeri düşüktür
- Design Doc yazma ve inceleme yükü prototipleme ve hızlı iterasyonla uyumlu olmayabilir
- Çevik metodolojiyi takip etmek, bilinen bir problemin çözümü üzerinde düzgünce düşünmek zorunda olmadığınız anlamına gelmez
- Prototiplemenin kendisi Design Doc yazmanın bir parçası olabilir ve “denedik, çalışıyor” ifadesi tasarım seçimi için güçlü bir gerekçe olabilir
Design Doc’un yaşam döngüsü
- Design Doc’un yaşam döngüsü dört aşamadan oluşur
- Yazım ve hızlı iterasyon
- İnceleme
- Uygulama ve iterasyon
- Bakım ve öğrenme
-
Yazım ve hızlı iterasyon
- Belge yazar tarafından tek başına veya ortak yazarlarla birlikte yazılır
- Ardından problem alanını en iyi bilen meslektaşlarla paylaşılır ve hızla yinelemeye tabi tutulur
- Meslektaşların netleştirme soruları ve önerileri belgeyi nispeten istikrarlı bir ilk sürüme götürür
- Google’da sürüm kontrolü ve kod inceleme araçlarıyla belge oluşturmayı tercih eden mühendisler ve ekipler de vardır, ancak Design Doc’ların büyük çoğunluğu Google Docs’ta yazılır ve iş birliği özellikleri yoğun kullanılır
-
İnceleme
- İnceleme aşamasında belge, ilk yazarlar ve yakın çalışma arkadaşlarından daha geniş bir okuyucu kitlesiyle paylaşılır
- İnceleme büyük değer katabilir, ancak ek yük tuzağına dönüşebileceği için dikkatli ele alınmalıdır
- Hafif yöntem, belgeyi daha geniş ekip e-posta listesine gönderip insanlara gözden geçirme fırsatı vermektir
- Tartışmalar çoğunlukla belgenin yorum dizilerinde gerçekleşir
- Ağır yöntem, yazarın belgeyi kıdemli mühendislerden oluşan bir okuyucu kitlesinin önünde sunduğu resmî tasarım inceleme toplantısıdır
- Google’daki birçok ekip bu tür incelemeler için düzenli toplantılar yapar
- Bu toplantıları beklemek geliştirme sürecini ciddi biçimde yavaşlatabilir
- En önemli geri bildirimi doğrudan istemek ve daha geniş incelemeyi ilerlemenin önünde bir engel hâline getirmemek bu etkiyi azaltabilir
- Google daha küçük bir şirketken tasarımları tek bir merkezi e-posta listesine göndermek ve kıdemli mühendislerin uygun olduklarında incelemesi gelenekti
- Bu yaklaşımın şirket genelinde nispeten tutarlı bir yazılım tasarım kültürü oluşturma avantajı vardı
- Mühendislik organizasyonu çok daha büyüdükçe merkezi yaklaşımı sürdürmek zorlaştı
- İncelemenin başlıca değeri, organizasyonun birleşik deneyiminin tasarıma yansıması için fırsat yaratmasındadır
- Özellikle gözlemlenebilirlik, güvenlik ve gizlilik gibi çapraz kesen konuların tasarımda dikkate alınmasını sağlamakta inceleme aşaması tutarlı biçimde yardımcı olur
- İncelemenin temel değeri sorunun bulunmasından çok, değişiklik maliyetinin düşük olduğu geliştirme yaşam döngüsünün erken evresinde bulunmasındadır
-
Uygulama ve iterasyon
- Ek incelemelerin tasarımda büyük değişiklikler isteme olasılığının düşük olduğuna dair güven oluştuğunda uygulamaya başlama zamanıdır
- Plan gerçeklikle karşılaştığında kusurlar, ele alınmamış gereksinimler ve yanlış olduğu ortaya çıkan varsayımlar belirebilir; tasarım değişiklikleri gerekebilir
- Bu durumda Design Doc’un güncellenmesi güçlü biçimde önerilir
- Pratik kural olarak, tasarlanan sistem henüz yayınlanmadıysa belge mutlaka güncellenmelidir
- Gerçekte insanlar belgeleri iyi güncelleyemez ve başka pratik nedenlerle değişiklikler çoğu zaman yeni belgelere ayrılır
- Sonuç, tek ve tutarlı bir belgeden çok değişiklik maddeleri eklenmiş ABD Anayasası gibi bir hâl alabilir
- Özgün belgeden bu değişiklik belgelerine bağlantı verilirse, daha sonra bakım yapacak programcının hedef sistemi Design Doc arkeolojisiyle anlamasına büyük yardımcı olur
-
Bakım ve öğrenme
- Bir Google mühendisi ilk kez dokunacağı bir sistemle karşılaştığında sık sorduğu ilk soru “Design Doc nerede?” olur
- Design Doc da diğer belgeler gibi zamanla gerçeklikten sapma eğilimindedir, ancak çoğu zaman sistemi oluştururken izlenen düşünce sürecini öğrenmek için en erişilebilir giriş noktası olur
- Yazarların 1~2 yıl sonra kendi Design Doc’larını yeniden okumaları iyi olur
- Neyi doğru bildiğini kontrol etmek
- Neyi yanlış bildiğini kontrol etmek
- Bugün olsa neyi farklı kararlaştıracağını düşünmek
- Bu soruları yanıtlama süreci, mühendis olarak gelişmeye ve zaman içinde yazılım tasarımı yetkinliğini iyileştirmeye yardımcı olur
Design Doc ile ne zaman başlanacağına karar vermek
- Design Doc, yazılım projelerindeki zor problemleri çözerken netlik kazanmanın ve mutabakat oluşturmanın iyi bir yoludur
- Ön araştırmayla önlenebilecek kodlama çıkmazlarını azaltarak maliyet tasarrufu sağlayabilir
- Aynı zamanda yazım ve inceleme zaman aldığı için maliyet de yaratır
- Şu sorular değerlendirilebilir
- Doğru yazılım tasarımı belirsiz mi ve güven kazanmak için önceden zaman harcamak mantıklı mı?
- Her kod değişikliğini inceleyemeyebilecek kıdemli mühendisleri tasarım aşamasına dahil etmek yararlı mı?
- Yazılım tasarımı belirsiz veya tartışmalı olduğu için organizasyonel mutabakat değerli mi?
- Ekip gizlilik, güvenlik, loglama veya başka çapraz kesen konuları tasarımda zaman zaman unutuyor mu?
- Organizasyon içindeki legacy sistem tasarımına dair üst düzey içgörü sağlayan belgelere güçlü bir ihtiyaç var mı?
- Bu sorulardan 3 veya daha fazlasına “evet” yanıtı veriyorsanız, Design Doc büyük olasılıkla bir sonraki yazılım projesine başlamak için iyi bir yöntemdir
1 yorum
Hacker News yorumları
Google’ın tasarım dokümanı kültürü yüzünden şirketten ayrıldım
İşe girdikten hemen sonra, başka ürün alanlarında birkaç kez yapılmış görece önemsiz bir işi çok üst düzeyde toparlayan bir doküman yazdım; bir iş arkadaşım beni ayrıca çağırıp “burada böyle yapmayız” dedi
Önerdiğim yöntem, tavsiye edilen yöntemin küçük bir varyasyonundan ibaretti; buna rağmen “bu işi başarmanın daha fazla yolunu değerlendir” dedi, nedenini sorunca da “geniş çaplı düşündüğünü gösterir” diye yanıtladı
Google’da sahte iş kesinlikle var; keşke başka bir ekibe girseydim
Google kültürü, kendi kendini taklit eden bir kargo kültüne dönüştü
Google’dan sonra çalıştığım bazı şirketler terfi süreçlerini ayrıntılı konuşmaktan kaçınıyordu; çünkü insanlar o sürece göre mikro-optimizasyon yapınca neler olduğunu görmüşlerdi
Herkes meşgul olduğu için herkesle hafif bir 1:1 görüşme yapmak mümkün değil; paydaş incelemesini düzgün alamazsanız öfkeli insanların gelip yayını geri aldırması muhtemel
Bu bağlamda tasarım dokümanı, bilgi yoğun konular için asenkron iletişim aracıdır. Ürün başarılı olursa 10 yıl sonra katılan insanlarla da bu doküman üzerinden konuşursunuz
Bugün hâlâ ayağımıza dolanan garip kararları açıklayan 2010’dan kalma rastgele tasarım dokümanları sayesinde birkaç kez kurtuldum. Çevik küçük ekiplere veya daha az karmaşık işlere pek uymayabilir; ama mühendislik kültüründe kargo kültüne dönüşmüş olsa bile çoğu zaman kendince bir nedeni ve bağlamı vardır
Bir şeyi tasarlarken değerlendirdiğiniz tek bir çözüm varsa ya ortada tasarım yoktur ya da yeterince titiz değildir. Tasarımı oluşturan şey seçenekler ve ödünleşimlerdir
Bu kişilerin çoğu şirketle 15 yıldan uzun süredir çalışan dış danışmanlar; aynı kişiler aynı işleri yaptığı için zaten bir ölçüde standart oluşmuş durumda. Buna rağmen “insanlar standardı takip etmezse ne olur” diye bir korkuluk argümanı yaratmaya çalışıyorlar
Sonuç olarak tasarım dokümanları ya yok ya da fena halde eskimiş durumda; şirket de her yıl aynı danışmanları şişirilmiş maliyetlerle işe almaya devam ediyor
Şimdi 15 yıldan fazla kıdeme sahip eski Googler’ların çok olduğu bir ekipteyim; tasarım dokümanları yalnızca gerektiğinde var. Birden fazla sisteme yayılan işler veya çok fazla ödünleşim içerdiği için bariz biçimde karmaşık olan durumlar gibi. Bunun dışında sadece “CL’leri yazın” deniyor
Google’da tasarım belgeleri terfi dosyasına giren temel materyallerden biri olduğu için sorun çıkıyor gibi görünüyor
Bu yüzden belgeler, asıl okuyucusu olan ilgili sistem üzerinde çalışanlardan çok terfi komitesini düşünerek yazılıyor
Her yeni şirkete girdiğimde tasarım belgeleri yazmaya başlamayı öneriyorum; bu da yönetimde hemen iyi bir izlenim bırakıyor :)
Okuduğum birçok belge, istenen kararı zaten önceden belirlemiş; belgenin başına da o kararı göstermek için uydurulmuş iki veya daha fazla seçenek eklemiş gibi görünüyordu. Biri fazla basit, biri gereksiz ölçüde aşırı tasarlanmış olacak şekilde karşılaştırılıp, sonra makul görünen seçenek seçiliyor
Hangi tasarım belgesinin terfi dosyasında kullanılacağını bilmedikleri için en küçük işi bile tasarım belgesi olarak bırakıyorlar. 1 sayfalık tasarım belgesi diye bir kavram var ama genelde bir sayfadan birkaç sayfaya büyüyor
1 haftalık projeler için bile tasarım belgesi yazılıyor; başka bir şirkette tek bir JIRA biletiyle bitecek şeyler için 20, 30, 40 sayfalık tasarım belgelerini incelemek zorunda kaldığım da oldu
Birçok kişi terfi komitesinin “yazarı tek başına yazmış belge” görmek istediğini öğrenmiş; bu doğru olsun ya da olmasın, bu inanç her şeyi yavaşlatıyor ve çapraz öğrenmeyi engelliyor. Bir çeyrekten uzun süre izole kalıp sadece tasarım belgesi yazan yazılım mühendisleri de gördüm
Tasarım belgesinde asıl odak gerçek tasarım olmalı, ama geri kalan %99 problem tanımı oluyor. İnceleme sırasında problem tanımını iyileştirirken tasarımı çöpe atıp belgenin çoğunu yeniden yazmak zorunda kaldığımız çok oldu
En kötüsü, problem tanımını iyileştirince karmaşık bir tasarım gerektirmeyen basit bir çözümün ortaya çıkması. Yazar karmaşık tasarıma çok zaman yatırmış oluyor ve tarihsel olarak birçok komite bu karmaşıklığı terfi gerekçesi saydığı için basit çözüme direniyor
Hiç alternatif içermeyen tasarım belgeleri de gördüm. Sadece yapılması gereken işi ya da birinin yapmak istediği şeyi emek yoğun biçimde yazıya dökmekten ibaretti
Böyle olunca tasarım belgeleri, uzaktan bakıldığında bir bug takip sistemine dönüşüyor. Herkes kendi tasarım belgesi üzerinde çalışıyor, bug’lar üzerinde çalışmıyor. Çünkü bug’larla terfi edemezsiniz
Yeni bir ekibe girince sadece tasarım belgelerine bakmanın yeterli olduğu söyleniyor, ama pratikte bunlar çoğu zaman merkezi olarak takip edilmiyor. Birçok ekipte tasarım belgeleri ekibin ya da projenin değil, bireylerin mülkü; çünkü başkalarının katkı yapmadığını garanti edebiliyorlar, bu da yine terfi komitesi yüzünden
Erişim iznim olmayan birçok tasarım belgesi de var; çok gizli olduklarından değil, sadece öyle ayarlanmış. Ekipte iki üç tasarım belgesi yok; okunması gereken dağ gibi belge var. Google’daki iş değiştirme döngüsünün yaklaşık 2 yıl olduğu düşünüldüğünde, birçok belge zaman içinde kayboluyor
Başka bir şirkette bu, yeni ekibe gelen birine “gerekeni öğrenmek için kapatılmış tüm bug’ları oku ya da ana branch’teki tüm commit mesajlarını oku” demeye benzerdi
Başka bir yerde olsaydı, öğle yemeğinden sonra ekip tarafından yakalanıp birkaç saat boyunca whiteboard başında problem tanımlanırdı. Kıdemliler, gençlere bu tür problemleri nasıl düşünmeleri gerektiğini gerçek zamanlı öğretir ve hızlıca iterasyon yapardı
Çoğu şey bug takip sistemine yazılırdı; büyük bir işse proje wiki’sine ya da klasörüne konur ve herkesin ortak mülkiyetine verilirdi
Yukarıdaki sorunların hepsi iyileştirilebilir ve gerçekten iyileştirmeye de çalıştım, ama kültür yavaş değişiyor. Tasarım belgesi kavramının kendisi iyi, ancak tuzakları var; Google’daki birçok kişinin bunu kullanma biçimi doğru cevap değil
Maliyetinden daha fazla değer üreten tasarım belgelerini özlüyorum
Genel olarak bu stratejinin işe yaradığını görmedim
Öte yandan bağlam sağlamak için, ekibin ne yaptığı, ne yapmakta olduğu, problemin ne olduğu gibi şeyleri derleyen uzun belgeler vardı; bunlar da uzun ve abartılı olma eğilimindeydi
Bahsedilen şirkette çalışıyorum ama yazarla aynı deneyime sahip değilim
Tasarım belgelerinin birçok türü var; bunların içinde işe yarayanına rastlamadım. Google’da yararlı bir tasarım belgesi gördüğüm nadirdir. Tasarım belgeleri, prosedüre fazlasıyla odaklanan mühendisler içinmiş gibi geliyor
Gördüğüm türler kabaca şöyle: Terfi için tasarım belgesi, neyi çözmeye çalıştığını açıklamaz; sadece bu projenin ne kadar harika olduğunu ve şirketi nasıl daha iyi hâle getirdiğini anlatır. Mantıksal sonuç, yazarın terfi etmesi gerektiğidir
Turbo encabulator tasarım belgesi, ilk kez görülen terimlerle dolu teknik gevezelik belgesidir; ekibin kıdemlisi değilseniz anlayamazsınız. Bazen kıdemlilerin bile anlayıp anlamadığından emin olamıyorum
Yeni mezun tasarım belgesi, içeriği olmayan ama üniversiteden yeni çıkmış birinin neyi kanıtlamaya çalışıyorsa onu olabildiğince uzattığı belgedir. Bilgi aktarmaz; çoğu zaman önceden yazılmış kodu büyük bloklar hâlinde kopyalayıp yapıştırarak yaklaşık 70 sayfayı doldurur
Uydurma gerçekler tasarım belgesi “herkes bilir”, “herkes öyle der” ifadeleriyle doludur. Bir politikacı kadar bariz olmasa da “bu iyi uygulamaları izler”, “bu yazılım yavaş, dolayısıyla…” gibi ifadelerle kendi tasarımını dayatır. İyi uygulamayı kimin tanımladığı, neden iyi uygulama olduğu, neyin yavaş olduğu, ölçülüp ölçülmediği, bunun son kullanıcı hissi olup olmadığı eksiktir
Gördüğüm tasarım belgelerinin %99’u böyleydi. İstisnalar var ama deneyimime göre çok nadir. Yazarın bu pratiği zorlaması şaşırtıcı. Gerçi mühendis değil direktördü; o pozisyonda tasarım belgeleri mantıklı gelebilir, yine de böyle insanların ne değer kattığını hâlâ bilmiyorum
[1] https://en.wikipedia.org/wiki/Turbo_encabulator
İlk zamanlarda dikkatimi çeken şey, Google Docs’ta tutulan tasarım belgelerinin sürüm kontrol deposundakilere kıyasla daha düşük kalitede olma eğilimiydi. Bunun yazıldıkları dönemin dolaylı bir göstergesi mi olduğunu, yoksa kod inceleme sürecinin Docs düzenlemesinden daha sıkı olmasından mı kaynaklandığını bilmiyorum
Büyük bir tasarım belgesi, sanırım yaklaşık 40 sayfa, yazdığımda gelenek gereği elle yazılmış HTML olarak hazırlayıp kod inceleme sisteminden geçirdim. Merkezi posta listesine ve web sunucusuna da koydum; 3 numaralı çalışandan geri bildirim almak da güzeldi. Merkezi konumda kategorilere göre sıralandığı için bulması kolaydı
O zamanlar tek bir tasarım belgesinin terfide önemli olacak kadar büyük bir ağırlığı olduğunu hatırlamıyorum. Terfi belirli bir çıktıdan ziyade genel etkiyle ilgili olmalıydı. Elbette sistemin büyük kusurları vardı ve kötü anlamda şaşırtıcı kararlar da sıkça çıkıyordu; ama o dönemde performans değerlendirmesine göre optimize edilmiş tasarım belgeleri okuduğumu hatırlamıyorum
Eski elle yazılmış HTML tasarım belgelerinin toplandığı web sitesini bulabilirseniz göz atmanızı öneririm. O sistemlerin faal olduğu dönemde daha faydalı gelmiş olabilir
SmartASS gibi eski belgelerin bazıları temel denklemler ve modellere dair ayrıntılı açıklamalarla doluydu; nasıl çalıştığını ve neden o yaklaşımın seçildiğini anlamakta çok yardımcı olmuştu. Daha sonra kendi tasarım çalışmamı da etkiledi. Direktör değil, sıradan bir mühendistim ve gerçekten işime yaradı
chromium.org sitesinden bağlantı verilen Chrome tasarım belgeleri arasında da geçmişte yapıyı anlamama yardımcı olanlar oldu
Junior geliştiricinin çözümü önceden düşünmesini ve kararlarını gerekçelendirmesini sağlar; kıdemli geliştiricinin de bu kararları doğrulayıp asenkron geri bildirim verebilmesine imkân tanır
Ancak ben hep startup’larda çalıştım, bu yüzden 30~40’tan fazla mühendisi olan organizasyonlarda çalışmadım. Big Tech farklıdır ama benim deneyimim olumluydu
Benzer şekilde başka bir mühendise anlatmak uzun sürüyorsa, en azından 30 dakika kadar bile olsa, zaman kazanmak için belge yazmalısınız
Nasıl hiç belge yazmaya gerek olmadığını düşünebildiğinizi anlamıyorum
Daha sonra terfiye hazırlanırken 2. kategorideki belgeye yeterince bağlam ekleyip onu 1. kategoriye dönüştürüyorsunuz
Dokümantasyon genel olarak iyi, ama bu yaklaşım kusurlu görünüyor
“Kodlama projesine başlamadan önce” bir yazılım sistemi veya uygulamanın ana yazarının nispeten gayriresmî bir belge oluşturduğundan söz ediliyor; oysa tasarımın kendisi kodlama projesidir ve ikisi aynı iştir
Kodu commit etmeden önce tasarımı kâğıt üzerinde tamamen çözebileceğiniz fikri yanlıştır. Tasarım belgesi yaklaşımı da aslında başta biraz kod yazılması gerektiğini kabul eder, ama bunu “tasarımın uygulanabilirliğini gösteren prototip” diye katı biçimde ayrı bir bölmeye koymaya çalışır
Ön tasarım belgesinin büyük özelliği, asıl kodlamadan önce insanların kusur aramasına, yani review yapmasına izin vermesidir. Deneyimime göre bu olunca belge giderek daha fazla kayıt ve anlamsız alternatif tartışmasıyla şişer; tasarım belgesinden çok “lütfen artık bunu yapmama izin verin” belgesine dönüşür
Yön değişikliği gerektiren önemli bir mimari sorun varsa, ayrıntılı bir tasarım belgesi hazırlayıp sonra vurulmasını beklemektense doğru kişilerle önceden konuşmak ve işbirliği yapmak daha iyidir
“Nispeten gayriresmî belge” fikrine daha yakın kalıp ilerledikçe belgeyi güncellerseniz gerçekten yararlı olabilir. Çünkü çalışan bir sistemle birlikte yararlı bir belge de oluşturabilirsiniz. Ancak bu, tasarım belgesinden çok sürekli ve işbirlikçi bir sürecin parçası olarak dokümantasyon yapmaya daha yakındır
Google çalışanıyım. Birkaç makale de yayımladım ama eskiden tasarım dokümanı yazmaktan hoşlanmazdım. Birkaç yıl önce bunun bana sağladığı başlıca faydaları fark ettim.
Fikrin ilk akla gelen kısımlarını kafamdan boşaltıp daha derin noktalara ve üretken değerlendirmelere geçmemi sağlıyor.
Kusurlar daha görünür oluyor; özellikle de benim için.
Düşünceleri paylaşmak kolaylaşıyor; özellikle başka ofislerdeki insanlarla paylaşmak için iyi. Genelde çok iyi geri bildirim veriyorlar.
Doğrudan kodlamaya başladığıma kıyasla gereken iş miktarını çok daha iyi kavramamı sağlıyor.
Kodlamadan önce öğrenmem gereken şeyleri, komşu sistemleri ya da uygun teknoloji seçimlerini genellikle ortaya çıkarıyor.
Terfi için de iyi ama başarılı bir proje daha iyi. Dokümanlarımın faydalı olduğunu sıkça duyduğum için doğru bir yol bulmuş gibiyim.
Gerçekten işe yarıyor mu? Alternatiflerinden daha mı iyi? Bu tartışma nerede?
Amazon’da çalıştığım dönemde tasarım dokümanı kültürü harikaydı. Sonraki iş yerim Google’ın mühendislik kültüründen ya da SF’deki genel startup kültüründen ödünç almış gibiydi; tasarım dokümanı süreci ise işe yaramaz bir şaka gibiydi.
Daha geniş çalışma kültürüne bağlı bir mekanizmadır. Tek başınıza çalışıyorsanız lüks bir alıştırmadır; dev bir ekipteyseniz ekibin daha geniş uzmanlığından yararlanmayı sağlar ve dokümantasyon işlevi de görür.
Birkaç başarısızlık biçimi var. Sonuç yerine çıktıya değer vermek tipik bir uyumsuzluktur. Terfi için 40 sayfalık doküman yazmak gibi; derin mühendislikten ziyade cümleleri arka arkaya dizebildiğini kanıtlayan çok junior durumlar dışında pek işe yaramaz.
Tek başına çalışan ekipler için fazla kaçması da var. Diğer küçük ekipler, örneğin Jira gibi issue’lar ve fikirleri birlikte gözden geçirmeye ayrılmış ayrı bir oturumla da yeterince iletişim kurabilir.
Mühendislerin de etkili tasarım dokümanı yazma konusunda onboard edilmesi gerekir. İlk denemesi hemen övgü almadı diye hayal kırıklığı yaşayan üstteki yorum bunun bir işareti olabilir.
Kod hakkında yazmak zordur ve HN’de genelde bu tür alıştırmalar övülür. Bir ekipte çalışıyorsanız, yaptığınız işin her zaman paylaşılabilir bir dokümanla açıklanması ve derinlemesine düşünülmesi gerekmeyen işlerden ibaret olduğunu hissettiğinizde dikkatli olmalısınız.
Büyük bir yatırımcı kimliğini gizleyip birkaç hafta Google mühendisi olarak çalışsa, hemen Sundar’ın görevden alınmasını isteyen aktivist yatırımcıya dönüşür.
Google’ın tasarım dokümanı kültürü yüzünden boşa harcanan insan potansiyelinin ölçeğini anlamak neredeyse imkânsız.
Geliştirmenin çoğu öylece ilerliyor; ara sıra bir CL’yi gerekçelendirmeyi kolaylaştırmak için aceleyle doküman yazılıyor.
Yaklaşık 10’da 1’inde birinin işi aşırı abarttığını görüyorum ama ortalama bir yazılım mühendisi için büyük bir zaman kaybı değil.
Mümkün olduğunca çok para yakmak isteseydiniz şirketi tam da böyle tasarlardınız gibi geliyor.
Tasarım dokümanı kültürü herkesi kendi işi için bir gerekçelendirme katmanına itme eğiliminde. Gerekçelendirme kültürü, meslektaşlar tarafından kültürel olarak pekiştirilse bile yenilikçiler için oldukça baskıcı bir kalıp.
Bu sistem vizyoner denemeleri ve iddialı projeleri engelleme eğiliminde. Uzlaşı odaklı olmayan çabalar bastırılıyor; “izin verilen normların dışında” düşünürseniz grup tarafından cezalandırılıyorsunuz.
Bu tür sistemler grup düşüncesi doğurur; “bizim çalışma biçimimiz” denen gelenek merkezli karakteri de farklı şekilde çalışmanın kariyer açısından riskli hale gelmesini özünde dayatır.
Silikon Vadisi’nde ‘çevik’ ve ‘tasarım odaklı düşünme’ terimleriyle paketlenmiş klişelere yaslanan her tür şirket kültürü var; çoğu zaman ‘doğru yöntem’ gibi davranan bir kurumsallaşmaya yakın ve o kampüsün ulaştığı mühendislik tarikatı kültürü varyantını toplumsal olarak dayatan ek unsurlarla geliyor.
Google’da çalışmak çok rahat olmasına rağmen kariyerini sınırladığını düşündüğü için ayrılan sayısız insanla tanıştım; sayıları hiç de az değil.
Orada yaşadığım hayal kırıklığını tam olarak ifade etmişsin. Yine de o ücreti tekrar almak isterdim.
Çeviklik konusuna gelince, ben yaklaşık 20 yıl önce eXtreme Programming biçiminde çeviklikle tanıştım; bugünkü SCRUM ya da onun taklitleri olan kargo kültlerinden tamamen farklıydı.
Sonuçta geliştiriciye yaratıcı güç veren, yöneticilerin yönteme karışmasını engelleyen ve işin yapılmasını sağlayan bir ilkeler demetiydi. Buna karşılık müşteriye neyin, ne zaman ve ne ölçüde yapılacağını söyleme yetkisi veriyordu.
Tahmini geliştirici bizzat yapar; “ihtiyaç duyulmayacak şeyi inşa etme” ilkedir. Büyük bir ön tasarım yoktur; refactoring ve test, mimari ve tasarım ayrı story ya da görevler değil, standart en iyi uygulamalar olarak sürekli overhead’in parçasıdır.
Planlama toplantısı, ekip arkadaşlarının odada birlikte hizalanmasıdır; story’ler beyaz tahtadaki post-it’lerde asgari düzeyde teknik olmayan terimlerle ifade edilir. Standup gerçekten insanların çember şeklinde ayakta durup başkalarının ilgisini çekebilecek kadar çok kısa güncelleme vermesidir; bugün işe geldiğini kanıtlama ya da gösteriş yapma ritüeli değil.
Bu sistemde tasarım, uzmanlardan oluşan yaratıcı bir grubun birlikte çalışırken ortaya çıkan bir özelliğidir. Tasarım dokümanlarını dışlamaz ve mimari tartışmaları hâlâ içerir; ancak açık bir PRD/tasarım dokümanı süreci gerektirmez.
Böyle bir yerde tekrar çalışmak isterim. Google bunun tam tersiydi ve her şey çok uzun sürüyordu.
Bu tür sahte “biz çok zekiyiz” davranışı da bir boşa iş biçimi. Şirket gerçekten çalışan ürünlere odaklanmalı ve kendini bununla değerlendirmeli.
Ben de bir başka Googler’ım
Google’ın tasarım dokümanlarının işe yaramaz olduğuna dair zaten çok sayıda iyi yorum var, ama bunun neden sorun gibi göründüğüne dair bir bakış açısı daha eklemek istiyorum
Tasarım dokümanları, belirtildiği gibi terfi materyali olduğundan, muazzam miktarda gereksiz dolgu üretiyor. Üstelik gerçek dokümantasyonun yerini alıyormuş gibi de görünebiliyor
Tüm tasarım dokümanları tamamlandığı anda neredeyse eskimiş oluyor, ama ekipler yeni dokümantasyon yazmak yerine o tasarım dokümanına işaret ediyor. Sonuç olarak Google’ın dokümantasyonu oldukça kötü ve güncelliğini yitirmiş durumda
Açıkçası “yapılmamış iş” hakkında 20 sayfa yazmak yerine, gerçekten var olan bir şeyin nasıl kullanılacağını anlatan 2 sayfalık bir kullanım açıklaması yazmak terfi materyali olsaydı çok daha iyi olurdu
Gerçek dokümanları görebiliyor muyuz? Yazılım tasarım süreci dokümanları en sıkı korunan sırlar gibi görünüyor. Vaka çalışması için kullanılabilecek gerçek bir doküman hiç görmedim
Kubernetes: https://github.com/kubernetes/enhancements/tree/master/keps
Örnek: https://rfd.shared.oxide.computer/rfd/0177
Ana dizin: https://rfd.shared.oxide.computer