Proste jest piękne. Proste jest łatwe. 🙂
Prostota – to słowo, które każdy programista powinien wbić sobie do głowy i pamiętać o nim zawsze, gdy implementuje rozwiązanie jakiegoś problemu.
Niestety, nie jest łatwo. Mnogość technologii, frameworków, technik programowania jest tak duża, że niemal każde zadanie można rozwiązać na wiele różnych, mniej lub bardziej, skomplikowanych sposobów. Czasami można poczuć się jak ten osiołek z wierszyka Aleksandra Fredry – „ta technologia jest super modna teraz, ale ta druga ma więcej możliwości dostosowywania”. Ile razy stajecie przed takim wyborem, niezależnie czy programujecie w Javie, .NET, czy może w Haskell’u?
Okazuje się jednak, że zasada jest prosta: „Keep it simple stupid” (lub „Keep it simple, stupid”. 😉 ). Proste rozwiązania są łatwiejsze w implementacji, gdyż nie wymagają od nas skupienia się na wielu pobocznych wątkach naszego rozwiązania, a właśnie na samym clue naszego problemu. Więcej czasu poświęcimy na podstawową funkcjonalność i będzie ona zrobiona lepiej.
Dodatkowo, im bardziej skomplikowane rozwiązanie, tym więcej możliwości popełnienia błędów. Przykładowo jeśli implementujemy uwierzytelnianie w naszej aplikacji, nie twórzmy wielkiej liczby parametrów jakie mogą być wymagane przy tym procesie. Trafiłem kiedyś na stronę, gdzie podczas uwierzytelniania można było wybrać w jakiej roli chcemy się zalogować (jeszcze przed wysłaniem samego żądania zalogowania). Okazało się, że wybierając odpowiednią rolę i podając tylko numer użytkownika bez hasła, aplikacja logowała Cię na wskazanego użytkownika. Zaglądając do kodu można było znaleźć nieprzebrane stado if-ów, które „kontrolowały” kto, kiedy i jak się może zalogować. Oczywiście jeden z warunków przepuszczał pewien konkretny przypadek co generowało krytyczną podatność w aplikacji. Podobne problemy może powodować nadmierne skomplikowanie modelu obiektowego, gdzie nadmierny polimorfizm, czy dziedziczenie mogą nieoczekiwanie stworzyć obiekt, który ma większe uprawnienia, niż w rzeczywistości byśmy chcieli.
Dzięki prostocie rozwiązań, pomagamy tym, którzy nasz kod będą utrzymywać. Jako programista pracowałem zarówno w zespołach, które tworzyły oprogramowanie, jak i w takich, które pracowały z kodem odziedziczonym (legacy code) jako support. Nie ma nic gorszego, niż jakieś wyszukane rozwiązanie lub architektura, które musisz zrozumieć, aby dodać na formularzu jedno pole edycji. Tracisz masę czasu na rozpoznananie, a który mógłbyś spożytkować na rozwiązywanie kolejnych ticketów. Co więcej, nawet jeśli już wydaje nam się, że już wiemy co i jak działa, i zaimplementujemy wymaganą zmianę, to może okazać się, że nie wzięliśmy pod uwagę jakiegoś warunku i zrobiliśmy buga. Jest jedna fajna zasada, której zalecam się trzymać: „Pisz kod tak, jakbyś to Ty miał go utrzymywać” (albo „Nie rób drugiemu co Tobie niemiłe ‚ 😉 ). Pamiętajmy, że jeśli coś zrobimy źle, to może to do nas wrócić, a zgodnie z prawem Murphy’ego jeżeli coś się może wydarzyć, to się na pewno wydarzy.
Na koniec kilka ogólnych zaleceń w związku z zasadą „KISS”:
- wykorzystuj proste algorytmy
- stosuj zasadę dekompozycji i abstrakcji w rozbijaniu zadań na podzadania
- nie optymalizuj na początku: „Done is better than perfect” 😉
- unikaj parametryzacji, buduj rozwiązania dedykowane dla danego przypadku
- stosuj techniki programowania obiektowego z umiarem