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

140

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.

Ponury
źródło
Otworzyłem dyskusję na temat tytułu na czacie: chat.stackexchange.com/transcript/message/40126879#40126879 Dołącz do mnie.
dcorking
1
Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
World Engineer

Odpowiedzi:

263
  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.
Robert Harvey
źródło
1
Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .
yannis
Gdzie mogę systematycznie uzyskiwać te informacje o tym, że nie mam żadnych wskazówek?
Ooker
4
Nie tylko rozumiem, jaka jest najlepsza praktyka, ale jakie są wymierne korzyści z najlepszej praktyki. Pozwala połączyć najlepszą praktykę z właściwością, a także zapewnia skuteczność w stosowaniu praktyki, aby uzyskać najlepszy efekt. Jeśli tylko recytujesz, że najlepsza praktyka prowadzi do „rozdzielenia obaw”, prawdopodobnie nie możesz być pewien, że wybierasz właściwy sposób czerpania korzyści z praktyki.
AaronLS
51

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.

Peter A. Schneider
źródło
2
@nocomprende: no entiendo ... Czy masz na myśli, że to, co wspólne, jest częstsze, a to, co niezwykłe, jest niestety niezwykłe? Czy to, co wspólne, nie jest wyjątkowo dobre? No tak.
Peter A. Schneider,
3
„To, czego uczysz się na uniwersytecie, w rzeczywistości nie jest powszechne w tej dziedzinie” - To wydaje się być kluczem ...
Brian Knoblauch,
1
Chodziło mi tylko o to, że w dziedzinie oprogramowania znajdują się ludzie z pełnym zakresem ludzkich umiejętności, pełen zakres wiedzy specjalistycznej, firmy mają pełny zakres gotowości, pełen zakres problemów i tak dalej, jak reszta świata. Oprogramowanie nie różni się pod tymi względami od innych dziedzin. Problem mógł zostać postawiony w dowolnej witrynie SE.
1
„oprogramowanie związane z bezpieczeństwem zależy od dobrze sprawdzonych narzędzi (obecnie używamy sprawdzonego kompilatora C ++ z lat 90.)” brzmi dla mnie całkiem nowocześnie!
Hovercouch
1
@ PeterA.Schneider to był głupi żart o tym, jak najnowocześniejsze jest sprawdzanie narzędzi. ;)
Hovercouch
16

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.

Graham
źródło
6
Miło jest zająć się stosem technologii, o którym mowa
jasonoriordan
5
Kto chce przejrzeć 20 klas zagnieżdżających się i wywołujących, aby dowiedzieć się, co się stanie, gdy zaznaczysz lub odznaczysz pole wyboru? Tylko szaleni ludzie lub ludzie, którzy uważają profesorów uniwersyteckich za bogów.
developerwjk
1
W rzeczywistości, gdy utworzono WebForm, standardowe praktyki branżowe były różne (lub nie istniały), a już istniejące aplikacje nigdy nie otrzymują refaktoryzacji, gdy „nowy fajny sposób robienia rzeczy” zaczyna być przyjmowany. Dlatego widzisz dużo kodu WebForm zaśmieconego bałaganem. Zasady programowania są oderwane od stosu technologii, którego używasz, dzięki czemu można je stosować nawet w WebFormach, Cobolu, asemblerze, cokolwiek.
BgrWorker
1
Tak to prawda. Ile MB miał Twój ViewState? Dziwne, myślę, że kontrole po stronie serwera zachęcały logikę biznesową do interfejsu użytkownika. Jednak programista był bardzo winny, że chętnie poszedł w parze z kultowym ładunkiem programistycznym asp.net. Zatem: tak wiele zdarzeń, że obiekty biznesowe nie mogły uzyskać prawidłowego stanu. Autobus. obiekty nie mogły się nawzajem wywoływać z powodu sprzężenia interfejsu użytkownika. Następnie: och, patrz Mo! Możemy pracować „bez połączenia!” nyuck, nyuck, nyuck. Rzeczywista ilość danych sprawiła, że ​​Twoja aplikacja się zatrzymała, ponieważ klasy asp.net udawały silnik bazy danych. Ale oszczędzaliśmy połączenia przed zużyciem!
radarbob
1
Cała ta reguła jest prawdziwa ... serce niezwykle prawdziwe. Widziałem tak wiele z tego, co opisano w tym poście dotyczącym aplikacji WebForms, że mam wrażenie, że te aplikacje są niewiele lepsze niż niektóre skrypty PHP zrzucone razem przez licealistę napiętego na napoje energetyczne - i zostało uznane za oprogramowanie dla przedsiębiorstw!
Greg Burghardt,
12

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 ...

AnoE
źródło
2
Dlatego zatrudniaj tylko dobrze wykwalifikowanych, w pełni przeszkolonych i entuzjastycznych ludzi, którzy robią ... cokolwiek, wszystko. Dlaczego tego nie robimy? Nasuwa się pytanie: jak mają żyć ludzie niewykwalifikowani, niewykształceni i mało entuzjastyczni? Charles Dickens podał odpowiedź na to pytanie: niezbyt dobrze, jeśli w ogóle.
@nocomprende, wyświetlasz swoją opinię, nie sugerowałem w żaden sposób tego, co napisałeś. Wyjaśniam powody tego, co zauważył PO.
AnoE
Ja po prostu przestać myśleć o pytaniu Kurta Vonneguta od was Bóg błogosławi panie Rosewater : „Co u diabła są ludzie, dla ?”
2
@nocomprende, jeśli mówię o „nieprzeszkolonej osobie”, nie mówię, że ludzie są głupi, mówię, że z jakiegokolwiek powodu osoba wykonała pracę, która nie była dobrze wyszkolona do tej pracy. Może to być wina jego menedżera za to, że dał mu niewłaściwą pracę; lub z okoliczności (np. zachorowanie współpracownika) lub z wielu powodów, jakie możesz sobie wyobrazić. Nie ma to nic wspólnego z sugerowaniem, że powinniśmy zatrudniać tylko wspaniałych ludzi. Jeśli będę musiał naprawić instalację wodno-kanalizacyjną w moim domu, możesz być całkiem pewien, że zrobię bałagan, chociaż jestem świetny we wszystkim, co mógłbym zrobić.
AnoE
1
Antropologia ma stary pogląd, że społeczeństwa niewolników, takich jak starożytni Egipcjanie, czerpią znacznie mniej ludzi niż społeczeństwa, które pomagają ludziom „się rozwijać”. Właśnie dlatego kapitalizm był lepszy niż kultura średniowieczna. Idealnie byłoby, gdyby każdy był w stanie rozkwitnąć, a wtedy otrzymalibyśmy pełną korzyść każdej osoby, a każda osoba czerpałaby pełne korzyści społeczne. Kapitalizm nie jest wystarczająco dobry, aby to zapewnić, dlatego potrzebujemy czegoś więcej. Dowód jest taki, że ludzie wykonują mniej niż optymalną pracę, ponieważ gdyby kapitalizm był doskonały, nie byłoby to możliwe.
11

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 ...

Raul Luna
źródło
16
Nie ma nic wspólnego z Hiszpanią. Jest to zasada Piotra - ludzie awansują z miejsc, w których dobrze sobie radzą, dopóki nie osiągną pozycji tam, gdzie ich nie mają, i utkną tam, ponieważ nie ma dla nich żadnej promocji.
Jan Hudec
3
Istnieje również fakt, że branża oprogramowania wciąż się rozwija, więc osoby o stosunkowo niewielkim doświadczeniu są liczniejsze. I że w wielu firmach nie ma w ogóle żadnych doświadczonych ludzi, ponieważ są nowi i zbyt tani, aby zatrudnić weterana, myśląc, że zrobi to kilka zielonych koni z uczelni - nie zrobią tego.
Jan Hudec
1
@ JanHudec Nie wiem, człowieku, czuję, że wolałbym mieć świeżo upieczonego ucznia z college'u niż kogoś z ponad 20-letniego doświadczenia ludzi, o których mówi oryginalny plakat
Mikey Mouse
9
@MikeyMouse, prawda, istnieje wiele osób, które nie mają 20-letniego doświadczenia, ale raczej 20 razy 1-letnie doświadczenie. I oznaczają naprawdę duży problem.
Jan Hudec,
„.. zasada Piotra ..”; szczególnie w agencji rządowej, w której jest to bardziej świadome zjawisko. Nazywam to Programem Inbredu Zarządzania. Podczas gdy często występuje równowaga dobrych / złych koderów, grozą jest, gdy MIP wymusza niekompetencję. Lata później, kiedy ci pewni jr. programiści są teraz szefami dywizji, którzy z kolei nie będą promować nikogo lepszego niż oni, dobrzy ludzie i pomysły odejdą lub zostaną wypchnięci. Sklep stał się koszykiem przypadków niekompetencji; utknął w „nastawieniu na promieniowanie resztkowe” programowania na komputerach mainframe w kulturze, w której można się dogadać.
radarbob
7

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.

użytkownik45623
źródło
19
Naprawdę nie podoba mi się ten mit, że dobry kod jest oczywisty, a komentarze są przestarzałe. W najlepszym razie dobry kod powie dokładnie, co się dzieje. Jednak nie daje żadnych wskazówek, dlaczego coś robi, a nawet jeśli jest to poprawne. Skomentuj swój kod, aby jego przyszły opiekun nie musiał zgadywać, dlaczego robisz foo, ale nie bar .
user369450,
13
Nie zgadzam się z twoim pierwszym akapitem. Dokumentowanie kodu (na przykład z komentarzami) jest co najmniej tak samo ważne, jak na studiach. Różnica polega na tym, że żaden profesjonalista nie skomentuje tego, co robi linia - udokumentuje DLACZEGO. To, co się dzieje, można odczytać z kodu źródłowego. Dlaczego często jest wynikiem kilku minut do godzin myślenia.
Araho
1
Istnieje bardzo niewiele powodów, aby napisać, dlaczego kod coś robi, i większość czasu można to wyjaśnić lepszą nazwą metody. Spójrzmy prawdzie w oczy, większość kodu, który wszyscy piszemy, jest na tyle prosta, że ​​nie zasługuje na komentarze.
BgrWorker
1
Jak to znowu idzie? Kod jest zapisywany raz i czytany wiele razy. Napisz komentarze, a na dłuższą metę zaoszczędzisz czas. @BgrWorker Chyba zależy od osoby. Regularnie piszę algorytmy i myślę, że zasługują na komentarze (ostatnio symboliczny parser matematyczny ... zdecydowanie potrzebuje komentarzy)
person27
1
Myślę, że testy jednostkowe są znacznie cenniejsze niż komentarze. Zbyt często widziałem sytuacje, w których kod był aktualizowany, a komentarze nie miały już zastosowania. W tym przypadku nieaktualne komentarze utrudniają ustalenie, co się dzieje. Testy jednostkowe dokumentują zamiary oryginalnego programisty, a jeśli twój system CI przeprowadza testy jednostkowe podczas odprawy, jesteś zobowiązany do ich utrzymania.
bikeman868
2

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.

John Smith
źródło
Awaria zwykle również nie jest opcją.
1

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.

Gherman
źródło