Czy istnieje termin nadmiernej komplikacji OOP?

Rok lub dwa lata temu zobaczyłem doskonały artykuł na temat OOP (Java), który pokazał postęp prostego konkretnego rejestratora dwóch lub trzech linii kodu oraz teoretyczne nadmierne procesy myślowe przez niedoświadczonego programistę, który w zasadzie powiedział: och, powinienem dodaj to na wypadek, gdybyśmy tego chcieli! Pod koniec artykułu ten prosty program rejestrujący był gigantycznym bałaganem śmieci, którego pierwotny twórca z trudem mógł zrozumieć ...

Czy istnieje wspólny termin dla tego rodzaju nadmiernej komplikacji? Ten artykuł (który, szczerze żałuję, że nie mogę znaleźć ponownie) doskonale pokazuje tę koncepcję w odosobnionym przypadku, ale natknąłem się na całe projekty, w których programiści zasadniczo zaprogramowali się w węzeł przez nadmierne użycie wzorców, ram, bibliotek i inne sprawy. Na swój sposób jest to tak samo złe (lub nawet gorsze) niż starsze aplikacje spaghetti VB6, które dziedziczymy w celu wymiany.

To, czego naprawdę szukam, to poruszenie tej kwestii podczas rozmowy kwalifikacyjnej. Chcę wiedzieć, czy ktoś jest świadomy tego, jak łatwo wpaść w to bez architektury / wstępnego planowania (i dostania upadku za to, czy wydaje się, że ma właściwą równowagę), ale tak naprawdę to nie jest coś Mogę znaleźć wiele informacji na temat.

Najczęściej słyszanym terminem opisującym takie projekty jest nadinżynieria . Pierwotne znaczenie tego słowa, jednak nie jest związane z rozwojem oprogramowania, jak i poza rozwoju oprogramowania to chyba nie ma takiego złego tonu.

Na bardziej ogólnym poziomie Joel Spolsky nadał projektantom, którzy nadmiernie komplikują projekty architektoniczne, nazwę „ astronauci architektury ”.

Jednak, szczególnie w przypadku wywiadu, myślę, że ważniejsze jest, aby wiedzieć, jak nazywa się coś przeciwnego, umieszczając tylko rzeczy w projekcie, które są rzeczywiście potrzebne i zapomnieć o niezdrowym podejściu „na wszelki wypadek” - nazywa się to zasadą YAGNI .

Tak, nadinżynieria to najprostszy termin na opisanie tego. Widziałem przerobione, niepotrzebnie skomplikowane projekty więcej razy, niż pamiętam na przestrzeni lat. Wiele lat temu, biorąc udział w kursie Microsoft GWBasic, instruktor wielokrotnie doskonalił metodę KISS (Keep it Simple Stupid). Jest to dzisiaj tak samo prawdziwe jak wtedy.

Dlatego zawsze pamiętam KISS i zawsze projektuję z myślą o SOLID Principles . Biorąc to jednak pod uwagę, nadal można nadpisać projekt z pełnym uwzględnieniem zasad SOLID. Musisz pogodzić zdrowy rozsądek, pragmatyczne podejście z pragnieniem bycia czystym i przestrzegania ogólnie przyjętych wytycznych OOP. Jeśli masz wystarczająco dużo czasu i jeśli lubisz tworzyć skomplikowane rozwiązania, możesz skończyć na drodze do zaprojektowania silnika do deskorolki, ponieważ myślałeś, że ostatecznie zostanie przekształcony w samochód. Na szczęście przez lata byłem wystarczająco zdyscyplinowany, aby tego nie robić, ale widziałem to wiele razy.

Podsumowując, aby zapobiec nadmiernej komplikacji kodu:

1) KISS (Keep it Simple Stupid)

2) Przestrzegaj zasad SOLID, mając na uwadze praktyczność.

3) Nie próbuj projektować na każdą ewentualność. A czasem małe, nieszczelne abstrakcje nie są okropnymi rzeczami, jeśli są odizolowane, celowe i jeśli wysiłek, aby im zapobiec, znacznie przewyższa skutki ich utrzymania.

4) Rozważ wdrożenie rozwiązań podczas ich projektowania. Nie możesz po prostu powiedzieć „och, to szczegół implementacji” i założyć, że Twój projekt jest praktyczny. Pracowałem z architektem, który często to robił i, niestety, jego projekty nigdy nie działały, w wyniku czego już tam nie pracuję.

5) Koduj tak, jakbyś go utrzymywał.

Więc masz zamiar przeprowadzić ten wywiad i masz zamiar oszukać kandydata, aby pokazał, co wie o inżynierii oprogramowania, a następnie powiesz: „Nie, prawdopodobnie chcesz zastosować wszystko, co wiesz na pierwszym zadaniu, idź teraz , ty pozłacanie nadmiernie inżynieryjny twórcy wartości niemających charakteru biznesowego! Shoo! "

Myślę, że bezpieczniej byłoby przedstawić konkretny przykład i omówić zalety i wady stosowania pewnych wzorów. Należałoby wtedy poprosić o odpowiedzi typu „To zależy, czy chcesz tego szybko? Czy to wszystko? Jak skomplikowany jest problem? Jakie wzorce już istnieją?” i możesz się czegoś nauczyć. Pozwoliłoby to również kandydatowi udowodnić swoje poczucie kontekstu, podczas gdy byłoby to pytanie bardziej otwarte. Oczekiwanie na konkretną odpowiedź i oczekiwanie na nią w najlepszym wypadku sprawi, że będziesz miał taką samą troskę jak twoja. Jeśli nie dostaniesz odpowiedzi, być może kandydat uważa ją za oczywistą.