Bir ekibin her şeyi şirket içinde yazması ne kadar yaygındır? [kapalı]

Yakın tarihli bir röportajda, röportajcılara "yeni teknolojileri ve kütüphaneleri (SignalR gibi) nasıl değerlendiriyor ve kullanmaya nasıl sokuyorsunuz?" Diye sordum. Yapmadıklarını söylediler, bunun yerine her şeyi kendileri yazıyorlar, böylece başkalarına güvenmek zorunda kalmıyorlar.

Firma, hükümet veya savunma müteahhitleri veya güvenlik açısından kritik projeler veya bunun gibi bir konuda çalışmaz. Onlar sadece ortalama, orta ölçekli bir yazılım geliştirme firmanızdı.

Sorum şu: ekiplerin her şeyi kendileri yazması ne kadar yaygın? Yapan takımlar tarafından endişelenmeli miyim?

Düzenleme - Çoğu yanıt, bunun endişe edilecek bir şey olduğunu söyledi. İkinci bir görüşme, evdeki her şeyi yazma konusundaki konumlarını netleştirme / tekrarlamalarını istemek için uygun bir zaman olabilir mi?

Asla üçüncü taraf kütüphaneleri kullanmama tutumu saçmadır. Her şeyi kendiniz yazmak , kod tabanındaki her satırın bir şirket çalışanı tarafından yazılmış olduğu kesin bir iş şartı olmadığı sürece, şirketinizin zamanının korkunç bir kullanımıdır - ancak bu, özellikle de özel sektörler için olağandışı bir senaryodur. tarif ettin.

Daha rasyonel ve kapsamlı bir cevap, yalnızca aşağıdakileri sağlayan üçüncü taraf kütüphanelerini kullanmaları olabilirdi:

• Aksi takdirde kendilerinin yazacağı kodun gereksinimlerini karşılayın
• Şirketin iş modeli ile uyumlu bir lisans altında mevcuttu
• Dahil edilen testler
• Kod incelemesi geçti

Eğer bu kriterler karşılandıysa (ve benim tecrübeme göre, kod incelemesi özellikle iyi testlerin varlığında çok esnektir), artık "başkasına güvenmiyorsunuz" - mevcut, mevcut ve tercihen sağlam kodu.

Kod açık kaynak ise, en kötü durumda, üçüncü taraf kitaplığı korunmaz hale gelir. Ama kim umursar? Testler, kütüphanenin ihtiyaçlarınız için uygun olduğunu kanıtlıyor!

Dahası, yerleşik üçüncü parti kütüphanelere olan karşılaşma programcının verimliliğini ciddi şekilde engellemektedir. Şirketin web uygulamaları yazdığını ve (örn.) JQuery'yi kullanmayı reddettiğini varsayalım, bunun yerine DOM manipülasyonunu basitleştirmek için kendi alternatif çapraz tarayıcı kitaplıklarını yazdılar. Kesin olarak, onların uygulandığını varsayabiliriz:

• JQuery'e zaten aşina olan geliştiricilere yabancı bir API olacak
• JQuery kadar iyi belgelenmeyecektir
• Kütüphaneyi kullanırken sorunlarla karşılaşırken alakalı Google sonuçları olmayacak
• Alan jQuery kadar test edilmeyecek

Bu noktaların tümü, programcı verimliliğinin önündeki başlıca engellerdir. Bir işletme böyle bir üretkenlikten nasıl vazgeçebilir?

İkinci bir röportajda ortaya çıkmanın uygun olup olmadığını sormak için sorunuzu güncellediniz. Kesinlikle öyle.

Belki ilk görüşmede görüşmecinizin cevabını yanlış yorumladınız ya da görüşmeci sadece şirketin pozisyonunu yanlış açıkladı ve yeni bir görüşmeci bunu netleştirebilir.

Dış kütüphanelerdeki duruşlarından endişe duyduğunuzu açıklarsanız, en az iki olası sonuç vardır:

• Değişime açıklar ve süreçleriyle ilgili endişeleriniz diğer adaylardan daha iyi görünmenizi sağlıyor.
• Değişime açık değiller ve sizi "işe almak istemeyeceğimiz türden bir geliştirici" olarak düşünüyorlar. Önemli değil, yine de çalışmak istediğiniz yer orası değil.

Bu inanılmaz derecede rekabetçi görünüyor. Hibernate gibi standart açık kaynaklı kütüphaneleri atlamaya karar veren dükkanlarda çalıştım ve bazı "kritik" eksik özellikler nedeniyle kendi öğelerini yuvarladım. Sonunda yazılımın oluşturulması ve bakımı inanılmaz derecede pahalıydı. Tabii ki, kurum içi kütüphanenin gideri fena halde göz ardı edildi. Kurum içi kütüphane yazılırken, standart kütüphaneler hızlı bir şekilde gelişmiş ve kurum içi kütüphanede bulunmayan yeni özellikler eklenmiştir. Sonunda, standart bir kütüphane kullanarak bir saat sürecek bir çalışma iki gün sürdü. Ve dünya onları geçtikçe geliştiricinin kariyeri için de kötüydü. Böyle bir dükkandan kaçınırdım. Teslim etmeyi seviyorum ve tekrar kullanabileceğim zaman tekrar yazma sabrım yok.

Mağazanın Burada İcat Edilmedi adlı bir hastalığı var . Röportajı yerinde sonlandırıp derhal ayrılmak için iyi bir nedendir. Bu sadece gerçekleşmesi çok olası olmayan bir yukarıdan aşağıya ev temizliği ile iyileştirilebilir.

Sorunuzu cevaplamak için, düşündüğünüzden ne yazık ki çok daha yaygın ve kesinlikle endişelenmek için bir neden.

Evet, kesinlikle endişelen! Bu kibir kokuyor ve (sert olduğu için üzgünüm) aptallık. Beyninin yarısı olan herhangi bir programcı kendiniz yazmak yerine signalR gibi bir kütüphane kullanır. Zaten çözülmüş bir problemi çözerek zamanınızı boşa harcamanın hiçbir anlamı yoktur. İlk önce daha fazla bilgi edinmeye çalışacağım - sizi yanlış anlamış olabilirler (görüşmeler bitmiş olsa bile zor olabilir!)

Her ikisi de (kısaca) burada sendromu icat edilmemiş yazılım evlerinde çalışan birkaç arkadaşım var . Yani zihniyet orada bir yerde.

İkisinin de yaptığı bir gözlem, geliştirme ekiplerinde yaklaşımın geliştirdiği kültürün etrafındaydı. Her ikisi de, yazılım geliştirme konusundaki bakış açıları bakımından oldukça yalıtkan olan insanlarla ve gerçekten yeni şeyler öğrenmeye ve kaliteyi zorlamaya çalışan insanlarla çalışmaya başladı. Kariyerinizde hangi aşamada olursanız olun, daima akranlarınızdan yeni şeyler öğrenme şansına sahip olduğunuz bir yerde çalışmak istersiniz. Bununla birlikte, bu tür bir ortam genellikle her şeyi kendi yuvarlamak isteyen yerlerde bulunmuyor gibi görünmektedir.

Yaşadığım yerde yaygın değil ve meslektaşlarımdan çok şirket biliyorum. Benden hemen bir "teşekkür yok" olduğunu söylemek kadar ileri giderdim.

Şimdiye kadar yapılmış olan iyi noktaları tekrar kazanmayacağım, ama bir şey daha ekleyeceğim.

Sadece işe almayı çok daha zorlaştırdılar.

• Tüm yeni işe alımların, yazılımın / alanın ana bölümünden daha dik bir öğrenme eğrisi vardır
• En iyi adaylar yeteneklerinin kullanılmamasını istemeyeceklerinden ertelenecekler.
• İnsanlar, en sevdikleri araçları kullanmanın ne kadar kötü olduğunu fark ettiklerinde ve uzun süre pahalı kalmazlar.

Şimdi elbette mücadeleyi seven insanlar olacak, ama sanırım azınlıkta olacaklar.

Ve aynı şekilde, "İnternet ölçeğinde", Amazon, Facebook vb. Gibi çılgınca özel ihtiyaçları olan bazı şirketler de olacak, ancak bunlar yine azınlıkta.

Bir yazılım şirketinin bugün üçüncü taraf ve / veya açık kaynaklı yazılıma güvenmeden dayanabileceğini düşünmüyorum ve rekabet edebilmek için elbette aktif olarak yeni teknolojileri takip etmeleri gerekiyor. Bununla birlikte, en azından oldukça savunucu bir görüş alması için genellikle iyi sebepler vardır.

Örnek olarak, yazılım satıyorsanız ve 7/24 destek sağladığınızı iddia ediyorsanız ve ayrıca yazılımınızın doğru şekilde çalışmasından yasal olarak sorumluysanız, o zaman sorunlarınız için ne olacağı konusunda kesin bir fikre sahip olmanız gerekir. Örneğin, 1 saatlik üretim kesintisi süresinin birkaç milyon dolara mal olabileceği bir fabrikada yazılımlar kullanıyor ve ardından o açık kaynak kitaplığında ciddi bir hata oluşuyor. İnanın bana, söz konusu yazılımın çok kapsamlı değerlendirmelerini yapacaksınız.

Yine de, bu senaryoyu yazdıklarınızdan meselenin özünde görünmüyor.

Eğer belli büyüklükte bir teknolojiye sahip bir şirketseniz, örneğin kendi teknolojinizi daha fazla geliştiriyor olacağınıza benziyor, örneğin: google, çoğu yazılımı açık kaynak kodlu bir yazılım alırken pek olmasa da çok geliştirir. Bir endüstri standardı yapmak için peşinde.

Küçük şirketler için, belirli bir ürünü kendi iş mantığıyla göndermeye çalışırken çok fazla zaman kaybı gibi gözüküyor ve benim deneyimime göre, küçük-orta ölçekli şirketlerin bunu yaptığını görmedim.

Yüksek derecede uzmanlaşmış kod tabanından bahsederken daha karmaşık hale gelir, örneğin: şifreleme algoritmaları - bazı insanlar nasıl çalıştıkları hakkında temel bir anlayışa sahiptir, ancak gerçekte bir çözüm uygulamanın karmaşık kısımları kendinizi ayağınızdan vurmak gibi görünecektir. Bu tür konularda uzmanlaşmış bir şifreleyici tutmazsanız.

Bazı şirketler daha uygun görünen kendi açık kaynaklı projelerinizi oluşturma özgürlüğüne izin veriyor.

Şahsen böyle bir kültürle bir yere gitmem.

Elindeki şey, ikinci röportaja girip onlara zor sorular sormak için gerçekten iyi bir fırsat. Şirketin ne yaptığını bilmiyorum, bu yüzden bunun neden garip bir seçim olduğunu söylemek zor. Yorumu, Google'ın üçüncü taraf kitaplıklarını kullanmasıyla ilgili olarak @Daniel Pryden tarafından kullanabilirsiniz.

Kullandığınız herhangi bir yazılım, ister kurum içinde ister üçüncü şahıstan olsun, avantaj ve dezavantajları vardır. Bir alet kullanmamak, çünkü kurum içi değil, iş için en iyi araç olsa bile, belirli bir kapalı zihniyet gösterir ve bu asla inovasyonu ve yaratıcılığı teşvik etmeyecektir.

Belki de, belki de, belki, bu değişikliği tanıtan kişi sizsiniz. Her şeyde iyi şanslar.

Tabii ki uzaklaşmalısın. Burada bahsettiğimi görmedim, ancak işi devralmanın en büyük nedeni, aktarılabilir becerilerde fazla kazanamayacağınızdır.

Bir sonraki görüşmenizde, hangi teknolojilerle çalıştığınızı sorduklarını ve yalnızca çıplak C + kemiklerinden bahsedebileceğinizi düşünün.

Büyük şirketler her şeyi kendileri yazarlar.

Kendiniz yazmanın birkaç avantajı vardır:

1. Yazılımın kendisinin sahibi olmanız garanti edilir.
2. Oluşturmaya harcanan iş miktarlarını doğru olarak hesaplayabilirsiniz
3. Bir dahaki sefere lib'ler müsait olmasa bile adımlarınızı tekrarlamanız mümkün
4. İhtiyaç şişirmenizi azaltır
5. Diğerlerinin yaptıklarını tekrar etmiyorsun.
6. Bunu sürdürmek için yeterli insana sahip olacağınız garanti
7. Yazılımın her bölümünü değiştirebilirsiniz
8. Yazılımın boyutu, sahip olduğunuz kaynak miktarıyla sınırlıdır.

Birini başka bir kitaplıkta kullanıyorsanız, puanların her biri şu şekilde kırılır:

1. Başka birinin kütüphanesi var
2. Libi oluşturmak için ne kadar çaba harcandığını bilmiyorsunuz.
3. Bir sonraki ürün sürümünüz yeni platformda oluşturulamaz, çünkü aynı kütüphaneler artık mevcut değil
4. Gereksinimi uygulama yeteneği, lib'in onu yıllar önce uygulayıp uygulamamasına bağlıdır.
5. Bir başkası da aynı lib'i kullanıyor, aynı sınırlamaları ve özellikleri alıyor
6. Lib'leri oluşturmadığınızdan, ürününüzdeki tüm yazılımı korumak için yeterli sayıda kişi bulunmuyor.
7. Lib'ler değiştirilemez, ikili dosyalardır. Kaynak mevcut olsa bile, bu büyük miktarda kodu değiştirmek için yeterli sayıda kişiniz yok.
8. Oluşturduğunuz kodu + lib'leri korumak başlangıçta tahmin ettiğinizden daha büyük bir çaba