Kaynak: "[Robert C. Martin Series] Robert C. Martin - The Clean Coder_ A Code of Conduct for Professional Programmers (2011, Prentice Hall) - libgen.li.pdf" alıntıları.
Yazar: Robert C. Martin ("Uncle Bob") - 1970'ten beri programcı, Object Mentor, Inc. kurucusu ve başkanı.
Kitabın Amacı: Profesyonel bir programcı olmanın ne anlama geldiğini tanımlamak, bu profesyonelliği oluşturan tutumları, disiplinleri ve eylemleri açıklamak. Yazar, bu bilgileri kendi hatalarından ve deneyimlerinden yola çıkarak aktarmaktadır.
Ana Temalar ve Önemli Fikirler/Gerçekler:
Profesyonellik:
Profesyonel programcılık sadece kod yazma becerisiyle ilgili değildir. Aynı zamanda sorumluluk almak, iş ahlakına sahip olmak ve sürekli öğrenmekle ilgilidir.
"First, Do No Harm" (Önce Zarar Verme): Profesyoneller, kodlarına ve sistemlerine zarar vermekten kaçınmalıdır. Bu, hem fonksiyonel zararı (kodun doğru çalışmaması) hem de yapısal zararı (kodun bakımı ve anlaşılması zor olması) içerir.
“First, Do No Harm 11 Work Ethic 16” (İçindekiler bölümünden) "Do no harm” yaklaşımı, hem fonksiyonel (kodun doğru çalışmaması) hem de yapısal zararı (kodun bakımı ve anlaşılması zor olması) kapsar. Kodun doğru çalışır durumda olmasını sağlamak kadar, yapısının da sürekli iyileştirilmesi önemlidir.
"Boy Scout Rule" (İzci Kuralı): Modülleri her zaman aldığınızdan daha temiz bırakın. Sürekli olarak kodun yapısını iyileştirmek ("merciless refactoring" - acımasız refaktoring), yazılımın esnekliğini korur ve gelecekteki değişiklikleri kolaylaştırır.
“This philosophy is sometimes called merciless refactoring. I call it “the Boy Scout rule”: Always check in a module cleaner than when you checked it out. Always make some random act of kindness to the code whenever you see it.”
İş Ahlakı: Bir programcının kariyeri kendi sorumluluğundadır. İşveren, eğitimden veya gelişim fırsatlarından sorumlu değildir; bunlar profesyonelin kendisi tarafından yönetilmelidir.
“Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer.”
Sürekli Öğrenme ve Pratik: Endüstri sürekli değişmektedir. Profesyoneller, yeni teknolojileri, dilleri, teknikleri ve disiplinleri öğrenerek kendilerini geliştirmelidir. Kod katasları ve kod dojo gibi pratik yöntemler bu gelişim için önemlidir.
“Practice ethics, 93” (İçindekiler bölümünden) “The Coding Dojo 89 Broadening Your Experience 93” (İçindekiler bölümünden) “One of the first machines I ever wrote programs for was a PDP-8/I…And what am I doing with this increase in power of 22 factors of ten? I’m doing pretty much what I was doing with that PDP-8/I. I’m writing if statements, while loops, and assignments.” (Teknolojinin hızla değişmesine rağmen temel programlama kavramlarının aynı kaldığına dikkat çeker.)
"Hayır" Demek:
Profesyonel programcılar, kendilerini veya ekibi başarısızlığa götürecek taleplere "hayır" demekten çekinmemelidir. Bu, bir "takım oyuncusu" olmanın reddedilmesi anlamına gelmez; aksine, gerçekçi olmayan veya zararlı işlere karşı dürüst ve sorumlu bir duruştur.
“Adversarial Roles 26 High Stakes 29 Being a “Team Player” 30 The Cost of Saying Yes 36 Code Impossible 41” (İçindekiler bölümünden) "Bazen doğru "evet"e giden tek yol, "hayır" demekten korkmamaktır."
Gerçekçi olmayan taleplere "evet" demenin maliyetleri vardır: kalitesiz kod, kaçırılan teslim tarihleri, artan borç (technical debt).
“The Cost of Saying Yes 36” (İçindekiler bölümünden)
Müşteriler ve paydaşlar genellikle teknik detayları bilmezler. Teknik kısıtlamaları ve zorlukları net bir şekilde iletmek profesyonelin sorumluluğudur.
"The Client: What’s a web service? Me: ………… Continues" (Bir örnek hikayeden alıntı)
"Evet" Demek ve Taahhüt Dili:
Gerçek profesyonel taahhüt, sadece bir niyet veya umut ifadesi değildir. Taahhüt, üç bileşene sahiptir: söylemek, kastetmek ve yapmak.
“Say. Mean. Do. There are three parts to making a commitment.”
Gerçek taahhüt dilinin temel yapısı "Ben şunu şunu [eylem] yapacağım, şu zamana [bitiş zamanı] kadar." şeklindedir. Bu dil, kişisel sorumluluk almayı ve belirli bir sonuca ulaşmayı ifade eder.
“The secret ingredient to recognizing real commitment is to look for sentences that sound like this: I will . . . by . . . (example: I will finish this by Tuesday.)”
"Need/should", "Hope/wish", "Let's" gibi ifadeler genellikle taahhüt eksikliğinin işaretleridir. Bu ifadeler, durumun kişinin kontrolü dışında olduğunu veya kişisel sorumluluk alınmadığını ima eder.
“Here are some examples of words and phrases to look for that are telltale signs of noncommitment: • Need\should. • Hope\wish. • Let’s. (not followed by “I . . .”)”
Başkalarına bağımlı olunan durumlarda, taahhütler nihai hedefe değil, kişisel olarak kontrol edilebilen spesifik eylemlere verilmelidir (örneğin, "X kişisiyle bir saat oturup bağımlılıklarımı anlayacağım").
Kodlama:
Kodlama, yüksek düzeyde konsantrasyon ve odaklanma gerektiren zihinsel olarak yorucu bir aktivitedir ("Flow Zone" - Akış Bölgesi).
“Coding is an intellectually challenging and exhausting activity. It requires a level of concentration and focus that few other disciplines require.”
Hazırlıklı olmak ve kişisel kaygıların veya dışsal faktörlerin (örneğin, müzik dinleme) odaklanmayı bozmasına izin vermemek önemlidir.
“When I am worried about an argument with my wife, or a customer crisis, or a sick child, I can’t maintain focus. My concentration wavers.” “As a reader of the code, I was learning more about the music collection of the author (me) than I was learning about the problem that the code was trying to solve.”
Kesintilere karşı tutum önemlidir; profesyoneller yardım isteyenlere nazikçe yaklaşmalı, ancak odaklanmalarını korumak için de stratejiler geliştirmelidir.
“How do you respond when someone asks you a question? Do you snap at them? Do you glare? … Or, do you stop what you are doing and politely help someone who is stuck?”
Teslim tarihlerine yetişmek için acele etmek tehlikelidir. Profesyoneller, tahminlerine bağlı kalmalı ve gerekirse kapsamı azaltmayı önermelidir.
“Tell your boss that you’ve already considered the options (because you have) and that the only way to improve the schedule is to reduce scope. Do not be tempted to rush.”
Yardım istemek ve yardım teklif edildiğinde nazikçe kabul etmek profesyonel bir etik konusudur.
“Remember, just as you are honor bound to offer help, you are honor bound to accept help.” “It is unprofessional to remain stuck when help is easily accessible.”
Test Odaklı Geliştirme (TDD):
Test Odaklı Geliştirme (TDD), birim testlerini üretim kodundan önce yazma disiplinidir.
TDD'nin Üç Yasası:Başarısız bir birim testi yazmadan herhangi bir üretim kodu yazamazsınız.
Başarısızlığa yol açacak kadarından (ve derlenmemesi de başarısızlıktır) fazla birim testi yazamazsınız.
Mevcut başarısız birim testini geçecek kadarından fazla üretim kodu yazamazsınız.
“TH E TH R E E L AW S O F TDD 1. You are not allowed to write any production code until you have first written a failing unit test. 2. You are not allowed to write more of a unit test than is sufficient to fail—and not compiling is failing. 3. You are not allowed to write more production code that is sufficient to pass the currently failing unit test.”
Bu yasalar, kodu çok kısa döngüler halinde (yaklaşık 30 saniye) geliştirmeye zorlar ve daha hızlı geri bildirim sağlar.
TDD'nin faydaları arasında artan kesinlik, hata enjeksiyon oranının düşmesi, tasarımın iyileşmesi ve daha iyi dokümantasyon yer alır.
Pratik Yapmak:
Programcılık, tıpkı diğer disiplinler gibi pratik gerektiren bir beceridir. Kod katasları (örneğin, Bowling Oyunu, Asal Çarpanlar) veya kod dojo gibi ortamlar bu pratik için kullanılabilir.
“The Coding Dojo 89” “• The Bowling Game: http://butunclebob.com/ArticleS.UncleBob.TheBowling-GameKata • Prime Factors: http://butunclebob.com/ArticleS.UncleBob.ThePrimeFactors-Kata”
Pratik yapmak, becerileri keskinleştirmek ve yeni yaklaşımları denemek için bir yoldur.
Kabul Testleri:
Kabul testleri, paydaşlar ve programcıların bir gereksinimin "bitti" olarak kabul edildiği durumu tanımlamak için birlikte yazdığı testlerdir.
“In this chapter we will define acceptance tests as tests written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done.”
Bu testler, gereksinimlerdeki belirsizlikleri gidermeye yardımcı olur ve "bitti" tanımını netleştirir.
“One of the most common ambiguities we face as software professionals is the ambiguity of “done.” When a developer says he’s done with a task, what does that mean?”
Kabul testleri, paydaşlar ve geliştiriciler arasındaki iletişimi ve işbirliğini artırır.
Test Stratejileri:
QA ekibinin (Kalite Güvence) neredeyse hiçbir hata bulamaması geliştirme ekibinin hedefi olmalıdır. QA bir bulgu bulduğunda, geliştirme ekibi bunun nasıl olduğunu sorgulamalı ve tekrarını önlemek için adımlar atmalıdır.
“QA SH O U L D FI N D NOTH I N G I’ve said this before, and I’ll say it again. Despite the fact that your company may have a separate QA group to test the software, it should be the goal of the development group that QA find nothing wrong.”
Test otomasyonu, bir piramit modeli ile açıklanır: tabanda hızlı çalışan birim testleri, ortada bileşen testleri ve tepede daha yavaş ve kapsamlı sistem/entegrasyon testleri yer alır.
“The Test Automation Pyramid 115”
Zaman Yönetimi:
Profesyoneller, zamanlarını etkili bir şekilde yönetmek için stratejiler kullanmalıdır.
Toplantılar, zamanın önemli bir kısmını tüketebilir. Toplantılara katılmayı dikkatlice seçmek ve toplantı süresince odaklanmak önemlidir.
“Meetings 122”
"Focus-Manna", zihinsel odaklanma yeteneğidir. Bu, iyi bir uyku, ara vermek ve fiziksel aktivite ile yenilenebilir. Kafein, dikkatli kullanılmalıdır.
“Focus-Manna 127” “Professional developers manage their sleep schedule to ensure that they have topped up their focus-manna by the time they get to work in the morning.” “Focus-manna can be partially recharged by de-focussing.” “Muscle focus helps to recharge mental focus.”
Pomodoro Tekniği: Zamanı 25 dakikalık "domates" bloklarına bölmek ve bu süre zarfında kesintileri agresif bir şekilde engellemek, odaklanmayı ve üretkenliği artırmanın etkili bir yoludur.
“TI M E BOX I N G A N D TO M ATO E S One very effective way that I’ve used to manage my time and focus is to use the well-known Pomodoro Technique,2 otherwise knows as tomatoes.”
Tahmin (Estimation):
Tahmin, iş dünyası ve geliştiriciler arasındaki temel bir güvensizlik kaynağıdır. İş dünyası tahmini bir taahhüt olarak görürken, geliştiriciler genellikle bir tahmin (guess) olarak görür.
“Estimation is one of the simplest, yet most frightening activities that software professionals face… It is the primary wedge that has been driven between business people and developers. It is the source of nearly all the distrust that rules that relationship.” “The problem is that we view estimates in different ways. Business likes to view estimates as commitments. Developers like to view estimates as guesses.”
Taahhüt: Elde edilmesi gereken bir şeydir. Tarihi kaçırmamak için ne gerekiyorsa yapılmalıdır.
“A commitment is something you must achieve.”
Tahmin: Bir tahmin (guess)tir. Herhangi bir taahhüt ima etmez. Bir tahmini kaçırmak, onursuzluk değildir. Bir tahmin, bir sayı değil, bir olasılık dağılımıdır (en iyimser, nominal, en kötümser senaryoları içerir).
“An estimate is a guess. No commitment is implied. No promise is made. Missing an estimate is not in any way dishonorable. The reason we make estimates is because we don’t know how long something will take.”
Belirsizlikler birleştiğinde, toplam tahmin daha kötümser hale gelebilir (PERT tekniği gibi).
Tahmin yaparken, riskleri ve belirsizlikleri açıkça iletmek önemlidir.
Baskı:
Baskı altında, profesyonellerin gerçek disiplinleri ortaya çıkar. Kriz anında disiplinlerine bağlı kalanlar, o disiplinlere gerçekten inanırlar.
“CR I S I S DI S C I PLI N E You know what you believe by observing yourself in a crisis. If in a crisis you follow your disciplines, then you truly believe in those disciplines.”
Baskıyı önlemenin en iyi yolu, sistemleri ve kodu temiz tutmaktır. Karmaşalar, ilerlemeyi yavaşlatır ve baskıyı artırır.
“We can avoid pressure by keeping our systems, our code, and our design as clean as possible.”
Profesyoneller, baskı altında panik yapmamalı ve disiplinlerinden taviz vermemelidir.
Ekipler ve Projeler:
Küçük, birleştirilemeyen projelerin yönetimi bankalar ve sigorta şirketlerinde sıkça görülen verimsiz bir durumdur. Projelerin parçalara ayrılması ve kaynakların (proje yöneticileri, analistler, programcılar, test uzmanları) birçok projeye dağıtılması, odağı dağıtır ve verimliliği düşürür.
Takım Hızları (Team Velocities): Gelled (birleşmiş) ekiplerin sabit bir sürede ne kadar iş yapabileceğini gösteren bir ölçüdür. Hız istatistiksel bir ölçümdür ve zamanla ortalaması alınır.
“Teams have velocities.1 The velocity of a team is simply the amount of work it can get done in a fixed period of time.”
Gelled takımlar, projelere atanmış bireylerden daha verimlidir çünkü odaklanmışlardır ve zamanla birim zamanda daha fazla iş yapmayı öğrenirler.
Mentorluk, Çıraklık ve Zanaatkarlık:
Programlama, kişisel olarak öğrenilebilen ama aynı zamanda başkalarından (mentorlar, meslektaşlar) öğrenilerek büyük ölçüde gelişen bir zanaattır.
“I did not figure it all out for myself. I was mentored.” (Yazarın kendi ilk programlama deneyiminden alıntı)
Zanaatkarlık, değerler, disiplinler, teknikler ve tutumları içeren bir zihniyettir. Bu zihniyet, gözlemleme, öğretme ve öğrenme yoluyla nesilden nesile aktarılır.
“Craftsmanship is the mindset held by craftsmen. Craftsmanship is a meme that contains values, disciplines, techniques, attitudes, and answers.”
Yazar, kendi kariyerindeki çeşitli mentorluk deneyimlerinden (boole cebri kılavuzunun yazarları, Jim Carlin gibi BAL programcıları) bahseder.
Araçlar (Tooling):
Profesyonel programcılar, kullandıkları araçları iyi bilmelidir.
Kaynak Kod Kontrol Sistemleri: git gibi dağıtılmış kaynak kod kontrol sistemleri, geliştiricilerin dallanma (branching) stratejilerini ve genel iş akışlarını büyük ölçüde değiştirmiştir. SVN gibi merkezi sistemlerin aksine, git dallanmayı çok daha kolay ve esnek hale getirir.
“If you are using SVN, then I still think that’s a good policy. However, there are some new tools that change the game completely. They are the distributed source control systems. git is my favorite of the distributed source control systems.”
IDE/Editörler: Geliştiriciler zamanlarının çoğunu kod okuyup düzenleyerek geçirirler. vi ve Emacs gibi güçlü genel amaçlı editörler hala kullanılsa da, Eclipse gibi özel amaçlı IDE'ler kod düzenleme için daha yaygın hale gelmiştir.
“Emacs is still one of the most powerful editors out there… Editing code is not a general-purpose editing job.”
Birim Test Araçları: Her dilin kendi birim test aracı (JUnit, rspec, NUnit vb.) vardır. Bu araçların hızlı ve kolay çalıştırılabilir olması önemlidir.
“UNIT TE STI N G TO O L S Each language has it’s own particular unit testing tool.”
Bileşen ve Entegrasyon Test Araçları: FitNesse ve Green Pepper gibi araçlar kabul ve entegrasyon testleri için kullanılır.
UML/MDA: Yazar, Model Destekli Mimari'nin (MDA) kodu ana sorun olarak görmesini eleştirir. Ona göre sorun kod değil, detaylardır. Programcılar detay yöneticileridir.
“Unfortunately, this grand dream has one tiny little flaw. MDA assumes that the problem is code. But code is not the problem. It has never been the problem. The problem is detail.” “THE DE TA I L S Programmers are detail managers. That’s what we do.” (Örneğin, \n ve \r arasındaki fark gibi detaylar.)
Bu brifing belgesi, sağlanan kaynaklardan elde edilen en önemli fikirleri ve temaları özetlemektedir. Robert C. Martin, yazılım geliştirmeyi sadece teknik bir iş olmaktan çıkarıp, etik, sorumluluk ve sürekli gelişim gerektiren bir zanaat olarak ele almaktadır. Kitap, bu zanaatkarlığın nasıl inşa edileceğine dair kişisel deneyimlerden ve gözlemlerden yola çıkarak pratik tavsiyeler sunmaktadır.