Daha önceki yazımızda bahsettiğimiz gibi Code basitliği kitabın çevirisini yapıp anladıklarımızı aldığımız notları bazen de ek açıklamalar yaparak yazısı dizisi hazırlıyorduk. Bugün bu yazı dizisinin 2.bölümü olan Kayıp Bilimi işleyeceğiz. Bu başlık altında Her programcı bir tasarımcıdır, yazılımm tasarımın bilimi ve tasarımda neden bilim yok konularını işleyeceğiz. Hazırsak başlayalım :)
Bu kitap daha çok yazılım tasarımı diye adlandırılır. Bu tabiri daha önce duymuşsunuzdur, hatta bunla ilgili kitaplar da okumuşsunuzdur , fakat biz buna yeni bir anlam yükleyeceğiz.
Tasarımın ne olduğunu biliyoruz,fakat yine de tasarım kelimesini tanımlamamız lazım.
- Bir yapı için plan yapmak(Fiil): Yazılım hakkında bir çok şey ifade eder. Kodun yapısı, hangi teknolojinin kullanılacağı vs. Burada bir çok teknik karar vardır. Çoğunlukla sadece zihnimizdekileri tasarlarız, fakat bazen buna ek olarak plan ve diagramlarımızı da içerir.
- Planlanmış , fakat henüz inşa edilmemiş plan (İsim): Oluşturduğmuz tasarıma denir. Bu yazılmış bir döküman olacağı gibi, zihnimizdeki kararlar topluluğu da olabilir.
- Var olan yapının izlediği plan. (İsim) Bazı kodların net bir yapısı yoktur. Bunun anlamı kodu ilk yazan kişi tarafından iyi tasarlanmadığıdır. Kodun tasarlanıp tasarlanmaması arasında belirli seviyeler vardır. Hatta şunu söylemek mümkün, olmayan tasarım , kötü olan tasarımdan daha iyidir.
- Kodumuzu yapısı nasıl olmalıdır ?
- Kodun hızlı geliştirmeyi mi yoksa okunurluğunun yüksek olmasına mı odaklanmalı?
- İhtiyaçlarımız için hangi programlama dilini kullanmalıyız ?
Kapsamadığı konular:
- Şirketin yapısı nasıl olmalı ?
- Ne zaman toplantılar yapılmalı ?
- Programcılar kaç gün çalışmalı ?
- Programcıların performansı nasıl ölçülmeli ?
Bu kitap yazılımlarınız hakkında bilgi içermez. Size ve organizasyonuna odaklanır. Bazı yazılım projeleri kötü yönetim yüzünden başarısızlıkla sonuçlanır, fakat bu kitap bunla ilgilenmez. Bu kitap nasıl teknik kararlar vermeniz gerektiğiyle ilgilenir.
Yazılım tasarımı, yazılım sisteminin mimarisini veya sistemi olştururken aldığınız teknikler kararların hepsini içerir.
Her Programcı Bir Tasarımcıdır
Her yazılımcı aslında bir tasarımcıdır ve yazdığı kodun tasarımdan sorumludur. Grup lideri tüm projenin tasarımdan sorumlu iken , uzman yazılımcı kendi geniş alanında yazılımdan sorumludur, çırak yazılımcı ise yazdığı satırlardan sorumludur. Herkesin bir sorumluluk alanı vardır ve bu alandan sorumludur.
Projeyi tek başınıza dahi kodlasanız tasarım yapmak vazgeçilmezdir. Bazen düşünmeden parmakların klavyeye gider, bazen gece başını yastığa dahi koysan yazacağın kodu düşünürsün. Bu açıdan her yazılımcı, her aşama kodunun tasarımdan sorumludur ve bundan kaçınması düşünülemez.
Tasarımın demokrasisi olmaz. Yani herkes kafasına göre tasarım yapamaz. Bunu yaptığınız takdirde kötü bir tasarıma sebebiyet vermiş olursunuz. Bunun yerine her yazılımcı kendi alanında tasarımdan sorumlu olmalıdır. Eğer çırak yazılımcılar bu konuda bir yanlış yaparlarsa grup lider bu tasarıma müdahale etmeli ve tekrar yazdığı kodun üzerinden geçmelidir.
Projeyi tek başınıza dahi kodlasanız tasarım yapmak vazgeçilmezdir. Bazen düşünmeden parmakların klavyeye gider, bazen gece başını yastığa dahi koysan yazacağın kodu düşünürsün. Bu açıdan her yazılımcı, her aşama kodunun tasarımdan sorumludur ve bundan kaçınması düşünülemez.
Tasarımın demokrasisi olmaz. Yani herkes kafasına göre tasarım yapamaz. Bunu yaptığınız takdirde kötü bir tasarıma sebebiyet vermiş olursunuz. Bunun yerine her yazılımcı kendi alanında tasarımdan sorumlu olmalıdır. Eğer çırak yazılımcılar bu konuda bir yanlış yaparlarsa grup lider bu tasarıma müdahale etmeli ve tekrar yazdığı kodun üzerinden geçmelidir.
Yazılımcılar her zaman öneri ve geri bildirimleri dikkate almalıdır. Çünkü yazılımcılar gerçekten zeki insanlardır ve iyi fikirlere sahiptirler. (bizden bahsediyor :)) Ancak tüm her şey üzerinde düşünüldükten sonra kararı bir grup değil, birey vermelidir. Burada konuyu bireye yüklemedeki sebep acaba ne olabilir , bunun üzerinde kafa yormak lazım diye düşünüyorum. Hatta bunun üzerinde uzun uzadıya konuşulabilir diye düşünüyorum.
Yazılım Tasarımının Bilimi
Yazılım tasarımı an itibariyle bilim değildir. Peki bilim nedir ? Sözlükte karmaşık tanımlamaları mevcut ama özetle bir konunun bilim olabilmesi için şu testleri geçmesi gereklidir:
- Bir bilim varsayım ve görüşleri değil, gerçekleri içermelidir.
- Bu gerçekler organize olup birbiriyle tutarlı şekilde tamamlanmalıdır.
- Bilim genel geçer doğru ve kanunlardan oluşmalıdır.
- Genellikle bilim gözleme dayanan bilimsel metotlarla ispatlanır. Deneylerle doğrulanır. Farklı ortamlarda aynı sonuçları verir.
Aslına bakılırsa yazılım tasarımı içerisinde bir çok bilgi içerir, üstelik bu bilgiler düzenlenmiş bilgilerdir. Bunlar bilimin istediği şeylerdir , fakat en önemli parçayı unutuyoruz. O da kişiden kişiye değişmeyen kanunlardır. Mesela tecrübeli bir yazılımcı bir şeyi nasıl yapacağını iyi bilir, fakat bunun neden doğru veya yanlış olduğu hakkında farklı düşünceler olabilir. Bu da şuan için yazılım tasarımının bilim olmasını güçleştiriyor.
Yazılım tasarımının temel dinamikleri nelerdir ? Bu kitap bunun üzerinde durur. Burada tanım,gerçek, kural ve kanunlar üzerinde odaklanacağız. Peki bunlar arasındaki farklar nedir ona kısaca göz atalım.
- Tanım : Bir şeyin nasıl kullanılacağı hakkında bir şeyler söylersiniz.
- Gerçek : Doğru olan durumdur. Doğru bilgi gerçeğin bir parçasıdır.
- Kural : Sana doğru olana ulaşman için verilen tavsiyelerdir.
- Kanun : Her zaman doğru olacak gerçeklerdir.
Bunların arasında en önemlisi tabi ki kanunlar. Bu kitap da bunun üzerinde duracak. Bunları okuduğunda kendi kendine aa ben buları biliyordum diyebilirsiniz. Aslına bakıldığında sizden beklenen de budur. Kendi kendine şu soruları sor :
- Ben bu verilerin kanıtlanabilir olduğunu biliyor muyum ?
- Bunun ne kadar önemli olduğunu biliyor muyum ?
- Bir kişiyle sorunsuzca iletişime geçip onu tamamen anlayabiliyor muyum ?
- Yazılım tasarımdaki alan ve verilerin birbiriyle olan ilişkilerini anlayabiliyor muyum ?
Eskiden hayır veya bazen diye cevap verdiğiniz bu sorulara şimdi evet diyebiliyorsan yazılım tasarımına ait belirli bir deneyim kazandım diyebilirsiniz.
Bilim tabi ki mükemmel değildir. Her geçen gün yeni şeyler çıkıyor ve doğru bilinenler zamanla değişebiliyor, ama bu başlangıç noktası sayılır. Çünkü gözlemle yazılım kanun ve gerçeklerini inşa edebilirsiniz.
Bu kitap bu işi yanlış yapsa dahi, yazılım tasarımı bir gün bilim haline gelebilir. Bu gizlenecek bir durum değildir. Bu her yazılımcının hayalini kurması gereken bir şey olur ve bunun için üstüne düşeni yaparsa o zaman o günlerin gelmesi daha yakın olacaktır. Bu kitap bunu yapsın yapmasın , burada yüzlerce örnek ve nice tecrübeler vardır. Siz kendiniz karar vermelisiniz. Söylenenleri test edip kanun ve kuralların doğruluğuna kendin karar verebilirsiniz.
Neden Yazılım Tasarımında Bilim Yok ?
Bilimin neden yazılım tasarımında olmadığını belki de merak ediyorsunuzdur. Çünkü on yıllardır üzerine uğraşılan bir konu. Şimdi bu konuya biraz göz atalım.
Bugün bilgisayar diye düşündüğümüz şey, bir zamanlar matematikçilerin akıllarındaki problemlere çözüm bulmak için hayal edilen aygıtlardır. Zaten burada aldığımız derslerden olsun , kurduğumuz algoritmalardan veya iş ilanlarından bile anlayabilirsiniz matematikçilerin ve yazılımcılarının ne kadar iç içe olduğunu. Matematikçiler bilgisayar biliminin kurulması konusunda çalıştılar fakat bu programlamanın bulunacağı anlamına gelmezdi. Bununla birlikte ilk bilgisayarları elektronik mühendisleri yapmıştır. Bu tarz buluşların hemen hemen hepsinde olduğu gibi bu da yine askeri kaynaklı kullanıldı. Bildiğimiz üzere internet teknolojisi de yine böyle askeri kullanımı vardı daha sonra tüm dünyaya yayılmaya başlandı. Bu yüzden büyük savaşların teknolojik gelişmelere çok faydasının da olduğu söylenir. Ama temennimiz tabi ki bu teknolojilerinin savaşlara ihtiyaç olmadan da gelişmesi ama maalesef bu da oldukça zor görünüyor şuan için. Bundan sonra UNIVAC ve dünyanın ilk ticari bilgisayarları gelmeye başladı. Bunları sadece çok iyi matematikçiler kullanabiliyordu. Her bilgisayar satışına bir matematikçi veremeyeceğinizden alternatif yollar arandı. Buna çözüm olarak bu karmaşıklığın parçalanması yöntemine gittiler. Yazar yavaş yavaş konuyu kitabına bağlıyor :) Bunu da Bill yapacaktı.
Bill matematik biliyordu fakat kesinlikle karmaşık teoriler bilmiyordu. Buna ihtiyacı da yoktu. O dokümanları okuyup anlayarak deneme yanılma yoluyla bu karmaşık işleri çözdü. Böylelikle Bill ilk programcı olarak tarihe geçti. Tabi ki zamanla bu ticari bilgisayarlar çoğaldı. Bill'in üzerindeki baskı da arttı. Yöneticilerden bu işi yap nasıl yaparsan bizi ilgilendirmez gibi direktifler geldi. Bill'in programı iki saatte biri bozulmasına rağmen bu işi yapmayı başardı.
Sonunda Bill kendisiyle çalışacak bir ekip buldu. İşin nasıl tasarlanacağı , kimlerin ne işe yapacağı , iş bölümünün nasıl olacağı hakkında çalışmalar yapıldı. Bu iş git gide karmaşıklaşmaya başladı. İşin yönetilmesi çok zor hale gelmesine rağmen insanlar anlaşabiliyordu. Daha sonra Addison-Wesley adındaki efsane geldi. Yüksek gözlem gücü ile bu işleri rayına koydu. Yaptıkları tam bir bilim olarak adlanırılmasa da bu konuda büyük çalışmalar yaptı. Daha sonraları bilim olduğunu iddia etmeyen fakat bu işlerin nasıl yönetileceğini gösteren farklı modellemeler ortaya çıktı. Tüm bunlarla bugünkü noktaya gelindi.
Aslında iki kayıp bilim vardır. Bunlar :
- Yazılım Yönetim Bilimi : Programcılar arasında nasıl iş paylaşımı olacağını, bir işin ne kadar süre alacağını , işin tamamlanacağı süreyi hesaplamak üzere çalışır. Bunlar kesin olarak bilinmese de yakın tahminler verilmektedir.
- Yazılım Tasarım Bilimi : Çoğu insanın bunun nasıl bilim olacağına kafa yormak yerine , şu programlama dili nasıl kullanılır , ne işe yarar gibi işlere kafa yormaktadır. Bu kitap işte bu noktada ortaya çıktı.
Bu kitap bir bilgisayar bilimi kitabı değil, matematiksel bir çalışmadır. Çalışan programcılara yol gösteren, neyin nasıl yapılacağı konusunda yönlendiren, fizik , kimya gibi bilimsel gerçekleri içeren bir kitaptır.
Aslında bakılırsa programcının tek başına bu iş yaptığı genel bir kanıdır. Burada yazılımcı kendi sanatını oluştursa da buna uygulanacak bir bilimin olmayışı bizi çok karışık süreçlere yönlendiriyor. Eğer yazılımda bu bilimin eksikliği olmasaydı her şey çok daha kolay olacaktı. Kim bilir belki de o günler yakındır. Her geçen gün bu konuda gelişmeler oluyor. Gerçi bu bilim olsa ülkemiz buna ne zaman geçer o da ayrı bir konu. Maalesef neredeyse her konuda olduğu gibi bu konuda da sadece takip eden durumundayız. Umarım bunu da el ele vererek değiştirebiliriz. Bu konuda öncülük edenlerden olmak dileğiyle.
Serimizin 3.yazısında görüşmek dileğiyle. Hoşça kalın.
Hiç yorum yok:
Yorum Gönder