Yan projelerde kod kalitesine ne kadar önem verilmeli?
Günlük tam zamanlı işlerinin dışında yan projeler yazılımcıların boş zamanlarında belki de en çok keyif aldıkları aktivitelerden bir tanesi. Özellikle günümüzde değişimin çok hızlı olduğu yazılım sektöründe, her gün yeni bir teknolojinin ortaya çıkması öğrenmeye aç ve meraklı yazılımcıları cezbediyor. Bu yeni teknolojinin tadına bakmak ve onu öğrenmek istiyoruz.
Yan projeleri bizim yeni teknolojiler üzerinde deneylerimizi yapabileceğimiz laboratuvar ortamları gibi düşünüyorum. En iyi öğrenme metodunun yaparak öğrenme olduğunu bildiğimiz için hemen bir yan proje başlatıp bu yeni teknoloji ile ilgili ilk temelleri atmaya başlıyoruz.
Bazen yan projeleri farklı amaçlar doğrultusunda da başlatabiliyoruz. Özellikle üretmenin, yararlı olmanın ve birşeylere katkıda bulunabilmenin önemli olduğu günümüz dünyasında yan projeleri insanların karşılaştıkları problemleri çözmek için de kodlayabiliyoruz. Bazen boş zamanlarımızda geliştirdiğimiz açık kaynaklı proje insanların derdine deva olabiliyorken, bazen de geliştirdiğimiz yan proje hiç hayal bile etmediğimiz bir noktaya gelebiliyor.
Kendimizin bizzat karşılaştığı veya başkalarının karşılaştığı probleme çözüm olarak başlayan proje karlı bir girişim haline dönüşebiliyor. Hatta daha da ileri gidip bizim günlük yaşantımızı sürdürebilmemizi sağlayacak tek başına bir gelir kaynağı olabiliyor. Bu calıştığımız yerden ayrılıp yan projemizi tam zamanlı bir proje haline dönüştürebiliyoruz. Boş zamanlarda keyif almak için başlayan proje artık başkaları için bir ekmek kapısı haline geliyor.
Durum böyle olunca yan projeleri geliştirirken bir takım soruların aklımızı meşgul etmesi de pek muhtemel. Bunlardan bir tanesi de geliştiriğimiz yan projelerde kod kaltesine ne kadar önem vermemiz gerektiği.
Bu soruya cevap vermeden önce başka bir soruyu cevaplamamız gerekiyor. Biz bu projeyi hangi amaçla geliştiriyoruz?
Amacımızı iyi belirlersek kod kalitesine ne kadar önem vermemiz gerektiği sorusunu da cevaplamış oluyoruz aslında. Bir kaç başlık altında yan proje geliştirmenin arkasındaki yaygın motivasyonlara göre bu soruya cevap vermeye çalışalım.
Yeni teknolojiler öğrenmek için yan proje geliştirirken kod kalitesi
Yeni teknolojiler öğrenirken kod kalitesinin çok önemli olmadığını hepimiz az çok biliyoruz. Bu yeni teknoloji yeni bir programlama dili, yeni bir framework veya bir serverless mimarisi olabilir. Akılınıza ne gelirse. Bu tip durumlarda zaten daha yeni olan teknoloji ile ilk sıcak temasımızı kurarız.
Bir öğrenme sürecinde olduğumuzdan zorlanırız. Hatalar yaparız. Dokümantasyonu okur bunu proje de deneyerek pratikte görmeye çalışırız. Hata yaparak deneme yanılma yöntemi ile ilerleriz.
Böyle bir durumda kod kalitesinin pek bir önemi kalmıyor. Hele öğrenmeye çalıştığınız yeni bir programlama dili ise bu kod kalitesi kavramı ortadan kalkıyor. Şöyle düşünelim:
Nesne yönelimli programlama altyapımız olduğunu varsayalım ve öğrenmeye çalıştığımız yeni programlama dili fonksiyonel tabanlı bir dilse nesne yönelimli programlamanın pratiklerini burada denemeye çalışmak, kod kalitesini bu altyapıya göre zorlamak yanlış bir yaklaşım olurdu. Bu nedenle bu tip durumlarda amacımız kod kalitesini birinci plana koymak olmamalı.
Diğer bir örnek senaryo ise şu olabilir: Bazen kod kalitemizi geliştirmek için bir yan proje yapmak isteyebiliriz. Bu durumlarda muhtemelen bildiğimiz bir programlama dili ile kendimize bir proje seçip kodlamaya başlarız. Haliyle nihayi amacımız kod kalitesini arttırmak olduğu için yeni pratiklerimiz bu amaç doğrultusunda ilerler. Çeşitli mecralardan edindiğimiz kod kalitesi ile ilgili teorik bilgileri pratiğe dökerek ilerleriz.
Kısacası şunu söyleyebiliriz. Öğrenmek istediğiniz veya geliştirmek istediğiniz kod kalitesi olmadığı sürece yeni birşey öğrenirken kod kalitesi ikinci plandadır. Söylediğimiz gibi “yeni birşey öğrenmek” ilk amacımız.
Yeni bir girişim için başlatılan yan projede kod kalitesi
Bazen günlük rutin bir işte çalışırken girişimci ruhumuz bizi yeni birşeyler ortaya koymak için motive eder. Aklımızda yeni bir fikrin ilk tohumları atılmıştır ve bir proje başlatarak tohumların filizlenmesi evresine geçeriz. Buradaki nihayi amacımız yeni bir girişim başlatmaktır. Bunu aklımızda tutalım.
Adı üstünde bu yeni bir girişim olacağından bir takım riskler de beraberinde gelecektir. Muhtemelen girişimin ilk aşamalarındaki giderleri günlük rutin işimizden gelen maaşımızla finanse ederiz. En önemlisi de mesaiden arta kalan zamanımızı yan projemize ayırdığımızdan sevdiklerimizle vakit geçirememe fedakarlığında bulunuruz.
Bir yandan da aklımızdaki bir takım sorular bizi sürekli rahatsız eder. Acaba yaptığım bu girişim gerçekten insanların problemini çözecek mi? Başarılı olabilecek miyim? Ya işler kötü giderse? Ya insanlar yaptığım şeyi sevmez ve kullanmazlarsa? Tünelin sonunda başarısızlık da var. Yaptığım emeğe ve yatırıma değecek mi?
Bunun gibi sorular bizi sürekli rahatsız eder ve motivasyonumuzu aşağıya çekmeye çalışır. Belirsizlikle yaşamaya çalışırız. Daha doğrusu bunu öğrenmeye çalışırız.
Durum böyle olunca önceliklerimiz değişir. Yeni bir girişim başlatırken en büyük risk, çözmeye çalıştığımız bir problemin aslında gerçek bir problem olmadığı ve dolayısıyla girişimimize insanların ihtiyacı olmadığı gerçeği ile yüzleşmektir. Öyle ki istatistiklere baktığımızda başarısız olan girimşimlerin %49'unun bu sebepten dolayı başarıya ulaşamadıklarını görürüz.
Aslında yapmaya çalıştığımız yan proje nihayi bir projeden çok hipotezdir. Bi hipotezimiz vardır ve bunun doğruluğunu kanıtlamak için ortaya bir prototip veya diğer bir adıyla MVP (Minimum viable product) çıkarmaya çalışırız.
MVP demek kodun çok yalın olduğu, gereksiz her türlü ek özellikten arındırılmış ve insanların yaşadığı problemi en yalın şekilde çözmeye çalışan basit bir proje demektir. Bunun için hız burada en büyük avantajımız olacaktır. Çok yüksek bir ihtimalle ilk MVP’yi markete sürünce umduğumuz gibi toz pembe bir senaryo ile karşılaşmayacağız.
O yüzden hızlı olmak en önemli yeteneğimiz olacak. Kod kalitesi gibi amaçlar ikinci planda kalacaktır. Unutmayalım bir hipotezimiz var ve bunu somut hala getirmek için bir prototip geliştiriyoruz. İşe yarayıp yaramayacağını bile bilmiyoruz. Bu durumda kod kalitesinin ne önemi var? Bu fazda kod kalitesine çok önem vermek bizi yavaşlatabileceğinden bunu önceliklerimiz arasından çıkartmalıyız.
Belki aklınıza şu soru gelebilir? MVP’yi markete sürdükten sonra ya insanlar tarafından çok sevilir ve kullanıcı sayısı hızla artarsa? Bu durumda kötü bir kaliteye sahip kod ile ne kadar uzağa gidebiliriz?
İnanın bu en son endişeniz olmalı. Çoğu durumda girişimlerin ilk orjinal fikirleri değişir sabit değildir. MVP piyasaya sürüldükten sonra en önemli şey müşterilerden gelecek geri bildirimlerdir. Bu geribildirimler sayesinde siz hipotezinizin ne kadar geçerli olduğunu doğrularsınız. Hatta bir çok durumda olduğu gibi orijinal fikriniz tamamen bambaşka bir fikre evrilebilir. Müşterileriniz ürününüzü sizin düşündüğünüzden daha farklı bir amaç için kullanabilirler.
Böyle durumlarda ürününüzü hızlıca bu doğrultuda değiştirebilmelisiniz. Yüksek ihtimalle ilk MVP’yi yani kalitesine önem vermediğiniz kodları çöpe atacaksınız.
Lafın kısası MVP için hızlı olmak nihayı amaçtır. Kod kalitesi gibi sizi yavaşlatacak kavramlara izin verirseniz MVP’yi pazara zamanında sunamayıp başarısız olma ihtimalini artırırsınız.
Açık kaynak kodlu projelerde kod kalitesi
Bazen yazılım camiasına katkıda bulunmak için yan proje yapmaya karar verebiliriz. Bu bir framework veya bir eklenti olabilir. Hiç farketmez. Açık kaynaklı projelerde en önemli olan konulardan bir tanesi proje yönetiminin ve bakımının kolaylıkla yapılabiliyor olmasıdır. Projeye diğer yazılımcıların da katkıda bulunmasını isteriz.
Bu da projenin kodlarının github üzerinde birçok yazılımcı tarafından açılıp okunacağı anlamına gelir. Kod anlaşılabilir olmalıdır. Mimarı basit olmalıdır. Bir bug ortaya çıkınca bunu fixlemek çok zaman almamalıdır. Yazılım topluluğundan gelen geri bildirimlere göre projenin yönünü değiştirmek kolay olmalıdır. Eğer esnek ve değitirilebilmesi kolay olan bir koda sahipsek bu tür değişimlere hızlı cevap verebiliriz.
Bu bahsettiklerimizin hepsi iyi bir kod kalitesine sahip proje ile mümkün olabilir. Peki kod kalitesine ne zaman önem vermeye başlamalıyız? Bunun kişiye bağlı olacağını düşünüyorum. Eğer geliştirdiğiniz projenin kullanılıp kullanılmayacağı konusunda soru işaretleriniz varsa başlarda kod kalitesine önem vermeden projenizi çıkarabilirsiniz. Diğer yazılımcılardan gelen geri bildirimlere ve tepkilere göre eğer işler yolunda gidiyorsa küçük refactoringlerle kod kalitesini arttırıp projenizin yönetilebilirliğini ve esnekliğini arttırabilirsiniz.
Bir sonraki yazıya dek sağlıcakla kalın.
Originally published at https://huseyinpolatyuruk.com on April 10, 2020.
