Çirkin Kodunuzu Yayınlayın – DEV Community

Laravel ile projeler geliştirirken, birçok geliştirici başlangıçta yazılan kodun karmaşasını görmek istemez. Joel Spolsky’nin Netscape konusundaki makalesini okuduğumda, standart tavsiyeleri biliyordum: çalışan yazılımı atma, kademeli olarak yeniden yapılandır, eski kodu boğ. Ancak laravel new vlinqr komutunu terminalime yazmaya karar verdim.

Nasıl Başladı

Vlinqr, çok kiracılı bir SaaS platformu olarak, çevrimiçi mağazalar için bir kavram projesi olarak başladı. Tenancy izolasyonu, abonelik faturalama ve AI destekli arama gibi becerilerimi geliştirmek için serbest zamanımda üzerinde çalıştığım bir projeydi. Herhangi bir yol haritası olmadan tamamen bir oyun alanı gibi düşündüm.

Ancak bu tür oyun alanları zamanla büyür. Projenin tamamlanma hissi oluştu ve özellikler arasında bağlantılar kuruldu. Ürünün anlam kazandığını düşündüm. Bu noktada projeyi gerçekten başlatmaya karar verdim.

İşte o zaman, kod tabanına baktığımda rahatsızlık hissettim.

Action desenini kullanıyordum. Kod, nesnel ölçütlere göre kötü değildi. Ancak, bir plan olmadan geçen aylar, her şeyi üst üste bindirdi. İş mantığı eylemler arasında kaynayarak sıyrıldı. İzole olması gereken unsurlar birbirine girdi. Bir özellik eklemek için, ilgisi olmayan üç farklı yere dokunmak zorundaydım.

Bir yol haritası yazmaya oturdum. Gelecek lansman öncesinde eklemek istediğim her özellik, bir hastanın chart’ı olmadan ameliyat etmek gibiydi. Kod bozuk olduğu için değil — çalışıyordu. Ancak, yapının genişlemeyi zorlaştırdığı çok açıktı.

Standart Tavsiye (ve Neden İgnoredim)

Ne yapmanız gerektiğini biliyordum. Kademeli olarak yeniden yapılandır. Eski kodu boğ. Çalışan yazılımı atma.

Ama bu konudaki her makale, takımlar perspektifinden yazılmış. Mühendisler, bütçeler ve paydaşlar olan şirketlere hitap eden tavsiyeler, iki sistemi paralel olarak sürdürmek için kaynakların olduğunu varsayıyor.

Ben tek bir geliştiriciyim. Bu projeyi müşteri projelerim arasında yürütüyorum. Her şeyin öznel olduğu bir hesaplama, sadece siz olduğunuzda değişiyor.

Sonuç olarak, ne yapmam gerektiğini düşündüm. Bir AI’ya danıştım. Modüler monolit mimarisi ile gitmek istediğimi söyledim. Yanıtı doğrudan ve nazikçe, projeniz çalışıyorsa, öncelikle lansmanı hedefleyin. Fikrinizi kanıtlayın, sonra yeniden yapılandırın, şeklindeydi.

Karşı çıktım. Terminalimi açtım. laravel new vlinqr.

Harika bir duygu.

Dört Mükemmel Gün

Yeni proje. Temiz bir başlangıç. PHPStan’ı maksimum seviyede yapılandırdım. Otomatik yeniden yapılandırma için Rector, kod stilini sağlamak için Pint kullandım. İlk taahhütten itibaren %100 test kapsamı zorunluydu. Yeniden yazıyorsam, bunu doğru yapmalıydım.

Her dosya doğru yerdeydi. Her sınıfın tek bir sorumluluğu vardı. Testler ilk çalıştırmada geçti. Dopamin gerçek.

Dört gün boyunca kodumla aşk yaşadım.

Sonra matematiği yaptım. Mevcut hızımla, yeniden yazım dört ila altı ay sürecekti. Mimari mükemmel olacaktı. Test kapsamı kusursuz olacaktı. Kod sanat eseri gibi olacaktı ama kimse kullanmayacaktı.

Çünkü kendimi iyi tanıyorum. Bir hafta — belki iki hafta — sonra yorulurdum. Temiz bir kod tabanı heyecanı üçüncü ayda hayatta kalmazdı. Bu proje diğer mükemmel fikirlerim gibi, asla hayata geçmeyen bir projeye dönüşecekti. Mükemmel şekilde mimarisi yapılmış, ama asla piyasaya sürülmemişti.

Kimsenin Yazmadığı Kısım

Her yeniden yazım makalesi, riskleri iş terimleri açısından çerçeveliyor; pazar payı, müşteri aksaklığı, gelir kaybı. Bunlar gerçek riskler, ancak bunları modelleyebilirsiniz, tartışabiliyorsunuz ve tahminlerde bulunabiliyorsunuz.

Tek geliştirici olarak bir yan projedeki risk farklı. Motivasyon. Ve bunu modellemeniz imkânsız.

Daha önce projeleri terk ettim. Kötü fikirler yüzünden ya da kod bozulduğu için değil. Bulunduğum yer ile olmak istediğim yer arasındaki mesafe sonsuz gibi görünüyordu ve bunu aşacak enerji kalmadı. Yeniden yazım bu mesafeyi iki katına çıkarıyor. İleriye değil, zaten geldiğiniz yeri daha temiz inşa ediyorsunuz.

Yeniden yazım, yeni kodun daha kötü olması nedeniyle başarısız olmaz. Başarısız olur çünkü asla bitiremezsiniz.

Geri Dönüş

Mağlubiyeti kabul ettim. Aynı AI ajanına geri döndüm ve gerçek bir plan istedim. Yanıt son derece basit:

1. Her yeni özellik modüler tasarıma dahil edilecek.
2. Küçük, izole özellikleri önce yeniden yapılandır.
3. Eksik testleri yaz.

Hepsi bu. Büyüleyici bir göç stratejisi yok. Hiçbir mimar astronautik yok. Sadece üç kural.

Onları izlemeye başladım. Ve yavaş yavaş, şeyler değişti.

Mimari kılavuzları oluşturdum. Hangi özelliklerin nerede olacağını tanımladım. Bu kılavuzlarla birlikte AI ajanları kurdum, böylece bağlantıları işaretleyebiliyor, hangi özelliklerin taşınması gerektiğini belirleyebiliyor ve yeniden yazılması gereken unsurlar hakkında önerilerde bulunabiliyordu.

PHPStan kullanımım düzey 1’de değil, maksimum değerde başlamadı. Her hafta seviyeyi artırdım. Seviye 2. Seviye 3. Her artış, daha önce görmediğim şeyleri yakaladı ama kod tabanı buna hazırdı. Rector, kalıpları otomatik olarak temizledi. Test kapsamı adım adım büyüdü — ilk günden %100 değil, ama her taahhütle daha güçlü bir hale geldi.

Korktuğum bağlantılar çözülmeye başladı. Hepsi aynı anda değil. Tekrar tekrar, bir modülü çıkar. Bir sorgu taşı. Bir sınırı sarmala. Her değişiklik, tek bir oturumda tamamlanacak kadar küçüktü.

Ne Oldu

İlk haftanın sonunda, beklenmedik bir şey oldu. Eski kodu takdir etmeye başladım. Çünkü güzel olduğu için değil — güzellikten uzaktı. Ama çalışıyordu. Unuttuğum uç durumları ele aldı. Gerçek kararlarla doluydu — sıfırdan başladığınızda kaybettiğiniz bilgilerdir bunlar.

Kod tabanı hala çalışmaya ihtiyaç duyuyordu. Şu anda başka çalışmalara da ihtiyaç duyuyor. Ama bu, adım adım kendi standartlarımı benimsemeye devam eden çalışan bir ürün oldu, yeni özellikler ekleyebiliyor, artık korkmadan bunu yapabiliyorum.

Vlinqr, iki ay önce piyasaya sürüldü. Çok kiracılı mimari, abonelik faturalama, AI destekli arama, Arapça ve İngilizce dil desteği mevcut. Gerçek insanların kullandığı bir SaaS ürünümüz var.

Yeniden yazımı sürdürseydim, kimsenin daha önce görmediği bir proje için hala test yazmayı sürdürüyor olurdum.

Gerçekten Neler Öğrendim

Bir tek geliştiricinin en büyük riski, kötü mimari değildir. Asla yayınlamamak.

Tanınmış her geliştiricinin ilk düşüncesi, karmaşık kodları gördüklerinde “sıfırdan başla” olur. Bu içgüdü, bunu iyi yapma yetisi olduğunda daha da güçlenir. PHPStan, Rector, Pest, modern Laravel — temiz bir yeniden yazım yapmanın oldukça ulaşılabilir olduğunu hissediyorsunuz. Ve teknik olarak ulaşılabilir. Ancak “teknik olarak ulaşılabilir” ile “gerçekten tamamlanabilir” iki farklı sorudur.

Özellikle mevcut kodu yeniden yapılandırın. Başlatın. Gerçek dünyada test edin. Mimariyi gerçek kullanıcıların gerçek işler yapması altında evrim geçirmesine izin verin. Kod tabanı mükemmel olmayacak. Olması gerekmiyor. Var olması gerekiyor.

Daha fazlasını buradan paylaşıyorum: Naram Alkoht