Perspektywa, którą masz, może być wypaczona przez osobiste doświadczenie. Jest to śliskie zbocze faktów, które są indywidualnie poprawne, ale wynikowe wnioskowanie nie jest, nawet jeśli na pierwszy rzut oka wydaje się poprawne.
- Ramy mają większy zakres niż małe projekty.
- Zła praktyka jest znacznie trudniejsza do rozwiązania w większych bazach kodów.
- Budowanie frameworka (średnio) wymaga bardziej wykwalifikowanego programisty niż budowanie małego projektu.
- Lepsi programiści stosują więcej dobrych praktyk (SOLID).
- W rezultacie ramy mają większą potrzebę dobrych praktyk i zwykle są budowane przez programistów, którzy są bardziej doświadczeni w dobrych praktykach.
Oznacza to, że podczas interakcji z frameworkami i mniejszymi bibliotekami kod dobrej praktyki, z którym będziesz wchodzić w interakcje, będzie częściej znajdowany w większych frameworkach.
Ten błąd jest bardzo powszechny, np. Każdy lekarz, u którego byłem leczony, był arogancki. Dlatego dochodzę do wniosku, że wszyscy lekarze są aroganccy. Te błędy zawsze cierpią z powodu wyciągania wniosków na podstawie osobistych doświadczeń.
W twoim przypadku możliwe jest, że przeszedłeś dobrą praktykę w większych środowiskach, a nie w mniejszych bibliotekach. Twoje osobiste obserwacje nie są złe, ale są to niepotwierdzone dowody i nie mają uniwersalnego zastosowania.
2 tryby programowania - tworzenie mniej więcej dokładnie tego, co jest zadawane za pomocą wymagań i KISS (typowe programowanie), lub tworzenie bardzo ogólnej i wielokrotnego użytku logiki, usług itp., Które zapewniają elastyczność, jakiej mogą potrzebować inni programiści (programowanie w ramach frameworka)
Trochę to potwierdzasz. Pomyśl o tym, czym jest framework. To nie jest aplikacja. Jest to uogólniony „szablon”, którego inni mogą używać do tworzenia wszelkiego rodzaju aplikacji. Logicznie oznacza to, że struktura jest zbudowana w znacznie bardziej abstrakcyjnej logice, aby wszyscy mogli z niej korzystać.
Konstruktorzy frameworków nie są w stanie korzystać ze skrótów, ponieważ nawet nie wiedzą, jakie są wymagania kolejnych aplikacji. Zbudowanie frameworku z natury zachęca ich do używania kodu dla innych.
Twórcy aplikacji mają jednak możliwość kompromisu w zakresie wydajności logicznej, ponieważ koncentrują się na dostarczaniu produktu. Ich głównym celem nie jest działanie kodu, ale raczej doświadczenie użytkownika.
W przypadku frameworka końcowym użytkownikiem jest inny programista, który będzie wchodził w interakcje z Twoim kodem. Jakość kodu ma znaczenie dla użytkownika końcowego.
W przypadku aplikacji użytkownik końcowy nie jest programistą, który nie będzie wchodził w interakcje z Twoim kodem. Jakość twojego kodu nie ma dla nich znaczenia.
Właśnie dlatego architekci zespołu programistycznego często pełnią rolę strażników dobrych praktyk. Są o jeden krok od dostarczenia produktu, co oznacza, że mają tendencję do obiektywnego patrzenia na kod, zamiast skupiania się na dostarczaniu samej aplikacji.
Jeśli dodasz te punkty wejścia do abstrakcji, czy naprawdę spełniasz wymagania użytkowników, czy tworzysz strukturę na podstawie istniejącej struktury i stosu technologicznego, aby ułatwić przyszłe dodawanie? W którym przypadku służysz interesom klienta lub programisty?
Jest to interesujący punkt i jest (z mojego doświadczenia) głównym powodem, dla którego ludzie nadal próbują uzasadnić unikanie dobrych praktyk.
Podsumowując poniższe punkty: Pominięcie dobrej praktyki może być uzasadnione tylko wtedy, gdy twoje wymagania (jak obecnie znane) są niezmienne i nigdy nie będzie żadnych zmian / dodatków do bazy kodu. Ostrzeżenie o spoilerze: rzadko się to zdarza.
Na przykład, gdy piszę 5-minutową aplikację konsoli do przetwarzania określonego pliku, nie stosuję dobrych praktyk. Ponieważ zamierzam korzystać z aplikacji tylko dzisiaj i nie będzie trzeba jej aktualizować w przyszłości (łatwiej byłoby napisać inną aplikację, gdybym jej potrzebował ponownie).
Załóżmy, że możesz tandetnie zbudować aplikację w 4 tygodnie i poprawnie ją zbudować w 6 tygodni. Na pierwszy rzut oka tandetne budowanie wydaje się lepsze. Klient otrzymuje aplikację szybciej, a firma musi poświęcać mniej czasu na płace programistów. Wygrana / wygrana, prawda?
Jest to jednak decyzja podjęta bez wybiegania w przyszłość. Z powodu jakości bazy kodu dokonanie poważnej zmiany w tandetnie zbudowanym zajmie 2 tygodnie, a wprowadzenie tych samych zmian w poprawnie zbudowanej zajmie 1 tydzień. W przyszłości może pojawić się wiele z tych zmian.
Co więcej, istnieje tendencja do nieoczekiwanych zmian, które wymagają więcej pracy, niż początkowo sądzono, w tandetnie zbudowanych bazach kodu, co prawdopodobnie skraca czas programowania do trzech tygodni zamiast dwóch.
A także tendencja do marnowania czasu na poszukiwanie błędów. Dzieje się tak często w projektach, w których rejestrowanie zostało zignorowane z powodu ograniczeń czasowych lub zwykłej niechęci do jego wdrożenia, ponieważ bezmyślnie pracujesz przy założeniu, że produkt końcowy będzie działał zgodnie z oczekiwaniami.
To nawet nie musi być poważną aktualizacją. U mojego obecnego pracodawcy widziałem kilka projektów, które zostały zbudowane szybko i brudno, a kiedy najmniejszy błąd / zmiana musiała zostać wykonana z powodu nieporozumienia w wymaganiach, które prowadziły do reakcji łańcuchowej z koniecznością refaktoryzacji moduł po module . Niektóre z tych projektów upadały (pozostawiając nie do utrzymania bałagan), zanim nawet wydali swoją pierwszą wersję.
Decyzje skrótowe (szybkie i nieprzyzwoite programowanie) są korzystne tylko wtedy, gdy można jednoznacznie zagwarantować, że wymagania są dokładnie poprawne i nigdy nie trzeba ich zmieniać. Z mojego doświadczenia nigdy nie spotkałem się z projektem, w którym to prawda.
Inwestowanie dodatkowego czasu w dobrą praktykę to inwestowanie w przyszłość. Przyszłe błędy i zmiany będą o wiele łatwiejsze, gdy istniejąca baza kodów będzie oparta na dobrych praktykach. Będzie już wypłacał dywidendy po wprowadzeniu tylko dwóch lub trzech zmian.