Geliştirici komut dosyalarını yönetmenin doğru yolu nedir?

Geliştiriciler, çalışmalarına yardımcı olmak için komut dosyaları oluşturur. Örneğin, Maven'i belirli parametrelerle çalıştırmak, geliştirme sırasında ortaya çıkan gereksiz arka plan görevlerini öldürmek veya belirli bir sunucuya bağlanmak için. Komut dosyaları çekirdek oluşturma komut dosyaları değildir ve Sürekli Entegrasyon sunucumuzda kullanılmaz.

Onları yönetmenin en iyi yolu nedir? Onları bir dizine koymak (belki /scripts) ve Git'e bakmak için? Bunları bazı dosya sunucularında ayrı olarak korumak için?

Bunları kaynak kodu olarak ele alma argümanı, kaynak olmaları ve değişebilmeleridir. Bunu yapmama argümanı, sadece yardımcı araçlar oldukları ve tüm geliştiricilerin herhangi bir komut dosyasına (örneğin, bazı geliştiricilerin Windows üzerinde çalıştığı Linux'a özgü komut dosyaları) ihtiyaç duymadığıdır.

Geliştirici komut dosyaları sürüm denetimine de girer, çünkü genellikle bu komut dosyaları sürüm denetimindeki öğelere, örneğin dosya yollarına da bağlıdır.

Bu komut dosyaları sürümlendirildiyse, her geliştiricinin kendi komut dizilerini yazmasını önlemek için tüm geliştiriciler için çalışmalıdır, bu da bakım cehennemi haline gelir.

Buna ek olarak, bu komut dosyalarındaki hata düzeltmeleri veya geliştirmeler, sürüm denetimi aracılığıyla otomatik olarak her geliştiriciye dağıtılır.

@ Simon'un cevabına ek olarak.

Yazılım mühendisliğinin tümü programlama, tasarım veya modelleme ile ilgili değildir. Çalışma günü boyunca sürekli olarak yaptığımız sayısız görev var. Daha önce de bahsettiniz - projeyi IDE dışında inşa etmek - ama daha fazlası var.

Deneyimli / proaktif geliştiriciler bu görevleri otomatikleştirme eğilimindedir. Bazıları, bu görevler SDLC'nin bir parçası olduğunda ve elle yapmak için sıkıcı ve hataya eğilimli olduklarında araçlar oluştururlar . Programlar, ne kadar sıkıcı olursa olsun, tekrarlayan işler yapmakta iyidir. Biz - insanlar - o kadar iyi değiliz.

Bu araçların / komut dosyalarının başkalarının olumlu yan etkileri vardır

1. verimlilik
2. Bilgi aktarımı
3. Özerklik (yeni gelenler için)

Yani, evet komut dosyaları SCM'de olmalı ve geliştiricinin araç kutusunda bir araç daha olmalıdır.

Klasöre gelince, /scriptsönemli olmadığını söyleyebilirim. Basit olması için, bunları komut dosyalarında bildirilen tüm yolların projenin klasörüne göreli olması için projenin kök dizininde bırakıyorum . Harici klasörlere veya dosyalara erişmem gerekirse yumuşak bağlantılar oluştururum .

Scriptleri SCM'de kontrol etmeden önce dikkat edilmesi gerekenler.

• Güvenlik için, komut dosyalarının sabit kodlu kimlik bilgilerine sahip olmadığından emin olun - ideal olarak komut dosyalarının iyi parametrelenmiş olması gerekir -

• Örneğin geri alınamayan komutları yürütmek için komut dosyalarının sistemde tuhaf şeyler yapmadığından emin olun (en tipik rm -rf).

• Bunlar projenin kaynağının bir parçası olduğundan, dokümantasyon çok takdir edilmektedir.

• Senaryo yazmak roket bilimi değildir. Komut dosyalarını kısa ve öz yapın. Hepsine hükmedecek biri yerine ... ve karanlıkta onları bağlar , daha fazla, daha küçük ve özlü yapar. Sanki SRP uyguluyorsun.

Biraz daha olumsuz bir görüş sunacağım. Bir yandan, genel, etkili ve kullanışlı geliştirici komut dosyaları elbette diğer geliştiricilerle paylaşılmalıdır ve bunu yapmanın en iyi yolu, onları aynı depodaki kodla oturtmaktır.

Ancak senaryoların işlenmesi için girişe yüksek bir bar koyardım. Komut dosyaları, tıpkı yazılımın kendisi gibi koddur. Bu, diğer kod parçalarına benzer şekilde işlem görmeleri gerektiği anlamına gelir:

• Kod incelemesinden geçme
• Mümkünse test edildi ve otomatikleştirildi
• Kod tabanında değişiklik yaparken göz önünde bulundurulur (özellikle, bir komut dosyası birçok geliştirici tarafından kullanılıyorsa, komut dosyasını bozan bir değişiklik yapmak çok fazla çekişmeye neden olur)
• Bakım (her şeyi içeren - önceliklendirme, zaman, dokümantasyon vb.).

Komut dosyalarına yazılımın kendisinden daha fazla uygulanan birkaç başka husus vardır:

• Birincisi ve en önemlisi, bir kişinin kuruluşunu ve paydaşını, geliştiricilerin hayatını kolaylaştıran senaryoları korumaya yatırım yapmaya ikna etmek çok daha zordur. Bu, yukarıdaki kriterleri karşılamak için zaman elde etmenin daha zor olduğu anlamına gelir - ortamınızda sizin için çalışan bir komut dosyası yazmak kolaydır, ancak parametrelendirerek kararlı hale getirir, belgelendirmek çok daha fazla zaman alır. Bu, bir geliştirici komut dosyasını güncel tutmayı haklı göstermediği sürece komut dosyalarının ölü kod haline gelebileceği ve haline geleceği anlamına gelir.
• Birden fazla geliştiricinin, onu korumak için karmaşık bir komut dosyasına yeterince aşina olması veya birden çok geliştiricinin kodun sahibi olduğunu hissetmesi çok daha az olasıdır. Orijinal geliştirici ayrıldığında, sahiplik almak için başka birini bulmak zor olabilir (ve betiğin nasıl çalıştığını öğrenmek için zaman bulmak ve haklı göstermek).
• Bir betiğin geliştiriciler makinesiyle etkileşime girmesi ve bir şekilde ortam oluşturması daha olasıdır. Ayrıca, çok sayıda farklı ortama sahip birden çok geliştiriciniz olacaktır. Bir komut dosyası, düzgün bir şekilde muhafaza edilmediğinden veya bir köşe vakası dikkate alınmadığı için bir ortamı karıştırırsa, yalnızca yazılımınızın her gece derlemesini kırmakla kalmazsınız, potansiyel olarak bir geliştiriciye bir gün veya daha fazla iş çevre normale döndü. Bu, baad kanına ve güven kaybına neden olabilir.
• Komut dosyaları genellikle yazılımın dışında olduğundan, bunları korumak zor olabilir. Scriptler otomasyonlar üzerinden çalıştırılmazsa, eski haline gelmeleri veya unutulmaları kolaydır, bu noktada ölü kod haline geldiler ve sadece birisinin temizlenmesi için zaman alması gereken teknoloji borcu.

Özetlemek gerekirse, komut dosyaları tek bir geliştirici için çok yararlı olabilir, ancak kod tabanının bir parçası olarak paylaşmak çok daha zor bir iş olabilir ve çözülenden daha fazla soruna neden olabilir.