Temiz Kod Tasarımı - Lemi Orhan Ergin

Summary

The speaker emphasizes the importance of software design, which is often overlooked compared to architecture. Well-designed code should be easy to change over time. He recommends techniques like testing, refactoring, reducing coupling between components, and increasing cohesion within components to improve design quality. The speaker argues that taking time to create clean code ultimately saves more time compared to quick but messy code, even if managers don't see the immediate benefit.

Takeaways

• 😃 The speaker's journey began around 2012-2013, where they shifted focus from coding to reviewing projects, leading to a significant change in perspective.
• 🙂 Encountering a peculiar 15-line method dramatically altered the speaker's viewpoint on code quality and efficiency.
• 📝 Emphasizes the importance of understanding and reviewing tests to comprehend application behavior, highlighting that functioning code in production does not imply it's optimal.
• 🙋🏻‍♂️ Advocates for the necessity of questioning and reevaluating one's own code, stressing that mere functionality is insufficient for quality.
• 💡 A pivotal moment was realizing that complex code could often be simplified significantly, which sparked a deeper interest in writing quality code over merely learning new technologies.
• 🛠 Technical debt within an application can lead to its downfall, underscoring the need for continuous improvement and maintenance of code.
• 💬 Highlights the cultural aspects of coding, including the significance of addressing 'code smells' to avoid future problems.
• 📚 References Jack Reeves's view that code itself is the design, suggesting a shift towards recognizing coding as a form of design work.
• 🔧 Stresses the importance of automated testing, refactoring, and clean code practices as essential for sustainable software development.
• 📰 Discusses the dangers of coupling and the lack of cohesion, advocating for code that is easy to manage, modify, and understand.

Q & A

What significant change in perspective did the speaker experience in 2013 related to code review?

The speaker's perspective changed dramatically after coming across a 15-line method that, despite working correctly in production with unit tests, appeared odd to them. This led them to question and rethink their approach to writing and reviewing code.

How did the speaker approach unfamiliar frameworks and technologies?

The speaker tackled unfamiliar frameworks and technologies by reviewing and analyzing codes written using these, despite not having worked with them directly. This process involved scrutinizing codes they hadn't written to understand their structure and logic.

What was the speaker's main focus in their software development career?

The speaker's main focus has been on writing high-quality code. They emphasize the importance of not just making code work but ensuring it is well-designed and maintainable, indicating a shift from merely learning new technologies to mastering the art of coding.

Why does the speaker believe that addressing 'code smells' is crucial?

The speaker believes that addressing 'code smells' is crucial because these indicate deeper issues within the code that could lead to technical debt. Recognizing and rectifying these smells are essential for maintaining a healthy codebase and preventing future problems.

What does the speaker say about the role of testing in software development?

The speaker underscores the importance of testing, stating that untested code is equivalent to unfinished code. They argue that thorough testing is essential to ensure code reliability and functionality, drawing a parallel to proving mathematical formulas.

How does the speaker view the relationship between code design and software architecture?

The speaker views code design as integral to software architecture, emphasizing that design isn't just about the structural aspects but also involves the code itself. They argue that every line of code contributes to the overall design and architecture of the software.

What metaphor does the speaker use to describe software development?

The speaker compares software development to growing a city, where initial designs might not accommodate future growth. This metaphor highlights the need for scalable and adaptable code design to support the software's evolution over time.

What is the speaker's stance on refactoring?

The speaker advocates for continuous refactoring as a part of the development process, rather than a separate phase. They stress that refactoring is essential for maintaining code quality and should be integrated into daily coding activities.

According to the speaker, how can software developers ensure code quality?

To ensure code quality, the speaker suggests practices like pair programming, code reviews, and embracing a culture of communication and collaboration among developers. These practices help identify and rectify issues early in the development process.

What does the speaker identify as a key challenge in software development?

The speaker identifies managing complexity and avoiding 'code smells' as key challenges. They emphasize the need for clean code practices, including proper naming conventions, reducing dependencies, and enhancing code cohesion to tackle these challenges effectively.

Outlines

00:00

😀 Getting started: reviewing code in 2013

The author started reviewing code in 2013 when he joined Sony. He would look through code, frameworks and technologies he didn't work on to understand them better. He would leave comments asking questions even though he didn't fully grasp the code yet.

05:01

😷 Identifying code smells

The author argues that concepts like code, design, architecture etc all 'smell'. We get so used to these smells that we no longer notice them. But when we get exposed to better alternatives, we start noticing the 'smell'. Identifying these code smells is the first step to improving quality.

10:02

📝 Software design is in the code itself

The author highlights that Jack Reis said that the design of software is in the code itself. Software that is untested is considered incomplete. Testing validates that the code works as intended just as mathematical proofs validate the accuracy of equations.

15:04

🔨 Refactoring is essential

The real value of software is not in it working correctly, but in adapting to change. Refactoring cannot be a separate activity, but has to be woven into development itself through constant code review and rewriting. Legacy code that cannot adapt accumulates technical debt.

20:05

🤝 Programming concepts build on each other

The author argues that software design involves programming, testing and refactoring bound together, supporting each other. Lack of any one causes the whole structure to crumble. Refactoring aims to reduce coupling while increasing cohesion.

25:05

😎 Naming reveals understanding

The author argues that naming classes, methods etc appropriately reveals how well we understand the code. Meaningful names make the code more readable. Framework dependent code with ambiguous names makes the application rigid and hard to maintain.

30:06

🏭 Building maintainable software

Drawing from the Gang of Four book, the author argues that software systems need to be built for change, just as cities had to evolve from towns. The design has to change as code grows from more people working on it over time.

35:08

🤝 Collaborating for better code

The author argues that code reviews and pair programming are essential for higher quality code. No one person can write perfect bug-free code. Collaborating makes us leave aside egos and co-create better designed software.

Keywords

💡software design

The speaker emphasizes the importance of software design, which refers to the internal structure and organization of code. Good design makes code flexible, reusable, and maintainable over time.

💡refactoring

The process of improving existing code without changing its behavior. Refactoring aims to clean up duplicate code, improve names of methods/classes, break code into smaller pieces.

💡code quality

The overall readability, understandability, flexibility and maintainability of software code. The speaker argues that working code alone is not enough - its design quality is critical.

Highlights

Software design is the code itself

If code is not tested, there is a problem - it is unfinished

The real value of software is not that it works correctly, but that it can adapt to change

High coupling between concepts means changing one thing breaks many other things

Cohesion - related concepts should be encapsulated together

Refactoring, testing, programming are all essential - missing any means poor design

Naming is critical - names bring new abstractions and domain concepts

Avoid overuse of generic helper/utility classes - they hide business logic

Duplicate knowledge (not just code) indicates a missing abstraction

Making changes getting harder over time indicates design problems

Leaky abstraction - don't expose low-level concepts up higher

Use small interfaces/classes over large god classes

Code review and pair programming enable collaborative improvement

Take small steps - incremental improvement over big upfront design

Code to be refactored later - it will change

Transcripts

yıl sanırım 2013 civarıydı

2012'de sonye 3 girişim

sonrası yeni görev tanımım ve heyecanım

projeleri review etmeye başladım

kodlarını didikli üzerinde uğraşmadım

çalışmadığım kodlara bakıyorum üzerinde

çalışmadığım frameworkleri bilmediğim

teknolojilerin kodlarını incelemeye

çalışıyorum ve insanlardan habersiz

onlara komer yazıyorum Kod review

açıyorum Ve diyorum ki buradaki kodda

Bir gariplik gördüm Sence nedir Yani ben

garip belki normal bir şey ama ben

anlayamadım diye yorumlar

yazıyordum ve kodlar arasında dolaşırken

şöyle bir Bu kaç satır bir 15 satırlık

bir metoda denk geldim bunu Ar bir kısmı

bilmiyorum denk Gelmiş olabilirsiniz

buna bahsediyorum Çünkü 15 satırlık kod

benim bakış açımı dramatik değiştirdi bu

kodu yazan arkadaşı Eee

tanıyorum ben değilim

e ve bu kodan Scroll yaparken bu kodu

gördüğümde durdum Yani bir gariplik var

dedim okumaya çalıştım falan Sonra

testini açtım Çünkü benim ilk yaptığım

şey testine bakmak uygulamayı kendim

compile edemem uygulamanın nasıl

çalıştığını anlamı bekleyemezsiniz

testine bakmam gerekir Eee ki eğer K

test senaryolarını düzgün yazmışsa

oradan bir şeyler anlayabilirim ve

testini açtım testini Hark de yazmıştı

unit testleri var Bir de bu kod Bu arada

canlıya çıkmış durumda Yani bu kod

çalışmıyor bu kod çok falen

değiştirmemiz lazım diyecek durumda

değilim canlıda çalışıyor ve güzel

çalışıyor testi de var unit testi de var

harkulade ama bu koddan ayrılamıyorum

Scroll edemiyorum burada kaldım burada

bir şey var Sonra satır satır bu kodu

incelemeye

başladım satır satır incelerken ilk

başta message stringi oluşturuyorsunuz

ve oraya diyorsunuz

Mage sonra eğer ki bu arada bu validate

package metodu Yani bir paket objesi

alıyor Bunu val edece tamam mı ve paket

Eğer ki nsa package n mesajı stringe

ekleniyor Eğer ki paket n değil ama emp

ise Page not di

bires

oluyor sonra message null değilse Aha

Demek ki ortada bir problem var demektir

message n deilse burada exception

fırlatıyoruz runtime exception

fırlatıyoruz ve bir saniye yakalıyoruz

fırlattığımız an topu hemen yakalayıp

bakıyoruz ki Evet burada bir problem var

exception ve false dönüyoruz Eğer ki

bunun hiçbiri yaşanıyorsa Tabii ki True

deyip bunu diyoruz burada burada bir

gariplik var

cidden cidden üzerinde uzun zaman böyle

durdum durdum Baktım bir şeyler var Ve

bunu baştan nasıl yazabilirim diye merak

ettim e ve bu kodu baştan yazmak için

uğraştım şöyle bir hale geldi yani bu

burada e logger olduğu için loglamak

gerekiyor Peki ya loglamak için gereken

eforu burada sarf etmesek validate

package' çağıran yerde llas hani burada

loga gerek olmadığını düşünsek ne olurdu

Evet bu kadar

olurdu bu kod bu kadar bu kod tek

satırla halledilebilir bir kodmak

üstteki de çalışıyor alttaki de

çalışıyor bu bende eee bir şey ışıkların

parlamasına bilinç kaybına falan bir

şeylere bir şeyler bir şeyler oluştu

Yani kendimi sorgulam neden oldu ve

kendi kodlarım baktığım zaman evet evet

falan diye kendi kendi yazdığım kodlarda

da böyle Açıklar bulmaya başladım

çalışması yetmez arkadaşlar kodun

çalışması yetmez ve Odak noktam benim

Eee teknolojileri süper öğrenmek uzun

zamandır olmadı yani e teknolojiler

konusunda öğrenmeye çalışıyorum ama

hiçbirini süper bilmiyorum Benim ana

noktam kaliteli kod yazmakla alakalı ve

bunun daha kaliteli olduğuna inanıyorum

bunu da tartışabiliriz ama en

nihayetinde uygulamanın kodunun iç

tasarımının daha güzelleşmesi

gerektiğine inanıyorum çünkü Eee her

güzel her

Eee çalışsa bile uygulamanın içerisinde

teknik borçlar Eee var ve o teknik

borçlar gelecekte uygulamayı iflasa

götürebilir

eee bir şeyi atlam bir şeyi atladım y

ondan da

bahsedeceğim genele baktığımız zaman uı

Culture ya kültürümüz ofisin içi kodun

kendisi mimari buradaki bütün

kavramların ortak bir özelliği var

hepsinin ortak bir özelliği var infra

hatta müşteri ortak özellikleri neler

kodun kendisi

tasarım Bunların ortak özelliği şu

Bunlar kokab arkadaşlar Hem de ne

kokuyor bazen E hiç almıyorsunuz

kokmasına rağmen alışkanlık olmuş oluyor

uzun zamandır kokuyla yaşadığınız zaman

Tıpkı fiziksel olarak o kokuyu

hissetmediğiniz gibi Koda baktığınız

zaman da o kokuyu hissetmiyorsunuz ama

ara ara dışarıya

çıkıp nefesinizi temizlediğiniz ya da

farklı kokularla kendinizi tekrardan

ferahlığın o kokuyu fark farkındalık

yarattığınız fark edebilirsiniz ve bu

anlamda biraz evvel gösterdiğim

listedeki şeyler kavramlar kokarlar ve

kötü koktuk bilin ki ortada bir ciddi

bir problem vardır Önemli olan bu

kokuları tespit

etmek atladığım şey şu kendimi kısaca

tanıtmayı unuttum Eee adım Lemi eico da

çalışıyorum

eee Sony'de üç kere Eee sony'ye giriş

yaptım 10 sene kadar Sony'de çalıştım

Gitti Gidiyor e'de çalıştım 2 sene e

asm'de Eee danışmanlık tecrübem oldu Çok

fazla proje çok fazla Şirket çok fazla

İşini keyifle yapmayı aşkla tutkuyla Eee

uğraşan arkadaşla çalışma fırsatım oldu

çok şey öğrendim eee Çırağım ve çırak

olarak kalacağım e ve burada anlatmaya

çalıştığım şeyler tamamen e deneyimler

deneyimlediğimiz yani yazılım temiz kod

ya da yazılım tasarımı çok büyük bir

konu Yani devasa bir konu Bunun neresini

40 dakikada Hatta Zamanım çok olmadığı

için ne kadar yarım saatle anlatabilirim

diye düşünüyorum

Eee size ancak ve ancak gerçekten önemli

ama çok önemli olduğunu düşündüğüm

birkaç noktayı değineceğim ümit ediyorum

ki buradan çıktığınızda o önemli

noktalarla kodunuza geri döndüğünüzde o

kokuları alabilirsiniz ve bahsettiğim

pratik yöntemlerle bunları

temizleyebilirsiniz

şimdi çok severek okuduğum ve her

satırından da dediğim bir makale var

Kendisi 199 senesinde e What is software

Design diye bir makale yazıyor bu

makaleyi internetten erişebilirsiniz

yani Zaten bir 2 sayfalık bir yazı her

satırını yedim yuttum not aldım çizdim

Çünkü bunu e açıkça söylemek gerekirse

hiç beklemediğim kadar derin şeyler

yazmıştı Bu yazdıkları e uzun zaman çok

konuşulmadı gelin görün ki zaman

içerisinde Büyük Ustalar tarafından

dillendirilen başlanınca bize kadar

ulaştı Eee bu makalesinde birkaç tane

önemli nokta var Jack

rein yazılımın kaynak kodu tasarımınız

ta kendisidir arkadaşlar tasarım diye

bahsettiğimiz çoğu şey esasında mimari

yani işte buraya bir tane Eee relational

Database koyalım or ortaya bir elastic

Search koyalım şunu cluster haline

getirelim char ayarlarını yapalım işte

uygulamayı modelize edelim e sürekli

sürekli mimariden bahs ediyoruz Peki

tasarım nerede unuttu yazılım dünyasında

yazılımın unuttuğu şeylerin Bence

başında yazılımın iç tasarımı geliyor

Yani biz kodu yazıyoruz ama kod yazmak

ciddi bir tasarım emeği gerektiriyor ve

Eee bakıldığı zaman Jack Reis'in

makalesinde esasında her yazılımcı kod

yazarak tasarım yapıyor aslında ve bütün

koddaki problemlerin büyük bir çoğunluğu

tasarımsal

problemlerle örtüşüyor Yani biz ne kadar

fazla tasarımsal problemleri öğrenirsek

kodumuzun kalitesinin de o kadar

artabileceğini

inanıyorum jackin enteresan bir başka

bakış açısı

da uygulamanız eğer ki test

edilmemişse bir problem var demektir

bitmemiş demektir E kodunuzun sadece

tasarımınız sadece yazılmış olması

kodunuzun yazılmış olması yetmez test

edilmiş olması gerekir çünü yazılımlar

Tıpkı matematik formüllerine benzer

Bugün bana bilmem ne formülünü yazar

mısın dediğinizde yazarım istediğiniz

her formül yazarım Ama doğru değil tabii

ki Yani doğru şey yazacağımı Garanti

edemem ama yazarım Atarım ortaya bir şey

Peki verdiğim formülün doğru olduğunu

nasıl ispat edeceğim ispatlamak

zorundayım Eee Tıpkı yazılımlarda öyle

test edilmemiş kod bitmemiş demektir

hasarlı demektir yanlış demektir bunu

önceden eee

bu şekilde algılayabiliriz ve bu test

etmek manuel testle olabilecek bir şey

değil Tabii ki Tabii ki siz manuel

testle kodunuz her if statement içine

girebilir misiniz Bu mümkün mü yüz

binlerce

farklı ihtimalin dönüp dolaştığı bir

koddan bahsediyoruz

e test yazmaktan bahsediyoruz O nedenle

Tasarımın nihai hedefine ulaşabilmesi

için test yazmak zorundayız yazılmamış

kod yarım tasarlanmış

demektir şimdi bu açıdan bakıldığı zaman

kodun tasarımını programlama kodlama ve

test ya ben onu otomatikleştirilmiş test

otom test ya da bu bizim anladığımız şey

tüm test hiyerarşisinde unit test

integration functional test gibi

testlerle de örtüştürmek

tasarlamak bundan ibaret değil yazılımı

tasarlamak konusunda Tabii ki büyük usta

Robert Martin alıntı yapmazsak olmaz

yani Adet yerini bulmaz Robert marın

harkulade bir sözü var yazılımın Gerçek

değeri nedir bir numaralı değeri onun

doğru çalışması değildir yani Çalışan

yazılım geliştirmek değildir çalışan

yazılım önemlidir ama yazılımı değerli

kılan şey onun gerçekten çalışması

değildir ondan daha değerli bir tane

nokta var düşünün bu çok değerli bir şey

ondan daha da değerlisi var ondan daha

değerli nokta onun değişime karşı ayak

uydurabilmek

Yani sizden sonraki yazılımcının da o

Koda o satırlara kod yazabilmesi yani

önceki yazılımcı e Twitter hesabını

takip ediyorum her yazılımda midemi

kramplar giriyor sonra kendimi buluyorum

Yani resmen beni anlatıyor ya da bizi

anlatıyor buradan

e Bu açıdan baktığımız

zaman değişim kaçınılmaz ve bu değişim

sadece requirement lın değişimi değil bu

karşımıza çıkan bugdan sonra stack

overflow baktığımızda Bizim tahminimiz

de dışında orada kodlar görüyoruz ve

onları uygulamak zorunda kalıyoruz

oradaki çözümleri denemek zorunda

kalıyoruz ve işin yaptığımız kodun

tasarımı sürekli değişiyor ve değişime

karşı adapte olamadığımız zaman da

patchler yazmak zorunda kalıyoruz kim

123 tane metodu olan bir k

bakıp da acaba İhtiyacım olan metot

burada var mı diye bakar bakmaz 123 tane

metot varsa ne ihtiyacı varsa ekler

kimse önceki 123 acaba Burada şu benim

aradığım fonksiyonalite burada var mı

diye birisi bakan görmedi yani 5500

satırlık KL içerisinde of diye açarsınız

püf diye çevres şeyleri Scroll edersiniz

sonra da istediğiniz o User Manager

dünyaya Hakimiyet kurmaya çalışan o User

Manager classın içerisine istediğiniz

metodu yazıp çıkarsınız çok fazla

durmazsın Çünkü orada 123 tane metot var

yani eee bu

kritik şimdi grady book önemli

kişilerden Design Gang of for Design

patterns kitabının girişindeki o forward

kısmını yazan kişi yani o açıdan

bakıldığı zaman önemli bir kişi olarak

doğrudan söyleyebilirsiniz O da diyor ki

Eee yazılımlar da şehirler gibidir Bugün

1 milyon İstanbul'un durumuna bakın 17

milyon Ken bakın Ama birçok semti 1

milyon Ken kuruldu ama 17 milyonu

kaldırmıyor yazılımlar da öyle İlk başta

Tasarladığınız ve Yazdığınız şekilde

kalmayacak eklediğiniz her satır

takımınıza giren her kişiyle beraber

uygulamanız büyüyecek ve tasarımı da

değiştirmek zorunda kalacaksınız

tasarımı değiştirmek mikroservis

mimarisi yapalım 10 tane inst aynı anda

ayağa kaldıralım

değil kı işte yeni metotlar ekleyelim

daha çok feature ekleyelim daha çok

feature bu da değil farklı bir yolu

yöntemi olmalı şimdi bu açıdan bakıldığı

zaman uygulamayı reaktör etmemiz

gerekiyor Yani fonksiyonalite Esi aynı

kalarak uygulamanın iç tasarımını

değiştirmemiz gerekiyor yani eee yazılım

tasarımı dediğimiz şey bir üçgen Bermuda

sheytan üçgeni güzel bir üçgen yani e

burada programlama test ve Eee

refactoring bahsediyoruz Bunlardan

herhangi bir

eksikse üzgünüm sadece kod yazıyoruz

demektir tasarlama tasarımında ciddi

açıklarım olabilir anlamına

geliyor Bunu mutlaka söyle bunları hep

fark edip hep mevcut kodlarda kendi

kodlarım beraber çalışıp takımların

kodlarında gördüğüm için bunlardan

bahsetmek zorundayım o nedenle test

testing ve refactoring yani test unit

test yazma fonksiyonel test yazma

otomatik testler yazma ve refactoring

kaçınılmazdır arkadaşlar ve o testler

geçmek zorundadır test herhangi bir

testiniz geçmiyorsa bir problem var

demektir bütün üretim bandını

durdurmalısınız Çünkü uygulamanızın bazı

bölümleri çalışmıyor olabilir yani şu an

Eee ışık yanıyor arabanızda fren balata

bilmem ne ışığı yanıyorsa siz onu

servise götürmeniz gerekir onunla uzun

süre yaşayamazsınız yapmışlığım vardır

olmuyor yani o araç el nihayetinde

bozuluyor e ve refactoring bildiğiniz

gibi ya da düşündüğüm gibi Eskiden

refactoring ile alakalı bir bölüm olsun

yani bir hafta refactoring yapalım işte

bir sprinti refactoring le koşalım İşte

bu kısmı baştan yazmamız lazım

dediğinizde yöneticileriniz buna izin

vermez hiç kimse vermez yani bir saniye

Sen bu kodu aynı fonksiyonalite aynı

şekilde çalışacak ama ben bütün ekibe

Bir hafta boyunca çalışması için para

vereceğim Bir hafta son sonra aynı kod

aynı şekilde çalışmaya devam edecek yani

siz ne yapıyorsunuz orada falan di

sorular sormaya başlar O nedenle

refactoring mevcut kod yazmaktan ayırt

edilemez refactoring bunun bir

parçasıdır kodu yazarken aynı anlarda

Aynı zamanlarda reaktör etmeniz

gerekir şimdi buna yazılım tasarımının

üçgeni

diyoruz Bu üçgeni dah daha temiz hale

nasıl getirebiliriz Yani temiz temiz

yazılım tasarımı nasıl olabilir bu

üçgene Sadık kalacağız bunu bu

üçgeni biraz Pırıltı eklememiz gerekiyor

Yani refactoring biraz açmamız gerekiyor

iki tane kavram var bu iki kavramı

üstüne basa basa Konuşmamız gerekiyor Bu

iki kavraman bir tanesi cing yani cing

le alakalı vaktimiz olsa bir meetup

larda vesaire üzerine bir saat sadece

coupling konuşsak yani uygulamanın iç

tasarımında birbirine olan bağımlılıklar

eee buna Ara ara e şirkette muhabbet

ederken Hani bir şeyi değiştirmek için

çekiyorsun çektikçe geliyor Bütün bütün

Eee uygulamanın her yerinde değişiklik

yapman gerekiyor bir böyle de

açıklanabilir yahut uygulamaya hiç

dokunamam manla da açıklanabilir yani

burayı değiştiremiyoruz Neden Çünkü onu

şu kullanıyor Çünkü o şuraya bağımlı

Çünkü o burada bunu yapıyor Eee bu çok

sık karşımıza çıkıyor Spring Framework

Hey Java dünyasının medarı iftiharı ya

da böyle web mvc frameworkleri çatılar

harkulade şeyler ama ilginç bir

dezavantajı da var yani Biz şöyle

yapıyoruz controller yazıyoruz

controller altına controller konuşsun

konuşacağı servisler Manager yazıyoruz

Handler yazıyoruz milyon tane

isimlendirme veriyoruz ama onları bir

yazıyoruz şuraya Ondan sonra onların

konuşacağı repository database'e

erişecek olan repository objelerini

oluşturuyoruz E başka Class var mı Yok

uer var Her yerde her yerde helper

classları var Eee milyon tane statik

Herkes birbirini statik olarak çağırıyor

Eee ve uygulamada Eee Herkes her şeye

coupled Yani herkes her şeye bağımlı Eee

sıfır dizay p

yani uygulama içerisinde uygulamanın

modelize olacağı uygulamanın

genişleyebilir controller yazacaksın

Manager yazacaksın Bir de repost bir şey

ekleyeceğim ben gibi hissediyor Yani ben

Eee bu kadar notasyonu belli olan bir

yerde kod yazmak istemiyorum

Yani benim sorunlarım daha karmaşık ve

ben o karmaşık sorunları springe

yedirmek istemiyorum Ben o sorunları

çözmek istiyorum O nedenle Framework

bağımlı Hatta frameworkler kölesi kod

yazma diye bir kavram vardır Bu

tehlikeli bir kavramdır bundan biraz

daha bahsedeceğim coupling kavramını

Kent beck bir oturumda şöyle bahsediyor

internette görebilirsiniz Bir videosu

var 8 Büyük Usta Google Hangout

karşılıklı tartışıyorlar nefesimi

tutarak izledim kulaklık el Ellerim

titreyerek iz inanılmaz şeylerden

bahsettiler Kent orada şöyle söylüyor

Eğer ki bir komitenin içerisinde

birbirinden farklı kavramlar ya da

dosyalar ya da modüller ya da işte o

kavram o komit delerse Bunlar kır

değillerse lo cır yani birbirine olan

bağımlılıkları azdır bir şeyi

değiştirdiğin zaman onu da değiştir onu

da değiştir yapmana gerek kalmaz bu çok

net Anlaşılır komit bir bakın çoğunlukla

komit

baktığımızda ö değiştirirsiniz hepsini

hepsini bir alırsınız ve komit lersin

Peki içerisindeki kaçı bu feature

alakalı kaçı refactoring alakalı kaçı

Dün gördüğümüz bugla

alakalı Bilmiyorum işte yaptıklarımı

komit komit Bu Değil arkadaşlar Hani git

konusunda Çok hassasım O yüzden komit

komit kesinlikle bu değil komit çok özel

bir kavram belki günün birinde yine me

karşılaşır komikler hakkında konuşuruz

şimdi E bir ik kavram da cohesion yani

kavramlar arasındaki Fikir Birliği bir

kavramın tek bir yerden ulaşılabilir

olması günümüzde birçok arkadaşımla

değişik nedenlerle farklı projeler

geliştiriyoruz o projelerde işte Ticket

classı Event classı işte speaker

etkinlik düzenliyoruz etkinlikle alakalı

tasarım kodlar kodlar üzerine

tartışıyoruz cod review yapıyoruz ve cod

review da şeyi fark ediyorsunuz e

kullanıcı burada da var E kullanıcı

burada da var şimdi Ticket Ticket diye

bir Class var Ticket classın içerisinde

session bilgisi var Ben buna ihtiyacım

yok yani cod R yaparken domain ile

alakalı kavramları üzerinde tartışırken

bunun burada yeri Burası doğru mu diye

kafanızda soru işaretleri oluyor bilin

ki orada cohesion da yani alakalı olarak

adlandırdığım isimle türkçeleştirdi

bildiğim diyelim e bu kavramda bir

problem var demektir cohesion kavramı

alakalı kavramının en tepeye çıkması

cinge olabildiği kadar aşağı inmesi

gerekir birini yukarı çekerken Öbürü de

zaten aşağıya inecektir burada net price

eğer okumadıysanız mutlaka okumanızı

tavsiye ederim growing object oriented

software by tests diye bir kitabın

yazarlarından bir tanesi benim tahmin

daha tahminimden çok daha genç çıktı

açıkçası E onun çok iyi güzel tarif

etmiş Eğer ki siz bir kavram konusu bir

feature ekliyorsun login le alakalı

payment la alakalı işte transal bir şeyi

değiştiriyorsa açtıysanız o zaman bir

problem vardır diyor yani siz bir

kavramda değişiklik yapacaksınız o

dosyada bu dosyada bu dosyada bu dosyada

bir sürü farklı yerde onun parçalarını

görmektesiniz bunu Şununla da alakalı

aştı biliriz e primitive obsession diye

bir kavram bir kavram var primitifler

ilkel veri yapıları ona karşı olan

takıntı hepimiz primitiv her yere String

koyuyoruz her yerde integer long double'

havada uçuşuyor priz diyoruz Sonra bir

bakıyoruz Ah price'ın yanına ceny de

gerekiyor TL koymamız gerekiyor Tamam

Price T iki tane ayrı primitif olarak

kullanıyoruz bir bakıyoruz bir tane daha

bilgi gelmiş ortada bağırsakları olan

yine örneklerim hep iğrenç oluyor o

yüzden oraya girmiyorum E yani işler

kötüye sarıyor öyle söyleyeyim yani

örnek verme konusunda bir sıkıntım var

şimdi ene sonunda bakıldığı zaman bu

Bermuda Şeytan üçgenini biraz daha

şekillendirir isek altta refactoring

imizin ana amacı king'i düşürmek yani

uygulamanın iç tasarımındaki kavramların

birbirine olan bağımlılıklarını

olabildiği kadar aşağı indirmek bunu

yaparken de aynı anda zaten aynı anda

oluyorlar bunu yaparken de cohesion yani

Birbir alakalı arttırmak ikonları

seçerken burada king'de damma etkisi

Yani bir şeyi değiştirdiğiniz zaman Onda

da değiştir Bunu değiş tusuna mi etkisi

yaratıyor öbürü ise henüz internette

olmayan halay çekme ikonunu ben yarattım

halay çekme ikonu yani birbiriyle e

alakalı arkadaşların ayrılamaz bir

şekilde e beraber olma durumu halay

ikonu da Eee internete katkı tek katkım

bu yani bugün öyle söyleyeyim şimdi buna

baktığımız zaman

bir şeyi hiç yapmıyoruz ya da yaparken o

kadar zorlanıyoruz ki yapmasam olmaz mı

Lütfen yapmayayım diye ısrar ediyoruz O

da şu isimleri değiştirmek ne olur

isimleri değiştirelim ne var değiştirsek

Ne olur bir tane git bren al Değiştir

değiştirebilen kodları komikleri geri al

ne olur Yeter ki değiştirin arkadaşlar

isimlendirme değiştirmek önemlidir Çünkü

her yeni isimlendirme yeni veri yapıları

yeni kavram ları getirir buradan

bakıldığı zaman mesela biz ne yapıyoruz

mailer Nuse Gmail smtp Send email ya

smtp Gmail'in smtp üzerinden Send email

diye bir metot yazıyoruz sonra ya bu

isim çok jenerik ya Ben hla nasıla

ilgilenmiyorum yani E bu

işin ne Send email' çeviriyoruz Send

email her projede Send email vardır Her

projenin birçok Send emaili vardır Hatta

E ama esas istediğimiz şey şu Send

activation email Send activation emaili

arkada generik bir Send emaili

kullanabilir sorun değil ama Koda

baktığımız zaman Send email şimdi bu

Acaba hangi emaili atıyor diye

düşünüyoruz sonra 17 parametrede de

activation ile alakalı bir rakam

görüyoruz 12 12'nin Database activation

olduğunu birinin bakması gerekiyor Yani

kod daha okunaklı olması gerekmez mi Bu

açıdan bakıldığı zaman isimlendirme çok

çok önemlidir refactoring en önemli

parçalarından bir tanesidir en

önemlisidir demiyorum çünkü refactoring

en önemli parçası Bence extract metod

yani 100 yılın gördüğü en basit 100

yılın gördüğü idelerin destek en çok

destekledi refactoring yöntemi olan o

extract metodu kullanmamız gerekiyor

Yani 200 satırlık Koda baktığımız zaman

Ya bu çok fazla O yüzden gel teker teker

satırları okuyalım değil e var parçayım

tam gel parçaladım şu metodu yani

commenter Ben hatırlıyorum ben de çok

yaptım commenter le kodları bloklara

ayırıyoruz kodun bu kısmı şuraya bakıyor

bu kısmı price'ın bilmem nesini yapıyor

bu Tamam ayır o zaman metotları ayır

İşte tam refactoring ortaya çıktığı yer

bu kodu temizlerken buna gerçekten

ihtiyacımız

olacak bir başk bir isimlendirme ile

ilgili çok hassas olduğum konulardan bir

tanesi de şu

helper

helper utility utility şey metotları

classları Ama genel olarak şöyle

kullanılır seçersiniz Çünkü kınız o

kadar büyümüştür ki 123 tane 80 tanesini

seçersiniz User managerin vardır ya User

Manager helper diye ona aktarırsınız ona

da dependen verirsiniz Oh kodum çok

güzel oldu sadece 20 tane metot kaldı

geriye kalan 80 met öbür tarafta helper

tehlikelidir çünkü helper metı classları

içerisinde Business Logic Barındırır

utility classları tehlikelidir bugün

baktığınız zaman her şey utility diyoruz

her şeyin başına statik koyuyoruz

uygulama test edilemez hale geliyor

Cingi devasa oluyor Herkes her şeye

bağımlı Tabii ki isimlendirme ii

değiştirmek çok tehlikeli olur

uygulamayı daha genişleyebilir hale

getirebilmek Ama herkes ona ulaşıyor

rahatlıkla ulaşsın Ulaşmasın rahatlıkla

Ulaşmasın varsın kullandığımız Framework

40 yılın başı Spring kullanmışız varsın

Spring bunu inject etsin yaptığı tek şey

singleton olarak Ayağa kaldırmak ve onu

inject etmek Bu kadar

basit Daha bir sürü isimler isimler

isimler isimler hepsini kullanıyoruz

Peki ne manaya geliyor controller

biliyoruz ama arkasında Manager

repository helper parser vesaire milyon

tane var yemiyoruz Hatta bir seferinde

işte message helper message Broker

message işte zımbır bir sürü başında

message olan 50 tane Class gördüm

arkadaşla beraber kod yazıyorduk dedik

ki bu ne yapıyor Bunun bunun birisinin

grafiğini çizmesi lazım kod grafiği

çizilmesi gereken

bir bir şey olmaması gerekiyor Koda

baktığınız zaman onu anlamanız gerekiyor

o yüzden bu isimleri kullanırken dikkat

etmemiz gerekiyor ne manaya geldiğini

Bilmemiz gerekiyor ve e Framework

bağımlı kod yazmadan bunları kullanmayın

demiyorum ama kullanırsak da Bunlar

sadece ama sadece entry pointler olarak

kullanılarak e kodu tasarım Design

pattern lla

şekillendirmek şimdi E uygulamayı

parçalara bölmek bahsettik parçalara

bölmek çok kritik yeni abstraction

yaratmak çok daha kritik yani yeni yeni

isimlendir yeni gerektirir Yani

uygulamanızda siz Ticket var o ticketı

satın alacak User var bir de sınız var

bir de şu var bu var ve sürekli Bunları

bir yerden bir yere pas etmeye

başlıyorsunuz her yerde Ticket ve User

beraber gidiyor Ticket ve User Ticket ve

User her yerde Ticket ve User devam

ediyor O zaman bir yerlerde duplikasyon

yok mu ama kod duplikasyonu değil copy

paste değil bunlar Ticket ve User

beraber devam etmek zorunda Ama bu

knowledge duplication deniyor buna

bilginin duplikasyonu tekrarı

uygulamalarda Dry Prensi diye bir şey

duymuş olabilirsiniz Dry Prensi do not

repeat Yourself çoğunlukla şöyle söyler

kodda duplikasyon olmamalı kod düplik

asyonu Tamam Koda baktığınız zaman

birbirlerini tekrar eden if if if if if

if falan bunlardan bahsetmiyoruz sadece

bilginin de tekrarından bahsediyoruz ve

bu Bilgi tekrarı çok tehlikelidir

birbirini tekrar eden bu bilgiler mesela

kod rler düzenliyoruz bir Board Game

yazıyoruz ve orada da bir board'un bir

dama tahtası gibi X ve Y koordinatlarına

göre taşları koyuyoruz her yerde XY

geçiyor XY XY x XY XY Tamam bildiğiniz

dve prensibini uygulamamız gerekiyor

burada ciddi bir koku var coordinat

location position gibi bir objenin

içerisinde bunu enkapsüle edin yani bu

İlla object oriented mekle alakalı değil

Ya da istediğiniz herhangi bir

paradigmayı

kullanın illaki Oradaki duplikasyonu bir

şekilde çözmeniz gerekir sadece yeni bir

obje olması değil Ayrıca yeni veri

yapıları da

kullanabilirsiniz mapleri Collection lı

vesair kullanmıyoruz sürekli ya her şeyi

database'e yazıyoruz ya da her şeyi ama

her şeyi primitifler olarak pas ediyoruz

Oysa ki bu ortada uygulamanızın

ortasında var olacak mapler Collection

kodu geçici olarak bellekte

tutabileceğiniz ve sonradan

kullanabileceğiniz yapılar kritiktir

neden kritik uygulama öyle devam edeceği

için değil o veri yapılarından Siz daha

sonra uygulama evrilir Ken yeni veri

yapılarına yeni abstraction vara

erişecek yani uygulama Yazdığınız an

biten bir şey değil uygulama gelecekte

genişleyebilir olması gerekli Bu da

önemli adımlardan bir

tanesi leak abdan bahsetmem gerekiyor

leaky abstraction Yani abstraction daki

Sızıntı abstraction Türkçesi çok

soyutlama soyutlamanın sızıntısı Yani

siz Biz her yerde nal kontrolü yapıyoruz

e login kontrolü yapıyoruz User eş log

in User ya da authenticated User eşit

değil log n falan her yerde nal O ne

anlama geliyor bu kadar low level bir

abstraction anlamlı değil buradaki

abstraction abstract CL

bahsetmiyorum bildiğiniz kavramların

abran bahsediyorum Eğer ki sizin

uygulamanız bilet satın al Bilmem ne

organize Event organize et session aç

session kapat gibi metotlara sahip ya da

o seviyede abstraction sahipse User

login User eşit değilse n diye bir

kontrolün orada olmaması gerekir Peki

oraya o kontrolü koymamız gerekiyorsa Ne

yapacaksınız işte onu ayrı bir metoda

çekeceğiz Orada

validate

Locked authenticated onun gibi dışarıya

almamız ve ona özel isimler vermemiz

gerekiyor sonra taşıdığımız yeri Belki

başka bir yere götüreceğiz yani uygulama

evrilerek devam

edecek

implementasyon lı yine hep aynı örneğe

doğru kayıyorum yani içeride

sakladığımız detayları dışarıya

vermememiz gerekiyor şimdi Eee Robert C

Martin'in e her daim eee e referans

verdiğim kişinin güzel bir sözü var Eğer

bir şeyi yapmak daha yavaş daha zor Daha

Zor Her geçen gün daha zor oluyorsa Dün

yaptığınız Dün

Eee ya da bir ay önce 3 günde

bitirdiğiniz modülün benzerini yazmanız

Bugün 2 hafta alıyorsa bilin ki

uygulamanızın içerisinde dehşet kokular

var ve

hissetmiyoruz yani uygulamada bir

problem var Oy bu problemi çözmemiz

gerekiyor yani buna baktığım zaman bu

üçgen yetersiz Arkadaşlar bu üçgenle

Hayat bulabilmek mümkün değil bu üçgenin

üzerinde Ayrıca cod review koymamız

gerekiyor çünkü yazılımcılar olarak

Bizler mükemmel değiliz geliştirdiğimiz

kod doğru çalışmıyor yaptığımız tasarım

hatalı Bize gelen requirement eksik

testi yapan arkadaş test sadece Best

caseleri Happy padleri test ediyor Yani

herkese bir kus K var bunu kabul etmemiz

gerekiyor yaptığımız şeyler kusurlarla

dolu o zaman nasıl temiz Koda ulaşacağız

yani kaliteli Koda nasıl ulaşacağız

benim ulaştığım şey kaliteli kod

diyebilmem için başka gözlerin de

desteğine ihtiyacım var o açıdan

bakıldığı zaman pay programming ve Code

review ikisi çok ama çok önemlidir bunun

sadece kod yazmak da değil sosyalleşme

açısından da önemli bir yeri vardır

sizin kurumsal yazılım kültürünüzü

gerçekten ayak üzerinde tutabilmek ve

insanların gıptayla bakabileceği bir

iletişim ve Yardımlaşma kültürü

oluşturabilmeniz için insanların

birbirine iletişim kurabilmesi için

fırsat vermemiz gerekiyor Bu da cod

review ve p programming doğrudan bunu

amaçlıyor Aslında

şimdi buna baktığımız zaman eğer ki daha

temiz bir Koda ulaşmak istiyorsanız

lütfen Birbirinizin koduna yorumlar

yazın lütfen ego ımızı bir yere

indirelim egoların inen egoların

ışığında kodu tartışalım ve kodun daha

temiz daha az kokulu nasıl olabileceğini

kavramaya çalışalım bunun Keskin bir

şeyi yok kitaplar var bunun üzerine

kitapları okuyalım tartışalım

BG

çözmeye ve debug yapmaya vaktimiz var mı

Tabii ki var debug Yapmaya Tabii ki var

çünkü kodu yazacağız B çözmeye vaktimiz

var mı Tabi ki çözmeye vaktimiz var

çünkü bug çıkarsa çözmezsek uygulama

çalışmayacak bug çözmeye ve debug

yapmaya vaktimiz var ama temyiz kod

yazmaya test yazmaya tdd yapmaya pay

programming yapmaya vaktimiz yok bunu

kabul edemiyorum esasında bu tamamen bir

algıda algı yönetimiyle alakalı bir şey

yani bugün production da çok ama çok az

bugını çıktığını düşünün ne kadar çok

vaktiniz olacaktır ne kadar çok çok

vaktimiz olacak Eee bunu sağlayabilen

yolu daha 1 dakikadan itibaren buna

yönelik kod yazmaktan geçiyor

Eee düplik kasyon varı kaldıracağız

duplikasyon lı kaldırırken de sadece

kodu değil bilgi bilginin de duplike

olduğu tekrarladığı yerleri de bulup

Eee bunları kapsüle edeceğiz bunları

tekrarından

kurtulacağız ve lütfen her şeyi

küçültecek

Lütfen yeni klaslar oluşturalım her

yerde dosyalar olsun önemli değil 5500

satırlık bir klası mı tercih edersiniz

yoksa 500 tane minik klası mı tercih

edersiniz Tabii ki 500 tane minik klası

Çünkü bir fili yemenin en kolay yolu bir

Filik yemenin yolu lokmalara bölerek ya

lokmalar şeklinde yememiz gerekiyor o

nedenle lokmalara bölmem gerekiyor temiz

kod lokmalara bölünmüş yazılımdır yani

siz bir yazılımda lokmayla yamaya kodlar

varsa bilin ki temiz değildir O kısım O

nedenle interface deri classları

aklınıza gelecek her şeyi küçük küçük

parçalara bölmen

şart ve Lütfen Birkaç konuya dikkat

edelim frameworkler

frameworkler

şeyi kölesi kod yazmanın yanında

keywordleri statik keywordleri herkes

Bunu kullanırken 5 t'yi cebinde hazır

etmesi gerekiyor Yani yeri geldiği zaman

kullanacağız ama kullandığımız zaman da

işte 5 TL dememiz gerekiyor Yani bunları

Eee gerçekten bilgece kullanmamız

gerekiyor optimizasyona çok kafa

görüyoruz Tamam yazılımcı olarak

kodumuzu güzelleştirmek için seviyoruz

güzelleştirmeyi ama bırakın ilk günlerde

kötü olsun temiz olmasın ama şunun

bilincinde olalım bu kod reaktör edilmek

zorunda reaktör edilmeden bitmemiş

demektir

ve önceden büyük tasarımlardan kaçının

uygulamayı kodu yazarken iki paterne

denk geliyorum bir

tanesi hiç düşünmeden kod yazanlar işte

bir feature geliştiriyoruz Evet yazdım

kontroll anlat devam et yazıyorum falan

yazdın mı Evet işte repos Yazdım şu an

Database atabiliyorum çek çekeceğim

gönder bana bilgiyi böyle şeyler

görüyorum İkincisi de anlatıyorsunuz o

zaman bir çizelim başlıyor çizmeye o

böyle olmaz öyle olmaz çizdik çe çiziyor

anlattıkça anlatıyor bitmiyor O upfront

Design var ya bitmiyor en önce yapılan

bir Short upfront Design diye geçiyor

ecal dünyasında Yani kısa bir tasarım

ilk kafanızda Böyle bir şey olabilir

diye Giriş yapın daha sonra refactor

edeceğinizi emin olun refactor

edeceksiniz O nedenle işte hard cod

buraya 42 yazdım kalmas kalsın boş ver

ama onu reaktör edeceğini de garantisini

ver bunların ışığında baktı ın zaman bu

benim için yazılım temiz kod tasarımının

Bermuda Şeytan üçgeninin de ötesinde

Eee özel bir yapısı

e doğrudan gördüğüm ve Tanık olduğum

bilgiler ve deneyimler böyle daha

detayları için lütfen bu konular

hakkında harkulade kitaplar var bu

kitapları da yalayıp yutmam gerekiyor o

konuda da hani sizden de o tutkuya sahip

olacağınıza eminim

beni dinlediğiniz için teşekkür ediyorum

Arkadaşlar sağ

olun