{"id":195,"date":"2018-02-09T18:00:30","date_gmt":"2018-02-09T17:00:30","guid":{"rendered":"https:\/\/brozanski.net\/?p=195"},"modified":"2018-02-09T14:43:02","modified_gmt":"2018-02-09T13:43:02","slug":"kiss-prostota-droga-do-sukcesu","status":"publish","type":"post","link":"https:\/\/brozanski.net\/index.php\/2018\/02\/09\/kiss-prostota-droga-do-sukcesu\/","title":{"rendered":"KISS &#8211; prostota drog\u0105 do sukcesu"},"content":{"rendered":"<p>Proste jest pi\u0119kne. Proste jest \u0142atwe. \ud83d\ude42<\/p>\n<p>Prostota &#8211; to s\u0142owo, kt\u00f3re ka\u017cdy programista powinien wbi\u0107 sobie do g\u0142owy i pami\u0119ta\u0107 o nim zawsze, gdy implementuje rozwi\u0105zanie jakiego\u015b problemu.<\/p>\n<p>Niestety, nie jest \u0142atwo. Mnogo\u015b\u0107 technologii, framework\u00f3w, technik programowania jest tak du\u017ca, \u017ce niemal ka\u017cde zadanie mo\u017cna rozwi\u0105za\u0107 na wiele r\u00f3\u017cnych, mniej lub bardziej, skomplikowanych sposob\u00f3w. Czasami mo\u017cna poczu\u0107 si\u0119 jak ten osio\u0142ek z wierszyka Aleksandra Fredry &#8211; &#8222;ta technologia jest super modna teraz, ale ta druga ma wi\u0119cej mo\u017cliwo\u015bci dostosowywania&#8221;. Ile razy stajecie przed takim wyborem, niezale\u017cnie czy programujecie w Javie, .NET, czy mo\u017ce w Haskell&#8217;u?<\/p>\n<p>Okazuje si\u0119 jednak, \u017ce zasada jest prosta: &#8222;Keep it simple stupid&#8221; (lub &#8222;Keep it simple, stupid&#8221;. \ud83d\ude09\u00a0 ). Proste rozwi\u0105zania s\u0105 \u0142atwiejsze w implementacji, gdy\u017c nie wymagaj\u0105 od nas skupienia si\u0119 na wielu\u00a0pobocznych w\u0105tkach naszego rozwi\u0105zania, a w\u0142a\u015bnie na samym clue naszego problemu. Wi\u0119cej czasu po\u015bwi\u0119cimy na podstawow\u0105 funkcjonalno\u015b\u0107 i b\u0119dzie ona zrobiona lepiej.<\/p>\n<p>Dodatkowo, im bardziej skomplikowane rozwi\u0105zanie, tym wi\u0119cej mo\u017cliwo\u015bci pope\u0142nienia b\u0142\u0119d\u00f3w. Przyk\u0142adowo je\u015bli implementujemy uwierzytelnianie w naszej aplikacji, nie tw\u00f3rzmy wielkiej liczby parametr\u00f3w jakie mog\u0105 by\u0107 wymagane przy tym procesie.\u00a0Trafi\u0142em kiedy\u015b na stron\u0119, gdzie podczas uwierzytelniania mo\u017cna by\u0142o wybra\u0107 w jakiej roli chcemy si\u0119 zalogowa\u0107 (jeszcze przed wys\u0142aniem samego \u017c\u0105dania zalogowania). Okaza\u0142o si\u0119, \u017ce wybieraj\u0105c odpowiedni\u0105 rol\u0119 i podaj\u0105c tylko numer u\u017cytkownika bez has\u0142a, aplikacja logowa\u0142a Ci\u0119 na wskazanego u\u017cytkownika. Zagl\u0105daj\u0105c do kodu mo\u017cna by\u0142o znale\u017a\u0107 nieprzebrane stado if-\u00f3w, kt\u00f3re &#8222;kontrolowa\u0142y&#8221; kto, kiedy i jak si\u0119 mo\u017ce zalogowa\u0107. Oczywi\u015bcie jeden z warunk\u00f3w przepuszcza\u0142 pewien konkretny przypadek co generowa\u0142o krytyczn\u0105 podatno\u015b\u0107 w aplikacji. Podobne problemy mo\u017ce powodowa\u0107 nadmierne skomplikowanie modelu obiektowego, gdzie nadmierny polimorfizm, czy dziedziczenie mog\u0105 nieoczekiwanie stworzy\u0107 obiekt, kt\u00f3ry ma wi\u0119ksze uprawnienia, ni\u017c w rzeczywisto\u015bci by\u015bmy chcieli.<\/p>\n<p>Dzi\u0119ki prostocie rozwi\u0105za\u0144, pomagamy tym, kt\u00f3rzy nasz kod b\u0119d\u0105 utrzymywa\u0107. Jako programista pracowa\u0142em zar\u00f3wno w zespo\u0142ach, kt\u00f3re tworzy\u0142y oprogramowanie, jak i w takich, kt\u00f3re pracowa\u0142y z kodem odziedziczonym (legacy code) jako support. Nie ma nic gorszego, ni\u017c jakie\u015b wyszukane rozwi\u0105zanie lub architektura, kt\u00f3re musisz zrozumie\u0107, aby doda\u0107 na formularzu jedno pole edycji. Tracisz mas\u0119 czasu na rozpoznananie, a kt\u00f3ry m\u00f3g\u0142by\u015b spo\u017cytkowa\u0107 na rozwi\u0105zywanie kolejnych ticket\u00f3w. Co wi\u0119cej, nawet je\u015bli ju\u017c wydaje nam si\u0119, \u017ce ju\u017c wiemy co i jak dzia\u0142a, i zaimplementujemy wymagan\u0105 zmian\u0119, to mo\u017ce okaza\u0107 si\u0119, \u017ce nie wzi\u0119li\u015bmy pod uwag\u0119 jakiego\u015b warunku i zrobili\u015bmy buga. Jest jedna fajna zasada, kt\u00f3rej zalecam si\u0119 trzyma\u0107: &#8222;Pisz kod tak, jakby\u015b to Ty mia\u0142 go utrzymywa\u0107&#8221; (albo &#8222;Nie r\u00f3b drugiemu co Tobie niemi\u0142e &#8217; \ud83d\ude09 ). Pami\u0119tajmy, \u017ce je\u015bli co\u015b zrobimy \u017ale, to mo\u017ce to do nas wr\u00f3ci\u0107, a zgodnie z prawem Murphy&#8217;ego je\u017celi co\u015b si\u0119 mo\u017ce wydarzy\u0107, to si\u0119 na pewno wydarzy.<\/p>\n<p>Na koniec kilka og\u00f3lnych zalece\u0144 w zwi\u0105zku z zasad\u0105 &#8222;KISS&#8221;:<\/p>\n<ul>\n<li>wykorzystuj proste algorytmy<\/li>\n<li>stosuj zasad\u0119 dekompozycji i abstrakcji w rozbijaniu zada\u0144 na podzadania<\/li>\n<li>nie optymalizuj na pocz\u0105tku: &#8222;Done is better than perfect&#8221; \ud83d\ude09<\/li>\n<li>unikaj parametryzacji, buduj rozwi\u0105zania dedykowane dla danego przypadku<\/li>\n<li>stosuj techniki programowania obiektowego z umiarem<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Proste jest pi\u0119kne. Proste jest \u0142atwe. \ud83d\ude42 Prostota &#8211; to s\u0142owo, kt\u00f3re ka\u017cdy programista powinien wbi\u0107 sobie do g\u0142owy i pami\u0119ta\u0107 o nim zawsze, gdy implementuje rozwi\u0105zanie jakiego\u015b problemu. Niestety, nie jest \u0142atwo. Mnogo\u015b\u0107 technologii, framework\u00f3w, technik programowania jest tak du\u017ca, \u017ce niemal ka\u017cde zadanie mo\u017cna rozwi\u0105za\u0107 na wiele r\u00f3\u017cnych, mniej lub bardziej, skomplikowanych sposob\u00f3w.\u2026 <span class=\"read-more\"><a href=\"https:\/\/brozanski.net\/index.php\/2018\/02\/09\/kiss-prostota-droga-do-sukcesu\/\">Read More &raquo;<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[26],"class_list":["post-195","post","type-post","status-publish","format-standard","hentry","category-security","tag-miroburn_challenge"],"_links":{"self":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts\/195","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/comments?post=195"}],"version-history":[{"count":1,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts\/195\/revisions"}],"predecessor-version":[{"id":196,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/posts\/195\/revisions\/196"}],"wp:attachment":[{"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/media?parent=195"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/categories?post=195"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brozanski.net\/index.php\/wp-json\/wp\/v2\/tags?post=195"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}