Silmesi kolay kod yazmak
- Her kod satırı bakım maliyeti getirir. Kod yeniden kullanımı değişiklik yapmayı zorlaştırır.
- API tüketicisi ne kadar fazlaysa, değişiklik sırasında yeniden yazılması gereken kod da o kadar fazla olur.
- Kod bağımlılıklarını yönetmek, büyük ölçekli sistemlerde önemli bir sorundur.
0. aşama: Kod yazmamak
- Kod satırı sayısı tek başına çok fazla bilgi vermez.
- Yazılmamış kod, silmesi en kolay koddur.
1. aşama: Kodu kopyala-yapıştır yapmak
- Yeniden kullanılabilir kod, daha sonra örnekler üzerinden daha kolay yazılabilir.
- Kopyala-yapıştır, bağımlılıklardan kaçınmak ve esneklik kazanmak için bir yöntemdir.
2. aşama: Kodu kopyala-yapıştır yapmamak
- Kod yeterince kopyala-yapıştır edildiyse, onu bir fonksiyon olarak çıkarmanın zamanı gelmiştir.
- Çeşitli yardımcı araçları başka dosyalarda tutmak için
util dizini oluşturmak iyi olabilir.
3. aşama: Daha fazla boilerplate yazmak
- Boilerplate, kopyala-yapıştır koda benzer ama kodu farklı yerlerde değiştirir.
- Boilerplate, bağımlılıkları azaltır ve esneklik sağlar.
4. aşama: Boilerplate yazmamak
- Boilerplate çok fazlaysa, bunu politika, iş akışı ve durum hakkında görüş sahibi olan bir kütüphaneyle sarmalamak gerekir.
requests ile urllib3 arasındaki ilişki buna iyi bir örnektir.
5. aşama: Büyük parçalar halinde kod yazmak
- İş mantığı, bitmek bilmeyen istisna durumları ve hızlı ama kirli hack'lerle karakterize edilir.
- Büyük bir hatayı silmek, birçok küçük hatayı silmekten daha kolaydır.
6. aşama: Kodu parçalara bölmek
- Büyük parça halindeki kodun bakım maliyeti yüksektir.
- Kodun sorumluluklarını ayırmak ve modülleri değişim olasılığını hesaba katarak tasarlamak gerekir.
7. aşama: Sürekli kod yazmaya devam etmek
- Yeni fikirleri deneyebilmek için, mevcut koddan bağımsız yeni kod yazabilmek gerekir.
- Feature flag'ler, daha sonra fikrinizi değiştirebilmenin bir yoludur.
GN⁺ özeti
- Bu yazı, kod yazarken silmesi kolay kod üretmenin yollarını açıklar.
- Kod bağımlılıklarını azaltmak, esnekliği artırmak ve bakım maliyetini düşürmek temel noktadır.
- Benzer işlevlere sahip projeler arasında
requests ve urllib3 bulunur.
- Bu yazı, yazılım geliştiricilere kod yönetimi ve bakımın önemini hatırlatır.
1 yorum
Hacker News görüşleri
"Simple is robust" sözü hoşuma gidiyor. Bu, bir sistem ne kadar az karmaşıksa değiştirmenin o kadar kolay olduğu anlamına geliyor. Gelecek için planlar, ölçeklenebilir kod yerine sezgisel kod üzerine kurulmalı. Örneğin soyutlamayı yalnızca durum gerektirdiğinde yapmak, basit tekrarları teşvik etmek, başlangıçta monolit kullanmak ve yatay ölçekleme yerine dikey ölçeklemeye öncelik vermek. Birden çok 0-1 sistem kurarken bu ortak noktaları fark ettim.
Testler veya gözlemlenebilirlikten hiç bahsedilmemesine şaşırdım. Testlerin bakım maliyeti vardır, ancak kodu kaldırırken sorun çıkma riskini azaltır. Dış çağıranlara hizmet açarken bazı çağrıları kullanımdan kaldırılacak olarak işaretlemek ve hâlâ çağrılıp çağrılmadığını gözlemlemek için güçlü bir yönteme ihtiyaç vardır. Kısa süre önce GraphQL resolver'larını yarı otomatik olarak kaldırdım ve kullanım sıklığı metrikleri sayesinde silinemeyecek resolver'ları belirledim. GraphQL'de deprecated anotasyonları var ama serviste bunu özel olarak ele almamıştık. Gözlemlenebilirlik ekleyerek kullanımdan kaldırılacak fonksiyon çağrıldığında bir bayrak ayarlayabilir ve üretimde yeterince uzun süre çalıştırdıktan sonra dışa açık kodu güvenle silebilirsiniz.
"Silinmek için tasarlama" fikrini savunur oldum. Eskiden her durumu planlayıp her ihtiyacı karşılayan bir eser üretebileceğimi düşünürdüm, ama gelecekteki ihtiyaçları tahmin etmek zordur. Bir gün yaptığım şey bir başkası için işe yaramaz hale gelecek ve onun bunu söküp atması haklı olacaktır. Bu yüzden kaldırması kolay olacak şekilde yapmaya emek vermeliyim. Bu çoğu zaman bağımlılığı azaltmakla sonuçlanır, ama bu her şeyi meta düzeyinde yapılandırılabilir bir framework'e ayırmaya çalışan genç geliştiricilerin yaklaşımıyla aynı değil. Bazen mantıksal olarak anlaması daha kolaysa sıkı bağlılık daha iyidir.
Kodu silmesi kolay olacak şekilde yazmak için, bağımlılıklardan kaçınmak adına tekrar etmeli; yönetmek için tekrar etmemelisiniz. Kod katmanlarını ayırmalı ve uygulanması basit ama kullanımı rahatsız edici parçalar üzerine basit API'ler kurmalısınız. Kodu ayırmalı; yazması zor olan kısımlarla değişme olasılığı yüksek kısımları geri kalan koddan ve birbirlerinden ayırmalısınız. Her seçimi hardcode etmemeli, bazılarını çalışma zamanında değiştirilebilir kılmalısınız. Kişisel deneyimime göre silmesi kolay kod, katmanlı ve modüler olduğu için genişletmesi de kolay oluyor.
Hesaplamalı fizik öğrencilerine her zaman en iyi hesaplamanın, dert etmek zorunda olmadığınız hesaplama olduğunu söylerim.
Ben şahsen kodu iş mantığı ve gerçek uygulama olarak ayırıyorum. İş mantığı doğası gereği tekrar edebilir, ancak çok fazla teknik ayrıntı tekrar etmemeli. İş mantığını doğrudan ele almayıp uygulamadan bağımsız tuttuğunuz sürece, iş mantığı istediğiniz kadar dağınık olabilir. Bir sorun çıktığında ve işler yolunda gitmediğinde, tüm uygulamayı silme seçeneğiniz olur; böylece bunu düzeltmek ve gerçek spesifikasyonu uygulamanın içinden çıkarmaya zorlanmazsınız.
İlk paragraftaki bariz hata şu: kod yeniden kullanımının sorunu, daha sonra fikrinizi değiştirmenizi engellemesiymiş. Bu genelde yanlış bir iddia. Fikrinizi değiştirirseniz ve kod on yere kopyalanıp yapıştırılmışsa, on yeri değiştirmeniz gerekir. Buna karşılık kod bir fonksiyondaysa yalnızca bir kez değiştirirsiniz. On çağrıdan birinin değişmemesi gerekiyorsa, yine de kopyalayıp yapıştırabilirsiniz; ayrıca fonksiyonu daha genel hale de getirebilirsiniz. Nasıl ki karşıdan karşıya geçerken etrafa bakmamak kötü bir fikirse, kopyala-yapıştır da neredeyse her zaman kötü bir fikirdir.
Kötü kodun kaldırılması zor olduğu için uzun süre kaldığına dair çok iyi bir korelasyon var.
Acaba burada söylenmek istenen, yazılımı mümkün olduğunca varsayılan haliyle kullanmak ve derin özelleştirmeler yapmamak mı?