jako programiści często słyszymy banalne frazy rzucane wokół, takie jak „nie powtarzaj się”. Bierzemy takie pomysły i bierzemy z nimi, czasami trochę za daleko.

cofanie się i ocenianie, dlaczego robimy te rzeczy, jest pomocne. Dzisiaj przyjrzyjmy się alternatywnej ideologii dla suchego programowania.

DRY jest zdefiniowany (według Wikipedii) jako:

każda wiedza musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie.

niektóre z nich mogą stać się nieco pedantyczne, ale może to być pomocne przy rozważaniu czegoś takiego. Podzielmy części tego frazowania.

każdy kawałek

Co to jest „każdy kawałek”? Czy nie możemy nigdy powtórzyć nazwy zmiennej? Encja HTML?

Ok, ok. Więc możemy powtórzyć<div>’s bez większego problemu i myślę, że nikt się nie obrazi. Ale to rodzi pytanie-kiedy decydujemy, że coś stało się”kawałkiem wiedzy”? W Reakcie dobrym przykładem może być komponent – ale czy toPrimaryButton ISecondaryButton, czy też oznacza to uogólnioną klasęButton? Odpowiedź jest ogólnie uważana za „cokolwiek wybierze Twoja organizacja”, ale może to pozostawić sporo niejasności wokół tego, co wybieramy do abstrakcji.

wiedza

to kolejny niejednoznaczny punkt – co definiujemy jako wiedzę? Rozważ stylizowany element przycisku przy użyciu niektórych klas atomowych i reaguj. Jeśli tworzenie Senior dev zajmuje 10 sekund, mogą nie uznać tej wiedzy za wartą abstrakcji. Ale dla bardziej młodszego programisty, który nie zna dobrze systemu, ta wiedza może być dobrą abstrakcją. W przeciwnym razie będą musieli upolować klasy, przypomnieć sobie, jak działają przyciski i dowiedzieć się, jaka jest składnia dla onClick. Wiedza jest względna i użycie jej w definicji dodaje niejednoznaczności.

Update: Xander zostawił następujący komentarz poniżej. Myślę, że ten artykuł świetnie wyjaśnia, co „wiedza” powinna oznaczać.

Po prostu chciałem zostawić to tutaj dla ludzi, którzy są zainteresowani.

„suchy jest o wiedzy, powielanie kodu nie jest problemem.”
verraes.net/2014/08/dry-is-about-k…

pojedyncza, jednoznaczna, autorytatywna reprezentacja

„pojedyncza” reprezentacja pozostawia wiele do życzenia. Z punktu widzenia inżyniera devops pojedyncza reprezentacja może być całą aplikacją, którą musi wdrożyć. Dla programisty frontend, to może być komponent. A dla programisty backend, może to być metoda na klasie lub punkcie końcowym API. Gdzie jest rysowana linia?

mamy też słowo „jednoznaczne” – ale jak już wspomniałem, reszta tego zdania definiuje więcej niejednoznaczności. „Autorytatywny” ma sens – Twój suchy kod powinien dokładnie definiować to, co robi i być wierny tej definicji. Nie jest to jednak wyraźnie ograniczone do suchego kodu.

system

wreszcie mamy światowy „system” – to wraca do stwierdzenia „single”, o którym rozmawialiśmy przed chwilą. Co to jest „system”? W Reaccie może to być komponent lub Redux action / component / reducer. W oprogramowaniu kontenerowym możemy mówić o całym pod lub tylko jednej instancji.

pod koniec dnia wysusz wszystko, aby często promował wstępną optymalizację, która jest niepotrzebna, a czasami faktycznie szkodzi zdolności do pisania kodu. Czasami trudniej jest zmodyfikować abstrakcyjny komponent tak, aby pasował do konkretnego przypadku użycia. Dodajesz wiele złożoności lub rozkładasz ten komponent na coś nowego – co nie jest super suche. Nie możesz znać każdego przypadku użycia komponentu pierwszego dnia.

alternatywa-napisz wszystko dwa razy (mokre) programowanie

zamiast tego proponuję mokre programowanie. Dla mnie definicja byłaby następująca:

możesz zadać sobie pytanie ” czy nie pisałem tego wcześniej?”dwa razy, ale nigdy trzy.

Dzięki tej definicji fokus odchodzi od przedwczesnej optymalizacji i pozwala na powtórzenie podobnego kodu kilka razy. To również przesuwa nacisk na reakcję jelit. Pozwala na podejmowanie decyzji w oparciu o dokładny przypadek użycia, na który patrzysz. Jeśli budujesz aplikację internetową, prawdopodobnie chcesz streścić przyciski w komponencie, ponieważ będziesz ich używać wiele. Ale jeśli jest jedna strona, która ma specjalną stylizację(może strona z cenami?), wtedy nie musisz się zbytnio martwić o abstrakcję komponentów na tej stronie. W rzeczywistości w tym systemie, jeśli potrzebujesz nowej strony, która była podobna do tej specjalnej strony, możesz po prostu skopiować/wkleić I zmienić potrzebny kod. Jednak w chwili, gdy dzieje się to po raz trzeci, czas poświęcić trochę czasu na abstrakcję części, które mogą być abstrakcyjne.

dodałbym jeszcze ten warunek (zarówno do programowania mokrego, jak i suchego):