Photo by Paweł Czerwiński on Unsplash

YAZILIM SÜREÇLERİ

Yazılım Geliştirmedeki Prensipler

Yazılım Geliştirme’nin fazlarından Analiz, Tasarım ve Geliştirme sırasında uygulanan bazı prensipler var. Bu yazımda bu prensiplerden bahsedeceğim.

NOT: Bu yazıya okumaya başmadan önce konu hakkında bilginiz yok ise öncelikle aşağıdaki yazılarla başlamanızı öneririm.

• Bu yazı serisine ilk önce NEDEN farklı yazılım modellerine ihtiyaç duyduğumuzu projelerin farklılıklarından bahsederek anlatmaya çalıştığım yazım (Yazılım Geliştirme Yaşam Döngüsü)
• Yazılım Geliştirme Yaşam Döngüsünün içerisinde hangi FAZLARIN olduğunu anlattığım yazım (Yazılım Geliştirme Fazları)
• Ve bu fazların farklı farklı ele alınması oluşan yazılım geliştirme MODEL anlattığım yazım (Yazılım Geliştirme Modelleri)
• Bu modeller içerisinde Agile(Çevik) Yazılım Geliştirme Modeli üzerine geliştirilen AGILE FRAMEWORK’lerden bahsettiğim yazım (Kanban, XP, Scrum Arasındaki Farklar)
• İş hayatında yazılım geliştirme modellerinden hangilerini nasıl kullandığımı anlattığım yazım PRATİK (İş Hayatında Hangi Yazılım Geliştirme Modellerini ve Araçları Kullandık)

Prensipler

Yukarıda yazılım geliştirme fazlarından bahsettik modellerde de bu fazları belli şekilde işlettik, ekip mantığımızı vs değiştirdik ama fazların içerisinde ne tarz prensipler kullanarak bu fazların verimliliğini, kalitesini, hızını arttırabiliriz ?

• Yazılım Geliştirme Ekipleri ve Arasındaki İletişim Konusunda (Conway Yasası , Amazon, Two Pizza Teams)
• Geliştirdiğimiz ürünün gereksinimlerinin, özelliklerinin belirlenmesi konusunda ( Min Value Product, Jobs To Be Done, Customer Development, Feature Driven Development, Behaviour Driven Development, Domain Driven Development, Model Driven Development)
• Müşteri için geliştirilecek sistemin modellenmesi ( BrainStorming ve MindMap, UML, Prototyping, Design Systems)
• Kodlama Paradigmaları (Imperative/Declarative Programlama, Nesne Tabanlı Programlama, Aspect Oriented Programlama)
• Kod geliştirmenizin daha kaliteli olması için yapılacaklar ( SOLID, KISS, DRY, YAGNI, TDD, Design Patterns, Architectural Patterns, Integration Patterns, Pair Programming, Aspect Oriented Programlama)
• Dağıtık Sistemler geliştirip, bunların entegre/sorunsuz ve kaliteli bir şekilde çalışabilmesi için (Reactive Manifesto, 12 Factor Apps)

1. Conway Yasası

Yazılım geliştime ekiplerinin nasıl oluşturulacağı ve ekiplerin nasıl birbirleri ile iletişime geçeceği konusundaki yasa.

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations,

Organizasyonlara ait tasarım sistemleri ancak organizasyondaki yapıların iletişim şeklinin kopyası olacak şekilde tasarlanabilir. [Detay]

2. Amazon, Two Pizza Teams

Amazon’daki geliştirme ekiplerinin 2 pizza ile doyacak sayıda olması üzerine kurulu yaklaşım.

Bunun arkasında yatan felsefe çok fazla iletişim, iletişim problemlerini çözmez. Örneğin bir yemeğe, düğüne, doğum günü partisine gittiniz. Genelde çok fazla insan olsada insanların 5erli, 6şarlı gruplar halinde toplanıp konuştuğunu görürsünüz. Buda iletişim açısından takım sınırlarımızı göstermektedir. [Detay] [İletişim Yöntemleri]

# n(n-1)/2 bağlantı sayısı
6 kişide => 15 bağlantı
12 kişide => 66 bağlantı
50 kişide => 1225 bağlantı

4. MVP (Minimum Viable Product)

Aklınızda bir fikir var ve bu fikri ürüne dönüştürmek istiyorsunuz. Bunun için çok karmaşık düşünerek , bütün özelliklerini tam tamına yapayım şeklinde düşünmek yerine esas müşteri tarafında en değerli özelliğin hangisi olduğuna odaklanarak ürün geliştirmektir. [Detay]

Bu en değerli özelliği bulup minimum özellikte

• en az emek harcayarak,
• en hızlı şekilde ürünü müşteriye ulaştırma

5. Müşteri Geliştirme (Customer Development)

Ürün Geliştirme’deki en önemli konu, bunu kullanacak kişiler bulmak ve bulduğun bu kullanıcıların para ödeyecek kişilere dönüştürme çalışması [Detay]

• Müşteri keşfi: Şirket kurucularının vizyonunu doğrultusunda bir dizi iş modeli hipotezi oluşturulur. Daha sonra, bu hipotezlere karşı müşteri tepkilerini test etmek ve onları gerçeklere dönüştürmek için bir plan geliştirir.
• Müşteri doğrulama: Ortaya çıkarılan iş modelinin tekrarlanabilir ve ölçeklenebilir olup olmadığını test eder. Sonuç negatif ise tekrardan müşteri keşfine dönülmelidir.
• Müşteri elde etme/oluşturma: Ürünü kullanan ve bunun için para veren müşterileri elde etme
• Şirkete dönüştürme süreci: Girişimin bir organizasyon yapısına dönüştürecek modele odaklanmasını sağlar.

6. Jobs To Be Done

Temel felsefesi müşteriden aldığınız ürünü şöyle yaparsanız, şu özellikleri eklerseniz , fiyatını şu şekilde, limitlerini bu şekilde yaparsanız alırız söylemlerinin gerçeği yansıtmaması, özetle MVP, Müşteri Geliştirme yöntemlerinden elde ettiğiniz verilerin sonucunda geliştirdiğiniz ürün yine satmıyorsa bunun nedeni Müşteriler belki ne istediklerini veya neye ihtiyaçları olduklarını bilmemelerinden kaynaklanıyor olabilir.

Customers don’t know what they want. (Steve Jobs)

Genelde yukarıda bahsettiğimiz nedenlerden ötürü ürünler başarısız oluyor, ürün / market uygunluğunu yakalaması genelde şans faktörüne bağlı oluyor. Jobs To Be Done müşterinin anlatamadığı nedenselliği nasıl bulacağımız konusunda bize bir önermede bulunuyor

İnsanlar kendilerinin yaptığı bir işi veya problemli bir konuyu daha basit, daha ucuz vb.. şekilde onların yerine yapabilen ürünleri satın alıyor. Bu işi bulup bunu ürün ile sağlarsanız büyük bir ihtimalle müşterinizi bulabilirsiniz.

7. BrainStorming ve MindMap

Beyin fırtınası yöntemi ile bir toplantı sırasında gurubun bir konu üzerinde yaratıcı fikirler ortaya çıkarmasını sağlayan toplantılardır. Süreç iyileştirmesi, yeni bir ürün çıkarma, ürüne yeni bir özellik ekleme,pazarlama ve reklam süreçlerinde beyin fırtınasından faydalınarak güzel sonuçlar elde edilebilir.

Yaratıcı fikirler oluşturmanın bir diğer yöntemide sistemi , konuşulanları , toplantıları vb.. bir harita üzerinde tümüyle görebilmektir. Bunun için tuttuğunuz notları zihin haritası yöntemi ile tutarsanız bu size dönüp baktığınızda tüm sistemin zihninizdeki haritasını tek seferde gösterebilme imkanı sunar. [Örnek bir MindMap]

8. Sketch, Wireframe, Mockup, Prototype

Ürün arayüzü geliştirme sırasında kodlamaya geçilmeden önce uygulanmasında faydalı olan bazı adımlar/aşamalar vardır. Bu adımları ne kadar hakkıyla uygulayabilirseniz bu sizin projenizde sonradan çok maliyetli olacak değişiklikleri önceden öngörebilmenizi sağlar. Bu en basit çizimden , giderek en etkileşimli ve gerçek uygulamaya benzeyen prototipe dönüşür. [Detay]

Sketch → Wireframe → Mockup → Prototype

9. UML (Unified Modeling Language)

Yazılım geliştirmede tasarım sistemini göstermek için kullanılan temel amaçlı modelleme dilidir. Elinizde gereksinimler ve ilgili paydaşlardan alınmış veriler var ve bunlara göre anlatılanları modellemek veya bunlardan tasarım yapmak istiyorsunuz. Bu hem ekibinizin arasında ortak bir dil oluşturuyor hemde sistemin nasıl işlediğini daha net görebiliyorsunuz. 1994–1995 yılında Grady Booch, Ivar Jacobson and James Rumbaugh tarafından Rational Software firmasında iken oluşturulmuştur.

Bu modelleme dili Nesne Tabanlı Programlama yapısına uygun bir çok şemaya sahiptir. Bazıları sistemin yapısını, bazılarıda sistemin işleyişini modelleyerek yazılım geliştiricilerin baştan tasarımlar üzerinde konuşabilmesine olanak sağlar.

• Behavioral Diagram → Activity, State Machine, Use Case, Timing, Sequence, Communication, Interaction Overview Diagrams
• Structural Diagrams → Class, Composite Structure, Component, Deployment, Object, Package, Profile Diagrams

10. SOLID Prensibi

Robert C. Martin tarafından geliştirilen bu 5 prensip sayesinde Nesneye Yönelik tasarım ve programlamanızın kolay bir şekilde genişletilebilmesini ve daha kolay bakımının yapılabilmesine olanak sunar. [Detay]

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

11. Aspect Oriented Tasarım ve Programlama

Geliştirdiğimiz sistemlerde tüm sistemler tarafından ortak olarak kullanılması gereken fonksiyonaliteler vardır. Bu tip yapılar Nesne Yönelik Programalayı zorlayan konulardır çünkü High Cohesion — Low Coupling kavramını bozan Cross-Cut fonksiyonaliteleri içerir, Örneğin

• Sistemin Durumuna Göre Tüm Bileşenlerin farklı şekilde davranması
• Dark Mode / Light Mode
• Kullanıcı rolü veya yetkisinin olup olmaması
• Loglama Mekanizmaları
• Hata yakalama mekanizması (Exception Handling Mekanizması)
• Cache Mekanizmaları

Bunları geliştirebilmeleri için kodun içerisine bunlar ile ilgili kodları yazmak yerine fonksiyonların üstüne konulan Annotation/Aspect tagları ile bu kodların Nense tabanlı programlamanın içerisine dağılması engellenmiştir. Encapsulation sağlanmıştır.

12. KISS, DRY, YAGNI Prensipleri

KISS (Keep It Simple, Stupid): Kodu olabildiğince basit ve sade bir şekilde sadece işi yapacak şekilde geliştirmek. YAGNI(You aren’t gonna need it) Extreme Programlamanın temellerinden olan bu yöntemde gerekmiyorsa fazladan bir fonksiyon ekleme. Bu 2 yöntemde de geleceğe yönelik overengineering yaparak karmaşık sistemler tasarlamamak üzerine

DRY (Don’t repeat yourself): Kodunuzda farklı modülün içerisinde benzer fonksiyonalitede yapılar bulunur, bunları her modülde tekrar yazmanız kod tekrarı(code dublication) neden olacaktır. Olabildiğince belli işlerin sorumluluğunu ilgili modüllere vererek abstraction iyi sağlamak gerekiyor.

13. Design Patterns

Tasarım örüntüleri insanların projelerinde sık sık karşılaştıkları problemler çözüm olarak getirdikleri Problem-Çözüm ilişkileridir. [Detay]

Tasarım örüntülerini;

• Kodun daha esnek olabilmesini sağlamak
• Kodun tekrar tekrar kullanılabilmesi
• Sonradan yapılacak değişikliklere karşı kodun fazla etkilenmemesi amacıyla geliştirilmiştir.

14. Architectural Patterns

Mimari örüntüler gerçek mimariden örnek alarak ortaya çıkmıştır. Örneğin yukarıdaki resmi inceleyin. Mimaride hep aynı desenin tekrar ettiğini görebilirsiniz. Merdiven düzenleri, merdivenler arasındaki yuvarlak sütunlar her yerde tekrar eder.

Yazılımlarda bu mimari yapılara çok benzer. Bileşen, Servis, vb yapılarından oluşan uygulamaların aşağıdaki özellikler benzer problemler oluşturur. Bu problemleri gidermek için bulunan yöntemlere Mimari örüntüler denir.

• Yapısı
• Davranış Şekilleri
• Birbirleri İle İletişim Şekilleri

Mimari örüntülerin, tasarım örüntülerinden farkı; belli bir alanda, belli bir kapsamdaki problemi çözmek yerine uygulamanın her yerinde geniş alana yayılan problemi çözmeyi hedeflemesidir. [Detay]

15. Enterprise Integration Patterns

Daha önceki yazılarımızda tasarım ve mimari örüntülerden bahsetmiştik. Buradaki örüntüler ise mimari örüntüler/stiller içerisindeki iletişim kısmında yer alan örüntülerdir. 1'den fazla uygulamanın birlikte nasıl mesaj alışverişi yapacağı üzerine oluşturulmuş Entegrasyon örüntüleridir. Yani bir sistem içerisinde yer alan uygulamaların nasıl birbirleri ile entegre olacağı tanımlanmaya çalışılır. [Detay]

• Dosya Transferi
• Paylaşılmış Ortak Veritabanı
• Uzak Procedure Çağırma (RPC)
• Mesajlaşma

16 Test-Driven Development

Test Odaklı Yazılım geliştirmede geliştirici öncelikle test yazılır. Yani yazılacak fonksiyonu, sınıfı yazmadan önce testi yazılmaya başlanır. Test çalıştırılır ve test fail eder çünkü bunu gerçekleştiren sınıflar, fonksiyonlar henüz mevcut değildir. Refactoring yöntemleri ile ilgili fonksiyonlar geliştirilir , test geçer, test geliştirilerek ilerletilmeye devam eder, teste yine hata verdirtilir ve tekrardan refactoring ile testlerin geçirilmesi sağlanır.

Burda önemli bir konu test yazılabilen sistemlerin olabildiğinde düzgün tasarlanmasıdır. Daha düzgün arayüzler ve soyutlamalar ile sistem tasarlanır. [Detay]

17 Behaviour Driven Development

Yazılımlara daha yukarıdan bakarsak sadece geliştiricilerin sistemin içerisinde olmadığı Müşteri, Alan Uzmanı, Kalite vb.. kişilerinde yazılım geliştirmede rol oynadığını görebilirsiniz. BDD yönteminde Kullanıcı hikayelerinden(user stories) çıkan davranışlar üzerinde Acceptance Test oluşturularak yazılım davranışı, yazılım tasarlanmaya çalışılır. Burda amaç gereksinimlere/sistemin davranışlarına odaklanmaktır.[Detay] Burda Given-When-Then ortaya çıkarılmaya çalışılır.

Given: Kullanıcının sisteme girdileri

When: Ne zaman sistemin bu davranışının ortaya çıktığı

Then: Sonuçta sistemin verdiği tepkinin ne olacağının

ortaya çıkararak yapılan geliştirme türüdür.

18. Acceptance Test-Driven Development

Behaviour Driven Development aynı şekilde çalışır ama amaç özelliğin davranışlarını yakalamak yerine gerçek sistemi inceleyerek doğru gereksinimleri yakalamaya çalışarak geliştirme yapmaktır.

19. Feature-Driven Development

İstemci(müşteri) tarafından üretilen özellikleri belirlenip geliştirilmesi üzerine kurgulanmış yapıdır. Aşağıdaki yapıda feature tanımlamaları yapılır.

<action><result><object>
- Calculate the total of a sale
- Validate the password of a user
- Authorize the sales transaction of a customer

Bu feature FDD şeklinde işletilerek RUP — use case/kullanım senaryosuna , Scrum — user stories/kullanıcı hikayelerine dönüştürülerek bunların geliştirilmesi planlanır, tasarlanır ve geliştirilir.

20. Domain-Driven Development

Kompleks ve karmaşık sistemler, Bankacılık, Sigorta, Vergi, Uçuş vb sistemleri geliştirmek için Domain/Alan odaklı tasarım ve geliştirme yapılması oldukça önemlidir. Çünkü sistemler birçok alanı ve bu alanlar arası iletişimi içermektedir.

Birde bunun üstüne iş kuralları sürekli değişen ve güncellenen ve tamamı ile sistemdeki bağlantıları etkileyen bu mekanikleri normal yazılım geliştirme yöntemleri ile ilerlemek pek başarılı sonuçlar vermeyecektir.

Bunun yerine Etki Alanına Dayalı Geliştirme yöntemi seçilmelidir.

• Alan uzmanları ile ortak dil belirlenmeli (Domain Spesific Language)
• Bounded Context içerisinde Context Mapping yapılmalıdır.

21. Reactive Manifesto

Reactive Manifesto’da günümüz uygulamaları nasıl geliştirilmeli ki günümüz problemlerini giderebilsin üzerine yazılmış bir bildiridir.

Reactive Sistemler Responsive, Elastic, Resillient ve Message Driven olmalıdır ki günümüz ihtiyaçlarını karşılasınlar. Esnek olmalı, Bileşenlerin birbirine bağımlılıkları az olmalı, bileşenlerin(microservisler) ölçeklenebilir olmalı. Hata durumunda bu durumdan kurtulabilecek ve yoluna devam edecek şekilde yazılmalı. Sistemler kullanıcı etkileşimine yüksek cevap verebilme kabiliyetine sahip olmalıdır. [Detay]

22. 12 Factor Apps

Ölçeklenebilir SaaS uygulamalar yazabilmek için 2012 yılında Heroku’nun kurucularından Adam Wiggins tarafından ortaya atılmış bir manifestodur. [Detay]

• Projeye yeni katılan geliştiricilerin ortamlarını hızlı ve ucuz maliyetli bir şekilde ortamlarını kurabilmeleri ve otomasyonlarını sağlayabilmeleri için Declarative Format’ların kullanılması
• Alttaki işletim sistemi ile Clean Contract sağlanarak, çalışan ortamlar arasında Maximum Portability’nin sağlanabilmesi
• Üzerine WebApp/SaaS uygulamalar deploy edilebilecek modern Cloud Platformları sayesinde sunucu ve sistem yöneticiliği ile uğraşmamak
• Continues Deployment ile geliştirme ve canlı arasında farklılaşma oluşturmama..

Eğitimler

[sponsor] Bilginç IT Academy’nin Enterprise Design Patterns & Architectures eğitimi bulunmaktadır. Eğitim içeriğinde yer alan konular;

• Architecture, Design Patterns I and II, Serialization, WCF, Service-Oriented Architecture, Web Services, Concurrency, Messaging, Transactions, Security, Hosting and Deployment, Performance, and Reliability, Scalability

Eğitim Linki: https://bilginc.com/tr/egitim/1636/enterprise-design-patterns-and-architectures-egitimi

Okumaya Devam Et 😃

Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.