Czy istnieje termin nadmiernej komplikacji OOP?

18

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.

Jleach
źródło
25
Tak, nazywa się OOP.
ogrodnik

Odpowiedzi:

28

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 .

Doktor Brown
źródło
Dzięki. Jestem wielkim zwolennikiem YAGNI, nie byłem pewien, czy istnieje coś wspólnego.
jleach
Chciałbym podkreślić, że yagni dotyczy „tego, co jest obecnie potrzebne”. Nadal powinieneś pomijać rzeczy, nawet jeśli wiadomo, że będą potrzebne później, o ile nie jest to potrzebne w tej chwili.
Wygięty
7
@ Bent Chciałbym również podkreślić, że nie oznacza to całkowitego ignorowania rzeczy / zmian, o których wiesz, że na pewno nastąpią w funkcji bliskiej ... wiedza o tym, jak oprogramowanie zostanie rozszerzone po, może pomóc ci napisać kod, który będzie bardziej łatwo refaktoryzowalne wzdłuż osi zmiany.
Bakuriu
Używam terminu „słaba inżynieria” w przeciwieństwie do „nadmiernej inżynierii”. Pracowałem z ludźmi, którzy uwielbiają dodawać wszelkiego rodzaju funkcje i rozszerzenia „na wszelki wypadek”, które nie mają jasnych przypadków użycia. Jeśli nie rozumiesz problemu, który próbujesz rozwiązać, jest to po prostu słaba inżynieria.
Josh Johnson
4

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

David Spenard
źródło
-3

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

Martin Maat
źródło
4
Przepraszam, ale tak naprawdę zastanawiałem się, czy istnieje na to termin. Nie szukałem porady, jak przeprowadzić wywiad (lub aby moje pytanie było postrzegane w jakikolwiek sposób, jak przeprowadziłbym wywiad). Dziękuję za troskę ...
jleach
1
Cóż, napisałeś ostatni akapit w swoim pytaniu, które trudno zignorować i dość stwierdzenie. Jeśli nie doceniasz opinii na temat niektórych części tekstu, możesz chcieć być bardziej restrykcyjny w swoich wypowiedziach.
Martin Maat,