Bireysel Geliştiricinin Takım Gibi İnşa Etme Yöntemi: Planı Dondurma, Kesişen Noktaları Dondurma

LaraFoundry’yi tek başıma inşa ediyorum. Bir kişi, bir dal, her seferinde bir görev. Gerçek bir CRM’den (Kohana.io) çıkarttığım, yeniden kullanılabilir bir SaaS motoru.

Tek başıma çalışırken, çoğu ekiplerin karşılaştığı o zor soruya hiç rastlamadım: İki kişi aynı sistemin iki parçasını aynı anda nasıl inşa ederken birbirine çarpmadan çalışabilir?

Yine de o soruyu kendime sordum, düşünce deneyi olarak. Ve bu cevap, kod tabanıma olan bakış açımı değiştirdi.

Düşme noktasını neredeyse yakaladım

Büyük bir projeyi bir takıma teslim etmeyi hayal ettiğinizde, içgüdü hemen belli oluyor. Şunu düşünüyorsunuz: Öncelikle büyük bir doküman hazırlamam lazım. Her yol, her dosya adı, her yöntem, aldığı veriler, döndürdüğü sonuçlar, her test ve doğrulama, her güvenlik kuralı. İki kişinin asla çakışmaması için devasa bir harita çıkarmak gerekir.

Bu, olgun bir yaklaşım gibi görünse de aslında değil. Endüstride bunun adı “Big Design Up Front” ve ekipler bunun üzerinden uzaklaşmayı tercih ediyor.

Başarısız olmasının iki nedeni var:

Harita, yazmaya başladığınızdan daha hızlı çürüyor. Modül E’nin her yöntemini belirleyip yazmayı bitirdiğinizde, modül A’yı inşa etmek sizlere o yöntemlerden üçünün yanlış, ikisinin ise eksik olduğunu gösteriyor. Yazdığınız belgeyi çöpe atıyorsunuz.

Detay, güvenlik demek değildir. Riskli bir proje, plan daha fazla kelimeden oluşmuyorsa daha güvenli olmaz. Güvenliği, pahalı varsayımları erken test ettiğinizde elde edersiniz. Bir yöntem imzası yazmak ucuzdur ve hiçbir şey kanıtlamaz. Asıl önemli olan, oldukça geniş bir kesidin içinde çalışacak olan, kira, faturalandırma ve kimlik doğrulama süreçlerini içeren bir yapı kurmaktır; bu pahalıdır ama her şeyi kanıtlar.

Yani, kocaman bir önceden tasarlanmış diyagram, ulaşamadığınız ideal değil. Atlamak için doğru olduğunuz şeydir.

İki insanın paralel çalışmasını destekleyen şey

Ekipler devasa haritayı yazmazlar. Bunun yerine üç şey yaparlar.

Sistemi aşamalara göre değil, kesitlere göre bölerler. Benim aşamalarım (A, sonra E) yalnızca bir kişinin zamanı kesmesidir. Bir ekip, modül bazında belirgin sınırlar ile keser. Kimlik Doğrulama, Kiralama, Faturalandırma, Navigasyon. Her biri birine ait, her biri için küçük bir kamu sözleşmesi var ve içlerinde toplam özgürlük. Sınırlarınız ne kadar temizse, o kadar çok paralelleştirebiliriz.

Sözleşmeleri, uygulamaların kendilerini dondururlar. Bu anahtar noktadır. Takım B’nin takım A’nın beklemesini durdurması için, aralarındaki iletişimi sabitlersiniz ve başka hiçbir şeyi değil. Bir sınıfın her yöntemine değil, sadece A ve B’nin konuştuğu o tek sözleşmeye. Bir arayüz ve bir DTO. Takım B arayüze göre yazar, takım A bunu uygular. B beklemiyor, B arayüzü taklit ediyor ve devam ediyor.

Bağımlılıkları bir metin yığını yerine bir grafik olarak takip ederler. Görev E, C sözleşmesine bağımlıdır, ki bu da A’nın dondurması gereken bir şeydir. C dondurulduktan sonra (donmuş, uygulanmamış), E bir taklit ile başlayabilir. Çoğu zaman, “bağımlılıklar” olarak adlandırdığınız şeylerin %80’inin sadece bir dondurulmuş sözleşmeye ihtiyaç duyduğunu keşfedersiniz, tamamlanmış bir uygulamaya değil ve neredeyse her şeyi paralelleştirebilirsiniz.

“Dondurmak”, taşlaşmak demek değildir

Bir sözleşmeyi dondurmak demek: Bu noktadan itibaren diğer insanlar bu şekil üzerine inşa eder ve kimse bunu sessizce ve tek başına değiştiremez.

Değiştirmek yasak değildir. Maliyet arttı. Dondurmadan önce, istediğiniz gibi değiştirebilirsiniz, bu sizin taslağınızdır, kimse buna bel bağlamaz, özgürsünüz. Dondurduktan sonra, bunu yine değiştirebilirsiniz, ama bu artık sadece sizin özel kararınız değildir. Başka birinin çalışmasını bozmuş olursunuz. Bu nedenle, bir protokol vardır: duyurun, kimlerin buna bağımlı olduğunu kabullenin, sürümlü bir değişiklik olarak gönderin, herkes geçiş yapsın.

Donmanın amacı da tam olarak budur. Değişimin editördeki bir düzenleme olmaktan ziyade, bir olayla ve bir protokolle gerçekleştiği andır. Maliyetteki o artış, diğer herkese, üzerinize inşa etme izni verir.

Ve şekli dondurursunuz, içini değil:

interface PaymentGatewayManager
{
    // Donduruldu: isim, girdiler, dönüş tipi.
    public function charge(Money $amount, Customer $customer): ChargeResult;
}

Donduruldu: yöntem charge olarak adlandırılır, Money ve Customer alır, bir ChargeResult döner. Dondurulmamış: içeride nasıl çalıştığı, Stripe veya Paddle gibi, kaç tane özel yöntemi olduğu. Takım A iç kısmı on kez yeniden yazabilir ve takım B bunu hiç fark etmez, çünkü sözleşme hareket etmedi. Dar sınırı donduruyorsunuz ve içerde tam özgürlük bırakıyorsunuz.

Kendi kodumda büyük bir dönemeç

İşte beni etkileyen şey. LaraFoundry’de takımın hayatta kalmasını sağlayacak kısımları aradım. Ve bunlar zaten oradaydı.

Faturalandırma eklentisi, çekirdek ile EntitlementResolver adı verilen bir sözleşme üzerinden konuşuyor. Navigasyon uygulamaya MenuProviderInterface aracılığıyla takılıyor. Yönetim paneli, widget’ları DashboardWidgetProvider aracılığıyla kabul ediyor. Olaylar, sabit bir yük taşır.

Ben bunlara “kesitler” diyordum. Faturalandırma eklentisini, çekirdek sözleşmelere tamamen dayanarak inşa ettim ve bu süre zarfında çekirdek değişmedi (etiket sabit kaldı). Bu, eylemde bir dondurmadır. Eklenti bir şeklin üzerine yaslandı, şekil sağlam kaldı ve eklenti kendi hattında gönderildi.

Dolayısıyla, ekiplerin eş zamanlı çalışması için kullanılan mekanizmanın içine rastladım. Tek başıma ve sıralı olarak çalışırken onları kullanmam gerekmiyordu.

İkinci bir kişi geldiğinde neyi değiştirirdim

Büyük haritayı yazmak değil. Şunları yapardım:

Sözleşmeleri daha erken bir dondurulmuş katmana alın. Şu anda, kesitler, ilk kez ihtiyaç duyduğum aşamalarla birlikte ortaya çıkıyor. Bir ekipte bunu çevirirsiniz: Önceden tüm çapraz modül arayüzlerini ve olay yüklerini dondurup, ardından aşamaları kişilere dağıtacak bir oturum.

Kararları kayıtlar olarak yazın, kendi hafızam olarak değil. Solo çalışırken kararlarım kafamda ve notlarımda yaşıyor. Bir ekip, aynı kararları küçük sürümlü kayıtlar olarak depoda ihtiyaç duyar, böylece kimse bana sormadan neden kiralamanın başarısız kapandığını görebilir.

Her bağımlılığı “bir sözleşmeye engel” veya “bir uygulamaya engel” olarak işaretleyin. İlk tür, dondurmadan itibaren engeli kaldırır. İkincisi gerçekten bekler. Genellikle çoğu ilk türde bulunur.

Planlama derinliği hakkında nasıl düşünülmeli

Planlama derinliği homojen değildir.

Modül sınırları ve aralarındaki sözleşmeler: detaylı ve erken. Değiştirmek pahalıdır, diğer insanları engeller.

Modül içleri: bir taslak, detaylar geliştikçe. Değiştirmek ucuzdur, kimseyi engellemez.

Testler: yazılabilir spesifikasyonlar olarak değil, anlatım olarak değil. Bir Pest testi, neyin girdiği ve çıktığına dair resmi bir kayıttır. Bu yüzden ekipler, “hangi testler ve ne döndürdüklerini” bir planda yazmazlar. Testleri yazarlar. Benim çekirdeğim tam olarak bu nedenle bir Pest kiti üzerinde duruyor, testler sözleşme değil, testler hakkındaki paragraflardır.

Bir resim olarak: Oda arasındaki kapıları detaylı bir şekilde planlarsınız; yerlerini, ne kadar geniş olduklarını anlatırsınız, çünkü aksi takdirde duvarlar birleşmeyecek. Oda içindeki mobilyaları planlamazsınız. Kim hareket ederse o belirler.

O halde nerede yanlış yaptım

Çoğunlukla hiç yanlış bir şey yapmadım. Çıkar, artır, kesitler. Bu, karmaşık bir proje için doğru şekildir.

Büyük önceden oluşturulmuş şemalar, bir anti-düğüm olup, ulaşmadığınız bir ideal değildir. Paralel çalışmaların sırrı, “her şeyi yazmak” değil, dar sözleşmeleri sınırda dondurmak ve uygulamalar diverge olmadan hareket etmek ve taklitler üzerinde çalışmaktır. Kesitler, bu mekanizma boyunca her zaman mevcut oldu. Ekipler için tek eklemem gereken şey, onları daha erken dondurmak ve hangi bağımlılıkların gerçek olduğunu, hangi bağımlılıkların bir sözleşme dondurulduğunda ortadan kalktığını kaydetmektir.

Tek başınıza çalışıyor ve gerçek bir projede doğru yaptığınızı merak ediyorsanız: kendi ayrıştırma noktalarınıza bakın. Modülleri ayrı tutmak için oluşturduğunuz arayüzler. İşte bu, dondurma noktalarınızdır. Ekiplerin çalışmasından daha yakınsınız, büyük belgelendirme içgüdünüzden daha fazladır.

Takip Edin