Czy wewnętrzny kod powinien być współdzielony z innymi programistami w organizacji?

Tam, gdzie pracuję, mamy wielu programistów i strasznie dużo kodu uruchamiającego nasze zastrzeżone aplikacje, z których korzystają zarówno pracownicy, jak i klienci.

Mamy też wielu inteligentnych pracowników pomocy technicznej, którzy lubią rozumieć wewnętrzne działanie naszych systemów, aby lepiej wspierać naszych klientów, a może nawet od czasu do czasu przesyłają łatkę.

Czy powinniśmy otworzyć nasz kod, aby nasi pracownicy niebędący programistami mogli czytać? Jakie czynniki należy wziąć pod uwagę przy podejmowaniu tej decyzji? Natknąłem się na wiele argumentów i kontrargumentów w każdym kierunku i chciałbym podjąć decyzję w oparciu o doświadczenia innych, a także dobrze rozumiane ryzyko.

Dotychczasowe argumenty:

• Hasła w VCS są ujawnione (rozwiązanie: pozbądź się haseł - na początku nie powinno ich być)
• Kod jest otwarty na ataki bezpieczeństwa białych skrzynek (kontrargument: chroni to tylko przed uczciwymi / leniwymi atakującymi)
• Personel pomocniczy może zapytać programistów „jak” rzeczy działają (przeciwdziałać: nauczyć człowieka łowienia itp.)

Czy ktoś otwiera kod dla pracowników swojej organizacji? Czy spowodował jakieś problemy?

Nie sądzę, że istnieje ogólna odpowiedź na to pytanie. Organizacje różnią się ogromnie wielkością, zasięgiem geograficznym, kulturą firmy, polityką praw autorskich, rodzajem tworzonego oprogramowania itp. Itp.

Na przykład dla firmy opracowującej oprogramowanie typu towar / infrastruktura otwarcie kodu źródłowego może być łatwe, nawet w celu jego otwarcia, tak jak Cisco kilka lat temu przy pomocy oprogramowania sterownika drukarki (IIRC).

Dla firmy opracowującej rzadkie zastrzeżone oprogramowanie, potencjalnie zawierające specjalne algorytmy lub inne rzeczy, które dają im przewagę konkurencyjną nad konkurencją, doskonale rozumiem, czy starają się zachować swój kod w tajemnicy. Np. AFAIK Google bardzo ściśle ogranicza liczbę osób, którym przyznano dostęp do swojej podstawowej implementacji algorytmu wyszukiwania.

Również organizacja międzynarodowa jest obecnie rozproszona w wielu krajach, strefach czasowych i kulturach, a ze względów bezpieczeństwa prawdopodobnie segmentują swój intranet i używają zapór ogniowych do kontrolowania ruchu między różnymi segmentami / domenami. Tak więc udostępnienie repozytorium SCM „całej firmie” może w rzeczywistości wymagać dużo dodatkowej pracy dla administratorów systemów i dodatkowego ryzyka bezpieczeństwa. Chociaż zwykle nie przynosi to żadnych korzyści, ponieważ pracodawcy pracujący na innym kontynencie, zajmujący się zupełnie innymi sprawami, prawdopodobnie nawet nie wiedzą o naszym projekcie tutaj, a tym bardziej pozytywnie.

Więc jeśli ma to sens w twoim dziale i / lub dla osób związanych z projektem w jakiś sposób, dlaczego nie. Ale ogólnie rzecz biorąc, ze względu na „otwartość” nie jestem pewien, czy warto.

Ostatnia uwaga: nawet jeśli ludzie wsparcia są sprytni i chętni do dodawania poprawek, powiedziałbym, że ich wkład powinien zawsze zostać sprawdzony przez programistę przed zintegrowaniem z systemem.

W większości organizacji, w których pracowałem, repozytorium kodu było otwarte dla wszystkich programistów.

W niektórych przypadkach był także używany do przechowywania dokumentów (takich jak specyfikacje i wymagania) w celu ich wersji wraz z oprogramowaniem. W takim przypadku większość innych pracowników również miała dostęp. Tam, gdzie repozytorium było używane tylko dla kodu, nie-deweloperzy zwykle nie mieli dostępu - ale nigdy nie słyszałem, żeby ktoś narzekał, więc prawdopodobnie nie była to żadna wielka sprawa.

Poleciłbym jak najwięcej otwartości - więc jeśli ludzie chcą dostępu, daj mu je, chyba że istnieje oczywisty problem. Ale to naprawdę kwestia kultury organizacji ...

Podzielam ogólny / pragmatyczny pogląd na ten temat i może również zależeć od charakteru pracy / organizacji. Uważam jednak, że baza kodu powinna być otwarta dla wszystkich (pokaże także otwartość i zaufanie w organizacji).

Pracuję również w podobnej konfiguracji, jak wspomniałeś, gdzie mamy zespół wsparcia / pomocy technicznej, który zajmuje się żądaniami klientów. Jednak niektóre złożone obszary systemu wymagają dodatkowej pomocy. W moim przypadku baza kodu jest otwarta na wszystko, z czym nie napotkaliśmy żadnych problemów.

• Myślę, że otwierając bazę kodu, inni chętni członkowie zespołu wsparcia mogą również sprawdzić bazę kodu i zapoznać się z regułami biznesowymi / obszarem, którymi są zainteresowani lub muszą znaleźć odpowiedzi (i ewentualnie poprawić swoje zrozumienie techniczne i patrzeć na coś inaczej niż monotonna rutyna, jeśli czas na to pozwala;)). Może się to również przydać, gdy członkowie zespołu wsparcia otrzymają problemy z klientami i logi i będą mogli wskazać / pomóc w możliwych obszarach kodu, gdzie dzieje się to, patrząc np. Na stacktrace (oczywiście będzie to zależeć od problemu itp.). Zaoszczędzi to również czas z deweloperem, ale oczywiście w zależności od problemu.

Pomoże również posiadanie aktualnej dokumentacji / wiki produktu, która zawiera wszystkie reguły / decyzje biznesowe. Ale oczywiście musisz upewnić się, że wiki jest stale aktualizowana, aby udoskonalać nowe ulepszenia i / lub poprawki błędów (w przypadku zmiany zachowania). Moje szczere myśli

Ogólnie rzecz biorąc, z punktu widzenia organizacji - ludzie przychodzą i odchodzą; projekt (lub produkt) musi nadal ewoluować. Dlatego w większości organizacji istnieje zwykle Otwarte na wszystkie repozytoria do obsługi kodu.

Zwykle istnieją prawa dostępu itp., Aby zapobiec niezauważonemu nieautoryzowanemu dostępowi (aby zapobiec kradzieży kodu itp.), Ale większość wyższych ulepszeń nie jest tak naprawdę zablokowana. W organizacji należy ufać ludziom (wystarczająco), aby można im było zaufać za pomocą kodu. Ukrywanie kodu przed pracownikami (lub współpracownikami) jest świetnym czynnikiem motywującym.

W naszej organizacji nawet wtedy, gdy ludzie tak naprawdę nie wnoszą wkładu w kod - mają bezpośredni dostęp do kodu, który pomaga, ponieważ próbują walczyć / naprawiać problemy w terenie (z własnością), a nie wyrzucać rzeczy z powrotem do programisty i iść spać!