PowerShell Komut Dosyası Oyunları Üzerine Düşünceler
PowerShell'de hâlâ yeni olanlarınız için şunu da açıkça belirteyim ki PowerShell komut isteminde etkileşimli olarak kullanıldığında, işi verimli bir şekilde yapmanıza yardımcı olan her şey yolunda gider. Ancak, varlığını sürdürecek bir şey olan komut dosyası içeren bir PowerShell çözümü oluşturduğunuzda yönergeler biraz farklıdır.
Geçmişteki oyunlarda karşılaşılan zorlukların karmaşık olduğu doğru. Açıkçası bunlardan birkaçına nasıl başlayacağımdan bile emin değilim. Bununla birlikte, sonuçta hala PowerShell betiklerinden bahsediyoruz. Değerlendirdiğim girişlerde beni etkileyen şeylerden biri, ne sıklıkla bir PowerShell betiği değil de bir Visual Studio projesinin kaynak kodunu okuduğumu hissetmemdi. Bir yandan bu iyi bir şey olarak değerlendirilebilir: PowerShell, temel komut dosyalarından incelediğim giriş türlerine kadar her şeyi oluşturabilecek kadar esnektir. Ama yine de, eğer benim okuduğum gibi kod üretecek teknik beceriniz varsa, muhtemelen "gerçek" bir derlenmiş araç seti oluşturabilirsiniz. Geliştirme sürecinizin bir noktasında kendinize bir PowerShell betiği mi oluşturduğunuzu veya bunun ötesine geçip geçmediğinizi ve belki de bir betiğin doğru çözüm olmadığını sorabilirsiniz. Evet, oyun girişlerinin PowerShell betikleri ve modülleri olması gerekiyordu, peki ya üzerinde çalıştığınız şey?
Yine de bu beni bir sonraki noktaya getiriyor: sürdürülebilirlik. Bunu test etmenin en iyi yolu, betik dosyalarınızı ideal olarak sizden biraz daha az PowerShell bilgisine sahip başka birine vermek ve betiklerinizin ne yaptığını ve nasıl yaptığını anlayıp anlayamadıklarını görmektir. Okuduğum girişlerin çoğu geniş kapsamlı, karmaşık işlevler, komut dosyaları ve .NET kodlarıydı. Birçok durumda neler olup bittiğini anlamaya çalışmakla zorlandım. Eğer *ben* senaryonuzun veya modülünüzün tüm parçalarının nasıl çalıştığını anlamakta zorlanmak zorunda kalırsam, terfi ettiğinizde bakımı veya sorunları gidermesi için çözümünüzü teslim alan iş arkadaşınızı düşünün. Veya 6 ay sonra buna geri dönebilirsiniz.
Yorumlara herhangi bir ceza uygulanmaz. Yeni başlayanların, çalışmalarını organize edebilmeleri ve planlayabilmeleri için önce yorumları yazmalarını teşvik ediyorum. Bir modül için kendi Yardım konularınızı da yazabilirsiniz. Bana göre bu gibi bilgiler en az kullandığınız PowerShell komutları kadar önemli.
Son olarak, sözdizimi ve dil seçimleriyle ilgili her zamanki endişelerim var. Evet, her zaman istisnaların olduğunu biliyorum. Bir cmdlet'in işe yarayacağı durumlarda .NET sınıflarını kullanmaya başvurmayın. Komut adlarınızda standart fiiller ve anlamlı isimler kullanın. Ancak belki de benim için en büyük sıkıntı Return anahtar sözcüğünün sürekli kullanılmasıdır.
Return anahtar sözcüğünü her gördüğümde, komut dosyası yazarının PowerShell paradigmasını tam olarak kavramadığını hissediyorum. Benim düşünceme göre değerleri döndürmüyoruz, nesneleri boru hattına yazıyoruz. Return'ü kullandığım tek zaman, kasıtlı olarak bir komut dosyasından veya işlevden kurtulmak ve her şeyi zarif bir şekilde sonlandırmak istediğim zamandır. Genellikle Return kullanımını gördüğümde, her biri bir şeyi "geri döndürmeyi" amaçlayan birçok gereksiz yardımcı işlevi de görüyorum. Bu yalnızca işinizin (gereksiz) karmaşıklığını artırır. Belge eksikliğini de ekleyin ve buna optimalin altında PowerShell diyebiliriz.
İyi hazırlanmış bir PowerShell betik dosyası güzel bir şey olabilir.
Ardışık düzen açılıyor,
neşe gönderen nesneler çiçek açar
mutluluk olarak biçimlendirilmiştir
Ne düşünüyorsun? Şirketinizde veya doğada iyi, kötü veya çirkin ne gördünüz?