Temiz Kod Tasarımı - Lemi Orhan Ergin
Summary
TLDRThe 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
😀 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.
😷 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.
📝 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.
🔨 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.
🤝 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.
😎 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.
🏭 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.
🤝 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.
Mindmap
Keywords
💡software design
💡refactoring
💡code quality
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
Посмотреть больше похожих видео
Abstraction Can Make Your Code Worse
If Your Code Looks Like This... You're A GOOD Programmer
ISTQB FOUNDATION 4.0 | Tutorial 23 | Static Testing Basics | Reviews & Static Analysis | CTFL
CH03. L01. Static Techniques and the Test Process
How principled coders outperform the competition
"Clean Code" is bad. What makes code "maintainable"? part 1 of n
5.0 / 5 (0 votes)