Czy pracowaliście kiedyś z wewnętrznymi firmowymi frameworkami? Mam tu na myśli jakieś biblioteki zawierające implementacje interfejsów z warstwy infrastruktury czy kontrolki UI gotowe do użycia. Taki framework narzuca zazwyczaj jakąś "dobrą" architekturę projektu i ma umożliwiać szybkie wystartowanie z projektem. Co sądzicie o takich frameworkach? Są używane obecnie, czy może firmy obecnie piszą projekty raczej od 0 w czasach .NET Core?
0
2
nobody01 napisał(a):
Czy pracowaliście kiedyś z wewnętrznymi firmowymi frameworkami? Mam tu na myśli jakieś biblioteki zawierające implementacje interfejsów z warstwy infrastruktury czy kontrolki UI gotowe do użycia. Taki framework narzuca zazwyczaj jakąś "dobrą" architekturę projektu i ma umożliwiać szybkie wystartowanie z projektem. Co sądzicie o takich frameworkach? Są używane obecnie, czy może firmy obecnie piszą projekty raczej od 0 w czasach .NET Core?
"Wewnętrzny framework" nie brzmi zbyt dobrze, natomiast jeżeli chodzi o implementacje czegoś niskopoziomowego to nie widzę problemu. A jeżeli chodzi o kontrolki UI to DevExpress ma coś takiego, i nie jest to też żaden dramat. Ale jeżeli jest to bardziej rozbudowane niż te dwie rzeczy, to to może być problem (np. implementacja nisko poziomowa + kontrolki UI gotowe do kopiuj wklej), bo to będzie znaczyło to, że będziesz pewnie to konkretnie rozwijał i tylko tego używał zamiast w tym wypadku pisać coś od 0.
3
Wewnętrzne frameworki to zło. Zero dokumentacji, nikłe możliwości poszukania czegoś w Internecie, no bo przecież wszystko zostało napisane przez firmę. Makabra, nie polecam.
1
tak sobie wyobrażałem pracę programisty kiedy zaczynałem. wydawało mi się że firmy mają przewagę nad freelancerami bo mają wypracowane własne narzędzia i frameworki przyspieszające pracę. no więc okazało się w praktyce że nie bardzo - prędzej mają narzucone limity i nie można nawet swobodnie korzystać z tego co się znajdzie w necie.
pracowałem w dwóch firmach które miały swoje "frameworki" - w pierwszej to była biblioteka... nie aktualizowana od wielu lat odkąd odszedł programista który ją wymyślił. procedura zmiany czegoś w tej bibliotece była skomplikowana i ogólnie to lepiej nie ruszać bo wszystkie projekty są o nią oparte i jak chcesz czegoś to rób workaroundy (czyli najlepiej przeklej kod do swojego programu i go tam popraw).
druga firma miała zdrowsze podejście - stworzyła swój framework będący nakładką na istniejący, ale stworzyła wokół niej pewną społeczność i udostępniła na zasadach open source na githubie. oczywiście nadal przechodzą głównie pull requesty od pracowników ale wsparcie nie jest całkiem zerowe jak w przypadku zamkniętego wewnętrznego frameworka
1
Pracowałem w dwóch firmach mających swój framework.
W pierwszej to było całkiem fajne narzędzie które pozwalało szybko utworzyć aplikację (CRUD oczywiście) bazując na generykach i konwencjach, jednocześnie było bardzo elastyczne jeśli trzeba było dodać jakiś element czy cały bardziej rozbudowany ficzur w zupełnie inny sposób. Napisałem sobie później coś podobnego.
W drugiej natomiast... Tu już wolę nic nie pisać...
1
@var: coś jak https://github.com/dwdkls/pizzamvc? :P
0
Tak, narzędzie tego typu
1
nobody01 napisał(a):
@var: coś jak https://github.com/dwdkls/pizzamvc? :P
To może być fajne, zaznaczyłem sobie. Brakuje mi w .NET pewnego rodzaju "demokracji" (w por. do Javy) głównie co do rozwiązań architektonicznych alternatywnych do MS/Oracla
1
Litości, kto w tych czasach jeszcze używa MVC?
Co do demokracji, to jest masa alternatyw dla rozwiązań MS w każdej dziedzinie: IoC, ORM, logowanie, konfiguracja, walidacja, dokumentacja...
Demokracji to nie ma raczej w Javie, tam 95% pracy to jakiś Spring.
Co do wewnątrz firmowych framoworków, to problemy są dwa:
- To nie są frameworki tylko wrappery, które tak naprawdę limitują funkcjonalność tego, co mają pod spodem nie dając niczego w zamian, czyli tak naprawdę utrudniają pracę, bo nie da się korzystać normalnie z dobrze znanej biblioteki, tylko trzeba się ograniczyć do tego, co zapewnia ten firmowy framework.
- Są w założeniach megakonfigurowalne, czyli framework potrafi zrobić wszystko, programista musi tylko napisać konfigurację, np. w trzymanym w bazie XML, z którego później framework renderuje GUI, walidację, procesy biznesowe, i w końcu zapis klienckich danych do bazy.
Ekstremalny przypadek takiego drugiego frameworka miałem okazję obserwować z dość bliska. Nie przeczę, że był megakonfigurowalny, ale to niczego nie dawało, bo praktycznie co chwilę jakiś klient przychodził z potrzebą, której nie przewidzieli twórcy frameworka. Czas dodania czegokolwiek we frameworku to np. pół roku, oczywiście klient tyle nie mógł czekać, więc programiści, którzy mieli "tylko konfigurować" tak naprawdę mieli 3 razy więcej roboty, bo musieli hackować framework.
Framework poza tym umiał wszytko - oprócz walidacji na backendzie, więc jakby ktoś wysłał sobie request pomijając GUI, to mógł dowolne dane do bazy wstawić i rozpieprzyć system.
Takie frameworki prowadzą do śmieszny patologii, np. niektórzy klienci tej firmy stwierdzili, że zamiast czekać na poprawki zreversują kod i wprowadzą swoje zmiany. Śmiesznie było, gdy później zgłaszali jakieś bugi, a support nie był w stanie ich odtworzyć, no bo przecież nie mieli kodu z ich zmianami.
1
Wewnętrzny framework ma sens, gdy jest traktowany jak pełnoprawny produkt, czyli jest osobny zespół pracujący nad jego wsparciem (i nie tworzą go ludzie z "bencha"). Wiele "prawdziwych" frameworków tak zaczynało. Ale jeżeli nie ma zespołu, ludzie ciągle się zmieniają, a poprawki są wprowadzane raz na pół roku, to nie ma to sensu i tylko utrudnia życie.
Czasami można trafić na śmieszne oferty pracy, na przykład VSoft z Krakowa ma VSoft Business Platform, który wdrażają w różnych bankach, a potem firmy szukają ludzi znających to oprogramowanie, chociaż jest praktycznie w całości wewnętrzne.