Bir yazılım şirketinin araştırma ve / veya yardımcı program kütüphaneleri için özel bir ekibi olmalı mı?

Çeşitli bankalar ve daha küçük e-mağazalar için web uygulamaları yapan bir şirkette çalışıyorum. Yaklaşık 20 geliştirici istihdam ediyoruz ve aynı anda 4-5 proje geliştiriyoruz. Geliştirme ekiplerimiz çok fazla etkileşime girmez ve aynı problemlerin birçoğu çeşitli şekillerde yapılır (iyi ile kötü arasında).

Bir şirketin, mevcut çerçeveler üzerinde araştırma yapan ve ortak bir fonksiyon kütüphanesini ve mevcut ve gelecekteki projeleri çok daha hızlı ve daha verimli bir şekilde inşa etmenin ortak bir çerçevesini geliştiren bir programcı ekibine sahip olmanın iyi bir fikir olup olmadığını merak ediyordum.

Böyle bir ekip ne kadar büyük olmalı?

Ayrıca başkalarını eğiten kalıcı üyeleri olmalı mı yoksa insanları mı döndürmeli?

Güncelleme: İnsanların eğlenmek için üzerinde çalışabilecekleri biraz ilgi uyandırabilecek ortak bir proje düşünüyordum. İnsanların iş baskıları olduğunda ortaya koydukları çözümler en iyi değil gibi görünüyor.

Önemli bir nokta, toplam izolasyonda iyi bir çerçeve geliştirmenin imkansız olmasıdır. İyi çerçeveler organik olarak büyür : bir programcı belirli bir işlevselliğe ihtiyaç duyduğunu fark ettiğinde, çerçeveye ekler ve böylece çerçeve, asla işe yaramayan "mükemmel bir çerçeve" tasarlamanın aksine, yavaş yavaş büyür, çünkü mimar sonuçta ortaya çıkan tüm kullanım durumlarının farkında olamaz.

Tabii ki, organik olarak çerçeveyi büyütmek, iç bütünlüğünün çok iyi olmayabileceği ve spagetti'ye dönüşmesinin dezavantajına sahiptir. Ekibiniz iyi bir iç iletişimi sürdürürse, her iki dünyanın en iyilerini birleştirebilirsiniz: çerçevenin bütünlüğünü koruyan, ancak son kullanıcıların (geliştiricilerin) gerçek ihtiyaçlarını karşılayan ayrı bir mimar ekibi .

Duygularım hayır.

Bunu yapsaydınız bulacağınızdan şüphelendiğim şey, ekibin dışında hiç kimsenin kullanmadığı kütüphaneler üreten bireysel ekiplere sahip olmak yerine, ekibin dışında hiç kimsenin kullanmadığı kütüphaneler üreten özel bir ekibinizin olması (ve bunu yapmak) önemli ölçüde ek maliyetle).

Tanımladığınız ekiple ilgili çeşitli sorunlar var, ancak benim için asıl olan, aslında sahip olduğunuz sorunu ele almamasıdır.

Sahip olduğunuz sorun kütüphaneleri kimin üretmediği değil (bu sorunlara zaten çok fazla çözümünüz olan şeylerin sesleri ile nasıl yardımcı olacak?), Ekipler konuşmuyor ve etkileşime girmiyor.

Takımların birbirlerinin kodlarını tekrar kullanmamalarının iyi nedenleri vardır (örneğin, yüzeysel olarak benzerken sorunların ustaca farklı olması veya proje zamanlamasının birlikte bir şeyler geliştirmenin ek bağımlılığına izin vermemesi), ancak mümkün olduğunda etkileşime girmelerini nasıl sağlayabileceğinize bakın.

Şunu öneririm:

• ekipleri projeler arasında döndürme
• takımlar arası öğle yemeği ve tartışma grupları düzenlemek
• sorunların nasıl çözüldüğüne dair proje sonrası incelemeler (diğer ekiplerin katılımıyla)
• wiki anahat kodunun yeniden kullanılabilir olabileceği bir alan (ve bunun hakkında kiminle konuşacağı) belirleyin
• iyi yeniden kullanımı teşvik etmeyi düşünün - gerçekten insanlara bunu yapmak için ekstra para ödeyin. Bir bileşeni tekrar kullanmak 5 gün ve 2000 $ maliyet tasarrufu sağlıyorsa, projenin sonunda bir gece için ek ücrete ek olarak 200 $ 'lık para vermeyin (tasarrufun gerçek olduğunu doğruladığınızda)

Bir kütüphane ekibi, şüphesiz, hiçbir faydası olmadan ek yük olacaktı.

Geliştiricilerin eğlenmek için üzerinde çalıştıkları ortak bir proje olması açısından, hiçbir şirket kendi zamanlarında işler üzerinde çalışan programcılara güvenmemelidir. Bu sadece ödenmemiş fazla mesai ve her durumda, kimsenin işler üzerinde çalışmak istemediği büyük dönemler olacağı için güvenilir değildir.

Projeler arasında şirket zamanında çalışan insanlar olacağını söylüyorsanız, belki işe yarayabilir, ancak bunun gerçek sorun olduğunu düşünmüyorum. Hala insanların kütüphaneleri nasıl kullanmasını sağlayacağınızı bulmanız gerekiyor. Söylediğim gibi, her projede geliştirilen bu sorunlara zaten çözümleriniz var, sorununuz neden paylaşılmıyor.

Bu bir mimarın işi .

Bir yazılım mimarının ana sorumlulukları şunlardır:

• Uygulama geliştirmeyi takip etmenin standart bir yolunu seçerek geliştirme sırasında mevcut seçenekleri sınırlamak
• uygulama için bir uygulama çerçevesi oluşturma, tanımlama veya seçme
• Daha geniş sistem ortamını gözlemleyerek ve anlayarak organizasyonda veya uygulamada olası yeniden kullanımın tanınması
• Bileşen tasarımı oluşturma Organizasyondaki diğer uygulamalar hakkında bilgi sahibi olma

Daha fazla bilgi için: - Yazılım mimarı - Çözüm Mimarı - Kurumsal mimar .

" Kendi köpek mamasını yeme " diyerek bu sorunu çözebilirsiniz. En iyi cool-rockstar kodlayıcı, pratikte hiç kullanmadığı bir kütüphaneyi doğurursa, bunun iyi bir kitap olduğunu nasıl söyleyebilir?

Çerçevede işlevsellik geliştirmenin temel nedenleri

1. geliştirici için yararlı 2. yararlı olduğu
birkaç durum vardır 3.
diğerleri için yararlı olabilir

2'ye bastığınızda, işlevsellik zaten orada, onu başka birine nasıl aktarabilirsiniz?

Oyuna biraz geç kaldım ama hiç kimsenin buna değinmediğini hissettim:

Farklı sorunları farklı şekillerde çözen bireysel ekipleriniz kesinlikle paylaşılan işlevsellikten yararlanır ve bunu tek bir ekibi geliştirmeye adamayacak şekilde almanın çeşitli yolları vardır, ancak çok şey gördüm yerlerin.

Çoğu durumda, bunun ürün hattınızın "çekirdeği" olarak adlandırıldığını görüyorum ve bazen (Amir'in önerdiği gibi) bir mimar tarafından yönetilmesinden sorumlu bir ekip var. Bu genellikle, kuruluşunuzda belirlediğiniz en sıkı standartları izleyen ancak yalnızca tam teşekküllü uygulamalara genişletilmesi gerekebilecek veya gerekmeyebilecek en çıplak işlevleri sağlayan bir çerçeveden nasıl yararlanabileceğinizi veya bir çerçeve oluşturabileceğinizdir. bireysel ürün ekiplerinizin sundukları. Bu, temel kodunuzu, kullandığınız her bir yerde uygulayarak "dogfooding" avantajına sahip olmanızı ve ardından tamamen farklı uygulamalara sahip olabilecek farklı ürünlere dalmanızı sağlar. Bu, tüm ekiplerinizin çekirdek kütüphanelere katkıda bulunmasına izin verir, ancak yalnızca ihtiyaç duydukları işlevsellik ile başa çıkmaz.

Bence bu İYİ BİR FİKİR DEĞİL , çünkü kütüphanelerin faydalı olması için gerçek proje problemlerini çözmenize yardım etmeleri gerekiyor ve onları sadece gerçek projelerde çalışarak tanıyabilirsiniz.

Aksi takdirde "teorik olarak" çok iyi bir kütüphane ile son!

Çalıştığım şirkette gerçekten benzer bir şey vardı, iyi çalışmıyor gibi görünüyordu. İç takımdaki insanlar düzgün bir fikir bulur ve çoğunlukla işe yarayan bir prototip geliştirirdi, sonra duvarın üzerinden geçti ve bunu bir ürüne dönüştürmemiz bekleniyordu.

Olmasını beklediğim şey, araç grubunun kendi küçük programına devam edip, o kadar da kullanışlı olmayan, ancak API'yi dağınık hale getiren ve kolayca kullanılamayan yeterince kullanılan işlevler üretecek olması. çıkarıldı. Yeterince belgelemediler.

Alet grubu, gerçekte aletleri kullanan insanlarla sürekli temas halinde olan bir sistem mimarı altındaysa, işe yarayabilir. Alet grubu sık sık dönerse (bu çok fazla dış araştırma yapmayı engelleyecektir) işe yarayabilir. Ancak, ücretli işi yapan insanlarla teması kaybetmekten korkarım.

Çerçeveyi kullanmanın her durumda fayda sağlayıp sağlamayacağını tartışmak için ne kadar zaman harcayacaksınız? Bir proje, çerçevenin yükseltilmesini bekleyerek ertelenir mi? Bir noktada, varlığını haklı çıkarmak için çerçevenin kullanılması gerekir.