Regu\u0142a DRY jest obok YAGNI, SOLID, czy KISS jednym z\nnajpopularniejszych akronim\u00f3w pisanych wielkimi literami, kt\u00f3re wyp\u0142yn\u0119\u0142y na\nspos\u00f3b w jaki staramy si\u0119 tworzy\u0107 oprogramowanie. Jest prosta, intuicyjna i\nprzyswajana przez programist\u00f3w na wczesnym etapie edukacji. Tyle, \u017ce zrodzona w\nzupe\u0142nie innych okoliczno\u015bciach, ni\u017c te z kt\u00f3rym dzi\u015b mamy do czynienia sta\u0142a\nsi\u0119 martwa. <\/p>\n\n\n\n
Jej truch\u0142o le\u017cy na \u015brodku sceny i zatruwa nas swoimi oparami.<\/p>\n\n\n\n
Prosty pomys\u0142<\/em><\/p>\n\n\n\n Nie jestem historykiem\nprogramowania i nie dysponuj\u0119 pewno\u015bci\u0105 co do genezy regu\u0142y DRY, ale wyobra\u017cam\nsobie, \u017ce powsta\u0142a w czasach programowania proceduralnego. W ka\u017cdym razie\nproceduralno\u015bci\u0105 pachnie, wr\u0119cz cuchnie.<\/p>\n\n\n\n Prosty to pomys\u0142. Banalnie\nprosty. Mamy sobie kod. Kod nale\u017cy organizowa\u0107 w procedury, czyli wycina\u0107 bloki\nkodu, kt\u00f3re s\u0105 u\u017cywane wielokrotnie. Je\u015bli w jakim\u015b bloku si\u0119 powtarzamy, to\ndzia\u0142amy \u017ale, powinni\u015bmy wydzieli\u0107 go i przekszta\u0142ci\u0107 w procedur\u0119.<\/p>\n\n\n\n Ci\u0105gle ma\u0142o<\/em><\/p>\n\n\n\n Od czasu programowania proceduralnego troch\u0119 si\u0119 pozmienia\u0142o. Przede wszystkim nast\u0105pi\u0142a wielka eksplozja paradygmatu obiektowego. Z\u0142o\u017cono\u015b\u0107 oprogramowania wzros\u0142a. Biznes mia\u0142 ju\u017c swoje systemy automatyzuj\u0105ce ksi\u0119gowo\u015b\u0107, sumuj\u0105ce przychody, generuj\u0105ce raporty. Trzeba by\u0142o pisa\u0107 przegl\u0105darki internetowe, komunikatory, systemy tradingowe dla gie\u0142d i snake\u2019a na 3310. Poza ostatnim \u2013 by\u0142y to coraz wi\u0119ksze wyzwania.<\/p>\n\n\n\n Tyle tylko, \u017ce regu\u0142a DRY pasuje do programowania obiektowego jakby mniej. W zasadzie w og\u00f3le nie pasuje, jak si\u0119 dobrze zastanowi\u0107.<\/p>\n\n\n\n Co si\u0119 dzieje, gdy pr\u00f3bujemy w obiektowym kodzie unika\u0107 powtarzania si\u0119? Pierwsze co przychodzi do g\u0142owy to dziedziczenie: pi\u0119kny akademicki koncept, kt\u00f3ry za\u0142ama\u0142 si\u0119 pod ci\u0119\u017carem rzeczywisto\u015bci. Pies si\u0119 wabi, kot ma imi\u0119, zr\u00f3bmy klas\u0119 zwierz\u0119. Zrobili\u015bmy. Szybko okazuje si\u0119, \u017ce pies si\u0119 wabi, ale jednak imiona ma inne ni\u017c kot, \u017ce wabi si\u0119, ale kot jako\u015b gorzej reaguje na w\u0142asne imi\u0119, \u017ce zwierz\u0119 ma imi\u0119, ale nie do ko\u0144ca, bo tylko zwierz\u0119 domowe. Robimy klas\u0119 zwierz\u0119 domowe i dzikie. O cholera \u2013 przecie\u017c prawie nikt nie nazywa swoich rybek.<\/p>\n\n\n\n Drugie popularne rozwi\u0105zanie to \u017cartobliwa oznaka senior developera. Co robi senior developer, gdy przychodzi do chaotycznego projektu? Tworzy folder utils. <\/p>\n\n\n\n Klasy gromadz\u0105ce wsp\u00f3lne, niepasuj\u0105ce nigdzie indziej kawa\u0142ki kodu znajduj\u0105 si\u0119 obecnie w wi\u0119kszo\u015bci projekt\u00f3w. W niekt\u00f3rych z nich widzia\u0142em nawet rozros\u0142e do 8-16 tysi\u0119cy linijek \u201ecommony\u201d. Tych polip\u00f3w da si\u0119 unikn\u0105\u0107 i tak naprawd\u0119 powinny zosta\u0107 rozmasowane z g\u0142ow\u0105 na r\u00f3\u017cne fragmenty projektu, ale ich g\u0142\u00f3wnym \u017ar\u00f3d\u0142em jest pr\u00f3ba stosowania regu\u0142y DRY \u2013 wydzielenia gdzie\u015b, gdziekolwiek, bo tak naj\u0142atwiej, kodu, kt\u00f3ry si\u0119 powtarza.<\/p>\n\n\n\n Mikroserwisy \u2013\ngw\u00f3\u017ad\u017a do trumny<\/em><\/p>\n\n\n\n Kiedy zapyta\u0142em kolegi, kt\u00f3ry odszed\u0142 z Amazona – firmy, kt\u00f3ra traktowana jest jako modelowa i pionierska, je\u015bli chodzi o stosowanie architektury mikroserwis\u00f3w \u2013 jak organizuj\u0105 cz\u0119\u015bci wsp\u00f3lne, sk\u0105d wiedz\u0105, \u017ce inny zesp\u00f3\u0142 nie napisa\u0142 ju\u017c czego\u015b podobnego, odpar\u0142:<\/p>\n\n\n\n Nie szukamy. Piszemy swoje rozwi\u0105zanie. Przy tej skali jest to ta\u0144sze i szybsze.<\/em><\/p><\/blockquote>\n\n\n\n Skala, ogrom system\u00f3w, z jakimi przychodzi nam si\u0119 dzisiaj mierzy\u0107 sprawia, \u017ce konieczne staje si\u0119 dzielenie ich na mniejsze. W zasadzie od zawsze by\u0142o to jedn\u0105 z podstaw programowania, ale w architekturze mikroserwis\u00f3w oraz komponentowym podej\u015bciu do aplikacji webowych (Angular, React) trend ten uwyra\u017ania si\u0119 i przybiera na sile.<\/p>\n\n\n\n I w gruncie rzeczy jest to du\u017co bardziej obiektowe oraz zgodne z natur\u0105, ni\u017c dziedziczenie. Organizmy s\u0105 do siebie podobne, ale ci\u0119\u017cko powiedzie\u0107, \u017ceby by\u0142y takie same. Oko cz\u0142owieka nie jest tym samym okiem, co oko psa, czy soko\u0142a. Tylko z pozoru i powierzchownie mo\u017cna zak\u0142ada\u0107, \u017ce jest mo\u017cliwe wsp\u00f3\u0142dzielenie. Nie jestem ekspertem z dziedziny genetyki, ale nie wydaje mi si\u0119, \u017ce gdyby wyci\u0105\u0107 z cz\u0142owieka fragmenty DNA, kt\u00f3rych nie wsp\u00f3\u0142dzieli z ma\u0142p\u0105 sta\u0142by si\u0119 automatycznie orangutanem. Silne jest we mnie podejrzenie, \u017ce cho\u0107 wiele w tym podobie\u0144stw, czy identycznych fragment\u00f3w kodu, to jednak subtelno\u015bci, kilka \u201elinijek\u201d r\u00f3\u017cnicy sprawia, \u017ce dziedziczenie trzeba wzi\u0105\u0107 w du\u017cy, znacz\u0105cy cudzys\u0142\u00f3w.<\/p>\n\n\n\n Jak \u017cy\u0107?<\/em><\/p>\n\n\n\n Wygl\u0105da na to, \u017ce regu\u0142a DRY dobrymi intencjami wybrukowa\u0142a nam piekie\u0142ko. Czy czas j\u0105 odrzuci\u0107? By\u0107 mo\u017ce. Na pewno warto j\u0105 jednak przemy\u015ble\u0107. Warto pami\u0119ta\u0107, \u017ce w wielu scenariuszach nie powinna by\u0107 dla nas rekomendacj\u0105, \u017ce nie jest uniwersalnym narz\u0119dziem. Powtarzalno\u015b\u0107 kodu mo\u017ce sygnalizowa\u0107 problemy, a r\u00f3wnie dobrze mo\u017ce by\u0107 najlepszym mo\u017cliwym rozwi\u0105zaniem. <\/p>\n\n\n\n Czy dwukrotne powt\u00f3rzenie identycznego kodu jest z\u0142e? Je\u015bli w tej samej klasie, pewnie jest. Je\u015bli w tym samym module, by\u0107 mo\u017ce. A je\u015bli w projekcie sk\u0142adaj\u0105cym si\u0119 ze 100 000 linii kodu, w odleg\u0142ych od siebie modu\u0142ach? Chyba nie.<\/p>\n\n\n\n Czy cz\u0119\u015bciowe powt\u00f3rzenie kodu jest z\u0142e? C\u00f3\u017c, mo\u017ce nie jest z\u0142e arbitralnie, a zale\u017cy to od tego, czy da si\u0119 zbudowa\u0107 odpowiedni\u0105 abstrakcj\u0119, kt\u00f3ra pozwoli tego unikn\u0105\u0107? Cz\u0119sto stosujemy pewne zasady ortodoksyjnie. Dobrze jest jednak zosta\u0107 centryst\u0105. Wybra\u0107 z\u0142oty \u015brodek. Regu\u0142y w programowaniu to zwykle zaledwie sugestie. Nie kierujmy si\u0119 nimi \u015blepo. <\/p>\n","protected":false},"excerpt":{"rendered":" Regu\u0142a DRY jest obok YAGNI, SOLID, czy KISS jednym z najpopularniejszych akronim\u00f3w pisanych wielkimi literami, kt\u00f3re wyp\u0142yn\u0119\u0142y na spos\u00f3b w jaki staramy si\u0119 tworzy\u0107 oprogramowanie. Jest prosta, intuicyjna i przyswajana przez programist\u00f3w na wczesnym etapie edukacji. Tyle, \u017ce zrodzona w zupe\u0142nie innych okoliczno\u015bciach, ni\u017c te z kt\u00f3rym dzi\u015b mamy do czynienia sta\u0142a si\u0119 martwa. <\/p>\n","protected":false},"author":1,"featured_media":316,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[204,7],"tags":[14],"_links":{"self":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/283"}],"collection":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/comments?post=283"}],"version-history":[{"count":7,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/283\/revisions"}],"predecessor-version":[{"id":696,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/posts\/283\/revisions\/696"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media\/316"}],"wp:attachment":[{"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/media?parent=283"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/categories?post=283"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kalkus.dev\/blog\/wp-json\/wp\/v2\/tags?post=283"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}