Bir şirket belirli bir IDE'ye kırmızı bayrakla geçiş emri mi veriyor? [kapalı]

Son zamanlarda hızla büyüyen bir girişime katıldım. Son 3 ayda, geliştirme ekibi 4 ila 12 arasında büyümüştür. Şimdiye kadar, geliştiricilerin işlerini yapmak için kullandıkları şeylerle ilgili çok eksikti . Aslında şirkette başlangıçta çekici bulduğum şeylerden biri, programcıların çoğunun Linux kullanması ya da işletim sistemi için çabalarını en iyi şekilde düşündükleri her neyse.

Şimdi, emirler, tartışmasız, herkesin Eclipse'e geçmesi gerektiği konusunda geldi. Güzel bir editör. SublimeText2'yi tercih ediyorum ama bu benim kişisel zevkim.

Açık olmak gerekirse: Backbone ve Eclipse kullanan bir JS ekibiyiz, Backbone kodunu anlamada iyi değil. Bu, bir / iyi / IDE (PHP Fırtına) kullanan ekipte, geri arama-bul-oh-bekle-nerede-ben-üç-adımlar-öncesi-tür-tür şeylerin çoğuna geri dönmek zorunda kaldıkları anlamına gelir. yerine sadece ctrl + tuşlarına basıp geri / ileri kullan - üretkenliği% 15 azaltarak ve eğlenceyi% 50 azaltarak ...

Bu bir kırmızı bayrak mı? Geliştiricilere (MS üyesi olmayanlar), zaten yerleşik ve üretken olmaları durumunda hangi IDE veya araç setlerinin kullanılacağını söyleme konusunda kaprisli ve makul bir şekilde kontrol edici görünüyor.

“Şimdi, tartışmalar olmadan emirler, herkesin Eclipse'e geçmesi gerektiğine karar verdi.”

Ben düşünüyorum bu gerçek kırmızı bayrağıdır. Ekibiniz yazılım geliştirme konusunda uzman ve karardan etkilenecek olan kişidir, ancak bu sırayla sonuçlanan tartışmada bir kelime söyleyemediniz mi?

Sivri saçlı patronlar tarafından aşırı yönetmek gibi geliyor. Karar veren kişi / ekibin bu kararla ilgili görüşü var mı?

Karar vericilerin böyle bir karar için yeterli nitelikte olduğu düşünülürse, dev ekibin fikrini sormamak en az iki eksikliğe sahiptir:

• Takım karışmış hissetmiyor. Takımın dahil edilmesi yönetim için bir öncelik olmalıdır. IDE gibi merkezi konular hakkındaki düşüncelerimin istenmesi için bile yeterli olmadığı bir yerde çalışmak istemem. Birisinin fikrini istemenin ve buna karşı karar vermenin daha kötü olacağı kabul edildi, ancak bu durumda bu karar için sağlam bir gerekçe beklerdim.

• Ancak deneyimli yönetim bu kodun geliştirilmesiyle% 100 çalışmaz. Hiç ilginç bir kavrayışı olmayan insanların saf olmadığını varsayarsak. Elbette, yöneticilerin geliştiricilerin ortaya çıktıkları her şeyi düşündüğü, ancak bilmenin tek yolu sormak olabilir.

Ortak bir proje üzerinde birlikte çalışırken, her iş istasyonunda yazılımınızı düzenlemek / derlemek / hata ayıklamak için kullanılabilecek tüm araçlara sahip olmanız ve geliştirmenin yaklaşık% 90'ını yapmak için çekirdek araçların herkes tarafından bilinmesi mantıklıdır. takım. Bu hedef, takımınız büyüyorsa ve herkes kişisel favori araç setini kullanıyorsa, elde edilmesi daha zordur - ne kadar çok insan, o kadar çok görüş. Ayrıca, araç sayısının gereğinden fazla büyümesine izin vermezseniz, idari işler de kolaylaşır.

Elbette, bir geliştirici kişisel favori editörünü kullanmakta ısrar ederse, kaynağın ekibin ana editöründe (sizin durumunuzda Eclipse'de) görünmediğinden veya farklı davrandığından emin olabileceği sürece tamam olabilir. B dev A'nın kaynağını düzenlemelidir, dev B, kaynağı etkin bir şekilde değiştirebilmek için A'nın kişisel favori editörünü öğrenmeye zorlanmamalıdır. Ancak, ikisinin de aynı ekranın önünde zaman zaman birlikte çalışması gerekiyorsa (veya bazı çift programlama yaparsanız), seçilen editör her ikisi tarafından da iyi biliniyorsa, işler genellikle daha kolaydır.

Çift programlama için, klavyeyi kullanırken ekranın her iki tarafının da aynı becerilere sahip olması güzel. Projenizin IDE'de özel yapılandırma ihtiyaçları varsa, o zaman herkes için aynı şekilde yapılandırıldığını bilmek güzel. Araçlar herkes için aynı olduğunda, yeni bir geliştiriciye başlamak daha kolaydır.

Ama bunu sadece en etkili olmaya çalışmakla karşılaştırırsanız, buna gerçekten değmez

Evet, yönetimin, kendinizle hangi araçlarla daha verimli olacağınıza daha iyi karar verdiğini düşünmesi kırmızı bir işaret.

Bu kendi başına bir kırmızı bayrak değil.

Bazen yönetim karar almak zorundadır . Bir konuda standardizasyon gerektiren herhangi bir konu, bu kategoriye girme eğilimindedir. Bir keresinde birkaç yıl boyunca standartların sürüklenmesine izin veren ve 20'den fazla farklı SCM aracına sahip olan bir müşteride çalıştım. Farklı geliştirme ekipleri tarafından bağımsız bir seçim olarak başlayan şey, organizasyon genelinde kod üzerinde beceri ve işbirliğini paylaşmayı ciddi şekilde engelleyen lojistik bir kabusa dönüştü. Entegre inşa edildi ..... er ..... çok entegre değil .....

Ayrıca, her karar için herkese danışmak pratik ya da gerekli değildir . Bunun ne kadar yapılması gerektiği organizasyonun kültürüne ve kararın önemine / karmaşıklığına bağlıdır. Genellikle bu daha az konsültasyon ağırlıklı seçeneklerden birini alırsınız:

1. Artıları / eksileri hakkında yeterli bilgiye sahipseniz ve geniş kapsamlı bir istişare gerektirecek kadar önemli bir karar değilse, kararı kendiniz verin.
2. Birkaç kilit kişiyle görüşün (muhtemelen kararı almaya en uygun kıdemli geliştiriciler olabilir).
3. Etkilenebilecek herkese (e-posta, belediye toplantısı, takım toplantıları) karar verdiğiniz gerçeğini yükseltin. Doğru kararın ne olduğunu düşündüğünüzü söyleyin, aksi takdirde yeni kanıtlar ortaya çıkarsa bunu değiştirmeye istekli olduğunuzu söyleyin. Bazı önemli görüşleri varsa, insanları bireysel olarak öne çıkmaya davet edin
4. Seçenekleri gözden geçirmek ve bir karar önermek için insanları alt ekip kurmaya davet edin. İyi bir seçenek eğer gerçekten yakın bir çağrıysa, cevabı bilmiyorsunuz ve katılanların karara bağlanmalarını istiyorsunuz.

Geliştirici araçları gibi (potansiyel olarak tartışmalı bir mesele) gibi bir şey için muhtemelen 2 veya 3 ardından 4 yapardım, yani kesinlikle bu konuda kişisel olarak konuşamayacağım bazı kişiler olacaktı, ancak diğer taraftan kilit kişilerin karar vermelerine katkıda bulunma şansı olurdu.

Bana göre, yanlış kararın alındığını kuvvetli bir şekilde hissederseniz , gerçek kırmızı bayrak olacaktır (yanlış == sadece favori aracınızın seçilmesinden ziyade şirkete zarar verir). Bu sorunu dile getirdiğinizde yönetim nasıl tepki verir:

• İyi yönetim argümanınızı dinler, geri bildiriminiz için içtenlikle teşekkür eder ve yeni görüşler edinmeniz durumunda konumlarını yeniden gözden geçirir . Yine de sizinle aynı fikirde olmayabilirler ve kararlarına sadık kalabilirler, ancak onlarla birlikte büyüttüğünüzü takdir edeceklerdir ve kararlarına neden sadık kaldıklarını söyleyerek nezaketiniz olur. Gelecekte bu tür kararları alma şeklini bile değiştirebilirler ve iyi puanlar verirseniz sizi "sorması akıllı insanlar" listesine dahil edebilirler.
• Kötü yönetim savunuculaşacak, “kararın verildiğini” ve yanlış bir karar vermiş olmaları gerçeğiyle yüzleşmekten kaçınmak için bu tür taktikleri söyleyecektir. Seni bir "baş belası" olarak görebilirler. Şirket, yönetime olan inancınız gibi acı çekiyor. Bu gerçek bir kırmızı bayrak! Mümkün iken dışarıya çık!

Eğer maven veya benzeri bir şey kullanıyorsanız, hangi IDE'yi kullandığınız önemli değildir. Güvendiğiniz bir eklenti varsa, tutulma gibi belirli bir IDE'ye bağlı durumlar olabilir.

Kendi IDE'nizi, en üretken olduğunuz IDE'yi seçebilmeniz gerektiğini düşünüyorum. Ancak, daha önce de belirttiğim gibi, standart bir IDE kullanmanın mantıklı olduğu durumlar vardır.

"Kurumsal olarak yetkilendirilmiş" IDE'yi kurdum, ancak çalışmamın çoğunu istediğim IDE'de yapmayı düşünüyorum - kaynak kodunu düzenlemek için hangi IDE'nin kullanıldığını kimsenin söyleyebileceği bir şey değil.

Editör ön vs IDE üzerinde ... neredeyse tüm diller için, ben şiddetle bir editör can daha sizin için yapabileceği sadece çok daha fazlası var çünkü IDE (IntelliJ) tercih ederler. ID2'ye veya Emacs'a döndüğüm bazı şeyler var, ancak günlük kodlama için, her iki ST2 / Emac'ı ne kadar sevsem de, IDE neredeyse her zaman kazanıyor.

Şimdiye kadar bulunduğum her takımın birçok IDE'si ve editörü vardı: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - bu hiç sorun olmadı. Asla.

Bana göre bu, gerçekte neyin önemli olduğu ile ilgili olarak organizasyonun üst düzeyindeki bir yanlış anlama anlamına geliyor. Önemli olan, iyi kodlayıcıların yapmaları gerekeni yapmalarını ve onları en konforlu kılan araçları kullanmalarını sağlamak. IDE bütünlüğünün, nesne mimarisi, birim testi, algoritmalar vb. Gibi temel sorularla ilgili gerçek iletişim ile ilgisi yoktur.

Sıradaki adamla aynı IDE'ye sahip olmak, her ikimizin de aynı kısayollarla koda nasıl gözatılacağımızı ve derleme / yapılandırmamızın nasıl kurulduğunu bilmemiz anlamına geliyor. Gerçek kod meseleleri hakkında konuşurken bunların hiçbiri önemli değildir.

Bak, şirketteki diğer faktörlere bağlı olarak yaşanabilir. Günlük işler için kendi tercih ettiğiniz editörünüzü her zaman kullanabilirsiniz. Ve belki de grubunuz harika kültür oluşturan başka harika şeyler yapıyordur. Ancak zorunlu IDE'ler çok büyük bir yanlış IMO'dur. Benim için, eğer ben bir şirketle görüşme ve onlar hangi IDE beni bilgilendirdi izin Onların kez kibarca onlara teşekkür ederim kullanmak.

Gelen bizim Yakut dükkanda orada biz iş yapar biliyorum çünkü, takımın en hoşlanan IDE (rubymine) kullanmak için güçlü bir öneri var ve birbirimizi kısayollar vb öğretebilir

Geliştiriciler farklı bir IDE kullanmakta serbesttirler, ancak seçmeleri durumunda bu editörde sağlam becerilere sahip olmalarını istiyoruz. Projelerinde gezinmek veya özel FooEdit'lerinde metin düzenlemek için mücadele eden birini görürsek, onlar için RubyMine öyledir.

Bir programcı belirli bir IDE'de uzman ise, kullanmalılar. Herhangi bir IDE'de uzman değillerse, muhtemelen programlama diliniz için veya ekibinizde çok yaygın olan bir veya iki tane vardır ve muhtemelen öğrenmeleri için mantıklı olur.

Bir IDE'yi standartlaştırmaya zorlanmak, korkunç bir fikir gibi geliyor.

Bir şirketin geliştiricilerini genel olarak belirli bir editör veya yazılımı zorlama nedenleri incelenmelidir. Paranoyak (belki de aradığım kelime değil) bir parçam, geliştiricilerden yüklemelerini istedikleri tutulmaya eklenen bir çeşit verimlilik takibi olabileceğini düşünüyor. Çok daha az paranoyak (yine) bir düşünce, bu IDE'ye herkesin kod dalını sınamak ve oluşturmak için aynı düğmeye basması durumunda işleri daha kolaylaştıracak ürün oluşturma araçları eklemek için zaman harcayacakları düşüncesi olurdu.

Her neyse söylemeye çalıştığım şey, muhtemelen sadece bürokrasiden ya da geliştiricilerin kafasını karıştırmaktan daha fazlası.

Bu büyük bir kırmızı bayrak. Her şirketin böyle aptalca fikirleri vardır, ancak diğer kırmızı bayraklar gelmeye devam ederse, hemen bırakın.

Bazı kararların arkasındaki motivasyonun kaybolması kolaydır - özellikle hızlı büyüyen bir ekiple. Eclipse'e geçme motivasyonu, geliştiricilerin çoğunun sadece IDE'yi yapılandırmak için çok zaman harcıyor gibi görünmesi ve şirketinizde yalnızca sınırlı bir uzmanlık olması gibi olabilir.

Gerekirse Eclipse kurulumuna sahip olmanız gerektiği anlamına gelmek için Eclipse'e geçme emrini alırdım, ancak çalışmanıza en sevdiğiniz editörde devam edin. (Şirketiniz Eclipse içinde harika araçlar kullanmaya başlarsa yavaş yavaş Eclipse'e geçmek zorunda kalabilirsiniz.)

Kızıl Bayrak: Endişelenmeden önce birkaç irrasyonel emir olup olmadığını beklerdim.

Bir başlangıç ​​genellikle sürdürülebilir bir iş modeli bulmak için yeterince çevik kalmaya çalışıyor. Para kısmını anladıktan sonra, yönetim işi büyütmek için devreye girer. Genelde, tüm erken teknoloji çalışanları ayrılmaya başladığında, mühendislik işlemleri sıkılaştıkça.

Bildiğiniz gibi, çalıştırmadan önce kodun gerçekte ne yapacağını bilmiyorsunuz. Turing, hesaplamaların ilk günlerinde bunu kanıtladı. Bu, yazılıma gelince, verimliliğin anlamlı bir ölçüsü diye bir şey olmadığı anlamına gelir. Ancak, yönetimin işini yapması için verimlilik okunaklı olmalıdır. Kodu ölçemezsiniz (ve insanlar denedi - örneğin kod satırları), görebileceklerini ölçecekler. Programcılar geliştirdikleri yazılımlardan daha okunaklıdır. Tipik yönetim ekibi, programcıları bu şeyleri kendilerine okunaklı kılmak için kontrol etmeye çalışır (gerçek işlerini yapmak yerine: yoldan çekilmek). Ve yanlış şeyleri ölçtükleri için çok iyi çalışmaz.

Bunu söylerken, gevşek bir şekilde birleştirilmiş bir ekiple hala uzun bir yol kat edebilirsiniz. Github'un geliştirme ekibi yaklaşık 50 kişiden oluşuyor ve işletme yönetimi kitaplarındaki her kuralı ihlal ediyor. Tamam gibi görünüyorlar. Hatalar giderildi (sonunda). Özellikler eklendi. Yangınlar söndürüldü.

Büyük bir kırmızı bayrak, para kazanmayı düşünmeden bir şeyleri büyütmeye çalışıyorlarsa. Bu noktada, yatırılmayan seçeneklerin ve bağışların ne kadarının gerçekten değerli olduğunu merak etmelisiniz.

Elbette bu kötü bir fikir. Yeni araçlar kullanmayı öğrenmek zorunda oldukları için ekibin daha az üretken olması kaçınılmaz. Ve o zaman bile onlar zaten araçlarla kadar etkili olmayacaktır grok .

Çeşitli araçları kendim denediğimden beri her zaman bir noktada "Tanrım, bu editör beni“ tercih edilen araçtan bir hata / fark ekle> ”ile rahatsız ediyor. Böylece ahlaki bir dezavantaj olacak.

Fakat elbette, bir takımın aynı araçları kullanması için de artılar var. Konfigürasyonların, skriptlerin, eklentilerin ve tüm bu tür şeylerin paylaşılması. Bu, çeşitli araç takımlarıyla mümkün olmazdı.

Diğer taraftan… eğer herkes kendi tercih ettiği yazılımı kullanıyorsa, bu son bit gerekli olmazdı. ;)

SublimeText2'de hala yazarken Eclipse "kullanabilirsiniz".

Bu, Eclipse'in projeleriniz için kurulu ve yapılandırılmış olması ve programın eşleştirilmesi durumunda kullanmakta eşit derecede rahat olmanız için hızlandırılması anlamına gelir. Paralel kurulumunuzu sürdürmek gereğinden fazla zaman almadığı ve kendinizden uzak durmadığınız sürece, işlediğiniz bir kod parçasına gerçekte hangi editörü kullandığınızı kimse umursamaz (veya en azından gerekir). standart geliştirme ortamı.

Git kullanıyorsanız ve dallanma konumunuz düşükse, birbirinizin editörlerini yine de kullanmanız gerekmez. Bir takımı zorlayabilir ve alet setinizi gerçekten çözemezse çalışmasını sağlamak için başka bir cihazla çekmesini sağlayabilirsiniz. Herkesi aynı düzenleyiciyi kullanmaya zorlamak, akıllı görünmek isteyen ancak işleyiş biçiminizi gerçekten anlamayan bazı iş kafalarının emri gibi geliyor.

Bunu yönetim açısından düşünüyorsanız, bunu yapmasının nedeni yasal uygunluktur. Şirket, kullanılan her aletin yasal olarak kullanılmasını sağlamaktan ve ayrıca geliştirilmekte olan ürünü istiflemeyeceğinden de sorumludur. (Bazı editörler kişisel kullanım için ücretsizdir ancak başka hiçbir amaç için ücretsiz değildir.) Her geliştiricinin kullanmak isteyebileceği her aracı denetlemek pahalı olabilir. Zaman çizgilerinin sıkı olduğu projelerde, yönetimin daha sonra yasal kişilerce yönlendirilen projedeki değişiklikleri en aza indirmek için hangi araçların / kütüphanelerin / vb. Kullanıldığı konusunda temkinli davranacağını gördüm.

Daha yüksek güvenlik projelerinde, IDE'lerin geçici dosyaları nerede sakladıkları ve oturumlar arasında hangi bilgilerin depolandığı konusunda da endişeler var.

Hepsi Eclipse'i önerme nedenlerine bağlı. Geliştiriciler, ortamlarını ayarlamada sorun yaşıyorlarsa, çünkü herkes işleri farklı şekilde düzenler, bir gömme ceket önermek için bir neden olabilir. Bununla birlikte, herkes istediklerini kullanarak mutlu ve üretken olsaydı, yaratıcı süreçle çok derinden ilgilenen bir şeyi değiştirmek için çok az neden vardır.

Eclipse, bir editörden çok daha fazlasıdır - kodunuzu düzenlemek için favori editörünüzü kullanmaya devam edebilir ve kaynak kontrolü, hata ayıklama ve kurumsal zorunlu iş akışının ne için istediğini başka bir yerde kullanmak için Eclipse'e güvenebilirsiniz.

Son bir şey - bu seviyedeki zorlayıcı süreç, şirketin geliştirme ekibini genişletme niyetinde olduğunu ve yeni ekip arkadaşlarının daha hızlı üretken olmalarını sağlamak için belirli bir yapıya sahip olmak istediklerini gösterebilir. Rails (veya Django) 'yı düşünülmüş bir çerçeve olarak görüyorsanız, yapının yeni uygulamaların daha kolay anlaşılmasına yardımcı olduğunu fark edersiniz.

Kırmızı bayrak, her geliştiriciye tek bir IDE / editör zorlanacak kadar değil, bu kararın ve özellikle de IDE / editörün hangi kararın kullanılacağına kararın tüm geliştiriciler tarafından verilmediğini ve belki de hiçbirinin onları!?!

Kuşkusuz, geliştiricilerin bir fikir birliğine varmaları en iyisi olacaktır, özellikle de karar için açıkça en iyi nitelikte oldukları için (en azından hangi editör / IDE'de). Uyumu sağlamak için iyi bir neden olabilir ve bu kararın yönetim tercihine ağırlık vermesi gerekir, ancak hangi editörün / IDE'nin tüm geliştiricilerin kararı olması gerektiğine karar vermelidir.

12 oy geliştiricisinin oy kullanması kolay olacak. Kesinlikle bunu yapmak için yeterli zaman vardı! Sonuç, bazı zamanlar için acı verici olabilirdi ve sonunda Eclipse bile olabilirdi, ancak gerekliliği bu durumda "kırmızı bayrak" olarak etiketlemek daha tartışmalı olurdu.