Bazı işler için şirketiniz tarafından desteklenmeyen bir dil kullanmak uygun mudur?

COBOL, VB6, C # ve Java: Birkaç dili destekleyen bir şirkette çalışıyorum.
Bu dilleri birincil çalışmam için kullanıyorum, ancak Python'daki bazı küçük programları (örn. Scriptler) kodlarken kendimi sık sık buluyorum çünkü bu tür bir görev için en iyi araç olduğunu gördüm.

Örneğin: Bir analist bana bazı DB tablolarını doldurmak için karmaşık bir CSV dosyası veriyor, bu yüzden Python'u ayrıştırmak ve bir DB betiği oluşturmak için kullanırdım.

Sorun ne?
Gördüğüm en temel sorun, bu hızlı ve kirli komut dosyalarının birkaç bölümünün yavaş yavaş önem kazanması ve:

1. Şirketim Python'u desteklemiyor
2. Sürüm kontrollü değiller (Onları başka şekilde yedekledim)
3. Arkadaşlarım Python'u tanımıyor

Analistler bile e-posta ile gönderme yapmaya başladılar ("dışa aktaran betiği başlat ..."), bu yüzden başlangıçta düşündüğümden daha sık ihtiyaç duyuluyor.

Bu senaryoların sadece ana projenin parçası olmayan araçlar olduğunu eklemeliyim; sadece daha az zamanda önemsiz görevleri yerine getirmelerine yardımcı olurlar. Kendi küçük işlerim için çok yardımcı oluyorlar.

Kısacası, kaza geçiren bir piyango kazanan olsaydım , iş arkadaşlarımın bu senaryolar olmadan projeyi canlı tutmaları gerekirdi; Örneğin CSV hatalarının düzeltilmesi için daha fazla zaman harcarlardı.

Bu ortak bir senaryo mu? Yanlış bir şey mi yapıyorum? Ne yapmalıyım?

Bu noktaya gelmemesi gerektiği için durumu resmileştirmelisin. Ancak, bu şeyler olur, bu yüzden patronunuza kişisel senaryolar için bu senaryoları yarattığınızı, ancak daha geniş bir dolaşımda "kaçtığını" açıklamanız gerekir. (Gerekirse) bunu daha önce dikkatine sunmadığınız için hatalı olduğunuzu kabul edin.

En azından senaryolar kaynak koduna "tam olarak" konulmalıdır - o zaman en azından müsait değilseniz (ne sebeple olursa olsun) iş arkadaşlarınızın komut dosyalarına erişimi olacaktır.

Öyleyse, patronunuzu Python'un bunlara gideceğiniz yol olduğuna ikna etmeniz ya da onları desteklenen bir dilde tekrar yazmak zorunda kalacağınızı kabul etmeniz gerekir. Senaryoları belgeleme ve Python'daki iş arkadaşlarınızı eğitmenin maliyeti, yeniden yazmakta olduğundan daha düşükse, tartışmayı bile kazanabilirsiniz.

Ne yapman gerektiği konusunda sana tam bir cevap veremem . Başlamak için kullanabileceğiniz yalnızca tek bir öneride bulunabilirim:

Komut dosyalarını tüm (gerekli) geliştiricilerin erişebileceği bir havuza yerleştirin. Ancak, bu komut dosyalarını ilk önce kendi amacınız için yazdığınızı , yani size verilen bir görevi yerine getirdiğinizden emin olun . Ardından, başkalarının yararlanmalarına izin vermek için yalnızca bu komut dosyalarına göz attığınızı ekleyin.

Ondan sonra sadece diğer insanların buna nasıl cevap verdiğini görmeniz gerekir.

Çalıştığım yerde benzer sorunlarla karşılaştım. "PHP nedir?" Diye duydum birkaç yıl önce. MS yığının dışında bir şey öğrenmeyi anlamıyor ya da umursamıyorlar. Eğer python iş için doğru bir araçsa, denetçilerime bu konuda sadece bilgi vereceğim ve python'un neden doğru seçim olduğunu açıklamaya ve açıklamaya çok hazırım. Sinir bozucu olacak, ama çoğunun python'un metin işleme için iyi bir seçim olduğu konusunda hemfikir olacağını düşünüyorum.

Yapmanız gereken ilk şey, takım ve patronunuzla konuşmak. Şu anda çok büyük bir kamyon faktörüne sahipsiniz (eğer bir kamyonete çarptıysanız, başka hiç kimse senaryolarınızı kolayca koruyamaz). Bu görevleri yapmak için komut dosyalarına sahip olmak önemlidir, ancak bu komut dosyalarını düzenlemek ve sürdürmek için gereken herkesin de çalışması önemlidir. Python kullanmanın nasıl değer kattığını açıklamanız gerekiyor - zamandan, emekten, kaynaklardan, paradan, vb.

İkinci olarak, projenin sürüm kontrolüne alın. Şimdi. Bir proje için ürettiğiniz hiçbir şey, o projenin sürüm kontrolü dışında hiç olmamalıdır.

Boşluğa hazırlıklı olun - insanlar genellikle değişmekten hoşlanmazlar. Kendi başınıza kaçmak, desteklenmeyen ve bilinmeyen (ekip / kuruluş) teknolojilerini kullanmak, en azından diğer geliştiricilere danışmadan ve herkes için bu görevleri otomatikleştirmenin en iyi yolunu (sadece proje için değil) belirlemekten kötü bir fikirdi. kullanmak.

Bence bu muhtemelen iyi bir durum

Bağışlanmak, izin almaktan daha kolay.

İşi bitirmiş gibisin, ama şimdi tepkilerle ilgilenmek zorunda kalacaksın.

Baş parmağımın kuralı:

Başkalarının çalışmalarını potansiyel olarak etkileyebilecek herhangi bir şey, akranlarınız ve ASAP üstlerinizle tartışılmalıdır.

Ancak, yalnızca sizin için ve sizin için, firmanızın altyapısına veya güvenliğine bir zarar vermediği sürece, işi yapmak için istediğiniz kadar özgürsünüz.

İki seçeneğiniz var:

1. Standart yapmak
2. Standart bir araca çevir

Organizasyona bağlı olarak # 1 zorlu olabilir (sonuçta standart teknolojilerin listesini sınırlandırdıktan sonra birleşik bir eğitim patlamasını önler ve beceri gereksinimlerini destekler).

İkinci seçenek, yeteneklerinizin gelişimine yardımcı olacaktır ve sıkı çalışmanın bir kısmını yapmak için üçüncü tarafları (ve muhtemelen ticari lisansa sahip lisanslı açık kaynakları) bulabilirsiniz. Örneğin, "LINQ to CSV" araması bazı yararlı sonuçlar almalıdır.

BTW, VB6'nın geliştirici araçları (IDE, derleyici) desteklenmiyor (güvenlik düzeltmeleri bile yok) bu nedenle standartın yine de güncellenmesi gerekiyor. (VB6 çalışma zamanı, geçerli Windows sürümlerinin bir parçası olarak kuruludur ve kuruluma dahil edilmiştir). Bu belki de # 1 yaklaşımı için bir yardımcı olarak kullanılabilir: standart araç setinin tedarikçi bağımlılıkları nedeniyle hareketli bir hedef oluşturması gerekir.

Size bir görev verilirse ve zamanında başarabilmenin tek yolunu seçtiyseniz, gerçekten bir seçeneğiniz yok. Yetkili kişilerin ne yaptığını bilmelerine izin vermenin akıllıca olacağını düşünüyorum. Gerekli kaynak kontrolünün dışına çıkmamalısınız (kesinlikle işe yaramadığı sürece?) Test ve dokümantasyonu.

Bazen bir şirket, tek bir geliştiricinin yeni bir geliştirme alanına bakmaya başlamasına izin vermek zorunda kalabilir. Ne yazık ki, kod, başkalarının hız kazanabileceğinden daha hızlı şekilde üretime girebilir.

Kabul etmeliyim ki, 20 farklı dilde çalışmanın kokuyor, çok.

Sen C dll çağıran Java ikili çağıran Perl komut dosyasını çağıran Python komut dosyasını çağıran bir Bash komutunuz var ...

Sonra bir şey tüm boru hattındaki fana vurur ve siz de devam edersiniz - WTH IS DAT KODEZ? Özellikle Perl'de ... Ve basit hata ayıklama, örneğin kodlama problemi, kabus gibi bir karışıklığa dönüşüyor. 7 dilden 5'inde etkili bir şekilde hata ayıklayamazsınız ve bu gerçek bir acıya dönüşür.

Ya da basit bir değişiklik eklemek zorundasınız, ancak 10 hata yaratıyorsunuz çünkü Perl'de var, Java'da var.

Ve bu 7+ dil zinciri her seferinde bir adım başlar.

Dikkatli bir şekilde bas, burada ejderhalar ...

Bunlar kendiniz için kullandığınız araçlarsa, sizi daha üretken kılan her şeyi yapmakta özgürsünüz.

Aslında, sonuçta kollarınızın bir uzantısı olacak bu tür araçları kullanmanız ve kullanmanız teşvik edilmelidir .

Sonunda, hangi dilde yazıldığına bakılmaksızın bu tür araçlara sahip olmanın önemini anlayacak ve çalışma ortamlarında uygulamaya başlayacaklar.

Sth. Yaparak kod yazmanız istendiğinde, dil genellikle belirtilir veya ima edilir (kurumlarda kural).

Ancak, verileri DB'ye içe aktarma gibi bir kereye mahsus bir görevi yapmanız gerektiğinde, doğru ve hızlı bir şeyler yapmanız gerektiğine göre, fikrinize en uygun olan aracı seçmekte özgürsünüz, ve sonuç önemlidir. araçlar değil.

Bu yüzden bu kuralı kullanırdım:

1) Veri alma gibi bir işlem yapmanız istenirse, tools / dil / etc. Bu benim için en uygun ve görev için en hızlı olanı olurdu.

2) Bazı verileri içe aktarma gibi bazı görevleri yerine getiren bir araç yazmanız istenirse, yöneticiyle hangi dili / aracı kullanacağımı tartışacağım (örneğin standart bir dil kullandığım zamanlar hariç, örneğin şirket kullanırken [neredeyse] ] yalnızca Java).

3) Görev tek seferlik görünüyorsa, ancak tekrarlanabilir hale geldiyse, yönetici ile konuşarak 1) 'den 2)' ye değiştirmek ve tercih ettiğinizden şirket destekli dilinize yeniden yazmak zorundasınız.

Sanırım karar verecek bir durumda değilsin (yoksa soruyu sormayacaksın). Patronunuz bu konuda ne düşünüyor? Onunla konuşmalı ve onu Python'un gideceğin yol olduğuna ikna etmeye çalışmalısın ...

Tabii ki, mesele ayrıldığınızda ne olacağı ile ilgili. Kodu koruyamamak, Python'u kullanmayı bırakacak kadar iyi bir neden olabilir. Veya meslektaşlarınızı bu dilde eğitmeye başlayabilirsiniz ...