English version

Dobry kod to krótki kod. To znaczy, jeśli możemy zaimplementować tą samą funkcjonalność w 100 liniach kodu, albo w 500, to wersja 100 linii będzie lepsza. Głównie dlatego, że krótsza = zawierająca mniej elementów = mniej złożona = prostsza do zrozumienia. A sytuacja, gdy programista nie wie co się dzieje w kodzie nie jest fajna. No i mniej kodu to mniejsza szansa na buga.

Ale niektórzy stosują podejście, które tylko pozornie zmniejsza ilość kodu.

Biblioteki

Jeśli zamiast napisać fragment kodu samodzielnie użyjesz biblioteki, masz mniej swojego kodu. Jednak kod wewnątrz biblioteki, to też jest kod, i uruchamia się on tak samo, jak kod napisany przez ciebie osobiście. Co więcej, tworząc publicznie dostępną bibliotekę autor musi dostosować ją do wielu różnych przypadków użycia i zaimplementować wiele funkcjonalności, których ty nie potrzebujesz.

Nie zrozumcie mnie źle, nie twierdzę, że używanie w kodzie zewnętrznych jest złe. Bardziej chodzi mi o sytuację, gdy mam działającą funkcję o długości 20-30 linijek, a inny developer każe mi ją skasować, a zamiast niej załadować zewnętrzną bibliotekę.

Ale biblioteka z dużym community ma mniejsze szanse, że w środku będzie bug.

Tak, ale za to pojawia się ryzyko, że biblioteka będzie robić coś, czego nie jesteś świadomy i to może doprowadzić do błędu.

Brałem udział kiedyś w jednym projekcie z użyciem JQuery. Czasami zdążała się taka sytuacja, że kliknięcie w jakiś przycisk wywoływało Exception wewnątrz samego jQuery, ale po odświeżeniu F5 problem znikał. Dużo czasu poświęciłem na znalezienie przyczyny.

Okazało się, że w innym widoku dodawałem event listener, ale zamiast metody handlera ustawiałem undefined. JQuery nie robił problemów z ustawieniem takiego listenera, ale rzucał exceptiona przy próbie obsłużenia, nawet jeśli byłem już na innym widoku i tamten event nie był mi potrzebny.

Ale biblioteka będzie lepiej napisana

Może tak, może nie. Trzeba pamiętać, że nie tylko senior ninja developerzy wrzucają projekty na githuba, więc to, że tam coś jest, nie znaczy od razu, że będzie lepsze.

Druga sprawa, że głównym celem tworzenia software jest by działał i robił to, co ma robić. To czy jest dobrze napisane jest tylko środkiem do osiągniecia celu, a nie celem samym w sobie.

Mikroserwisy

Osobiście jestem zdania, że mikroserwisy to architektura tylko dla najbardziej doświadczonych. Ja, mając ponad 5 lat doświadczenia komercyjnego, ciągle czuję się za mały do mikroserwisów.

Pokusą do użycia mikroserwisów może być, że zamiast dużego monolitu w którym jest dużo kodu, masz małe projekciki, które są krótkie i proste do zrozumienia. Problem polega na tym, że jeden mikroserwis to nie jest cały program. Co z tego, że będą oddzielone, na różnych serwerach, może w różnych językach programowania. Dopiero zbiór różnych serwisów tworzy coś użytecznego.

Za to dochodzi ci logika związana z komunikacją. Wysłanie requestu do innego serwisu będzie zawsze bardziej skomplikowane, niż zwykłe wywołanie metody w innej klasie.

Nie jestem przeciwnikiem mikroserwisów, ale jeśli chcesz je zastosować, powinieneś mieć lepszy powód. Jeśli chcesz tylko zachować porządek w kodzie, to podziel go sobie na klasy, namespace, może wydziel do osobnych bibliotek, ale uruchamiaj w ramach jednego procesu.