Czy złe praktyki programistyczne są typowe w branży oprogramowania? [Zamknięte]

Właśnie zacząłem swoją pierwszą pracę jako programista ponad miesiąc temu. Wszystko, czego dowiedziałem się o OOP, SOLID , DRY , YAGNI, wzorach projektowych, SRP itp. Można wyrzucić przez okno.

Używają formularzy internetowych C # .NET i robią prawie wszystko w ramach kodu za pomocą bardzo niewielu zewnętrznych klas, zdecydowanie nie nazywanych obiektami. Używają niestandardowych formantów i ponownie ich używają. Jedyne używane obiekty to Entity Framework . Ponownie wykorzystują kod za każdego klienta. Mają metody o długości 400 linii, które wykonują wszystkie rodzaje rzeczy. W przypadku nowych klientów biorą aspx i aspx.cs, usuwają kod klienta i zaczynają dodawać nowy kod specyficzny dla klienta.

Ich pierwszą wymówką byłoby dodanie dodatkowej konserwacji, a więcej kodu to więcej konserwacji. To mały sklep z trzema programistami, w tym mną. Jeden programista ma ponad 30-letnie doświadczenie, a drugi ma ponad 20-letnie doświadczenie. Jeden był twórcą gier, a drugi zawsze działał w C i C ++.

Jak często występuje to w branży oprogramowania? Jak mogę się upewnić, że jestem na bieżąco z OOP i powiązanymi zasadami? Ćwiczę w wolnym czasie i czuję, że naprawdę muszę pracować pod kierunkiem bardziej doświadczonego programisty, aby być lepszym w OOP.

1. Zasady, które zacytowałeś w swoim pytaniu, są po prostu… zasadami. Nie są to mandaty, prawa ani nakazy.
2. Chociaż ludzie, którzy wymyślili te zasady, są bardzo mądrzy, nie są jednak absolutnymi autorytetami. Są tylko ludźmi oferującymi swoje spostrzeżenia i wskazówki.
3. Nie ma „poprawnego” sposobu programowania. Dowodzi tego fakt, że „przyjęty” sposób, w jaki to robimy, zmienił się i zmienia się radykalnie z czasem.
4. Wysyłka produktu często ma pierwszeństwo przed robieniem go „we właściwy” sposób. Jest to tak powszechna praktyka, że ​​ma nazwę: dług techniczny.

5. Niektóre powszechnie stosowane architektury oprogramowania nie są idealne. Najlepsze praktyki ewoluują od dużych monolitycznych aplikacji w kierunku luźno połączonych kolekcji modułów.

6. Kontekst jest ważny. Wiele zasad architektonicznych sprawdza się tylko wtedy, gdy pracujesz z dużymi programami lub określonymi domenami. Na przykład dziedziczenie jest najbardziej przydatne w przypadku hierarchii interfejsu użytkownika i innych struktur korzystających z głęboko zagnieżdżonych, ściśle powiązanych konfiguracji.

Jak więc podążać „właściwą” ścieżką, ścieżką opartą na zasadach, abyście mogli wyjść z dziczy?

1. Studiuj stosowność, a nie poprawność. „Właściwy” sposób na zrobienie czegokolwiek w rozwoju oprogramowania to taki, który najskuteczniej spełnia określone wymagania.
2. Studiuj kompromisy. Wszystko w tworzeniu oprogramowania jest kompromisem. Czy chcesz więcej prędkości lub mniej pamięci? Czy chcesz mieć bardzo ekspresyjny język programowania z niewielką liczbą praktyków, czy też mniej ekspresyjny język, który zna wielu programistów?

3. Studiuj ponadczasowość. Niektóre zasady przetrwały próbę czasu i zawsze będą istotne. Systemy typów są uniwersalne. Funkcje pierwszej klasy są uniwersalne. Struktury danych są uniwersalne.

4. Naucz się pragmatyzmu. Ważna jest praktyczność. Matematyczna czystość, architektura kryształowej katedry i zasady wieży z kości słoniowej są bezużyteczne, jeśli nie możesz wysłać.

5. Bądź rzemieślnikiem, a nie fanatykiem. Najlepsi programiści to ci, którzy znają reguły, a następnie wiedzą, jak je złamać, gdy ma to sens. To oni wciąż wiedzą, jak rozwiązywać problemy i myśleć sami. Używają zasad, aby informować i kierować ich wyborami, a nie dyktować im.
6. Napisz kod. Dużo tego. Zasady projektowania oprogramowania są przedwczesnymi optymalizacjami, dopóki nie napisałeś dużo kodu i nie rozwinąłeś instynktu prawidłowego stosowania.

To nie jest niespotykane. Należy zdać sobie sprawę, że przemysł oprogramowania jest niezwykle różnorodny. Niektóre firmy są nowatorskie. Czołowe uniwersytety i innowacyjne firmy produkujące oprogramowanie (nawet niektóre duże laboratoria!), A także błogosławione osoby lub grupy, takie jak czteroosobowy gang, analizują problemy występujące przy powszechnych sposobach robienia rzeczy i wymyślają nowe języki, maszyny, narzędzia i wzorce. Nowe firmy, często spin-off lub off-off, starają się wykorzystywać je komercyjnie, a czasem odnoszą niesamowity sukces. Pomyśl o Facebooku lub Google.

Ale oprogramowanie jest obecnie używane prawie wszędzie, być może głównie w firmach, które w rzeczywistości nie są firmami zajmującymi się oprogramowaniem. Pracowałem głównie w branży transportowej (motoryzacyjnej i kolejowej), a doświadczenie jest zróżnicowane. Ale żaden z nich nie był tak blisko „najnowocześniejszych”. Czasami nie mogą być; oprogramowanie związane z bezpieczeństwem zależy od dobrze sprawdzonych narzędzi (obecnie używamy sprawdzonego kompilatora C ++ z lat 90.). Czasami nie mają odpowiednich ludzi. Często oprogramowanie jest opracowywane przez inżynierów z innych dziedzin, którzy akurat wpadli w rozwój oprogramowania w swojej firmie, gdy oprogramowanie stało się coraz ważniejsze. Nie można oczekiwać, że znają lub stosują zasady inżynierii oprogramowania.

Kolejną rzeczą do rozważenia jest to, co jest ważne w inżynierze w prawdziwym świecie. Często zadaniem jest dosłownie nauka rakietowa. Problemy związane z chlebem i masłem w firmach niezwiązanych z oprogramowaniem można rozwiązać za pomocą skromnych środków programowych. To, co czyni użytecznym, być może nawet dobrym inżynierem oprogramowania, jest po części tym, co czyni dobrego inżyniera ogólnego: Bądź wiarygodny; odpowiedzialnie organizuj i dokumentuj swoją pracę; współpracować; sporządzać dobre oszacowania kosztów i czasu (ważność oszacowania jest ważniejsza niż faktyczny koszt i czas!); zrozumieć, co możesz, a czego nie możesz zrobić. Wyraźnie brakuje tutaj „znać i korzystać z najnowocześniejszych narzędzi i procedur”. Opisujesz firmę, która ustanowiła zestaw narzędzi i proces, który działa dla nich. Prawdopodobnie nigdy nie wyprodukują niczego seksownego ani niezwykłego, ale spełniają wymagania klientów wystarczająco dobrze, aby generować stały strumień wystarczających przychodów. To może być definicja inżynierii ;-).

Więc tak: to, czego uczysz się na uniwersytecie, w rzeczywistości nie jest powszechne w wielu dziedzinach.

Chcę dodać pociechę lub bardziej optymistyczną notatkę. Czego się nauczyłeś, nie należy wyrzucać przez okno. Możesz stosować lepsze zasady w swojej codziennej pracy, gdy nic nie psuje. Być może pojawi się okno z okazją do wprowadzenia nowego narzędzia lub wzoru projektu. Szanse są najlepsze, gdy stary sposób robienia rzeczy jest nieprzyjemny dla kolegów lub gdy napotkają problemy z zarządzaniem złożonością lub utrzymaniem (dwa najbardziej zjadliwe problemy rozwiązane przez innowacje). Przygotuj się na oferowanie ulepszeń, gdy będzie taka możliwość. Wywieraj pozytywny wpływ i stopniowo ulepszaj metody i narzędzia; rozpowszechniać wiedzę tam, gdzie jest to doceniane.

Używają formularzy sieciowych C # .Net i robią prawie wszystko w ramach kodu za pomocą bardzo małej liczby klas zewnętrznych

Oto twoje wyjaśnienie. Jeśli nie jesteś świadomy, gotowy do użycia kod formularzy sieci Web jest prawie biegunowym przeciwieństwem OOP, SOLID, DRY, YAGNI, wzorców projektowych, SRP itp. Nawet oficjalne przykłady Microsoftu sprzed kilku lat sprawiłbyś, że dziś się kulisz.

Formularze internetowe pchają się w kierunku proceduralnych, a niektóre fałszywe „zdarzenia” są wywoływane przez kliknięcia kontrolne i tym podobne. Deweloperzy, którzy spędzili dużo czasu na tworzeniu formularzy internetowych, również zwykle wydają się niechętni, aby z nich zrezygnować, prawdopodobnie dlatego, że poświęcili tyle czasu na naukę cyklu życia strony i jak wykonywać dynamicznie renderowane kontrolki, że nie chcą teraz wyrzucać tej wiedzy w obliczu nowszych / lepszych metod. Nieprzytomna wersja błędnego kosztu. Ci deweloperzy spędzili lata ucząc się, jak wymyślać formularze internetowe, a teraz nie będą łatwo odchodzić od tej wiedzy, stąd ich rozmowa na temat czasu „konserwacji”.

Jest to dość powszechne w przestrzeni .NET Web Forms, przy okazji.

Jak często występuje to w branży oprogramowania?

Bardzo powszechne. Mniej więcej tak samo często, jak hydraulik niszczy instalacje, cieśla dostarczający śmieci lub tani krawiec robiąc źle dopasowany garnitur. Tj. To wszystko ludzkie.

Jest dobry powód, dla którego tak się dzieje: ludzie, którzy nie są tak naprawdę przeszkoleni (lub nie entuzjastycznie nastawieni), muszą wdrożyć coś pod presją.

Nie jest to przede wszystkim problem tych ludzi, ale zwykle struktur otaczających rozwój oprogramowania w tej firmie. Na przykład firma może mieć stażystów opracowujących wewnętrzne oprogramowanie; nawet jeśli stażyści są bystrzy i kompetentni, będą tam tylko przez kilka tygodni lub miesięcy, a własność często się zmienia.

Lub osoba, która jest świetna w tej dziedzinie, ale nie jest programistą, może zhakować trochę aplikacji VBA itp., Ponieważ na początku wydaje się to dość łatwe.

Lub dobrze wykonana aplikacja kończy się w fazie konserwacji, wszyscy dobrzy programiści przechodzą dalej, a następnie jest rozwijana przez kilka osób (w najgorszym przypadku: jedna), które niewiele o niej wiedzą, nie mają dokumentacji itp.

Jak mogę się upewnić, że jestem na bieżąco z OOP i powiązanymi zasadami? Ćwiczę w wolnym czasie i czuję, że naprawdę muszę pracować pod kierunkiem bardziej doświadczonego programisty, aby być lepszym w OOP.

Istnieją dwie możliwe odpowiedzi:

• Albo: przedyskutuj to ze swoim szefem i upewnij się, że zajmujesz się czystymi projektami. Jeśli nie jest to możliwe, znajdź nowego szefa.
• Lub: sam weź na siebie odpowiedzialność. Oznacza to robienie tego samemu - w wolnym czasie lub, jeśli możesz, w firmie, ale kierujesz się sobą (mało prawdopodobne).

Jeśli druga odpowiedź brzmi dla ciebie zbyt cynicznie, to zapewniam cię, że nie jest. Stolarz, który ma stolarnię w domu będzie najbardziej pewno będzie lepiej niż cieśla kto nie.

Na przykład, jest absolutnie możliwe i dla niektórych osób dużo zabawy, np. Kopać w nowym języku, takim jak Ruby, uczyć się nie tylko składni, ale także zgłębiać specjalne aspekty OO tego języka i naprawdę nurkować głęboko. Wszystko w wolnym czasie, bez żadnego związku z pracą. Będzie to po prostu hobby, ale będąc wyszkolonym profesjonalistą, którym jesteś, może być równie skuteczne (lub bardziej), jak siedzenie obok jakiegoś wiodącego programisty i próbowanie śledzić, co robią. Będzie to wtedy wyłącznie dla twojego osobistego rozwoju i twojej zabawy. Jeśli nie sprawia ci to przyjemności lub jeśli okaże się, że po prostu nie możesz osiągnąć zrozumienia, zdrap to i wróć do pierwszej odpowiedzi.

Że głównym programistą, który trenuje was ma całkiem prawdopodobne, że rzeczy nauczyłem się w dokładnie taki sposób ...

Myślę, że w Hiszpanii jest to stałe, ponieważ gdy deweloper spędza wiele lat w firmie, zwykle (lub ona) awansuje do innych obszarów zarządzania, takich jak analiza i zarządzanie projektami. W rezultacie nie jest przeprowadzana żadna recenzja, a kod jest zwykle pisany przez mniej doświadczonych ludzi.

Awarie tych doświadczonych ludzi nigdy nie są korygowane: ich jedynym celem jest wykonanie pracy. W rezultacie w kodzie gromadzi się coraz więcej niewłaściwych praktyk.

W końcu jakiś inteligentny tyłek mówi, że najlepszym „rozwiązaniem” jest przejście na powstającą technologię, która wygeneruje czystszy i łatwiejszy w utrzymaniu kod, tworząc nową aplikację. Jakby sama technologia mogła to zrobić.

Znów niedoświadczeni programiści pracują w tej nowej technologii, nikt nie przegląda kodu, a krąg jest ponownie zamknięty ... na zawsze i na zawsze ...

Niektóre z „najlepszych praktyk”, których uczysz się w szkole, nie są praktyczne ani opłacalne w rzeczywistych projektach. Jedną z największych zmian, które zauważyłem, było formatowanie i komentarze. Większość moich profesorów podkreślała znaczenie obszernego dokumentowania twojego kodu, ale w prawdziwym świecie dobry kod jest często (nie zawsze!) Objaśniający, a co ważniejsze, wielu szefów nie chce płacić za to, że spędzasz dodatkowy czas na pisaniu komentarze

Czasami zobaczysz programistów, którzy są naciskani na czas za pomocą skrótów i anty-wzorów, które wymagają mniej płyty kotła niż rozwiązania wysokiej jakości.

Jednak jednym z największych problemów, które zauważyłem w wielu zespołach i projektach, jest niechęć do uczenia się nowych rzeczy. Wielu starszych programistów, z którymi rozmawiałem, zaczynało swoją karierę w okresie inżynierii oprogramowania na „dzikim zachodzie”, kiedy kwalifikacje zaczynały się i kończyły z chęcią pisania kodu. Często specjalizowali się w zupełnie innych dziedzinach i skakali do programowania z niewielkim wykształceniem lub bez formalnego wykształcenia, gdy pojawiła się okazja (np. Ich pracodawca nie miał programisty i potrzebował kogoś do nauki, aby zbudować oprogramowanie wewnętrzne). Niektórzy z tych old-schoolowych samouków programiści nigdy nie starają się nauczyć nowoczesnych praktyk kodowania i nadal kodują mniej więcej w takim stylu, jakiego nauczyli się dekady temu. Kiedy ze względu na starszeństwo kończą jako odpowiedzialni za nowe projekty, zwykle wstrzymują projekty i szkodzą ogólnej jakości kodu.

Oczywiście powyższe nie dotyczy wszystkich starszych programistów, a kodery nowej generacji mogą być równie winne. Pracowałem z wieloma młodszymi programistami, którzy wybrali kilka narzędzi i bibliotek świeżo po studiach, a potem przestali się całkowicie uczyć. Raz pobiorą IDE lub bibliotekę i nigdy go nie aktualizują, chyba że ich firma tego wymaga (czasem można zgadnąć, w którym roku programista ukończył studia na podstawie tego, jak nieaktualne są jego biblioteki). Nie nadążają za nowymi funkcjami w wybranym przez siebie języku (językach) i nigdy nie uczą się nowych języków. Nie uczą się nowych strategii programowania i mogą niewłaściwie wykorzystywać wzorce lub paradygmaty, ponieważ nie znają bardziej odpowiednich alternatyw (o MVC, jak bardzo jesteś nadużywany). Z biegiem czasu ich przepływ pracy staje się coraz bardziej przestarzały i stają się bardziej zobowiązaniem niż aktywem.

Podsumowując, dwie największe przyczyny niechlujnych baz kodowych to przyspieszone terminy i programiści z nieaktualną lub niepełną wiedzą. Niestety odpowiedzialność za obie kwestie może w dużym stopniu spoczywać na szefie lub CTO, który musi dopilnować, aby terminy były realistyczne, a personel był na bieżąco ze swoją wiedzą i umiejętnościami. Jeśli szef nie wie nic o dobrych praktykach programistycznych, najlepiej możesz zasugerować zmiany i mieć nadzieję, że będą otwarci na sugestie. Niestety mogą być skłonni zaufać słowu starszego programisty, który nie rozumie OOP i lubi pisać 10 000 klas linii.

Niektóre z złych praktyk programistycznych wynikają z konieczności pracy ze starszym oprogramowaniem, które rozpoczęło tworzenie dekad temu. Jeśli istnieje bardzo złożone oprogramowanie, przepisywanie wszystkiego może nie być opcją. Może być nawet niezwykle trudno zrozumieć wszystko, co faktycznie robi kod. Najlepszą opcją może być po prostu skopiowanie tego, co działa, a także próba zintegrowania lepszych praktyk programistycznych, jeśli możesz to zrobić bez niczego.

Myślę, że ważne jest, aby nie odróżniać dobra od zła, ale znać przyczyny każdego dobra i zła. Kiedy znasz powody, możesz przewidzieć konsekwencje. Po co stosować tę lub inną zasadę nie dlatego, że została opisana w książce, ale dlatego, że wiemy, jak to pomaga i co dokładnie się dzieje, powinniśmy ją złamać. Jeśli wiesz, co się wtedy stanie, możesz zważyć zalety i wady i podjąć decyzję. Pomoże to również za każdym razem argumentować swoją pozycję. SOLID i OOP mogą również ograniczyć konserwację, jeśli są dobrze stosowane.

SOLID, jeśli jest stosowany zbyt dogmatycznie, prowadzi do zbyt wielu klas i metod, co nie jest aż tak dobre. Nie przesadzaj. Jest to po części duży problem z naszymi podręcznikami i samouczkami, ponieważ często próbują promować pomysły bez odpowiedniego uzasadnienia. OOP ma również swoje wady. Wiele zasad i paradygmatów jest ze sobą sprzecznych. Nie musisz być na szczycie, musisz uczynić wszystko rozsądnym, uzasadnionym, eleganckim i prostym.

Ponieważ jest to Twoja pierwsza praca, istnieje duże prawdopodobieństwo, że programiści nie są zbyt wykwalifikowani. Ale z drugiej strony zapewne ufają im niezbyt trudne zadania, które można wykonać bez tak dużych umiejętności i za niższe wynagrodzenie przez mniej wykwalifikowanych, tańszych programistów. Tak działa ekonomia. Każde miejsce pracy jest inne.

Rozumiem jak się czujesz. Nie panikuj . Będziesz potrzebował tego, co wiesz, może nie od razu, ale to ci pomoże. Może w innym miejscu pracy, może przy niektórych okazjach. Masz przed sobą czas na pójście dalej.