Software Engineering at Google Kitap Özeti. Devam edecek...

Camille Fournier, "Software Engineering at Google" kitabının önsözünde, Google'da yazılım mühendisliği yapmanın ayrıntılarına olan sonsuz ilgisinden bahseder. Google'da çalışmış ya da oradan ayrılmış mühendislerle çalışmanın, onun bu konudaki merakını daha da artırdığını ifade eder. Google'ın büyük kod havuzunu nasıl yönettiğini, binlerce projede on binlerce mühendisin nasıl başarılı bir şekilde işbirliği yaptığını ve sistemlerinin kalitesini nasıl koruduklarını merak eder.

Kitap, Google'da yazılım mühendisliği yapmanın arkasındaki pratikler, araçlar ve kültürel unsurların uzun bir rehberini sunar. Sadece araçların inanılmaz detaylarına odaklanmak yerine, Google takımlarının izlediği felsefe ve süreçleri de açıklar. Bu süreçler, ölçek ve araçlara sahip olup olmamanıza bağlı olmaksızın çeşitli durumlara uyarlanabilir. Fournier, otomatik test konusundaki derinlemesine tartışmalardan özellikle memnun olduğunu belirtir, çünkü bu konu endüstride hala fazla dirençle karşılaşmaktadır.

Fournier, Google'ın yazılım mühendisliği organizasyonunu tam olarak kopyalamanın aptalca olacağını, ancak bu kitabın, test etme, bilgi paylaşımı ve işbirlikçi takımlar oluşturma gibi en iyi uygulamaları benimseme argümanlarınızı desteklemek için kullanılabilecek fikirler ve bilgiler sunacağını ifade eder. Google gibi bir şirketi kurmanız gerekmeyebilir ve onların tekniklerini kendi organizasyonunuzda uygulamak istemeyebilirsiniz, ancak Google'ın geliştirdiği pratiklerle tanışmamışsanız, yirmi yılı aşkın süredir on binlerce mühendisin yazılım üzerinde işbirliği yaparak kazandığı yazılım mühendisliği perspektifinden mahrum kalırsınız. Bu bilgi, göz ardı edilemeyecek kadar değerlidir.

Preface 

Bu kitap, "Google'da Yazılım Mühendisliği" başlığını taşımaktadır ve yazılım mühendisliğinin ne olduğunu, "programlama" ve "bilgisayar bilimi"nden nasıl ayrıldığını ve Google'ın geçmiş 50 yıl boyunca yazılmış yazılım mühendisliği literatürüne neden benzersiz bir perspektif ekleyebileceğini açıklar. "Programlama" ve "yazılım mühendisliği" terimleri endüstride bir süredir birbirinin yerine kullanılmaktadır, ancak her terimin farklı bir vurgusu ve anlamı vardır. Üniversite öğrencileri genellikle bilgisayar bilimi okur ve "programcı" olarak kod yazmaya başlarlar. Ancak "yazılım mühendisliği", teorik bilginin gerçek ve hassas bir şey inşa etmek için uygulandığı daha ciddi bir alanı ifade eder.

Yazılım mühendisliği, sadece kod yazmayı değil, bir organizasyonun kodu zamanla oluşturmak ve sürdürmek için kullandığı tüm araç ve süreçleri kapsar. Bu kitap, Google'ın son iki on yılda edindiği kolektif deneyimle, kodu uzun vadede değerli tutacak uygulamaların neler olabileceği konusunda ışık tutmayı amaçlar. Yazılım mühendisliğini "zamana göre entegre edilmiş programlama" olarak düşünebiliriz; yani kodumuzu, hayat döngüsü boyunca gerekli değişikliklere adapte olacak şekilde nasıl sürdürülebilir hale getirebiliriz?

Kitap, tasarım, mimari ve kod yazımı sırasında yazılım organizasyonlarının aklında bulundurması gereken üç temel ilkeyi vurgular: Zaman ve Değişim, Ölçek ve Büyüme, ve Maliyetler ve Tercihler. Google, sürdürülebilir bir yazılım ekosisteminin büyümesi ve evrimi konusunda benzersiz bir perspektife sahiptir. Bu kitapta kültür, süreçler ve araçlar olmak üzere Google'ın yazılım mühendisliği manzarasının üç ana yönü ele alınmıştır.

Google'ın kültürü, mühendislik kültürünün geliştirilmesinde öğrenilen derslerin geniş olarak uygulanabilir olduğunu gösterir. Süreçler bölümü, Google'ın büyük boyutu ve uzun ömürlü kod tabanı sayesinde en iyi uygulamaları geliştirme konusunda stres testi sağlar. Araçlar bölümü ise, Google'ın yatırımlarını nasıl lehine kullandığını ve kod tabanının büyümesi ve yaşlanması sürecinde nasıl fayda sağladığını gösterir. Kitap, yazılım mühendislerinin iş başında öğrenmesi gereken dersleri açıklar ve Google'ın iyi tavsiyeler üzerinde bir tekel olmadığını belirtir. Google, bu kitapta yer alan kavramları hala kusursuz bir şekilde uygulamamakta ve hatalar yapmakta, ancak mühendislik organizasyonunun büyüklüğü her sorun için çeşitli çözümlerin varlığını garanti eder. Bu kitap, bu çeşitliliğin en iyisini içerir ancak yazılım tasarımı gibi bazı önemli konuları kapsamaz; bunun yerine daha çok mühendislik üzerine odaklanır.

What Is Software Engineering?

Titus Winters, "Software Engineering at Google" kitabında yazılım mühendisliği ile programlama arasındaki temel farkları zaman, ölçek ve oynanan tercihler olarak açıklar. Yazılım mühendisliğinde, mühendislerin zamanın geçişi ve değişim ihtiyacı, ölçek ve verimlilik, ve karmaşık kararlar alma gibi konularla daha fazla ilgilenmeleri gerekir. Google, "yazılım mühendisliğini zamanla entegre edilmiş programlama" olarak tanımlar. Bu, yazılım mühendisliğinin sadece kod yazmayı değil, kodu üretmek ve sürdürmek için kullanılan tüm araç ve süreçleri kapsadığı anlamına gelir.

Kitap, yazılımın sürdürülebilir olmasını, teknik veya iş gereksinimlerine bağlı olarak değerli herhangi bir değişikliğe yanıt verebilme yeteneği olarak tanımlar. Google'ın deneyimi, kodun beklenen ömrü boyunca sürdürülebilir olmasının önemini ve bu sürdürülebilirliği sağlamanın yollarını vurgular. Yazılım mühendisliğinin programlamadan farkı, kodun zamanla yönetilmesi, ölçek etkileri ve karar verme süreçlerindeki karmaşıklıktır. Yazılım mühendisliği, programlama anında kod üretmekten çok daha fazlasını içerir; aynı zamanda kodun kullanışlı olduğu süre boyunca bakımını da içerir ve bir ekip çalışması gerektirir.

Kitap ayrıca, her organizasyonun tekrar tekrar yapması gereken her görevin insan girdisi açısından ölçeklenebilir (lineer veya daha iyi) olması gerektiğini belirtir. Politikalar, süreci ölçeklenebilir kılmak için harika bir araçtır. Süreç verimsizlikleri ve diğer yazılım geliştirme görevleri yavaş yavaş ölçeklenir, bu nedenle kaynar kurbağa problemlerine dikkat edilmesi gerekir. Uzmanlık, ölçek ekonomileriyle birleştirildiğinde özellikle iyi bir getiri sağlar. "Çünkü ben öyle dedim" bir şeyleri yapmak için korkunç bir nedendir. Veriye dayalı olmak iyi bir başlangıçtır, ancak gerçekte çoğu karar bir miktar veri, varsayım, emsal ve argüman karışımına dayanır. Objektif verilerin bu girdilerin çoğunu oluşturması en iyisidir, ancak nadiren hepsini oluşturabilir. Veriye dayalı olmak zamanla, veriler değiştiğinde (veya varsayımlar çürütüldüğünde) yön değiştirme ihtiyacını içerir. Hatalar veya revize edilmiş planlar kaçınılmazdır.

How to Work Well on Teams

Brian Fitzpatrick, "Google'da Yazılım Mühendisliği" kitabında, yazılım geliştirme sürecinde takım çalışmasının önemine odaklanır. Fitzpatrick, başarılı ve verimli bir yazılım mühendisi olmanın, insanlarla ilgili sorunlara daha az enerji harcayıp daha fazla zamanı harika kod yazmaya ayırmayı gerektirdiğini vurgular. Yazılım geliştirmenin bir takım çabası olduğunu ve mühendislik takımlarında veya diğer yaratıcı işbirliklerinde başarılı olmak için davranışları alçakgönüllülük, saygı ve güven temel prensipleri etrafında yeniden organize etmenin gerekli olduğunu belirtir.

Fitzpatrick, yazılım mühendislerinin genellikle kodlarını saklama eğiliminde olduklarını ve bu davranışın altında yatan nedenin güvensizlik olduğunu açıklar. Güvensizlik, insanların işleri eleştirilmekten korkması ve işlerinin başkaları tarafından yargılanmasından çekinmesinden kaynaklanır. Yazılım geliştirme sürecindeki güvensizliğin, daha büyük bir problemin belirtisi olduğunu ve bu problemin "Deha Mitosu" ile bağlantılı olduğunu belirtir. "Deha Mitosu", bir takımın başarısını tek bir kişiye/lider atfetme eğilimimizdir.

Fitzpatrick, yazılım mühendisliğinin takım çalışması gerektiren bir çaba olduğunu ve yalnızca bir dehanın değil, takımdaki herkesin katkılarıyla başarıya ulaşılabileceğini vurgular. Takım çalışmasının önemine dikkat çekerken, etkili takım çalışmasının üç temel direği olan alçakgönüllülük, saygı ve güveni geliştirmenin önemini vurgular.

Alçakgönüllülük, kendini evrenin merkezi olarak görmemeyi, açık fikirli olmayı ve kendini geliştirme isteğini içerir. Saygı, çalışma arkadaşlarına gerçek bir ilgi duymayı ve onları nazikçe davranmayı, yeteneklerini ve başarılarını takdir etmeyi gerektirir. Güven ise, diğerlerinin yetenekli olduğuna ve doğru şeyi yapacaklarına inanmayı ve uygun olduğunda onlara yönetimi bırakmayı içerir.

Fitzpatrick, yazılım mühendislerinin takım olarak çalışırken kendi içlerindeki "deha" fantezisini bir kenara bırakmaları ve diğer insanlarla işbirliği yaparak, vizyonlarını paylaşarak ve emeği bölüşerek daha başarılı olabileceklerini belirtir. Bu süreçte, herkesin katkılarının toplamından daha büyük bir başarı elde edilebileceğini vurgular. Kitap, yazılım mühendislerine takım çalışmasının önemini anlamaları ve sosyal becerilerini geliştirmeleri için rehberlik eder.

Knowledge Sharing

Nina Chen ve Mark Barolak'ın yazdığı "Bilgi Paylaşımı" başlıklı bölümde, bir organizasyonun kendi problem alanını internet üzerinde rastgele bir kişiden daha iyi anlayacağı ve çoğu sorusuna kendi içinden cevap verebileceği vurgulanır. Bu, hem konularında uzman kişilere hem de bilgilerini dağıtma mekanizmalarına sahip olmayı gerektirir. Basit sorular sormaktan dersler ve eğitimler düzenlemeye kadar çeşitli mekanizmalar bu amaçla kullanılabilir. Ancak en önemlisi, insanların bilgi eksikliğini kabul etmelerine izin veren psikolojik bir güvenlik ortamı oluşturulmasıdır.

Öğrenmeye engel olan bazı zorluklar arasında psikolojik güvenlik eksikliği, bilgi adaları, tek başarısızlık noktaları, her şeyi veya hiçbir şeyi bilmeme durumu, papağanlama ve hayaletli mezarlıklar sayılabilir. Google gibi büyüyen bir şirket, bu zorlukların birçoğunu yaşamıştır. Bu sorunların üstesinden gelmek için öğrenme kültürü oluşturmak, mentorluk, ofis saatleri, teknik konuşmalar, dersler, belgeler ve kod incelemeleri gibi çeşitli yöntemler kullanılmıştır.

Öğrenme sürekli bir süreçtir ve herkesin, farklı seviyelerde de olsa, öğretecek bir şeyi vardır. Bireysel bilgiyi artırmak için soru sormak, bağlamı anlamak ve toplulukla iletişim kurmak önemlidir. Organizasyon genelinde bilgiyi genişletmek için ise, bilgi paylaşımı kültürünü teşvik etmek, kanonik bilgi kaynakları oluşturmak ve organizasyonun bilgisini ölçeklendirmek gerekir.

Google, bilgi paylaşımını teşvik etmek ve ödüllendirmek için performans değerlendirme ve terfi kriterlerini, akran bonuslarını ve diğer tanıma mekanizmalarını kullanır. Ayrıca, tüm mühendisler için geçerli olan stil rehberleri, en iyi uygulamalar ve kod inceleme kılavuzları gibi kanonik bilgi kaynakları oluşturmuştur. Okunabilirlik programı, Google mühendislerinin en iyi uygulamaları ve kodlama stillerini öğrenmelerine ve uygulamalarına yardımcı olur. Bu program, mühendislerin yüksek kaliteli, tutarlı ve bakımı kolay kod yazmalarını sağlamak için tasarlanmıştır.

Sonuç olarak, bilgi paylaşımı, bir yazılım mühendisliği organizasyonunun en önemli sermayesidir ve bu bilginin etkili bir şekilde paylaşılması, organizasyonun değişikliklere karşı dayanıklı ve yedekli olmasını sağlar. Açık ve dürüst bir bilgi paylaşımı kültürü, bilginin organizasyon genelinde verimli bir şekilde dağıtılmasını sağlar ve şirketin zamanla ölçeklenmesine olanak tanır.

Engineering for Equity

Demma Rodriguez tarafından yazılan "Eşitlik için Mühendislik" başlıklı bölümde, mühendislerin geniş bir kullanıcı tabanı için ürün tasarlarken üstlendikleri benzersiz sorumluluklar ve bir organizasyonun çeşitliliği benimseyerek herkes için çalışan sistemler tasarlayabilme ve kullanıcılarına zarar vermekten kaçınma yeteneği ele alınmaktadır. Yazılım mühendisliğinin etkilerinin çeşitli topluluklar ve toplumlar üzerindeki anlamı yeni yeni anlaşılmaya başlanmışken, Google'ın en savunmasız kullanıcılarını korumada yaşadığı kamuoyuna açık başarısızlıklar da dahil olmak üzere, daha adil ürünler yolunda ilerlemenin, kendi başarısızlıklarımızı değerlendirmemiz ve büyümeyi teşvik etmemiz gerektiğini vurgulamaktadır.

Bölümde, mühendislerin farklı milliyetler, etnik kökenler, ırklar, cinsiyetler, yaşlar, sosyoekonomik durumlar, yetenekler ve inanç sistemleri gibi çeşitli kullanıcılara odaklanmadıklarında, en yetenekli ekiplerin bile kullanıcılarını kazara hayal kırıklığına uğratabileceği belirtilmektedir. Bilinçsiz önyargı, kasıtlı dışlama eylemlerinden daha sinsidir ve hafifletilmesi daha zordur. Google gibi şirketler, ürünlerinde eşit temsili sağlamakta başarısız oldukları durumlar yaşamış ve bu, mühendislik ekibinin çeşitlilikten yoksun olmasına bağlanmıştır. Bu eksiklik, ürünlerin dezavantajlı veya marjinalleştirilmiş kullanıcılara nasıl etki edebileceğini anlamamızı zorlaştırmaktadır.

Demma Rodriguez, mühendislerin ürün tasarımı ve uygulamasına çeşitli perspektifleri dahil etmelerinin ve mühendis adayları arasında daha temsili bir iş gücü oluşturmanın önemini vurgulamaktadır. Ekiplerin mevcut ve gelecekteki kullanıcılarını temsil edecek şekilde çeşitlendirilmesi gerekmekte, ekip çeşitliliğinin eksikliğinde ise mühendislerin tüm kullanıcılar için nasıl inşa edeceklerini öğrenmeleri gerekmektedir. Bu süreçte, çok kültürlü kapasite oluşturmak, sistemleri daha adil hale getirmek için mevcut süreçlere meydan okumak ve çeşitliliği eyleme dönüştürmek gibi konular ele alınmaktadır.

Sonuç olarak, yazılım geliştirmek ve bir yazılım organizasyonunu geliştirmek ekip çalışması gerektirir. Bir yazılım organizasyonu ölçeklendiğinde, hem geliştirme ekiplerinin hem de ürettikleri ürünlerin, kullanıcıları kadar çeşitli ve kapsayıcı değerleri yansıtacak şekilde tasarlanması gerekmektedir. Organizasyon, temsil edilmeyen grupları görmezden gelirse, sadece organizasyonu kendisini değil, yazılımın dünyadaki geniş ve çeşitli kullanıcılar için gerçekten yararlı olmasını sağlayacak benzersiz ve gerekli perspektifleri de kaybeder.

Devam edecek...