KISS oraz YAGNI

Oryginalny post: KISS and YAGNI

Autor: Jeff Atwood

Rico, gość odpowiedzialny za wydajność, pracujący w firmie Microsoft, porusza temat bliski i drogi mojemu sercu

Wątpię w to, aby z mojego artykułu znajdującego się na "Performance Tidbits", ktokolwiek wysnuł wniosek na temat tego, który producent ma przewagę w kwestii wydajności. Jeśli miałbym podsumować moją radę z tego bloga w kilku słowach, to byłoby to "nie używaj OOP w sposób, który nie jest konieczny."

To nie znaczy, aby porzucić funkcje wirtualne, dziedziczenie, czy inne możliwości współczenych języków programowania. Jest zupełnie odwrotnie. Nie tylko sprawiają one, że kod jest bardziej przejrzysty i łatwiejszy w utrzymaniu, ale również poprawiają jego wydajność. Niemniej jednak często bywa tak, że programiści piszą swój kod w sposób zawiły, kiedy to prostsze podejście byłoby równie łatwe w utrzymaniu i bardziej wydajne. Niezależnie od tego, którą programistyczną religię wyznajesz myślę, iż zgodzisz się z tym, że bardziej skomplikowane abstrakcje językowe niekoniecznie wpływają dobrze na architekturę -- raczej jest tak, iż każda bardziej wyrafinowana właściwość języka zaczyna z wynikiem ujemnym i musi jakoś zasłużyć sobie na to, aby tak nie było, poprzez dodanie przejrzystości, łatwości utrzymania, wydajności, itp.

Tak więc, kiedy mówię rzeczy typu "nie używaj delegatów, jeśli zwykły polimorfizm wystarczy", nie mam na myśli tego, abyś ich unikał, tylko to, abyś nie używał ich, jeśli są przesadą.

Nie używaj wyszukanych własności OOP tylko dlatego, że możesz. Wykorzystuj je, jeśli są one w stanie dać konkretny, możliwy do wykazania pożytek w kontekście problemu, który starasz się rozwiązać. Możesz się śmiać, ale tak jak Rico, często zauważam ten problem. Większość programistów nigdy nie stworzyło obiektu, którego by nie polubili. Myślę, iż powinno być na odwrót: każda z tych technik uważana jest za winną, dopóki przed sądem KISS nie zostanie udowodnione inaczej.

Sądzę, iż jako programiści, często jesteśmy zbyt optymistyczni w szacowaniu ogólności naszych rozwiązań, za czym idzie to, że tworzymy zawiłe frameworki OOP wokół rzeczy, które mogą nie być w stanie uzasadnić takiego stopnia skomplikowania. Aby zwalczać tę pokusę, sugeruję podążanie za doktryną YAGNI (You Aren't Gonna Need It [Nie będziesz tego potrzebował]). Twórz to, czego potrzebujesz wtedy, gdy tego potrzebujesz, agresywnie refaktoryzując w międzyczasie; nie trać zbyt wiele czasu na planowanie imponujących, nieznanych przyszłych scenariuszy. Dobre oprogramowanie potrafi wyewoluować w to, czym ostatecznie ma się stać.

Data publikacji oryginału: 21 października, 2004

2 komentarze:

godlark pisze...

Ja tam wolę polskie BUZI (Bez Udziwnień Zapisu, Idioto) ;)

khalas pisze...

Wydaje mi się, że życie programisty można podzielić na 3 etapy:
* etap 1 - siadam do klawiatury i koduję,
* etap 2 - chęć zaprojektowania wszystkiego do samego końca, zachłyśnięcie się wzorcami projektowymi, wspomniane nadużywanie mechanizmów OOP, na tym etapie często występuje "paraliż projektowy",
* etap 3 - złoty środek, co da się zaprojektować projektuje, co trzeba napisać szybko i nie ma sensu nad tym myśleć koduję od razu, oczywiście refaktoryzując wszystko w międzyczasie.

Szczęśliwy ten kto osiągną już etap 3 :)

Prześlij komentarz

Related Posts with Thumbnails