- Wejście w technologie konteneryzacji wymaga sporej zmiany w postrzeganiu deploymentu - trzeba zacząć "myśleć kontenerami".
-Przede wszystkim należy poczuć różnicę pomiędzy kontenerami, a maszynami wirtualnymi - kontenery są tylko (i aż) wyizolowanymi procesami na systemie hosta, a nie emulacją pełnego środowiska. Powinny być lekkie, efemeryczne i robić jedną, dobrze sprecyzowaną rzecz.
- Jedną z większych zalet obrazów dockerowych jest przenaszalność pomiędzy środowiskami. Budowanie obrazów per środowisko ignoruje tę właściwość i prowadzi do zaprzeczenia zasady odtwarzalności - nie mamy pewności, że pomiędzy środowiskami testujemy to samo oprogramowanie.
- Lista anty-patternów jest oczywiście dłuższa. Warto się zapoznać.
The reduce ({...spread}) anti-pattern
- Sedno sprawy jest takie, że operator spread w JSie wykonuje pod spodem iterację, co w pewnych warunkach wprowadza spory narzut wydajnościowy.
- Na pierwszy rzut oka autor opisuje jeden bardzo konkretny przypadek - iterację w operatorze spread w kontekście operacji reduce. Robi to jednak na tyle dobrze, że warto się w niego zgłębić ponad samo sedno sprawy - wchodzi w szczegóły implementacji silników JS, podchodzi do tematu od strony badania złożoności obliczeniowej, porównania wydajności równoważnych funkcjonalnie rozwiązań, skończywszy na nieco ogólniejszych rozważaniach nt. premature optimization oraz programowania funkcyjnego.
- Wychodzi z tego pozornie oczywisty wniosek - unikając premature optimizations, można wpakować się w premature de-optimization.
- O ile z samym przykładem można dyskutować (odnośnie: czytelność kodu vs analiza złożoności dla problemów o znanym pomijalnym rozmiarze), o tyle metodologia i pragmatyzm autora zasługują na szacunek! Czapki z głów!
