Bir programcının bir dil ve çerçeve seçiminde ne kadar özgürlüğü olmalıdır?

Öncelikle C # odaklı bir şirkette çalışmaya başladım. Java ve JRuby'yi seven birkaç kişi var ama programcıların çoğunluğu C # gibi. İşe alındım çünkü web uygulamaları geliştirme konusunda çok deneyimim vardı ve JRuby on Rails veya nodejs gibi yeni teknolojilere yaslandım.

Kısa bir süre içinde pek çok işin yapılmasına odaklanan bir web uygulaması inşa eden bir projeye yeni başladım. Yazılım lideri, raylar yerine mvc4 kullanacağımı belirledi. Tamam olabilir, mvc4'ü bilmeme dışında, C # bilmiyorum ve web uygulama sunucusu ve ön uç kullanıcı arayüzü oluşturmaktan sorumlu olan tek kişi benim.

Mvc4 kullanmak yerine zaten çok iyi bildiğim bir çerçeve (Raylar) kullanmak mantıklı olmaz mıydı? Kararın arkasındaki mantık, teknik liderin Jruby / rayları tanımıyor olması ve kodu tekrar kullanmanın bir yolu olmamasıydı.

Karşı argüman:

• Koda katkıda bulunmayacak ve açıkçası
  bu projede gerekli değil . Bu yüzden, JRuby / rayları bilmesi ya da bilmemesi farketmez.

• JRuby'nin kodu alabileceği ve tam tersi şekilde kullanabileceği çok sayıda java uygulamasına sahip olduğumuz için kodu yeniden kullanabiliriz. Aslında, yalnızca Java kütüphanesini JRuby on Rails uygulamasında çalıştırmak yerine, bir Java kütüphanesini C # 'ya dönüştürmek için bazı kaynaklar ayırdı. Çünkü Java ya da JRuby'yi sevmiyor.

Çok sayıda web uygulaması geliştirdim, ancak yabancı bir şey kullanmak bazı sıkıntılara neden oluyor ve alıştığım kadar kısa sürede harika bir uygulama oluşturamıyorum. Bu iyi olurdu; Yeni teknolojilerin öğrenilmesi bu alanda önemlidir. Sorun şu ki, bu proje için çok fazla şey yapmamız gerekiyor.

Bir geliştiricinin hangi noktada araçlarını seçmesine izin verilmelidir? Bu şirkete bağlı mı? Şirketim emiyor mu yoksa bu normal mi? Daha yeşil meralar var mı? Buna yanlış mı bakıyorum?

Takım liderinizle konuşmanız ve şöyle bir şey söylemeniz gerektiğini söyleyebilirim:

Sizin bir .NET mağazası olduğunuzu biliyorum, ama aslında Java / JRubyRails becerilerim için işe alındım. Zaten bildiğim bu araçları kullanarak bu yeni uygulamayı X zamanında oluşturabilirim. İstediğiniz gibi C # / mvc4 öğrendim, ancak >> X miktarını alacak . Ne istiyorsun?

Bu vs "-hired-için (assumedly)-you-sen- becerileri" konusunu gündeme getirmektedir "beceri ihtiyaçları karşılayan bir-an" ve ayrıca yeni beceriler öğrenmeye istekli olduğunuzu gösterir, ancak bu edecektir almak Bu araç setinde yeni olduğunuz için yeni uygulamayı geliştirmek için daha uzun. Ve do yeni beceriler öğrenmeye istekli olduğunuzu göstermek istiyorum. Yeni beceriler öğrenmeye açık olmamak, becerilerinize ihtiyaç duyulmadığında istihdamınızın sona ermesini sağlamanın iyi bir yoludur.

Sonunda sorunuza gelince:

Bir geliştiricinin hangi noktada araçlarını seçmesine izin verilmelidir? Bu şirkete bağlı mı? Şirketim emiyor mu yoksa bu normal mi? Daha yeşil meralar var mı? Buna yanlış mı bakıyorum?

Genellikle şirkete bağlıdır. Bir şirket MS araçları satın alır ve VisualStudio platformunda ve .NET çerçevesinde her şeyi standartlaştırırsa, bir geliştirici Linux ve C kullanmakta ısrar ederse çok garipleşebilir. Üreticilerin, aynı olduğu sürece, geliştiricilerin Vi ve Emacs'ı seçmelerine izin vermek gibi, editörler hakkında daha az telaşlı olduğu durumlar olabilir. Bazı şirketlerin geliştiricilerin Windows ve Linux'u seçmelerine bile izin verdiklerini biliyorum, ancak çalıştıkları dilin her iki işletim sistemi için de çok iyi desteği ve çalışma süreleri var.

Şirketler bunu neden yapıyor? Tutarlılık bir nedendir. Uygulama, çeşitli geliştiricilerin favori dillerinde / çerçevelerinde yerleşik, farklı araçlarda inşa edilmiş ve çok farklı sistemlerde test edilmiş bir ikili dosya parçası olduğunda hata ayıklamak çok zor olabilir. Tüm geliştiriciler çoğunlukla benzer kurulumlarda çalışırsa , bu tür sorunlar çözülür.

Sizin durumunuzda, bu şirkette standart olmayan teknolojide çalışmak için işe alınmışsınız gibi geliyor. Bu bana garip geliyor ve neden onları istedikleri konusunda sizi işe alan kişiyle konuşmak isteyebilirsiniz .

Bir geliştiricinin hangi noktada araçlarını seçmesine izin verilmelidir?

Takımını etkilemediğinde.

Buna yanlış mı bakıyorum?

Kesinlikle.

Evet, kısa bir son tarihin var. Evet, Rails'te daha hızlı halledebilirsiniz. Ancak şirketin bir bütün olarak uygulamayı konuşlandırması ve sürdürmesi gerekiyor. Eğer şirket iyi bir C # geliştiricisinin kararlılığına sahipse, korumak için bir C # uygulamasına sahip olmak muhtemelen daha ucuz (ve daha iyi kalite veriminde) olacaktır.

Sizin DBA ve diğer yönetici personel muhtemelen bu yığının aşina olan ve dağıtmak ve güncellemek üzere kullandığı süreçler var olduğunu yığını. Kodu daha hızlı halledebilseniz bile, profesyonel bir web uygulamasını çalıştırmak ve çalıştırmak için gereken tüm masrafları hesaba katmanız daha uzun sürebilir.

Unutmayın, uygulamanızı korumak için yazmaktan çok daha fazla zaman harcayacağınızı unutmayın. Bu maliyet için optimize edin.

1. Görünüşe göre "yeni" teknolojilere adapte olma yeteneğin yüzünden işe alındın. C #, bu konuda farklı değil. Yeni bir şey öğrenme fırsatı bulmak istemediğinizden emin misiniz?

2. ASP.NET MVC, Ruby on Rails'e birçok yönden çok benzer.

3. Sonsuza dek bir salyangoz hızında olmayacaksın. Zaten ROR biliyorsanız, ASP.NET MVC sizin için bir cinch olacaktır. Hile C # öğreniyor.

Java / JRuby ile kaldığınız için argümanlar

Muhtemelen, patronun üretmeni istiyor. Şirkete değer katabilmeniz için sizi kiraladılar. Onlar aşina olmayan bir çerçeve kullanmanızı zorlayarak onlar anlamak emin olun olacak size neden:

1. Sonuçları daha yavaş bir şekilde üretin
2. Daha düşük kaliteli kod oluşturun

En iyi programcılar bile yeni diller / çerçeveler ile ısınma süresi gerektirir.

MVC4 ve C # Öğrenmek İçin Argümanlar

Yeni diller öğrenmek iyidir. Yeteneklerinize programcı olarak yatırım yapmak, yalnızca öğreneceğiniz dil / platform yakın gelecekte kaybolacaksa ve Microsoft birlikte devam ederken, bunun bir sorun olduğunu sanmıyorum. C # ve MVC'nin ikisi de boru hattında daha da fazla güncelleme ile ikisini de iyileştiren son güncellemelere sahiptir.

Sizi, şahsen daha iyi bir geliştirici haline getirmek, sizi bu duruma tekrar sokmanıza engel olacak. En iyi kısım? Patronunuz, bu şeyleri öğrenmeniz için size para ödeyecek, bu da kendinizi daha fazla para kazanmanız için ödeyeceğiniz anlamına geliyor.

Alt çizgi

Bu mücadeleyi kazanabilirsin, ama hoşnutsuz meslektaşlarınla ​​çalışmaya başlayacaksın. Sadece her birinin avantajlarını ve dezavantajlarını menajerine anlat ve sonra diğer taraf daha mutlu olacak.

Bir geliştiricinin hangi noktada araçlarını seçmesine izin verilmelidir?

Adı geçen geliştirici yazılım lideridir.

Kuşkusuz, üretkenlikten endişe duyuyorsanız farklı araç setini kullanmak için dava açabilirsiniz (ve yapmalısınız), ancak sevmeyeceğiniz bir cevaba hazır olun. Liderinizin belirli bir araç seti kullanmanızı istemesi, mevcut mimari ile uyumluluk, bakımla ilgili endişeler, lisans sorunları, vb. Gibi nedenlerle çok iyi bir sebep olabilir.

Btw, ifade

kısa sürede çok fazla şey yapmaya odaklanmak

yazılım endüstrisindeki mide ekşimesi ve kargaşanın başka herhangi bir şeyden çok daha fazla sorumluluğu var.

JRuby ya da Java programcısı olarak işe alındığınızı söylemediğinizi unutmayın.

İşte bu yüzden işe alındığınızı söylediniz: “[B] çünkü web uygulamaları geliştirme konusunda çok deneyimim var ve çünkü JRuby on Rails veya nodejs gibi yeni teknolojilere yöneliyorum.”

Başka bir deyişle, web deneyiminizi ve yeni teknolojileri öğrenme isteklerinizi seviyorlar .

Şimdi sizden web deneyiminizi kullanmanızı ve yeni bir teknoloji öğrenmenizi istiyorlar .

Öyleyse soru şu, bunu yapacak mısın yoksa yapmayacak mısın?

Yazılımın En Büyük Harcama Bakımında

En büyük masrafın (% 80) yazılımın bakımında olduğunu okudum. İlk gelişme, toplam geliştirme maliyetinin yalnızca% 20'sidir.

Kendi dilinde (İngilizce değil) kod ve yorumlar geliştiren bir geliştirici hakkında bir yazı okudum ve diğer ekip üyeleri kodu geliştirip sürdürdüğünde, dil imkansızdı çünkü dil (herhangi bir programlama dili değil) yabancıydı. onlara.

Benzer şekilde, kendi seçtiğiniz bir programlama dilinde kod geliştirirseniz, diğer ekip üyelerinin bakımı zor olacaktır.

Çözüm: Çift Programlama

İşvereninizden sizi, gerekli programlama dilini bilen ve birlikte çalışabilecek başka biriyle eşleştirmesini isteyin. Birbirinizden öğrenebilirsiniz ve ikinizden biri şirketten ayrılırsa diğeri kodu bilir.

"Çift Programlama" konulu Wikipedia Makalesi: http://en.wikipedia.org/wiki/Pair_programming

Birçok şirket, her zaman yaptıklarını veya "güvenli" olanı yapmayı tercih eder. Java ve PHP'nin hala popüler olmasının bir nedeni var. Şu anda, inde.com'daki "COBOL" kelimesini aramak, gerçekten kendisi için konuşması gereken 2144 listeleri döndürür. Endüstri iyi kod umurunda değil, mümkün olduğu kadar uzun süre süt verebilecek kod umurunda (bu C # 'nın kötü olduğu anlamına gelmiyor, gerçekten değil).

Bunun hakkında bir düşünün: kod size üstün gelecek. Başka birinin kodunuzu korumaya devam etmesi iyi bir şans ve C # Node.js ve Rails'ten daha güvenli bir bahis. 5 ya da 6 yıl içerisinde Ruby programcılarının sayısı yarıya düşerse, Perl ve bir noktada "o" web dili olarak kabul edilen herhangi bir dilin başına geldiğinde, bu beni şaşırtmazdı. Javascript'in kaybolması pek mümkün değil ama zaten webin bir tür ASM'si (veya hatta C'si) olarak kullanıldığını görmeye başlıyoruz - başka dillerin sunucu tarafında kod yazabilmesi için derleyebileceği bir ara dil çok iyi eski hale geldi.

Geliştiricilerin amaçlarını nasıl uygulayacaklarını seçme konusundaki temel endişem, normalde yalnızca kodu değiştireceklerini varsaymalarıdır. Şuna bakın, 12 ay sonra değişikliklere ihtiyaçları olabilir; müsait değilsin (şirketi terk etmiş veya gerçekten başka bir işle meşgul) ve başka bir geliştirici kodunu çalmak zorunda. Eğer bir C # mağazasıysa, araç setlerini kullanmak iyi bir ekip çalışmasıdır. Yeni teknolojiler araştırılmalı ve uygulanmalıdır, ancak yalnızca lider zamanın doğru olduğunu düşündüğü zaman, sadece bir tane değil birçok hedefe göz kulak olduklarından.

Arkanı dön lütfen. Bir Ruby geliştiricisi kiraladığınızı ve çalışmalarını Asp.net/MVC'de uygulamakta ısrar ettiklerini düşünün.

Onlara ne söylerdin? Bu bizim yığınımız dostum. Onunla yaşamayı öğren.

Altın kural, işte burada, altının sahibi olan kuralları yapar.

Birkaç çelişkili hedef vardır ve sorun en iyi uzlaşmayı bulmaktır. Son teslim tarihine sahibiz, belirli bir araç seti talep eden bir takım liderimiz var ve bu araç setiyle deneyimsiz bir geliştiriciye sahibiz, ancak (kısa bir süre içinde) bir süre içinde bir şeyler üretmeye mahkumuz.

Takım liderinin tam olarak bu araç setini (neden henüz bilmediğiniz bir nedenden dolayı sizi bu araç setine alıştırmak için kullanabileceğini) talep etmesinin bazı iyi nedenleri olduğunu anlamak önemlidir. İlk aşamada yapabileceğiniz en iyi şey, bu nedenlerin tam olarak ne olduğunu bulmaktır.

Konumunuza koymak için, takım lideriyle konuşmaya çalışacağım ve durumu sizin görüşünüzde olduğu gibi açıklamaya çalışacağım ve seçenekler ve hangi sonucun (kısa vadeli ve uzun vadeli ekonomik etkiler dahil) üretileceğini açıklamaya çalışacağım. bu seçeneklerin her birini takip ederek. Örneğin, daha deneyimli bir geliştirici, belki de bazı çift program oturumları veya benzerleriyle, sizi yönlendirmek için görevlendirilebilir.

Takım lideriniz tam bir moron değilse, proje ve şirketin genel hedefleri için mantıklı bir fikir birliği bulabilmelisiniz.

Bah. Herkes yanlış.

Bu tek platformlu insanlardan daha iyi bir geliştirici olun ve her zamankinden çok daha ilginç seçeneklere sahip olacaksınız. Yani, şimdilik, MVC'yi öğrenin. Ve kendi zamanınızda, sizi ilgilendiren platformlar hakkında daha fazla bilgi edinin. Düğüm becerilerinizi geliştirin. Biraz Django öğrenin. Hangi Java ya da MVC öncesi maruz kaldığınızı ve sonra kaçtığınızı düşünün, sonra kaçın, ama en azından bu platformların ne kadar gizli yanma nefreti önyargınıza soktuğunuzu düşündüğünüzü eleştirebilecek ve açıklayabilecek kadar bilgi edinin. (tamam, belki orada projeksiyon yapıyorum)

Ve şimdi önemli tavsiyeler için. Uzmanlıklarınızı geliştirmeye devam ederken diğer alanlardaki uzmanlığınızı çeşitlendirmeye devam ederseniz, sonuçta yılın herhangi bir zamanında yeni iş bulabileceğiniz bir yerde olacaksınız. çoğunlukla en az yarısı ilginç. Kendinizi bu yerde bulduğunuzda, bunu istediklerini söyledikleri bu işlerle uğraşmayın ve iki güne kadar uzun vadede gelecekte öngörülebilecek bir geri dönüş umuduyla THAT yapıyorlar. Sadece kibarca açıklayın ve özür dileyin; ama hayır, siz gerçekten yapmak istemediğiniz ve röportajınızda söylediğiniz kadar çok şey söylemediğinizden sonra! pozisyonunu size yanlış tanıdıkları ve kabul etmeyi reddettiği gerçeği.

Ama güven bana, yeni bir iş bulmak her zaman 5 dakikadan uzun süren herhangi bir süre boyunca ciddi şekilde tahriş ve mutsuz olmaktan daha iyidir. Ama elbette, önce bunu yapabilmek için aidatlarınızı ödemek zorundasınız. Bazı insanlar asla yapmaz. Bu yüzden en iyi bildikleri şeydeki her şeyi istiyorlar. Ve elbette diğer cevaplar pek de yanlış değil. Aptalca bir şeyi yapmaları gerekiyorsa, bir .NET mağazasının .NET ile gitmesi mantıklı geliyor.

Elbette, mantıklı olmayan, neden bir Rails / JS / UI dev ile çeşitlendirdikleri ve sadece MVC uygulamaları yapmasıdır. Ama şimdilik. Almanız ve aidatlarınızı ödemeniz gerekebilir. Ve söylediğim gibi MVC'ler o kadar da kötü değil. Tüm seçenekler göz önüne alındığında gerçekten kötü bir seçim ama kesinlikle en kötüsü değil. Oldukça basittir, gerçekte olan her şeyin üstüne 10.000 kat soyutlama atmaz ve birileri rahatsız edilebilecek olursa, sorumlu MS mühendislerinin isimlerini lanetleyeceğiniz şekilde müşteri tarafında o kadar bükülmez onları öğrenmek için.

Öyleyse, henüz yapmadıysanız ve şu anda sevdiğiniz şeylerin daha şüpheci bir gözünüz olduğunu bile görebilirsiniz, istediğiniz zaman gidebileceğiniz o yere gidin. Kendimi benim kadar bile raylardan hoşlanmayan buluyorsun. Ruby'de yanlış bir şey olmadığı için değil (tabiki tercümanı dışında).

Durumunuza bağlı olarak, sizi neden işe aldıklarını bildiğinizi varsaymak tehlikeli olabilir ve hatta yöneticinizin bunu bildiğini ve insanları becerilerinizle işe almanın iyi bir fikir olduğunu kabul etmek tehlikeli olabilir.

Yukarıdaki tavsiyeyi almanızı ve neden C # üzerinden JRuby ile devam etmeniz gerektiğine dair bir dava hazırlamanızı isterim, belki argümanınız ve zaman çizelgeleriniz eski yöntemlerden kopmak anlamlıdır. Sadece bunun iyi olup olmadığını varsaymayacağım, yöneticiye vereceğim ya da gerçekleri yönlendireceği ve karar vermelerine izin vermeyeceğim, bunun için büyük paralar ödeniyor, artı bir miktar CYA.

Dürüst görüşüme göre, iyi geliştiricileri mükemmelden ayıran şeylerden biri, yeni teknolojiye uyum sağlama yetenekleridir. Bugünün en iyi teknolojisinin yarın modası geçmiş olacağı hızlı tempolu bir dünyada yaşıyoruz. Dolayısıyla, adapte olmak istemeyen bir geliştirici, şirket için sınırlı kullanımdadır. Bu iyi olurdu, eğer iyi insanları bulmak ve işe almak gerçekten çok zor, ve bir şirket taşlarını bulduğunda, uzun vadede planlıyorlardı.

Teknoloji kapsamı dışında çalışan şirketleri gördüm ve aynı sebeple yapıyorlar. Yeni teknolojiye adapte olmalarını beklemek anlamına gelse bile harika geliştiricilere el ele geçirmek istiyorlar.

Şimdi senin durumuna. Gruptaki yeni bir adam olarak, söylediklerime ve üstlerime söylemediklerime çok dikkat ederim. Elbette, yeni ortamınıza uyum sağlama sürecinde olduğunuz varsayımına dayanarak çok şeyden kurtulacaksınız. Bununla birlikte, tercih ettiğiniz teknolojideki otorite ve inatçı sebatın altını kesmek, yalnızca üstlerinizin sizi işe almada bir hata yaptıklarını ve sizin rahat bölgenizi terk etmek istemediğinizi düşünmelerini sağlayacaktır.

Seçeceğiniz şey size kalmış, ancak yeni teknoloji öğrenmeye çalışmanızı öneririm. Acıtmayacak, söz veriyorum.

C # bilgisi eksikliğiyle ilgili görüşmeniz sırasında dürüst olduğunuzu varsayacağım, çünkü o zaman olmasaydınız yasal açıdan çok güvencesiz bir durumda olabilirsiniz.

İyi programcılar programlamayı bilir. Hiç kimse açıkça tüm dillerde ve çerçevelerde ustalaşmasa da, çoğu arasında oldukça fazla bir ortaklık vardır. Bugünlerde ana akım olandan (örneğin Lisp) çok farklı olan bir dilde çalışmanız istenmiyorsa, o zaman iyi bir programcının uyum sağlayabilmesi gerekir.

Doğal olarak bir öğrenme eğrisi var. İşveren sizi işe aldıysa, o zaman bu eğriyi makul bir süre içinde takip etme becerilerinize güvenmeleri gerekir (yine, C # bilmeme konusunda dürüst olduğunuzu varsayarak). C # dili yoğun biçimde Java'dan ödünç alır ve daha genel olarak, çoğu sınıf tabanlı programlama dili temelde oldukça benzerdir (prototip tabanlı bir dil olan ECMAScript'in üstüne kurulu olan node.js kodundan bahsettiniz, bu yüzden açıkça diğer programlama paradigmalarında rahat.

İyi programcılar, esnek olmanın yanı sıra, yeni şeyler öğrenmeye istekli olmalıdırlar. Yazılım geliştirmede, genellikle öğreniyorsunuzdur ya da ilgisiz oluyorsunuz.

Elbette, işvereniniz, C # bilmediğinizi bildiklerini varsayarsak, sizinle yarı yolda buluşmak zorundadır. Öğrenmeye istekli olduğunuzu gösterirseniz, bunun için size zaman ve kaynak vermek zorundadırlar. Seni derinlere atmak haksızlık ve gereksiz yere streslidir. Oturmanız ve amirinizle sakin ve rasyonel bir tartışma yapmanız gerekiyor. Eğer C # 'da istiyorlarsa, o zaman üzerinde çalışırken bir öğrenme eğrisi üzerinde olacağınızı kabul etmeye hazır olmalılar ve size sıkı son teslim tarihleri ​​getirmeleri haksızlık olur. Eğer son tarihler esnek değilse ve yüksek stratejik öneme sahiplerse, o zaman içinde işi bitirmek için bir miktar enlem yapabilmeniz için hazırlıklı olmaları gerekir. Ofislerinde daha çok kullanılan dilde olmaları gerekiyorsa, o zaman belki de şu anda uygulayabilmenizi isteyebilirsiniz. Son teslim tarihini karşılamaya aşinasınız ve bir sonraki projeniz C # 'da bir öğrenme alıştırması olarak yeniden uyguladıktan sonra ve dışsalları karşıladıktan sonra yazılımı iç gereksinimlere uygun hale getirmek için. Dediğim gibi, günümüzde daha çok kullanılan dillerin çoğunun ortak bir yanı var, bu yüzden çoğu zaman uygulama detaylarına iniyor.

Er ya da geç bir C # mağazasında çalıştığınızı kabul etmeye hazır olmalısınız ve bu nedenle kemerinizin altında C # bulundurmanız gerekir.

Belki de herkesin MVC'yi .NET ortamında kullanma şeklinden memnun değillerdir. Web formları gibi işlem yapmak çok fazla olabilir. OOP'da prosedürel geçmişe sahip bir kişi başladığında, her şeyi büyük bir sınıfa koyup her zamanki gibi iş yapmaya devam ettiğinde bu durum farklı değildir.

Bu ilk proje ideal durum değil çünkü bunun çok çabuk yapılmasını istiyorlar. Mümkün olduğunca hızlı bir şekilde .NET'te hızlanın ve özellikleri olabildiğince hızlı bir şekilde dağıtmaya başlayın. Bir şeyleri yapma şeklinizden hoşlanmayacaksınız, aklınızdan çıkarmaya çalışın, bu şeyleri yeniden değerlendirmeye başlayacak ve becerilerinizi başka bir dilde uygulamaya başlayacaksınız.

Umarım, daha fazla Ruby tarzında MVC4'ü kullanma şekliniz (herkesin tam olarak doğru yapmadığını varsayarsak), herkesi Webform zihniyetinden uzaklaştıracak ve kıracaktır.