Temel kuralım, üçüncü kez bir şey yapmam gerektiğinde, otomatikleştirmek için küçük bir senaryo yazmanın ya da yaklaşımımı yeniden düşünmenin zamanı geldi.
Bu noktada tam gelişmiş bir "araç" yapmıyorum, daha önce manuel olarak yaptığımı otomatikleştiren küçük bir senaryo (genellikle bash veya python; perl de çalışacaktı, hatta PHP). Temel olarak, DRY ilkesinin (ya da özünde aynı şeyin olduğu Tek Gerçeğin Kaynak ilkesinin) bir uygulamasıdır - eğer iki kaynak dosyasını aynı anda değiştirmek zorunda kalırsanız, paylaştıkları ortak bir gerçek olmalı. hakikat çarpanlara ayrılmalı ve tek bir merkezi yerde saklanmalıdır. Bunu yeniden yönlendirme yoluyla dahili olarak çözebiliyorsanız harikadır, ancak bazen bu mümkün değildir ve özel komut dosyalarının girdiği yer burasıdır.
Daha sonra, komut dosyası tamamen gelişmiş bir araca dönüşebilir veya gelmeyebilir, ancak genellikle içinde kodlanmış birçok şey olan çok özel bir komut dosyasıyla başlarım.
Bir tutkuyla homurdanmaktan nefret ediyorum ama aynı zamanda bunun kötü veya yanlış tasarımın bir işareti olduğuna inanıyorum. Tembel olmak, bir programcıda önemli bir kalitedir ve tekrarlayan işleri önlemek için büyük uzunluklardan geçtiğiniz türden daha iyidir.
Elbette, bazen bakiye negatiftir - kodunuzu yeniden gözden geçirmek veya size bir saatlik tekrarlayan çalışmadan tasarruf etmek için bir senaryo yazmak için üç saat harcarsınız; ancak, genellikle, denge pozitif, eğer doğrudan görünür olmayan maliyetleri düşünürseniz: insan başarısızlığı (insanlar tekrarlayan işlerde gerçekten kötüdür), daha küçük kod temeli, azaltılmış yedeklilik nedeniyle daha iyi bakım, daha iyi öz dokümantasyon, daha hızlı gelecek geliştirme, daha temiz kod. Yani denge şu anda negatif gözükse bilekod tabanı daha da büyüyecek ve üç veri nesnesi için web formları oluşturmak için yazdığınız araç hala otuz veri nesnesine sahip olduğunuzda çalışmaya devam edecek. Tecrübelerime göre, denge genellikle grunt çalışması lehine tahmin edilir, çünkü muhtemelen tekrarlayan görevlerin tahmin edilmesi daha kolay ve bu nedenle düşük tahmin edilirken, yeniden yapılanma, otomatikleştirme ve soyutlama daha az öngörülebilir ve daha tehlikeli olarak değerlendirilir ve bu nedenle aşırı tahmin edilir. Genelde sonuçta otomatikleştirmenin o kadar zor olmadığı ortaya çıkıyor.
Ve sonra bunu çok geç yapma riski var: üç yeni veri nesnesi sınıfını yeniden biçimlendirmek ve onlar için web formları oluşturan bir komut dosyası yazmak kolaydır ve bir kez bunu yaptıktan sonra, 27 sınıf daha eklemek kolaydır. Ayrıca betiğinizle de çalışın. Ancak, her biri elle yazılmış web formları olan ve aralarında herhangi bir tutarlılık olmadan 30 veri nesnesi sınıfının olduğu bir noktaya ulaştığınızda bu senaryoyu yazmak imkansızdır (aka "organik büyüme"). Bu 30 sınıfı formları ile sürdürmek, tekrarlayan kodlama ve yarı-manuel arama-değiştirme kabusudur, ortak yönleri değiştirmek, olması gerektiği sürece otuz zaman alır, ancak problemi çözmek için bir senaryo yazmak, proje başladığında hiçbir kesinti olmayan bir öğle yemeği molası olacaktı, şu an iki ay süren korkunç bir projedir. eski kod temeli. İronik olarak, 30 sınıfı karışıklığı yazmak, temiz çözümün elde edebileceğinden çok daha uzun sürdü, çünkü her zaman uygun senaryoyu kullanıyor olabilirdiniz. Tecrübelerime göre, tekrarlayan işleri çok geç bir zamanda otomatikleştirmek, uzun süren büyük yazılım projelerinin en büyük sorunlarından biridir. Çünkü her zaman uygun senaryoyu kullanıyor olabilirdin. Tecrübelerime göre, tekrarlayan işleri çok geç bir zamanda otomatikleştirmek, uzun süren büyük yazılım projelerinin en büyük sorunlarından biridir. Çünkü her zaman uygun senaryoyu kullanıyor olabilirdin. Tecrübelerime göre, tekrarlayan işleri çok geç bir zamanda otomatikleştirmek, uzun süren büyük yazılım projelerinin en büyük sorunlarından biridir.
