Bir Programı Akılda Tutmak
Paul Graham
Ağustos 2007

Tıpkı bir matematikçinin çözmeye çalıştığı bir problemi aklında tutması gibi kendi yazdığı bir program üzerinde yoğun olarak çalışmakta olan iyi bir programcı da bu programı aklında tutabilir. Matematikçiler, okulda çocuklara öğretilenin aksine sorulara kağıt kalem ile çözüm aramazlar. Zihinlerinde daha fazlasını yaparlar: problemi etraflıca anlamaya çalışıp böylece tıpkı sizin büyüdüğünüz evin hatıraları arasında gezinebileceğiniz gibi bu problem uzayında dolaşabilirler. Uygun hallerde programcılık da bu şekildedir. Bütün programı aklınızda tutar, onu dilediğiniz şekilde işlersiniz.

Bu özellikle bir projenin başlangıç aşamasında önemlidir çünkü öncelikle en önemli olan şey yaptığınızı değiştirebilmektir. Problemi farklı bir yolla çözmenin yanı sıra çözdüğünüz problemi de değiştirmek.

Yazmakta olduğunuz kod, keşfetmekte olduğunuz problemi anlayışınızı yansıtır. Dolayısıyla ancak bu kod zihninizde bir yer edindiğinde gerçekten problemi anlamışsınız demektir.

Bir programın zihninizde yer etmesi kolay değildir. Bir projeye birkaç ay boyunca ara verirseniz geri döndüğünüzde onu tekrar anlamanız günlerinizi alabilir. Program üzerinde etkin olarak çalıştığınız zamanlarda bile her gün çalışmaya başlarken onu zihninize yüklemeniz yarım saatinizi alabilir.

En iyi programcılar dahi her zaman üzerinde çalıştıkları programın tümünü zihinlerinde taşımazlar. Ancak yapabileceğiniz birkaç şey işinizi kolaylaştırabilir:

  1. Dikkatinizin dağılmasını önleyin. Dikkat dağınıklığı, çeşitli birçok iş için kötü olmasının yanı sıra program yazarken özellikle kötüdür çünkü programcılar ancak üstesinden gelebilecekleri seviye ölçüsünde detaylı çalışabilirler.

    Dikkat dağınıklığının yol açtığı risk, ne kadar sürdüğüne değil aklınızı ne kadar karıştırdığına bağlıdır. Bir programcı zihnindeki kodu unutmadan ofisinden ayrılarak bir sandviç alıp gelebilir. Ancak yanlış tipte bir kesinti 30 saniyede zihninizi boşaltabilir.

    İşin tuhaf tarafı ise planlı oyalanmaların planlı olmayanlara göre daha kötü olabilmesidir. Şayet bir saat sonra bir toplantınız varsa meşakatli bir şey üzerinde çalışmaya başlamazsınız bile.

  2. Çalışmalarınızı uzun zamanlara yayın. Program üzerinde çalışmaya her başladığınızda belirli bir çaba harcamak zorunda olduğunuzu dikkate alırsak çalışmanızı birçok kısa oturum yerine birkaç uzun oturuma bölmeniz daha verimli olacaktır. Elbette yorulduğunuz için saçmalamaya başladığınız anlar gelecektir. Bu zaman dilimi kişiden kişiye değişir. 36 saat boyunca durmadan program yazabilen insanlar olduğunu duydum fakat benim altından kalkabildiğim en uzun süre 18 saattir ve işimi 12 saati geçmeyen zaman dilimlerine böldüğüm zaman aldığım verim en üst düzeyde oluyor.

    İdeal olanı ise fiziksel olarak kaldırabileceğiniz limit değildir. Bir projeyi parçalara ayırmanın yararlarının yanı sıra bedelleri de vardır. Bazen dinlendikten sonra bir probleme geri döndüğünüzde bilinçaltınızın sizin için bir cevap bulduğunu görürsünüz.

  3. Kısa ve öz olan programlama dilleri kullanın. Programlama dili ne kadar güçlüyse yazılan programlar da o denli kısa olur. Ve programcılar yazdıkları programı kısmen de olsa yazdıkları dilin çerçevesinde düşünürler. Dilin ifade gücü ne denli yüksekse program da o kadar kısa olur ve zihninize yükleyerek hatırda tutmanız da o kadar kolay olur.

    Alttan üste diye tabir edilen programlama tarzıyla yazdığınız programı alt katmanların üst katmanlar için bir programlama dili vazifesi göreceği birçok parçaya bölebilirsiniz. Bunu doğru yapabilirseniz sadece en üstteki katmanı aklınızda tutmanız yeterli olacaktır.

  4. Programınızı yeniden yazmaktan vazgeçmeyin. Programı yeniden yazmak sıklıkla daha sade bir tasarım üretmenizi sağlar. Böyle bir tasarım ortaya çıkmasa da yeniden yazmanın yararları vardır: bir programı yeniden yazmak için onu bütünüyle anlamalısınız. Yani programı zihninize yüklemenin daha iyi bir yolu yoktur.

  5. Yeniden okunabilir kod yazın. Her programcı okunabilir kod yazmanın iyi olduğunu bilir. Ancak en önemli okuyucunun kendiniz olduğunu unutmayın. Özellikle başlangıçta; programın ön modeli kendinizle yaptığınız bir söyleşiden ibarettir. Başkaları için yazıyorsanız kodun anlaşılmasının güç olmamasına özen gösterebilirsiniz. Programın belli bölümleri geniş tutulduğunda tıpkı başlangıç seviyesinde bir ders kitabı gibi okuması kolay hale gelir. Bununla birlikte eğer zihninize yüklenmesi kolay olacak şekilde kod yazmak istiyorsanız kısa ve öz olmak en iyi tercih olabilir.

  6. Küçük gruplar halinde çalışın. Zihninizde bir programla oynarken ufkunuz kendi yazdığınız kodun sınırlarının sonuna kadardır. Diğer kısımları ise anlamıyor ve daha da önemlisi üzerilerinde serbestçe oynamalar yapamıyor olabilirsiniz. Dolayısıyla programcıların sayısı ne kadar azsa proje de o denli eksiksiz evrilebilir. Eğer sadece bir programcı varsa - başlarken neredeyse hep böyledir - projeyi bütünüyle yeniden tasarlayabilirsiniz.

  7. Birden fazla kişi aynı anda aynı kodu değiştirmesin. Başkalarının yazdığı kodu hiçbir zaman kendinizinkiler kadar iyi anlayamazsınız. Ne kadar dikkatli okursanız okuyun sadece okumuş olursunuz, yazmış olmazsınız. Yani bir kod parçası birden fazla yazar tarafından yazıldıysa hiçbiri kodu tek bir yazarın anlayacağı kadar iyi anlayamaz.

    Ve elbette diğer insanların üzerinde çalıştıkları bir şeyi kolayca yeniden tasarlayamazsınız. İzin istemeniz gerekeceğinden değil böyle şeyleri yapmayı düşünmekten bile kendinizi alıkoyduğunuz için bunu yapmazsınız. Birden fazla yazarı olan kodu değiştirmek yasaları değiştirmeye benzer; yalnız kendi kontrolünüzde olan kodu yeniden tasarlamak ise çok anlamlı bir resmi farklı bir biçimde yorumlamak gibidir.

    Eğer birden fazla kişiyi bir projede çalıştırmak istiyorsanız projeyi bölümlere ayırın ve her bölümü bir kişiye verin.

  8. Kolay işlerle başlayın. Bir programa aşina oldukça onu zihninizde tutmanız da kolaylaşacaktır. Henüz bütünüyle keşfetmediğiniz bölümleri kara kutu gibi görmekle başlayabilirsiniz. Ancak ilk kez bir proje üzerinde çalışmaya başlıyorsanız her şeyi görmeye mecbursunuz. Çözmek için gereğinden büyük bir problem ile işe başlarsanız bu problemi hiçbir zaman bütünüyle çözemeyebilirsiniz. Dolayısıyla eğer büyük, karmaşık bir program yazmak zorundaysanız işe başlamanın en iyi yolu program için bir tanımlama yazmaktan ziyade problemin sadece belli bir kısmını çözen öncül bir model yazmaktır. Plan yapmak yararlı olsa da çoğu kez programı zihninizde tutabilmenin getirdiği yararlar daha ağır basar.

Programcıların sıklıkla bu sekiz noktaya rastlantı sonucu ulaşmaları çarpıcıdır. Bir programcının aklına yeni bir proje fikri gelir fakat resmi olarak onaylanmadığı için bu proje üzerinde boş vakitlerinde çalışmak durumunda kalır ve bu durum dikkatini daha az dağıttığı için daha üretken olmasına yol açar. Yeni bir projeye başlamanın verdiği coşku ile uzun saatler boyunca çalışır. Başlangıçta bir deneyden ibaret olduğu için bir “üretim” dilinden ziyade aslında daha güçlü olan bir “betik” dili kullanır. Programı defalarca yeniden yazar; resmi bir projede bu mazur görülemez olsa da bu bir aşk işidir ve onun mükemmel olmasını ister. Ve kendinden başka kimse görmeyeceği için kendi için yazdığı notlardan başka herhangi bir açıklama yazmaz. Belki bu fikri başkasına henüz açmadığından belki de başkalarının program üzerinde çalışmasına izin vermeyişinin projeyi gelecek vadetmeyen bir proje gibi göstermesinden, çaresiz sadece küçük bir grup ile çalışır. Bir grup olsalar bile aynı anda aynı kodu değiştirmezler çünkü kod bunu mümkün kılamayacak seviyede hızlı gelişmektedir. Ve proje küçük işlerle başlar çünkü fikir başlangıçta basittir; sadece denemek istediği havalı bir hack.

Daha da çarpıcı olan bütün bu sekiz noktayı da yanlış yapan resmi izinli projelerin sayısıdır. Gerçekten de çoğu kurumda yazılımların nasıl yazıldığına bakarsanız sanki bunları özellikle yanlış yapmaya çalışmaktadırlar. Aslında bir anlamda da öyledir. Bireyleri değiştirilebilir parçalar olarak görmek kurumların miladından bu yana onları tanımlayan özelliklerden biri olagelmiştir. Bu yaklaşım daha çok paralelleştirilebilen görevler için işe yarar, örneğin bir savaşta çarpışmak gibi. Tarih boyunca profesyonel askerlerden oluşan ordular, yiğit, bireysel savaşçılardan oluşan ordular üzerinde üstünlük sağlamıştır. Ancak bir fikir sahibi olmak pek de paralelleştirilebilir değildir. Ve programlar da aslında fikirlerin bir yansımasıdır.

Kurumların bireysel dahilere bel bağlamaktan hoşlanmadığı doğru olduğu gibi bahsedileni ifade etmenin farklı bir yoludur. Bu tavır kurum olma tanımının bir parçasıdır. En azından şimdiki kurum kavramımız için.

Belki de bireylerin çabalarını, onların değiştirilebilir olmalarını gerektirmeden, birleştiren yeni bir kurum çeşidi tanımlayabiliriz. Tartışmaya açık olsa da pazar bu tip bir yapıdır. Yine de pazarı bozulmuş bir durumun sonucu olarak tanımlamak daha doğru olacaktır zira bir kurum oluşturmanın mümkün olmadığı noktada önümüze çıkan şey odur.

Belki de yapılabilecek en iyi şey bir çeşit cinlik yaparak kurumun program yazan parçalarının diğerlerine göre farklı çalışmalarını sağlamaktır. Belki büyük şirketler için en iyi çözüm fikir geliştirmeye çalışmak yerine fikir satın almaktır. Çözüm ne olacaksa olsun, ilk adım bir sorun olduğunu kabul etmektir. “Yazılım şirketi” ifadesinde bile bir çelişki vardır. İki kelime farklı yönleri göstermektedir. Büyük bir kurumun içindeki her iyi programcı kurumla itilaf halinde olacaktır zira kurumlar programcıların arzuladıkları şeyleri engelleyecek şekilde tasarlanmıştır.

Her şeye rağmen iyi programcılar iyi bir iş çıkarmayı başarıyorlar. Ancak bu, çoğu kez kendilerini işe alan kuruma karşı pratik olarak isyankar sayılabilecek bir tavır takınmalarını gerektirir. Programcıların yaptıkları işin gerektirdiği gibi davranmaya çalıştıklarını daha fazla insanın anlaması belki işe yarayabilir. Uzun süreler boyunca hiçbir zorunluluğu kafaya takmadan çalışmaları, başlangıçta herhangi bir tanımlama yazmadan hemen programlamaya girişmeleri ve zaten çalışmakta olan bir kodu yeniden yazmaları sorumsuzluklarından değildir. Yalnız çalışmayı tercih etmeleri ve geçerken selam veren insanlara hayıflanmaları arkadaş canlısı olmadıklarından değildir. Bu gelişigüzel görünen rahatsız edici alışkanlıklar bütününü n tek bir açıklaması vardır: programı zihinde tutma gayreti.

Bunu anlamak büyük kurumlara yardım eder mi bilinmez ama rakiplerine yardım edeceği kesin. Büyük şirketlerin en zayıf noktası bireysel programcılara muhteşem işler çıkarma şansını tanımamalarıdır. İşe yeni başlıyorsanız onları eleştireceğiniz nokta bu olmalıdır. Bir büyük beyin tarafından çözülmesi gereken sorunlar üzerine yoğunlaşın.

Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, and Stephen Wolfram’a bu yazının taslağını okudukları için teşekkür ederim.

Çevirmenin Notu

Bu metin, Paul Graham tarafından yazılan “Holding a Program In One’s Head” başlıklı yazının Türkçe çevirisidir ve 18-03-2013 tarihinde http://www.paulgraham.com/head.html adresinden alınmıştır. Çeviri hakkındaki görüşleriniz ve eleştirilerinizin, bir programı aklında tutmak şöyle dursun, dostlarının yüzlerini bile unutmaya başlayan çevirmenin başının üstünde yeri vardır.