Czy firma programistyczna powinna mieć dedykowany zespół do spraw bibliotek badawczych i / lub użyteczności publicznej?

Pracuję w firmie, która zajmuje się tworzeniem aplikacji internetowych dla różnych banków i niektórych mniejszych e-sklepów. Zatrudniamy około 20 programistów i jednocześnie realizujemy 4-5 projektów. Nasze zespoły programistyczne nie współdziałają zbyt wiele i wiele takich samych problemów jest rozwiązywanych na różne sposoby (od dobrych do złych).

Zastanawiałem się, czy dobrym pomysłem dla firmy byłoby posiadanie zespołu programistów, którzy badają obecne ramy i stale ulepszają wspólną bibliotekę funkcji i wspólne ramy, aby budować obecne i przyszłe projekty o wiele szybciej i wydajniej.

Jak duży powinien być taki zespół?

Czy powinien także mieć stałych członków, którzy szkolą innych, czy też powinien zmieniać ludzi?

Aktualizacja: Myślałem o wspólnym projekcie, nad którym ludzie mogą pracować dla zabawy, który może wzbudzić pewne zainteresowanie. Wydaje się, że kiedy ludzie mają presję zawodową, proponowane przez nich rozwiązania nie są najlepsze.

Ważną kwestią jest to, że niemożliwe jest opracowanie dobrych ram w całkowitej izolacji. Dobre frameworki są hodowane metodami ekologicznymi : gdy programista zauważy, że potrzebuje określonej funkcjonalności, dodaje ją do frameworka, a więc frameworku stopniowo rośnie - w przeciwieństwie do tworzenia „idealnej frameworku” z góry, który nigdy nie działa, ponieważ architekt nie może być świadomy tego, że ostatecznie pojawią się przypadki użycia.

Oczywiście, organicznie rosnąca struktura ma tę wadę, że jej wewnętrzna integralność może nie być zbyt dobra i zmienia się w spaghetti. Jeśli Twój zespół utrzymuje dobrą komunikację wewnętrzną, być może będziesz w stanie połączyć to, co najlepsze z obu światów: oddzielny zespół architektów, który zachowa integralność frameworka, ale będzie budował dla rzeczywistych potrzeb użytkowników końcowych (programistów).

Mam przeczucie, że nie.

Podejrzewam, że odkryłbyś, że gdybyś to zrobił, zamiast indywidualnych zespołów tworzących biblioteki, z których nie korzystał nikt poza tym zespołem, miałbyś wyspecjalizowany zespół produkujący biblioteki, z których nikt inny nie korzystał (i robiłby to) przy znacznych dodatkowych kosztach).

Istnieją różne problemy z typem zespołu, który opisujesz, ale dla mnie najważniejsze jest to, że nie rozwiązuje problemu, który faktycznie masz.

Problem nie polega na tym, kto tworzy biblioteki (przy dźwiękach rzeczy, które już masz wiele rozwiązań tych problemów, więc jak jeszcze jeden może pomóc?), To, że zespoły nie rozmawiają i nie wchodzą w interakcje.

Istnieją dobre powody, dla których zespoły nie wykorzystują kodu innych użytkowników (na przykład, że problemy, choć powierzchownie podobne, są subtelnie różne, lub że czas projektu po prostu nie pozwala na dodatkową zależność wspólnego opracowywania czegoś), ale musisz zobacz, jak możesz je zmusić do interakcji, gdy jest to możliwe.

Sugerowałbym:

• rotuj zespoły między projektami
• organizować obiady między zespołami i grupy dyskusyjne
• przeglądy projektów opisujące sposób rozwiązywania problemów (z udziałem innych zespołów)
• ustaw obszar kodu opisującego wiki, który może być ponownie używany (i z kim o tym porozmawiać)
• pomyśl o zachęcaniu do dobrego ponownego wykorzystania - naprawdę poważnie zapłać ludziom za to. Jeśli ponowne użycie komponentu pozwala zaoszczędzić 5 dni i 2000 USD kosztów, to dlaczego nie dać zespołowi 200 $ dodatkowego zysku, który jest teraz dodatkowym zyskiem dla zespołu na wieczór pod koniec projektu (po potwierdzeniu oszczędności były prawdziwe)

Zespół bibliotek byłby, jak podejrzewam, nad głową bez żadnych korzyści.

Jest to wspólny projekt, nad którym programiści pracują dla zabawy - żadna firma nie powinna polegać na programistach pracujących nad rzeczami we własnym czasie. To po prostu nieodpłatne nadgodziny i w każdym razie nie można na nim polegać, ponieważ prawdopodobnie będą duże okresy, w których nikt nie będzie chciał pracować.

Jeśli mówisz, że byliby to ludzie pracujący w firmie w czasie między projektami, może to może zadziałać, ale nadal nie sądzę, że to prawdziwy problem. Nadal musisz dowiedzieć się, jak zachęcić ludzi do korzystania z bibliotek. Jak powiedziałem, macie już rozwiązania tych problemów, które są opracowywane w każdym projekcie, waszym problemem jest to, dlaczego nie są one udostępniane.

To jest praca architekta .

Główne obowiązki architekta oprogramowania obejmują:

• Ograniczenie możliwości wyboru podczas programowania poprzez wybranie standardowego sposobu realizacji aplikacji
• tworzenie, definiowanie lub wybór struktury aplikacji dla aplikacji
• Rozpoznanie potencjalnego ponownego wykorzystania w organizacji lub aplikacji poprzez obserwację i zrozumienie szerszego środowiska systemowego
• Tworzenie projektu komponentu Posiadanie wiedzy o innych aplikacjach w organizacji

Przeczytaj więcej o: - Architekcie oprogramowania - Architekcie rozwiązań - Architekcie korporacyjnym .

Powiedzenie „ Jedzenie własnej karmy dla psów ” rozwiązuje ten problem. Jeśli twój najlepszy programista Rockstar rodzi bibliotekę, której nigdy nie używał w praktyce, jak mógł powiedzieć, że jest dobra?

Głównymi przyczynami rozwoju funkcjonalności w ramach są

1. Jest użyteczny dla programisty
2. Istnieje kilka przypadków, w których był użyteczny
3. Może być przydatny dla innych

Kiedy osiągniesz 2, funkcjonalność już tam jest, jak możesz przekazać ją komuś innemu?

Trochę się spóźniłem do gry, ale czułem, że nikt się tym nie zajmuje:

Twoje indywidualne zespoły, które rozwiązują różne problemy na różne sposoby, na pewno skorzystałyby ze wspólnej funkcjonalności, i istnieje wiele sposobów, aby uzyskać to w sposób, który nie poświęca ani jednego zespołu na jej rozwój, ale widziałem wiele miejsc, które to robią.

W większości przypadków uważam to za „rdzeń” twojej linii produktów, a czasem zespół jest odpowiedzialny za utrzymanie go pod przewodnictwem (jak sugerował Amir) architekta. W ten sposób zazwyczaj można znaleźć sposoby na wykorzystanie lub stworzenie frameworka zgodnego z najsurowszymi standardami ustanowionymi w organizacji, ale zapewniającego tylko najdelikatniejsze funkcje, które mogą, ale nie muszą, zostać rozszerzone na pełnoprawne aplikacje które oferują poszczególne zespoły produktowe. Dzięki temu możesz czerpać korzyści z „dogfoodingu” swojego podstawowego kodu, wdrażając go w każdym miejscu, w którym go używasz, a następnie rozgałęzić się na różne produkty, które mogą mieć zupełnie inne implementacje. Dzięki temu wszystkie Twoje zespoły mogą wnosić wkład do bibliotek podstawowych, ale nie pogarszają go funkcjonalnością, której tylko potrzebują.

sądzę, że to NIE jest DOBRY POMYSŁ , ponieważ aby biblioteki były przydatne, muszą pomóc ci rozwiązać rzeczywiste problemy z projektami, a poznajesz je tylko poprzez ... no cóż, pracę w prawdziwych projektach.

W przeciwnym razie możesz skończyć z „teoretycznie” bardzo dobrą biblioteką!

W jednej firmie, w której pracowałem, było naprawdę coś podobnego, nie wyglądało to dobrze. Ludzie w wewnętrznym zespole wpadli na ciekawy pomysł i wymyślili prototyp, który przeważnie działał, potem przeszedł on przez ścianę i oczekiwano, że zamienimy go w produkt.

Oczekiwałem, że tak się stanie, że grupa narzędzi zakończy pracę nad swoim małym programem, tworząc funkcje, które nie były tak przydatne, ale zaśmiecały interfejs API i były wystarczająco używane, aby nie można ich było łatwo wykorzystać. oddalony. Nie dokumentowaliby odpowiednio.

Jeśli grupa narzędzi była w wystarczającym stopniu pod opieką architekta systemu, który był w stałym kontakcie z osobami faktycznie używającymi narzędzi, może to działać. Jeśli grupa narzędzi często się obracała (co utrudniłoby przeprowadzenie wielu badań zewnętrznych), może działać. Jednak bałbym się utraty kontaktu z ludźmi wykonującymi płatną pracę.

Ile czasu poświęcisz na zastanawianie się, czy korzystanie z frameworku będzie korzystne we wszystkich przypadkach? Czy projekt opóźnia się, czekając na aktualizację frameworka? W pewnym momencie konieczne jest użycie frameworka, aby uzasadnić jego istnienie.