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
Knowledge Sharing
Engineering for Equity