Dostosuj preferencje dotyczące zgody

Używamy plików cookie, aby pomóc użytkownikom w sprawnej nawigacji i wykonywaniu określonych funkcji. Szczegółowe informacje na temat wszystkich plików cookie odpowiadających poszczególnym kategoriom zgody znajdują się poniżej.

Pliki cookie sklasyfikowane jako „niezbędne” są przechowywane w przeglądarce użytkownika, ponieważ są niezbędne do włączenia podstawowych funkcji witryny.... 

Zawsze aktywne

Niezbędne pliki cookie mają kluczowe znaczenie dla podstawowych funkcji witryny i witryna nie będzie działać w zamierzony sposób bez nich.Te pliki cookie nie przechowują żadnych danych umożliwiających identyfikację osoby.

Funkcjonalne pliki cookie pomagają wykonywać pewne funkcje, takie jak udostępnianie zawartości witryny na platformach mediów społecznościowych, zbieranie informacji zwrotnych i inne funkcje stron trzecich.

Brak plików cookie do wyświetlenia.

Analityczne pliki cookie służą do zrozumienia, w jaki sposób użytkownicy wchodzą w interakcję z witryną. Te pliki cookie pomagają dostarczać informacje o metrykach liczby odwiedzających, współczynniku odrzuceń, źródle ruchu itp.

Wydajnościowe pliki cookie służą do zrozumienia i analizy kluczowych wskaźników wydajności witryny, co pomaga zapewnić lepsze wrażenia użytkownika dla odwiedzających.

Brak plików cookie do wyświetlenia.

Reklamowe pliki cookie służą do dostarczania użytkownikom spersonalizowanych reklam w oparciu o strony, które odwiedzili wcześniej, oraz do analizowania skuteczności kampanii reklamowej.

Brak plików cookie do wyświetlenia.

Kod, który działa to za mało

Zawartość

Kod, który działa to za mało

      Kod, który działa to za mało, czyli o kosztach bylejakości w projektach Vue/Nuxt

      Wielu juniorów (i niestety nie tylko) wychodzi z założenia, że “skoro działa, to jest dobrze”. Problem w tym, że aplikacje frontendowe, zwłaszcza te pisane w Vue czy Nuxt, bardzo szybko rosną. A z nimi rośnie również dług technologiczny.

      Brak dbałości o jakość kodu na początku może nie boleć. Ale kiedy produkt dojrzewa, zamiast dostarczać nowe funkcjonalności, zespół grzęźnie w refaktoryzacji, gaszeniu pożarów i walce z zależnościami.

      Komponenty nie są śmietnikiem

      Dobry komponent to taki, który robi jedną rzecz. I robi ją dobrze.

      Przykład złego podejścia

      <!-- ProductList.vue -->
      
      <template>
      	<div>
      		<input v-model="search" />
      		<ul>
      			<li v-for="product in filteredProducts" :key="product.id">
      				
      			</li>
      		</ul>
      		<button @click="fetchProducts">Reload</button>
      	</div>
      </template>
      
      <script setup>
      import { ref, computed, onMounted } from 'vue'
      
      const search = ref('')
      const products = ref([])
      
      const filteredProducts = computed(() =>
      	products.value.filter(p => p.name.includes(search.value))
      )
      
      const fetchProducts = async () => {
      	const res = await fetch('/api/products')
      	products.value = await res.json()
      }
      
      onMounted(fetchProducts)
      </script>
      

      Ten komponent:

      • pobiera dane,
      • filtruje dane,
      • obsługuje UI.

      I robi to wszystko w jednym pliku. Trudno to testować. Trudno rozszerzać. Trudno zrozumieć komuś nowemu.

      Lepsze podejście (zasada S z SOLID – Single Responsibility Principle)

      useProducts.ts

      // composables/useProducts.ts
      import { ref, computed, onMounted } from 'vue'
      
      export function useProducts() {
        const search = ref('')
        const products = ref([])
      
        const filteredProducts = computed(() =>
          products.value.filter(p => p.name.includes(search.value))
        )
      
        const fetchProducts = async () => {
          const res = await fetch('/api/products')
          products.value = await res.json()
        }
      
        onMounted(fetchProducts)
      
        return {
          search,
          filteredProducts,
          fetchProducts,
        }
      }
      

      ProductList.vue

      <script setup>
      import { useProducts } from '@/composables/useProducts'
      
      const { search, filteredProducts, fetchProducts } = useProducts()
      </script>
      

      Rezultat? Komponent robi tylko to, co powinien, czyli wyświetla dane. Logika żyje osobno. Testowanie, refaktoryzacja i ponowne użycie są o wiele prostsze.

      Architektura komponentów i dobre praktyki

      Vue pozwala na szybką pracę, ale nie zwalnia z myślenia. Oto kilka zasad, które pomagają zachować porządek:

      • Smart vs Dumb components – logika w “smart” komponentach lub composables, a “dumb” komponenty tylko renderują dane na podstawie propsów.
      • Props + Events, nie zależności – komponenty nie powinny mieć wiedzy o innych komponentach. Komunikuj się przez propsy i emit.
      • Typowanie z głową (TypeScript) – lepiej poświęcić 3 minuty na dobre zdefiniowanie typu niż 30 na szukanie błędów runtime’owych.

      Code Review to nie formalność

      Jeśli code review sprowadza się do „działa? ok”, to można równie dobrze wrzucać kod przez FTP.

      Dobre review powinno:

      • sprawdzać czy kod jest czytelny (nawet jeśli działa),
      • zadawać pytania: „czy to można uprościć?”, „czy to się nie powiela?”,
      • wyłapywać wzorce anty-kodu zanim się utrwalą.

      Co daje czysty kod?

      • szybsze wdrażanie nowych osób,
      • mniej regresji,
      • więcej czasu na rozwój, mniej na naprawianie,
      • kod, którego się nie wstydzisz za miesiąc.

      Nie chodzi o perfekcję. Chodzi o intencję, żeby pisać kod, który nie tylko działa, ale który inni będą chcieli utrzymywać.